Re: Y2K v.s. CHGJOB Gotcha?

When we looked at testing for our CD upgrade, we decided it made more sense to change the system date to insure the entire process worked for us, not just seperate components. We were upgrading to an S/30 from a 310 at the same time so it worked to our advantage to have a non production machine to manipulate dates with. Our testing process was to set the date to 12/26/99 and begin loading transactions into the various modules. We then let the system date roll forward on its own until 01/03/00; this also verified our automated month end and year processing. We then performed the same process for multiple date events throughout the calendar.

My comfort level was fairly high due to the fact that I had been in contact with several other pharmaceutical companies that had already done the same thing as had six of our "sister" organizations throughout Latin America. Of course we still needed to prove it to ourselves.

Regards,

Jon Le Roi
Dey, L.P.
(707) 224-3200

At 07:04 PM 8/5/99 -0500, you wrote:

e-mail from Al Macintyre at Tim PC at work
 
Aug 1999 News/400 arrived today & page 113 describes some down sides to using CHGJOB (Change Job) to set JOBDATE to a test date for Y2K testing, that raise some disturbing questions.
 
We did all our BPCS 405 CD Y2K testing on our AS/436 in 1998 by having users change job date to various dates in 2000, beyond, cusp of 99-00, then run test scripts & check for various criteria.  Are there any flaws in that general testing strategy?
 
We found Y2K problems & other bugs which we reported to SSA.  We thoroughly documented them & used dates in which the month-day-year were all different numbers so it was obvious where SSA's code broke down, such as in ORD570.  We trusted that SSA would make a sincere effort to fix Y2K problems in time, since they were being reported with at least 18 months advance warning before the deadline, and we soon learned that when SSA solves a problem they do not make a good faith notification to the customer that reported it, rather it is stuck some place on OSG for us to stumble over.
 
(a) If BPCS has any code that gets its date from RTVSYSVAL (Retrieve System Value), that code does not get tested using the CHGJOB date substitution in JOBDATE.  Does BPCS in fact get dates from RTSYSVAL or any equivalent methodology?  If not, then the only place I need to check are the modifications added by myself & our consultants.
 
(b) JOBDATE does not function exactly as the system date does ... any job that runs past midnite has clock roll over but not date.  I do not believe that is a problem for us, since our testing was conducted during regular business hours.
 
When I have needed a date in modifications, I have either grabbed a copy of whatever BPCS had, or used IBM *DATE to satisfy programming needs of the moment with a hopefully not misplaced blind faith that while SSA might occasionally let us down, IBM has a higher standard of excellence, although they use the same principle as SSA OSG when it comes to us finding out which of our peripherals have Y2K compliant electronics.
 
Bottom line, was CHGJOB an adequate testing strategy for Y2K compliance on BPCS 450 CD?
 
Al Macintyre
____________________________________________
Central Industries of Indiana, Inc.
www.cen-elec.com

+--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +---