Re: Y2K v.s. CHGJOB Gotcha? -- BPCS-L

There are a few more tools  that  do that as well.

I just go nuts ,when any tools do that by placing themselves on the
 top of the libl list

FWIW it looks like several more datesshould beconsidered and
tested unless they have been left off  for brevity.


At 10:24 AM 8/9/99 -0600, you wrote: 

>>>>

<excerpt>

Hello Y'all, 


Not to sound like an advertisement, but I am using a package called
ANYDATE 

the command OVRSYSDATE solves the problems created by the use of
rtvsysval 

qdate qtime as well as rpg commands udate *date and time instructions. It 

works and it does not cost an arm and a leg. There is also has a
companion 

product/command called ANYAGE which you can use to age your test 

environment into the future for proper testing of Y2K. 


Sincerely, 


Chris Ertz 


"Tim Armstrong"  on 08/05/99 06:04:05 PM 


Please respond to BPCS-L@midrange.com 


To:   BPCS-L@midrange.com 

cc: 

Subject:  Y2K v.s. CHGJOB Gotcha? 


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. 



-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 size=2>                                            

Central Industries of  Indiana, Inc.








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