Re: BPCS 405 ITH ---- Sequence Number

[MacWheel99@xxxxxxx]

>  From:    Roger.Henady@thorco.com
>  
>  What happens when the Sequence number rolls over?     Does it get reset
>  some how?     In INV300 transaction history, the listing is by Item and
>  Seq#.      I'm trying to figure out why the seq# would not follow the
>  Transaction Date.   Even on a "T"  transaction ( Location Transfer) one "T"
>  would have a much lower Seq# than the other.
>  
>  The Next sequence number is stored in the IIM file.     We also have three
>  FAC / WH if that matters.

I love this list - people ask such wonderful thought provoking questions, 
that help us explore the innards of how BPCS really works.  Then I put my 
foot in mouth & someone explains where my anatomy is not quite right.

I think BPCS blows up big time if your Sequence number on some item gets so 
large that it would need to roll over.
I think you need to have a Query or SQL or RPG to seek out what is in there & 
locate what item has the largest Sequence # & how close it is to blowing up.
If you are at risk, lower the time frame of how long you keep your 
transactions on-line, or change how you do stuff so that item gets less 
activity ... like for example giving it a new item # & the first transaction 
on new # would be a COMMENT pointing at the old # for the old history & the 
last transaction on old # would be COMMENT pointing at the new # for future 
history.

Running out of numbers is like a Y2K variant.

Will the USA run out of Social Security Numbers?  There's whole strings of #s 
they cannot use because of religious implications - new #s are issued to new 
born babies & every corporation, and they have to keep old #s of people who 
died, because of descendents drawing on the funds.
Will the internet revolution mean that phone #s will have to get more digits?

I used to tell people that Y2K was the end of the Computer Universe, like the 
Mayan Religion ... some magic date when God comes along & changes the rules 
of physics so nothing we depended on to work right is the same again ... 
UNLESS WE FIX the Y2K problem in time.
Well you may have a similar problem.  You are standing on the Railroad Tracks 
of Major Trouble headed your way, speculating what will happen when it gets 
to the end of the Sequence # Universe, and you need to divert that train, or 
there is going to be a major derailment.

My understanding is that in EOM with INV900 it splits what is in ITH into 2 
files ... there are the records to be kept off line & the records to be got 
rid of.  In the process of copying the records to be kept, the sequence # is 
recomputed from one since the oldest ones have now gone away.

Sometimes the date & sequence # do not appear to be in synchronization.
This is because the sequence # is the actual sequence that the transactions 
are posted.
If you do any transactions in which the data was slow in getting to the 
computer, then sometimes the input gets dated for the day it was actually 
done.
For example, we have people working our factory some weekends, but we do not 
have a full clerical staff working the weekend, so many of the factory 
transactions do not get keyed in until the next Monday.
Now suppose the Monday transactions were done on a timely basis, then someone 
spent a few hours Monday afternoon keying in all the weekend work, and dated 
it using the weekend day ... you would have the dates out of sync with the 
sequence #.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

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