Re: Warning-BPCS 405 CD data files with bad creation dates

>  davem@drme.com original scenario 
>  
>  > through a conversion from BPCS 404 to 4.05 CD and have
>  >  found application errors caused by bad file creation dates.
>  >  
>  >  The problem is that about 600 files and members have a creation date of
>  >  03/12/2004!   We discovered this problem when billing stopped posting to
>  >  the G/L.  It worked fine for three days after the live conversions, then
>  >  stopped working.  During the first three days, the only member in the
>  >  GJW file was the GJW member (created 03/12/2004).  On the fourth day,
>  >  one of the BPCS programs created a new workstation member in the GJW
>  >  file.  Guess where your new billing  records are written when the files
>  >  default to the *First member (hint-it's not in the GJW member that was
>  >  created 03/12/2004).  The G/L posting programs look at the GJWL* members
>  >  which are built over the GJW member

>  From:    Ata510@aol.com

>  Yep! This was not the worlds cleanest release, that's for certain! They 
>  brought in too many outside developers to do the project, from what I 
heard. 
> 
>  You couldn't really run some programs in BPCS CD until REL02 came out - 
> after the initial release, it was rushed out of the outside developers 
hands and 
>  cleaned up a lot by SSA in Canada with REL01 and REL02. 
>  But install problems like the file dates were never corrected. 

This once again proves a truism that a lot of people forget when disregarding 
Y2K advisories on the importance of contingency planning

A rushed project introduces new bugs
Y2K is the biggest rushed project in all of computer history

However, I have my suspicions that BPCS Version 6 might be a contender for 
the 2nd biggest, along with some WinTel products.

>  The issue you described with GJW is actually very well documented on OGS 
>  Online and even has a BMR (not completed). The problem appears to be the 
>  conversion process itself - those pesky empty workstation members 
mentioned 
>  in other notices here get carried over during Conversions and your normal 
>  creation dates on those members remain, but the GJW file and GJW member 
>  have 2004 dates, and somehow in the conversion copy file/restore/convert 
process 
>  the members end up flip/flopped so that your workstation members become 
the 
>  *FIRST member, and the 2004 dated member 'GJW' ends up last. And to top it 
>  off, some programs are hardcoded to look in the "GJW" member to retrieve 
>  their data, while the other part of the program writes the data to the 
>  generic *FIRST member (which has now become your workstation member from a 
prior release).
>   
>  Al M. mentioned he did not encounter this problem 

Well we also abandoned the official conversion because of the volume of 
conversion hassles, overwhelming our ability to figure out where all our 
problems were coming from --- we ended up converting the static files through 
3rd party products, so any problems in the final data were either artifacts 
of the BPCS external files into which the data was flowing, or from our use 
of the 3rd party products.

> - it appears if you had to 
>  convert from a lower release of BPCS and followed the "Conversion for the 
>  AS/400" step to remove the empty workstation members, then you do not hit 
> the problem (nothing to flip flop). If you are already at 4.04 or 4.05 and 
just 
>  convert to CD, or you ignored that step to remove the members, you would 
hit 
>  the problem.
>  
>  What joy to discover! Then of course, if you don't realize the problem is 
in 
>  the conversion itself, you correct it only on the 405CD side in the test 
>  environment, and you might test and re-convert several times before going 
>  live - and the problem comes up again and again. 
>  
>  To prevent it - grab that handy program to remove workstation members 
> (talked about in earlier posts) and make sure BEFORE you convert, that all 
>  workstation members are gone from GJW. 

    <snip>

>  The other main problem I could imagine this might (?) cause is doing 
backups 
>  by when a file was last changed (SAVCHGOBJ) - be sure you are getting good 
>  backups. If the file is created in 2004, and you make changes in 1999, OS/
> 400 may not recognize a real change has occured and 
> SAVCHGOBJ may skip the file - verify by reading your joblogs from backups 
> very carefully. A full backup (SAVLIB or SAVOBJ) will have no problem with 
this. 
> Maybe an IBMer out there familiar with Save/Restore could confirm 
> if this is really something to worry 
>  about or not? (Several data files delivered from SSA were created and 
>  compiled in 2004 and delivered that way on the install tapes).
>  
>  I searched also for a way to alter this in a simple command, and know of 
no 
>  way to correct the file dates except via CRTDUPOBJ or to recompile the 
files 

Recompiling wipes the contents of files & in additon to replacing the data, 
you also have to kill all the logicals & replace all of them after the data 
has been replaced.

At one point in our conversion I was doing stuff that I was told was very 
very dangerous, when one of the consultants caught me in the act - I would 
create target files in some library - copy data into them, then go into QSYS 
& rename the library.

>  and copy data back into them. The BPCS CD install process restores the 
files 
>  to the system, so I really don't think a save / restore operation alters 
the 
>  file dates the way you are hoping? ? (Not sure. . )
>  
>  The 2004 date also potentially messes up some 3rd party change control 
>  utilities too . . . for the same reason SAVCHGOBJ may not notice a change 
- 
>  2004 sure looks more recent than 1999.
>   
>  I think you hit the only real program bad data type of error in BPCS that 
>  results from this bad file dates, however.
>  
>  Try searching OGS on '2004' and 'CD' or '405CD' for other details - there 
was 
>  a BMR on the files themselves, but of course they would have to re-cut the 
>  install tapes to fix it, so they didn't fix it.
+---
| 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
+---