Al,
This is very helpful. I would like your offline post!
Thank You!
Don
-----Original Message-----
From: bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx] On Behalf
Of Al
Sent: Wednesday, May 12, 2010 3:55 PM
To: 'BPCS ERP System'
Subject: Re: [BPCS-L] A/P Check Payment SNAFU
***** Warning ***** Long post here.
I recognize it, but may not have a good solution, because of a myriad of
complications that I try to illuminate in this post. Especially since
it has been several years since last time we encountered this particular
kind of mishap.
It may be helpful for you, if I was to send you a copy of my FIX OOPS
document off-line. FIX OOPS is an SEU PDM member I added to BPCSDOC,
that lists everything that possibly could go wrong, that we have
encountered, and figured out what to do about it. The scenarios are
sequenced by a brief statement title of nature of perceived problem, or
program name where messup happened. Solution write-ups assume the
person trying to fix might have minimal know-how associated with the
techniques needed.
I looked in there, did not find much to help this scenario.
Cut & paste from there:
41900 1. Person-A is on the ACP600 screen where check ranges selected.
03/02/01
42000 2. Oops, Someone killed that job or ended it abnormally.
03/02/01
42100 3. Try to get back in & get the error message
03/02/01
42200 "Company currently being processed" (where Person-A WAS)
03/02/01
42300 4. Solution
03/02/01
42400 CHGDTAARA DTAARA(*LIBL/SSAACP) VALUE('')
03/02/01
42500
03/02/01
42600 DSPDTAARA DTAARA(SSAACP) shows a LONG data area
03/02/01
42700 Y in position 1 means company 1 is being processed
03/02/01
42800 Y in position 2 means company 2 is being processed etc.
In 405 CD, there are work areas named using a combination of the first
6-8 characters of work station id and a handful of letters in front that
designate what application or program is running.
Some work areas end up as members of key files, with same layout as the
files, but containing the data that the work station user intends to
post, and can modify the contents before conclusion. Thus, if a job
gets interrupted, then user returns to it, we have the phenomena of
messed up prior input intermingled with new input.
I suggest using *OUTFILE from List BPCS files to identify which files
have a count of more than one member, and vintage of those named other
than same as the file itself, with other than zero records.
There's also a data area, which keeps track of which step the user is
at, in a series of steps. SYS993C is the program in 405CD to reset this
to a particular check point. Note that A/P is not on the list for 405
CD. Not all programs have this particular repair made easy by BPCS.
You may want to list these data areas, to see which are susceptible to
manual repairs outside of SYS993C focus.
OBJTYPE(*DTAARA) and DETAIL(*BASIC) within DSPOBJ of wherever your BPCS
files etc. located. I wrote an RPG to compare each to the next to
highlight major differences in contents.
Some of the info, associated with some program, might be stored in
parameters, or local data area, whose contents will be lost if the work
session is killed then restarted.
There's also the phenomena of something "in use", where a cluster of
programs might need to access something, and keep other programs and
users out of that customer order item facility whatever until the task
has completed. If the task gets disrupted, then we miss the end of task
step to reset the "in use" flag(s).
If the user remembers details from immediately before the crash, and if
you are familiar with the files, then DFU can quickly fix this.
Otherwise you may need QUERY to list everything that is in-use, and some
mass fix.
I have a cheat sheet on "in use" scenarios ... cut paste from there (I
can e-mail it to you off-list), for example:
. HPH is the header physical file that contains the "in use" flag
for
purchase orders. The value "1" means the order is currently "in use".
Change this to blank or zero to say that it is not "in use".
. HPHL02 is a logical access to HPH file that works great when
fixing
"in use" via DFU.
Most users today are via PCs, which can be subject to dropping
connection with the 400-I in the middle of a BPCS program, or various
other mishaps.
Everyone who works the company should remain aware of what factors
contribute to such disconnections, such as bad weather, time of day,
numbers of concurrent users in particular programs, other uses of
corporate telecommunications. This to avoid running certain types of
programs during times of high risk, avoid having fragile software
building large batches, without good "saves".
There also should be check lists in place, how to recover from the
different kinds of mishaps, to minimize incomplete recoveries, and
people at cross-purposes.
At the instant of failure, an interactive program could be trying to
update a bunch of files, in sync with each other, so now we have partial
updates, where the files are not in sync with each other, with respect
to whatever the user was doing.
A common problem is for the 400 to believe the session is still active,
while the PC thinks the session is broke, so when the user tries to sign
on again, they are told, that session side is in use, with a total lack
of meaningful error message scenario. Ideally, we want the 400 to
remember the lost session long enough for the user to get back there,
then immediately take their work session to a menu, which will reset
flags and save totals.
For most programs, it is Ok to kill the job, restart from scratch. This
won't work for a lot of accounting, labor ticket input, shop order
launch, shipping. IT should be familiar with which applications need
more recovery effort, and which menu options to use for the different
kinds of resettings.
In some cases, modifications may have been needed to support this. On
our system, I have copied all such reset options to a consolidated menu
FXS.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
Don Cavaiani
Sent: Wednesday, May 12, 2010 1:30 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] A/P Check Payment SNAFU
Below is the description I asked our Payables Supervisor to phase - in
hopes that someone on the list would recognize this issue:
What happened yesterday is when I got the invoices ready for payment and
everything matched up I go into ACP650 to make payments: The bank 001
has the correct $ amount to use and agrees with my report. I fill in
Bank 001 and hit enter it goes to ACP650-03 at this screen it should say
170 numbered produced and the amount of payment should be $467033.31.
But when I entered my series of check numbers into the number range area
my computer lost connection. I explained to you that I could not get out
of that screen because I may lose everything. So I then tried to call
it back to re-enter it and it was locked (IT next changed the data area
to unlock it).
So I went out there again and when I call up the ACP650 and the first
screen is correct, but when I enter to the next screen it comes up with
different amount of checks. One time I did it came up to 165 checks, and
I re did it and it came up with 168, and I tried again and it came back
with 165 and the dollar amount also changes from $20,506.68 off at the
165 checks, and
$3817.53 off at the 168 checks.
I have not allocated any checks yet so the check run is not allocated at
all. It would not let me allocate if I wanted to because the amount of
checks I have is at 170 and the screen only shows 165 or 168, so the it
would not zero out. And if it did let me for some reason the check
numbers would be off from what the checks were given to the invoices. I
hope this helps!!!
Don F. Cavaiani
Amerequip Corp.
920-894-7063
"Only one who devotes himself to a cause with his whole strength and
soul can be a true master. For this reason mastery demands all of a
person."
Albert Einstein
--
This is the 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.
Delivered-To: macwheel99@xxxxxxxxxx
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.819 / Virus Database: 271.1.1/2869 - Release Date: 05/12/10
01:26:00
--
This is the 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.
Delivered-To: dcavaiani@xxxxxxxxxxxxx
midrange.com
