|
midrange.com
Our library list of our test environment:
OVRSYSDATE SYS <= added to system portion of library list by tool.
RBTSYSLIB SYS Robot System Library
SYSMOD SYS Modified System Objects
QSYS SYS System Library
QSYS2 SYS System Library for CPI's
QHLPSYS SYS IBM Supplied Library
QUSRSYS SYS IBM Supplied Library
QTEMP USR
AMTLIB USR A.M.P. Custom Library - User Test
BPCSUSRT USR User Data Files - Test
BPCSUST USR User SRC/OBJ - Test
BPCSPTT USR V62 Cumulative Library for Testing BMR's
BPCSPTF USR V62 Cumulative Library for - 0198
BPCST USR BPCS Data Files - User Test
BPCSO USR BPCS Object
QGPL USR IBM Supplied - General Purpose Library
There is only 32 objects in library and only 3 commands,
An example of the initial program used when testing.
SOURCE FILE . . . . . . . QGPL/QCLSRC
MEMBER . . . . . . . . . BPCSY2KCL
SEQNBR*...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6
...+... 7 ...+... 8 ...+... 9 ...+... 0
100 PGM /* BPCS USERS INITIAL PROGRAM - TEST +
200 ENVIRONMENT */
300
400
/********************************************************************/
500 /* OBJECT ID: BPCSY2KCL WRITTEN: 05/18/99 V4R1M0
*/
600 /* TEXT: BPCS USERS INITIAL PROGRAM - TEST ENVIRONMENT
*/
700
/********************************************************************/
800 /* MODIFICATIONS:
*/
900
/*------------------------------------------------------------------*/
1000 /* MOD SCN DATE MODIFICATION SUMMARY
*/
1100
/*------------------------------------------------------------------*/
1200 /* XXX XXX MM/DD/YY XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
*/
1300
/********************************************************************/
1400
1500 ADDLIBLE LIB(ANYAGE) POSITION(*AFTER QTEMP)
1600 ADDLIBLE LIB(OVRSYSDATE) POSITION(*AFTER QTEMP)
1700 OVRSYSDATE YEAR(2000) MONTH(01) DAY(03) +
1800 TIME(080000)
1900 /* OVRSYSDATE YEAR(1999) MONTH(12) DAY(31) +
2000 TIME(180000)
*/
2100 CALL PGM(RTVSVAL)
2200 CHGMSGQ MSGQ(*WRKSTN) DLVRY(*BREAK) SEV(0)
2300 MONMSG MSGID(CPF0000)
2400
2500 CHGMSGQ MSGQ(*USRPRF) DLVRY(*BREAK) SEV(0)
2600 MONMSG MSGID(CPF0000)
2700 CALL PGM(BPCSMENU)
2800 DLTDATEOVR
2900 SIGNOFF
3000
3100 EOJ: ENDPGM
The best way to conduct Y2K testing is to have a separate AS/400 for
testing.
Bust since our company was not willing to spend the money required to bring
in another
machine and pay for the use of another copy of BPCS and all of the other
tools that we
use. We were forced to use a tool. This tool does put a library above QSYS
in the library
list. It only does this for the users that are conducting the test, in the
test environment
by using the above initial program.
The system library list is modified after the ovrsysdate command has been
issued.
It is not in effect for any other user except the Y2K test user.
It does not cause any problems with the regular system functions.
I hope this is of some help.
Sincerely,
Chris Ertz
MMis2000@aol.com on 08/14/99 05:46:06 AM
Please respond to BPCS-L@midrange.com
To: BPCS-L@midrange.com
cc:
Subject: Re: Y2K v.s. CHGJOB Gotcha?
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
+---
+---
| 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
+---
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.
