An Un-COMMON Calendar Event
Noticeably absent from this year's fall COMMON Expo were Year 2000 tool and services vendors. Those that were there had other products to push and Y2K was never in the forefront of their booths. Year 2000 sessions numbered only 10 with 25 to 30 attendees on average. No vendors, few sessions--you might think Y2K was completely dead.
Even though Y2K was not a very public topic at the conference, that doesn't mean people weren't interested as it was the subject of chatter throughout the hallways and a frequent side topic during sessions that focused on other subject matter. It was also a topic of discussion among several scattered groups of passengers within earshot as I traveled between New York City and San Antonio.
Some attendees at AS/400 Sound Off expressed concern about the need to apply both the most current CUM PTFs and Year 2000 general PTFs (either SF99200 or SF99201) in order to be Year 2000 ready. As I understand it the Y2K group of PTFs are general PTFs which rollout faster than a CUM's more controlled release. Tom Jarosh, AS/400 general manager, assigned an IBMer to investigate and report back for the "Green Streak" (COMMON's daily newspaper) if this process might be combined and shortened. The next morning's published reply was NO.
Jarosh, in reply to comments related to the continued difficulties of ordering IBM products, mentioned that IBM had to abandon their modernization efforts to the outdated corporatewide order entry system because, much like many AS/400 installations, it had to abandon new development to address Year 2000 compliance. Stay tuned, the modernization of the system to today's business needs is scheduled to resume post Year 2000.
My best guess is that between one and two percent of the paid attendees took time out to visit each of the Year 2000 sessions. Topics such as testing, rapid remediation, contingency planning, and infrastructure held the highest interest levels, and interest in encapsulation as a rapid deployment solution still exists. There's no black magic going on under encapsulation's covers, just a unique variation of windowing that's highly automated to leverage current working application code and allow you to continue processing for 28 more years as if in the past while externally communicating as if it were today. Some methods take the process of encapsulation further and minimize the amount of change to about 30 percent of other offerings. Reduction in change is a reduction in risk and perhaps a reduction in testing requirements and procedures.
It was clear to me that people entered or were entering into the "traditional" AS/400-style testing processes. Some had finished, but were still in search of additional areas they might have missed. Such intense scrutiny in quest of the greatest success was most prevalent from industries that measure failure in terms of human life and death. This brings new meaning to mission-critical values on a comparative level in the resolve of Y2K issues.
What underscored the general state of readiness for me were conversations I overheard on testing and the processes that accompany the steps to the final conclusions. Asking how it has been accomplished? What controls and baselines were established to bring certifiably correctness to the results? Do you have a business continuity plan? If so, has it been reviewed and distributed to key personnel for execution should it be necessary? Has your disaster recovery (DR) plan been updated and tested to include Year 2000 elements?
Other conversation snippets indicated that independent verifications and validations (IV&V) were rarely used, and in some cases, unknown. My suspicions are that words such as audits and attorneys will get attention turned towards these valued processes. But, by that time it's too late as you're on your way to litigation and court where such omissions play against you. These review processes usually take only a few weeks. Why not check with both legal and corporate management to avoid any and all possible trouble. You, the corporate officers, and your corporation will very likely lose the battle without such processes.
The last of the high interest questions went something like, "Should we leave the AS/400 on during the rollover and will DASD have problems starting up after an extended shutdown period?" IBM has some general rollover advice on their Web pages. If I remember correctly they suggest it's OK to leave the system up during rollover, which would make question number two a non-issue.
On the other hand if one loses power and the environment changes over time (take a cold northern climate in the height of winter) disks are very likely to be difficult until things such as temperatures and humidity levels get back to normal. Loss of power brings me back to the question: Should the AS/400 remain powered on during the rollover? Assuming there's a UPS and the system can remain up for orderly shutdown, it is a 50/50 situation this time around.
Loss of electricity and/or transportation are problems of great magnitude. Loss of key suppliers and clients could make your business remediation/preparedness efforts virtually paralyzed. Some of the basic issues are movement of staff, services and materials into and out of your facilities and those of your suppliers and clients. How long can you function with what is currently in-house? You might be unable to access the facilities for tainted security reasons.
As evidenced by Y2K's relegation to a sideshow topic at COMMON, most AS/400 shops show outward confidence and sense of completion with their in-house Year/2000. Yet, judging by the topics of most conversations, they remain concerned over the status of others in their AS/400 inter/infra structure. If that sounds like you, send me a note and tell me why you think this way.