|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.