Referencing my very first TechTalk tip in the March issue of Midrange Computing on "Your First Checksum Configuration," I decided to write a follow-up story.
Working the weekend in a mainframe environment was something I had grown accustomed to. Since joining the ranks of the AS/400, I have found the operating system that lets one sleep at night and spend weekends doing more productive things - like playing golf.
At the time, I was still running OS/400 Release 1. Since I had to work the weekend, I thought it would be advantageous to install OS/400 Release 2 at the same time. My plan was to reconfigure Checksum during the Release 2 install. I soon found out that I had to complete the Release 2 install completely before I could reconfigure for Checksum.
The OS/400 Release 2 upgrade went very well. The Checksum reconfiguration also went very well. One may ask, how long did it take? Try THIRTY (30) HOURS. Was the company surprised to come in on Monday and find the system was unavailable? Oh yes! Were they beginning to question how much longer the reload may take when the system was still reloading at 5:00 pm on Monday? Oh yes, again! There weren't any problems, thank goodness, it just took a very long time.
One may ask, exactly what is it that takes the AS/400 so long to reload? The system DASD configuration was at 6.8 gigabytes. The DASD utilization was at 65%. There were four database libraries. Each database file library restore amounted to four hours of reload time, thanks to access paths, for a total of 16 hours, or just over half the time it took to reload the additional 100 libraries. What were my reload options? When I started the reload process, I began by reloading each tape sequentially in the same manner that the SAVSYS, SAVLIB *NONSYS, and SAVDLO created the system backup. Although I've never verified it, I heard that I could have restored the system in stages. It would have been cumbersome to reload the entire system by library, but I may have been able to provide a system to the organization on that Monday morning.
Another lesson learned. Planning is everything!
Ed Koziol Kenosha, Wisconsin
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online