RE: INV900 Oops

I frequently have issues with INV900 not running. More accurately, it
says "Ended abnormally." When I DSPMSG. It's always because a user had
the IIM file open and INV900 could not get the exclusive lock it needs.
Sometimes the user is not in, but the IIM file stays locked because they
did not sign off before closing the session window. In that case, I do a
wrkobjlck on the IIM file and determine the job(s) that are locking the
file. I then take action 4 to end the job.

Hope this helps!

Paul



-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx]
On Behalf Of DeeDee Virgei
Sent: Tuesday, June 03, 2003 2:14 PM
To: 'SSA's BPCS ERP System'
Subject: RE: INV900 Oops

Hi,

We are on 4.05 CD...  When we run inventory M/E (INV900), INV901C then
gets
submitted to batch...  Since your INV901C program wasn't used this month
and
from the last dates used on your other programs, it looks like during
submission of your M/E,  the options on the 2nd of screen of INV900 were
set
as follows:
INV900-02 ...
          Print all Outstanding Cycle Counts        Y      (Y or N)

          Continue with Month End Procedure      N      (Y or N)


These are the defaults setting; we have to change them every month to N
then
Y...  This being the case, the impact would be pretty much the same as
not
running INV900 at all.  We once forgot to run INV900; ended up running
it
the next evening and had to make some adjustments to some of the
reports... 

Hope this helps.  
 

DeeDee Virgei
Nelson Stud Welding, Inc.
7900 West Ridge Rd
Elyria, OH 44036

 -----Original Message-----
From:   Al Mac [mailto:macwheel99@xxxxxxxxxxx] 
Sent:   Tuesday, June 03, 2003 1:15 PM
To:     BPCS Users Discussion Group
Subject:        INV900 Oops

I am looking for suggestions while I struggle looking into some things.
We are BPCS 405 CD

I work nites and this info was as of what I figured out last nite

Last Friday night most of the EOM was done, finishing up Saturday 
Morning.  I was long gone from the system.  Monday I was informed that 
something went wrong with INV900, know not what exactly.  The hope is
that 
we can do June transactions almost like normal, then some recovery
effort 
in the next EOM.  What I expect is that there will be NO May totals in
the 
system except any reports accounting ran from MTD perspective and from 
files not affected by INV900, so the total sales for JUNE will really be

MAY plus JUNE combined, and some files will be out of sync with each
other 
for MAY JUNE.  Thus it might NOT be SMART for me to run the weekly files

REORG until I have a better grasp of what files went thru EOM Ok, and
which 
will have a double month next EOM..

This means the new sales reports that I developed last month with Y"all 
help should be considered as trash for now, and the AMP TYCO report will

not be available for another month.  AMP TYCO is one of our vendors ...
we 
send them a monthly report on how much raw materials we ordered on
behalf 
of each of our customers, in which the data is computed using
combination 
of BOM and Sales History.  Well I consider Sales History to be the same 
value as GARBAGE until I figure out what is Ok.

WRKOBJ INV90* gets at a list of related INV900 major steps
8 (eight) enter scroll second screen shows DATE last time that program
was
used

The following were last used end of May (last Friday)
INV900PM (prompt screen)
INV900C (Main CL from menu)
INV903 (I think this is involved in the cycle count clean up at the
start 
of INV900)
INV903O (report associated with cycle count distraction at very
beginning 
of INV900C)

The following were last used end of April (a month ago)
INV900 (main RPG program)
INV904 (Rel-2 version)
INV901C (I think this runs close to the end of the whole operation)

According to SSARUN03, the files that INV900 messes with are
IWM IWI ILI RCM SSM SSH SSD ITH and I know that is not a complete story
and 
that we do use ACR900, but I have lots of clues to explore

Some of these files are updated during the course of daily transactions,

while some only EOM hits.  I happen to have been messing with RCM Friday

before EOM due to placement of customers on a report sequenced by
customer 
name.

I know from past experience that YTH file contains copy of ITH
transactions 
cleared off in the previous EOM.  Our YTH file is empty of records
(DSPFD 
list members ... the date not help me ... my speculation is that when a 
file is cleared, that does not alter the date of last change, it is only

adding or changing records that updates that).  We used to write off
last 
month records to tape, not do that any more, I not remember when that 
policy changed ... that could be why January 2003 is date of last change
of 
YTH.

