Get empowered with IBM Power
Someone linked me to some code for displaying Bad Apple on IBM i over a 5250 terminal. So of course I had to try it.
I got it working and made a screen recording of it: asciinema.org/a/537960
Credit to Luigi Elettrico for the code, found here: gitlab.com/luigi.elettric… #IBMi
– Kevin Adler (@kadlerio)21:12 – Nov 15, 2022
The Briteskies team has been working with the client, a furniture manufacturing and distribution company, for over a year providing RPG development and support.
At about 1:30pm, the Briteskies RPG developer received a text from the client that that the business system had gone down and could he log on to the system and try to help diagnose and fix the problem.
“I logged on and it looked like a hardware issue, but I wasn’t sure so I called for backup,” – Dale, Briteskies RPG Developer
As the company is likely migrating off the AS400 system in the coming years, they’ve been thinning their related staff and don’t currently have a dedicated System Administrator for the AS400 system. Due to their managed service contract with Briteskies, though the majority of consulting work they receive from Briteskies is related to RPG needs, the Briteskies developer was able to easily pull in a System Admin to help resolve the issue.
“The first thing I did was get everyone talking on a video conference call,” says the Briteskies System Admin. In cases where time and information are of the essence and multiple people are involved, real-time, in-person virtual conversations with shared screen capabilities cutdowns the possibility of confusion.
In the next ten minutes, the Briteskies team had created a virtual PC, set up a VPN, and was instructing an on-site employee with directions to find the Hardware Management Console and identify its IP address so that we could gain access.
The HMC was older and hadn’t been updated in a few years so modern web browsers had a hard time connecting to it. To get around this problem, the Briteskies team uninstalled the browser and installed an older version of Firefox. This allowed our tea to access the HMC web administration display and share it during the video teleconference.
Once in, it was determined that the server was running, but there was no way to get a console connection.
To access the console, Briteskies started a “normal” shutdown of the server. While IBM i consoles have immediate shutdown capability, Briteskies took the time (over 30 minutes in this instance) to shut it down normally so that any open databases were able to flush their cache and write the contents of memory out to disk, avoiding the potential to damage the databases.
Once the shutdown was complete, our team administered a manual startup and within 15 minutes had access to the server console and was entering credentials on the sign-on screen.
“I continued to share my screen and explained what I was doing and why I was doing it during each step of the process.”
With the shutdown and reboot complete, the system returned to normal function. But everyone wanted to make sure this problem wouldn’t happen again in the future.
The Briteskies System Admin checked the history log and determined that the client’s system had run out of temporary disk storage, causing the server to pause. The reboot had triggered the server to release all temporary storage, allowing it to return to normal function.
Thanks to Briteskies’ immediate attention, the system was back up and running in only two hours. What could have kept the business halted for days was found, diagnosed, and fixed before creating any larger chasms in the business.
With Managed Service contracts, clients can access the expertise of the full Briteskies team depending on their needs.
Just want to thank [Briteskies] for their help this afternoon. We had an outage and were completely down. [Briteskies] jumped on the issue with us and provided great expertise. Meaningful explanation was provided to our team and we learned from that experience. Thanks again for your help, truly appreciated”
Whether you need technical or functional help, Briteskies can help keep your IBM i system up and running.
How to Re-sync IDENTITY columns in DDL tables in IBM i DB2 (AS400)?
What happen to the next identity column value when table cleared using CLRPFM or SQL Delete?
Mainframe and midrange server are probably among the least understood terms in IT – due in part to the fact that folks don’t necessarily know what differentiates these types of systems from each other.
Unless you work with mainframes or midrange servers specifically, you probably just think of both as weird, old-fashioned types of infrastructure. You know they’re different from commodity, x86-based servers and PCs, but you don’t know what really defines a midrange server or a mainframe, or what makes them different from each other.
If that sounds like you, keep reading. Below, we explain what mainframes and midrange servers are, and offer some examples of each type of system.
A mainframe is a large (though not necessarily as large as you think) server that is designed for processing and storing massive amounts of data. Mainframes originated in the 1950’s and have been an important part of the computing landscape ever since.
Most mainframes today are manufactured by IBM (although that was not always the case). They run either z/OS, the native mainframe operating system, or a version of Linux designed for mainframes.
Despite common misperceptions about the decline of mainframes, mainframes continue to see widespread use across a range of industries.
Read our whitepaper
See how to offload, accelerate and lower cost of your mainframe to maximize its value
A midrange server, meanwhile, is a server whose processing power falls somewhere between that of a mainframe and that of a standard commodity server.
Midrange servers were originally intended to meet the needs of small and medium-sized businesses, which did not require the massive computing power of a mainframe but needed more power than commodity servers could supply. (Actually, for the first couple decades of their history, there was no such thing as a commodity server; x86 servers came into widespread use starting only in the later 1980’s.)
Although midrange servers operate using their own class of hardware, it is more helpful to define midrange servers in terms of the operating systems that run on them rather than the hardware that they are built with. IBM created the first midrange server operating, called System/3, in 1969, which gave rise to the concept of midrange servers.
Several new midrange operating systems followed until 1988, when IBM released its AS/400 server line and the OS/400 operating system for it. By the early-2000’s, IBM was callings its midrange servers System i, and the operating system for them IBM i.
You might hear IBM i (or iSeries, a closely related term) used today to refer to midrange server operating systems (you might even still hear people talk about AS/400). Technically, however, since 2008 IBM’s nomenclature for midrange servers has been Power Systems. That’s the more proper term to use today.
No matter what you call them, midrange servers continue to cater to smaller organizations that need significant computing power and availability, but don’t want to move their workloads to commodity servers or the cloud because of cost, performance or security concerns.
If you’ve read this far, you know that both midrange servers and mainframes offer higher availability and performance than commodity servers. But what makes them different from each other, apart from the fact that mainframes offer more performance?
Here’s a basic rundown of the differences between mainframes and midrange systems:
Mainframes have been around longer. As noted above, they originated in the late 1950’s, compared to the late 1960’s for midrange servers.
Mainframes and midrange servers use different operating systems. Mainframes run z/OS or Linux; midrange servers run IBM i.
From a hardware perspective, a mainframe is really a distributed network of components, which interact to form a massive computing platform. A midrange server is a single, standalone system.
Mainframes are usually larger in terms of physical size – although as noted above, modern mainframes are not the huge machines of yore; they can be as small as a refrigerator. But midrange servers are typically even smaller than that.
Despite these differences, mainframes and midrange servers both remain an important resource for businesses across the world. While the advent of the cloud and very inexpensive commodity servers has drawn some businesses to redeploy workloads to those environments, mainframes and midrange servers continue to offer unparalleled levels of availability and performance.
Read “Getting the Most Out of Your Mainframe” to learn how to offload, accelerate and lower cost while leaving the primary CPU with more headroom for the organization’s core business applications.
The post Mainframes vs Midrange Servers: What’s the Difference, Anyway? appeared first on Precisely.
