Re: Inventory History -- BPCS-L

Hi,

Back before Y2K I recall a similar event happening at another one of our 
sites after they migrated to CD REL 00 (Base Release)
In SYS800 the parameter Inventory Transactions was set to 99999
When the first INV900 was run all the ITHs were deleted.
BMR 40209 had to be applied to prevent further occurrences.
However this BMR is now incorporated into REL02 so the cause of your 
problem lies elsewhere.

In addition to the normal back-ups, before we run the month-end  routines, 
we save BPCSF into a savefile which is overwritten each month. This speeds 
up the save and the back-up is also on-line of needed.

Regards,
Vincent 






Alister Wm Macintyre <macwheel99@xxxxxxxxxxx>
Sent by: bpcs-l-bounces@xxxxxxxxxxxx
01/09/2004 02:55
Please respond to "SSA's BPCS ERP System"

 
        To:     "BPCS_L discussion" <bpcs-l@xxxxxxxxxxxx>
        cc: 
        Subject:        Re: Inventory History


Some posts to BPCS_L get no significant replies.
Some get good stuff ... thanks ... lots of good ideas here.

I also checked BPCS_L archives on INV900 and ITH such as
http://archive.midrange.com/bpcs-l/200203/msg00008.html
finding references to the 99,999 problem (ceiling on # history records on 
one item), and lots of other stuff, most of which I had known already, but 

it had fallen out of my brain until I was reminded by these posts

I found in our system parameters file the record LASTCLOS
it contains
>
>          File 
> Key     LASTCLOS
> 
>
>   Record 
> ID             LC
>   Data - First 
> 20       2008082820031231

I interpret this as being last end year 2003-12-31 and last end month 
2008-08-28
as if instead of keying in for the date
082804
I had keyed in
082808

I think I have found my smoking gun
and BPCS_L was a big help this time.

While looking at the SSARUN03 documentation, the source code, and GO 
CMDREF
I got at a list of files that INV900 messes with, and I checked # records 
there.
They are all consistent with what I would expect to be there, except for 
ITH of course

I still not know if there is any problem with the data in those other 
files.
there are only so many things I can check before I run out of daily wake 
time.

Using SQL I got a count of how many records in ITH do not have a match to 
IIM ... history on items that have been deleted = 144,149

I have some stuff I put on automatic some time ago, to help me monitor 
file 
sizes as needed.
This info pretty much confirms for me that going into Monday transactions
THE ONLY records in ITH were those on the deleted IIM items

Currently I am thinking in terms of ignoring that problem, during this 
repair effort.
I have to get the ITH restored from Fri 8/27 backup
I have to get that combined with the ITH that is now on the system.
The history on the deleted records will be doubled up, but dealing with 
that is for another day when I will write some SQL to remove ITH records 
that do not have a match to IIM
and I suspect in that case the sequence numbers won't make a bit of 
difference

I am hoping our BPCS tech support has already written a program to fix ITH 

vs. IIM sequence numbering, because this problem cannot possibly be unique 

to us.  Yes I could write it, but for me to research what is needed, how 
test it, etc. there are times it makes more sense to get help, and my boss 

has authorized me to call tech support for help with this problem.

I normally work nites, sleep days, but tonite I am going to try to break 
off early (like not much later than midnite), taking a break from all the 
other stuff I want to check out, get to sleep early, set my alarm, so I 
can 
be awake to call our tech support Wednesday during normal business hours.

My boss changes from time to time, and we operate with the rules imposed 
by 
the prior bosses, until some reason to review what we are doing and why.

2 bosses ago, decision was made to stop saving the ITH records that get 
wiped out by INV900 purge, so the last date in YTH is from 2003-01-31 EOM.
It was never explained to me WHY this decision was made
I suspect it might be related to all the problems we were having back then 

with bad tape media, and the fact that the IBM tape drive died 2 days 
before an EOM, and we had to get IBM service to replace the tape drive.

My feeling based on this latest episode is that we would probably be 
better 
off going back to the old way, any time we are not having that kind of 
tape 
problem, which we have not had in years.

However, what are the odds of using the rope to hang ourselves, and where 
are all the places that can go wrong, perhaps other safety measures more 
prudent.  There are a ton of end-month steps, all controlled by what we 
key 
into the date field ... how are we to know if any one of them done wrong, 
and what damage from that.  I think my focus needs to be on blocking that 
risk, not on reacting to latest mess.

We also had a problem several years ago with our UPS going flakey, 
bringing 
the 400 down faster than OS/400 could make proper logs, and causing some 
BPCS files to get corrupted in BPCS terms (the data was there but BPCS 
acted like the file was empty) ... that episode taught us that if a 400 
file is corrupted, backup/400 won't work on that file ... I have now run 
enough backup/400 after problem discovered to verify that this is not a 
case of corrupted files.

In addition to what I said earlier, I also think smart to make sure 
inventory posts to GL caught up before I messing with this file.

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
Find BPCS Documentation Suppliers 
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.