I have some software off GO CMDSCDE that I not check every week, but
from 
it I see that our ITH Inventory History file had
1.330 million records as of a week before EOM
1.347 million records as of late afternoon of EOM (before final shipping

and some other transactions) = 17 thousand added in the 4 day week
1.347 million records (about 500 more) first thing Monday morning
1.350 million records Monday evening (3 thousand added during Monday)
This tells me that the INV900 did not clear off the records older than
our 
SYS800 system parameters (should be 365 days ... I still need to check
to 
make sure no one mucked with that) so I know INV900 did not get to
whatever 
step where that happens
It also tells me we have not lost anything valuable records wise

There are some files updated by EOM that I not sure if they supposed to
get 
updated each day ... some of them supposed to have MTD data like last 
shipment, but I not know when that data goes in
SSD & SSH Sales History files last updated last Friday EOM

Now unless something other than INV900 updates them, this tells me that 
INV900 successfully got through at least part of a step ... but I still 
need to look at MTD, month 01, etc.

I expect these files to change every day and they were in fact last
updated 
Monday June-2
IIM Item Master
ILI Inventory by Item Warehouse Location
IWI Inventory by Item Warehouse
RCM Customer Master

I am not sure what all updates these  ... they were last updated Monday
June
2
IWM Item Warehouse Master
SSM Salesperson master

I ran a list DSPFD all files when last changed.  I only looking at some
of 
them.
In most cases the date last used is same as date last changed.

Some weird ... RMAs last changed Mon June-6 but last used Fri May-30
When I not regularly look at some things, I not know what is (ab)normal

The menu launches INV900C whose CL uses a lot of soft coding, so it not 
obvious what job calls what job.
-
Al Macintyre
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/

>From: Al Mac <macwheel99@xxxxxxxxxxx>

Forwarded from the office


>Will do.
>
>You may recall that the reason we not want people doing BPCS
transactions 
>on the weekend of EOM is that with an EOM date of SATURDAY, that if you

>finish FRIDAY nite then someone posts transactions DATED in the fiscal 
>period you just closed, BPCS treats those transactions as if they had
in 
>fact gone in the month that you just closed ... altering opening
balance 
>... which Mike discovered by seeing that Opening Balance of CSTOPS had 
>changed during course of month.

I checked ITH date ranges ... nothing got posted dated Saturday or
Sunday.

>But what you describing sounds OPPOSITE scenario.
>
>There is another wrinkle ... if someone enters transactions LAST MONTH
but 
>DATES them into the FUTURE, BPCS does not include those transactions in

>the EOM.  We have had a scattering of that kind of scenario in the
past, 
>and I did not know all the implications of such activity.  Using a
wrong 
>date on BPCS transactions can occur through human error, where the user

>not realize what they doing, and they can occur through human 
>misunderstanding of the role of date in BPCS transactions.
>
>INV900 normally takes SEVERAL HOURS to do its thing, but Mike did have
a 
>change in procedure a few months ago which would have somewhat lowered
the 
>run time, but I still expected it to take several hours.  I did ask him
to 
>track how long various tasks take, and update his check list.  It may
be 
>that some things have changed significantly in time duration without
his 
>check list reflecting that.
>
>It is not just inventory opening balance that INV900 updates, also
stuff 
>related to sales history files.
>
>What I fear is that the job ended normally in IBM terms but abnormally
in 
>BPCS terms such that there might not be an IBM JOBLOG with clues.

There was no job log for me to examine.

>>Al,
>>
>>
>>Mike had mentioned the month end close on INV900 ran quickly.  I don't

>>believe it ran correctly.  Items show activity in the MTD totals now
when 
>>they should only show an opening balance.
>>
>>
>>I don't think this will have an impact on operations, but it might
create 
>>problems at the end of this month.  Please investigate this when you
get
in.
>>
>>
>>Thank you,
>>
>>Tim
>>
>>  -
>
>-
>Al Macintyre
>BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
>Find BPCS Documentation Suppliers 
>http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
_______________________________________________
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.
_______________________________________________
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.