Year 2000 = about 300 days & counting down

E-Mail from Al Macintyre

We first started to experience Year 2000 problems in 1996 on BPCS/36 and
converted to BPCS 405 CD in the first half of 1998.  

We completed our Y2K tests in BPCS 405 CD for modules
ACP ACR BIL BOM CST GLD INV JIT
MDM MPS MRP ORD PUR SFC SYS

We had an enormous amount of help from http://www.crowechizek.com/
We could not have done this task without them.

We have an AS/436 V3R7 soon to upgrade to V4R3 & we get our BMRs via 8 mm.  We
have received PTF-2 but have not been able to allocate staff or management
will to do any kind of planning for testing.  We are running on PTF-1.
Perhaps when I have gotten a few high priority projects completed, PTF-2 will
be declared mission critical at Central, or PTF-3 might be out by then.

 Y2K problems allegedly encountered with BPCS on AS/400
Some of these are problems of our own making, and some are just nervousness.

ACP

ACP500 & GLD had an enormous volume of glitches such as fiscal year 98 showing
up as 00 on screens & reports,  This was fixed with BMR41197 & 42345. 

We are currently struggling with BMR 46907 which is supposed to fix the fact
that discount terms date math quit working Feb 1999.  We seem to have an
enormous amount of bad luck with getting defective media from SSA & I seem to
lack the skills to figure out when the problem is with the SSA media, or with
the stuff on the media, or whatever.  I have DMPTAP & DSPTAP the latest tape
contents & cannot figure out why it constantly comes up mismatch.  I asked my
boss if I could have the Y2K consultants call in again & figure out what the
problem is & TEACH ME how you can tell when the media or contents defective,
but he told me to work through my local IBM CE, so I will have to explain to
him the whole scenario, and I just not yet got a round TUIT.

AS/Set = check recent BPCS_L Archives - a lot of V6 sites reported problems

BIL

Various entry dates default to 00/00/00.  Many users think default entry dates
should be today's date.  BMR 38036 fixes that for BIL500.

BOM

00/00/00 is also used as the default date for BOM900 -
Whether or not effectivity dates before some date are to be purged.

CST

Marco wrote
>  When you encounter dates 12/31/99 you will need to enter a
>  valid date before submiting job. (still thinks it's Dec 31, 1999). The
>  only one I have found so far (CST290D-01). SSA must fix

We tested various collections of CST jobs with various effective job dates &
found that CST600 could blow up generating garbage costs.  SSA sent us BMR
39917 41704 38037 40870 to fix this one at a time - usually the tape or
contents were defective, then when we finally got a replacement that loaded,
the tests came up with the same garbage.  Was it finally fixed?  I don't
remember - every time I asked, it was another variation on same old story & I
lost track, of how they were managing. 

ORD

ORD590 would not select order lines for printing shipping documents past Y2K.
SSA is working on a BMR to fix this.  I haven't checked OSG recently - for all
I know they have a solution.

PUR = check recent BPCS_L Archives on "PO History"

Susan wrote
> We use the default for "Upper Transaction Date" which is 0/0/00 
> to not purge any PO's. 

Marco wrote
>  Purchase order lines maintenance (PUR500-06). 
>  The Due date does not go further than 2043. 
>  (I won't be around,  but it's still a bug)

SYS

Marco wrote
>  Anything dated 99/99/99 is Y2K certified 
>  (so far my tests have showed that). 
>  It looks strange when your date range is 022599 to 999999. 
>  It considers 999999 is end year 2099. 
>  What happens in 2100 ??????  

Both IBM/400 and SSA use some windowing scheme - I don't remember exactly what
IBM is using - check out WRKSYSVAL - but SYS800 has a cut-off date in the
middle of 100 years & I thought it might be prudent if our IBM & SSA cut-offs
were about the same.  Supposedly as you slide your cut-off forwards,
everything is in sync, but I don't know if it works forever.

Susan speculated
> I wonder what will happen as 0/0/00 is used as default date in other
> programs as well. Has anyone changed the system date and tested this
> default date in any programs?

Marco wrote
>       When you encounter dates 0/00/00, you are forced to enter a
>  valid date. It won't submit job

Well you must be on a different version than us, because we have 00/00/00 all
over creation being accepted as a valid date for the bottom of a date range.
Many of our users were quite nervous with this, asking why 00/00/00 to
99/99/99 for including everything?  Shouldn't it be 01/01/40 to 12/31/39 in
synchronization with the SYS800 windowing?  Then some other users are just not
accustomed to mm/dd/9* to mm/dd/0* date range.

Marco wrote
>  Your sysdate (top right hand corner) does not kick over to
>  Jan 01/00. You must log off and log back in.

"Job Ended Successfully" when we know it bombed & message reply eforts meant
it missed some steps.  SSA working on a BMR to resolve that misleading info.

URLs relevant to Y2K = check recent BPCS_L Archives such as "New to this
listing"

USERS

We've got end users creating queries that other end users run with no
comprehension of the internal logic, which often contains time bombs in which
the logic will not work across Y2K because the Query creators had not thought
through the implications of Y2K.

We have other end users who forgot why I replaced all BPCS/36 entries of
123199 with 12312039, and force of habit resulted in a continuation of keying
123199 into new data & then some of those users asked me what will happen with
their data when we pass 123199 & I said all your data will go away because
THAT'S THE WAY YOU CODED IT - if you do not want it to go away, then use
123139 like I did in the Y2K conversion.  Panic City by one person.  There are
some end users who have not yet had this realization.

I am tempted to generate some queries listing stuff that is 123199 to inquire
whether this is because it really is 123199 or someone has forgotten why we
converted to Y2K compliant.  This is a training issue.

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