Re: Y2K v.s. CHGJOB Gotcha?

[Jon Le Roi <jonleroi@xxxxxxxxxxx>]

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
+---