Re: PO History -- BPCS-L

In a message dated 2/25/99 4:08:07 PM Central Standard Time, LACELLE@rcmint.ca
writes:

> So far the problems I have found 
>  
>       1. 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)
>  
>       2. When you encounter dates 0/00/00, you are forced to enter a
>  valid date. It won't submit job
>       3. 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
>  
>       4. Your sysdate (top right hand corner) does not kick over to
>  Jan 01/00. You must log off and log back in.
>  
>       5. 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 ??????  
>  
>       Marco
>  
>       Let's keep everyone informed on this. We should relay info has
>  we hear about it.
>  
You are not testing what BPCS has been modified to do regarding Y2K. Notice
that there is a data area set for Century Break Year in the System Parameters?
Yes, BPCS will only run until 2043 when the break year is set to '44' , then
when you get to 2030 or so, re-set the break year! It is most definitely NOT a
bug -- it is PER DESIGN. BPCS will then keep 100 years more of data with a
different beginning/ending year for what is considered a 19xx year and what is
considered a 20xx year...of course there will be a Year 2100 problem...but if
you consider what happened to System/36, System/38 etc., you had better
hope/bet that something better than what we currently have will be along by
that time -- back in 1899, a computer was an abacus!! You know SSA will not be
supporting this same stuff by then -- puh-leeze!!!

BPCS stores dates as 8 digits. However, it only allows users to enter 6
digits, and uses this century break year to determine if there should by a
'19' or a '20' in the last part of the year field in the database.

You don't provide enough context to understand what you are saying about
logging back on/off to get a system date change. But if I understand you, if
you are on at midnight and the date changes, your job date does not. You will
find that with ANY date, not just going past midnight into Jan 1 2000....try
it and you will see.Your job date is an AS/400 function, and it will reflect
the date the job was started, not the system date. And BPCS retrieves job
date, not system date. There have been discussions/complaints/modification
suggestions about that here before, and Enhancement BMRs have been entered
....but not fixed. Some jobs require the date stay constant...others, would
really work better using system date....it relates to the SYS9xx date
retrieval jobs common to all BPCS. At any rate, at the moment the software is
designed to retrieve job date, and yes, to get a new job date, you need to
sign off and on again to start a new job.

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