Re: Year 2K Testing - economical compromises -- BPCS-L

V3R7M0 is Y2K-certified by 
http://www.itaa.org

However, V3R7M0 will no longer be supported by IBM service when the witching 
hour of Dec 1999 to Jan 2000 rolls over, which is why we converted to V4R3.  
IBM is perpetually offering deals to upgrade your OS.  I suggest you 
seriously consider the peace of mind of being on an IBM supported operating 
system when everything else has this level of uncertainties due to Y2K.

Since you are on Client Server, I'd make sure all those PCs are Y2K compliant 
before even considering BPCS Y2K testing.  How about all the other hardware 
attached to our AS/400 - modems, controllers, printers, green screen work 
stations, from IBM & the competition - do they have Y2K exposure?

http://wwwyr2k.raleigh.ibm.com = where you can try to check out readiness of 
IBM peripherals - we have been having some trouble with the site - we get to 
the point where it accepts the list of our IBM hardware model numbers then we 
have trouble filling in the code numbers needed to authorize letting us see 
the answers

In the real world, everything is under budgeted too late.  There are tools to 
help us do testing, but there is a training curve learning how to use them 
effectively, and a lead time persuading management to spend the bucks to get 
what we think we need, preceeded by a time period evaluating pros & cons of 
which to ask for.

Does your company have the resources to permit having one AS/400 for regular 
work and a separate one for Y2K testing?  That's what one of our local banks 
is doing.
http://www.oldnationalbank.com/year2000_status.html
They also have a list of some dates they are using in testing.
On a regular basis they copy contemporary data from the production AS/400 to 
the Y2K testing AS/400 so that Y2K tests can be run in parallel with read 
data, the only difference being that the data has been aged.

If you don't have the resources for an independent AS/400 on site, perhaps 
you could rent time at your hardware supplier, which should be able to give 
you access to a system whose hardware is the same as yours, except you will 
have a software key problem, unless arrangements are made in advance with the 
providers of the software keys, because the platform you rent time on will 
not have same CPU serial number.

Be sure to test more than just the BPCS software - I read some place about 
9999 being used in backup expiration dates.

Whose software did you use to get your data converted to Y2K compliant & who 
is your trading partner for BPCS software support?  Some of those outfits 
have automated testing tools & can do the work for you at what MIS would 
consider reasonable prices, but perhaps not any top management that still has 
a learning curve regarding what ought to be done for quality assurance.

Instead of each BPCS customer spending bucks to buy some testing software 
that will benefit the company for a relatively short time period, and 
spending bucks and precious time to learn how to use it & interpret what it 
is saying to you .... send your data & software to some outfit like Nex Gen, 
which can use much more sophisticated automated testing to get a much more 
thorough picture than you can do yourself, they already know what needs to be 
tested, and they can do it much faster also.  Time is running out.

Suppose you have one environment for running the business day to day until 
the Y2K version is ready to take over.  If you change the system date to 
future dates for Y2K testing environment, that also applies to anything done 
in the old version & any other non-BPCS software you may have on your system. 
 Have you done an inventory of all that other stuff & are ready to test 
everything & can enforce non-user visitations to the production environment 
during Y2K testing? 

In my world, the only way to enforce this is to vary off all work stations 
except those involved in Y2K testing.  Otherwise some people will not 
understand your demands, then while you are doing Y2K testing, they will do 
stuff in production environment and unknowingly mess things up there, then if 
you restore older version of production version when Y2K testing is over, 
whatever transactions that those people did when you had asked for no access 
will be missing from your system because they remembered keying them in.

The approach we used was to teach CHGJOB to end users who would be doing Y2K 
testing.  We had a modified conversion process to get our data to what we 
thought was Y2K compliant, which we called "Conference Room Pilot" then 
people familiar with each application would run the same tests with the same 
test data for a variety of dates critical to Y2K concerns, and important to 
our business.  The first step in their tests was to change their sign-on job 
date to the date they were going to be using in their testing.  Testing is up 
to the individual, but they can be supplied with a suggested test script or 
check list of things to watch out for.

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