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

[Ata510@xxxxxxx]

In a message dated 7/28/99 12:11:56 AM Central Daylight Time, davem@drme.com 
writes:

> I have just been through a conversion from BPCS 4.04 to 4.05 CD and have
>  found some application errors that were 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
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. 

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 - 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. If any have data in them and you 
afraid to delete them, chase down the person who's workstation it is - 
because really they should not have data in them - all posting should be 
finished before a conversion is run. 
 
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 
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
+---