|
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.
www.cen-elec.com
-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.
www.cen-elec.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
