THE WORKERS’ COMPENSATION BOARD
(WCB) of Alberta, Canada, was IBM’s first zSeries 990 (code-named T-Rex) customer in Canada. In a period of 15 days, the deal was signed and the system was installed, seamlessly, for our customers. To recap the chain of events:
- June 27, early afternoon—the deal was signed
- June 30, the system was shipped from Poughkeepsie, NY
- July 2, late afternoon—the system arrived in Edmonton, Alberta, Canada
- July 3, the system was delivered
- July 4, we powered up the system
- July 9, we ran the first logical partition (LPAR) with a coupling facility (CF) and one production application
- July 12, the remaining four LPARs went into full production, replacing a z900-1C4.
Every effort was made to make all required changes, except for the processor replacement itself, before July 12:
- PTFs were applied to z/OS 1.2 on June 27 and 29.
- The few remaining parallel channels were migrated to 9034 ESCON converters on the old z900 on July 6 and 7.
- Token-ring and open systems adapter (OSA) cards are different, as they require some configuration and TCP/IP address changes.
- All but the essential I/O definition file and I/O configuration data set (IODF/IOCDS) changes required for the z900-to-z990 conversion were postponed until after the z990 installation.
- Software keys for non-IBM software products were applied to the test LPAR and the products tested in advance.
The successful and efficient transition to the T-Rex system was invisible to our customers, but here are the challenges we faced in pulling it off. Since not all non-IBM software products had been set up so they could be tested on the test LPAR, there were a few problems. In retrospect, the best way to handle software with processor serial number- dependent keys is:
- Obtain and apply emergency keys to the old system and make sure they work
- Change processors
- Obtain, apply, and test the new permanent keys later. Emergency keys are not processor serial number-dependent, but are time-limited, typically 10 to 30 days.
Each vendor has a different procedure for applying keys. One vendor’s permanent keys did not work. Another’s stopped working two weeks later because of a bad LPAR name. A third vendor repeatedly assured us that all the installed products used its common license management system; a key product, our multi-session manager, did not.
The only major challenge during the actual production install was having only one chance to successfully IPL our primary production LPAR on the z990. During shutdown on the z900, we had moved the CF from the z900 to the z990. Because we were using internal CFs (ICFs) within the z900 and z990, and did not change our CF LPAR names, we had to recover by IPLing the LPAR in LOCAL mode on the z990 without the CF.
In total, it cost us an hour and a half, and a consultant some sleep, but he gave us the piece we needed: the System Parameter GRS=NONE we could enter from the console at IPL time to IPL in LOCAL mode. This works only if you have an IEASYSxx member that will IPL successfully in LOCAL mode. For example, for IEASYSSA, you would respond: R 00,SYSP=SA,GRS=NONE
AFTER THE INSTALL
Despite a lot of testing on installation day, three problems did arise during the next two business days: