Re: Journal Imbalance V4.05 -- BPCS-L

Good Day ... it is Turkey Day here

I am V405 CD but it so happens I just came home to get a nap in the middle of End Month (year 2003 period 11) ... my mind is a bit foggy right now, and of course everything I post here is out of my brain, because I not have access to BPCS 400 at home PC.

Typically when someone says they posted something successfully, but it is seriously messed up, that means the user thinks they went through the steps they normally go through, and nothing else seemed to go wrong, which is not the same as doing the job successfully. In this case you might want to RUNQRY *N on the journals that theoretically were entered right before and right after the crisis ... I would have a suspicion that the number they gave you is not the whole story ... often the user does not have the foggiest notion what is going on under the BPCS covers, and my situation is not much better.

Typically the 400 never crashes ... worst case scenario, you end up with two threads in conflict and have to end one of them ... rather what happens is a user is on a PC which is unstable (I think all PCs with Windoze are unstable by definition) and what crashes is the PC, and it was in the middle of some BPCS job when it does so, and now something is messed up with respect to the task the user was doing. If the computer analyst can get to the work areas for the user session before the user goes back into that job, there is debris which can be used to reconstruct the broken job, but invariably the users stumble through best they can and do not call for analyst help until the situation is beyond repair.

A lot of BPCS vanilla programs work by joining valid content ... if something is messed up you get to see nothing, because the program looks up some file detail, finds nothing, and ends access, so you not get to see the fact that there is a header with no detail, vica versa, or part of the record not coded active, and other part coded normal. So when something is corrupted, you have to use tools in addition to vanilla BPCS to deciipher what is going on. We have added some logical files in addition to what came with BPCS to help us with a variety of problem solving.

Even if you truely do not have source code DSPFFD and file name will give you the layout of the file RUNQRY *N F4 bottom line *YES (selection criteria) gets you at the population patterns GO CMDREF can give you access to what resources used by which programs from the top down I did a dump of all of BPCS identities into a file that I access by query to trace this stuff from the bottom up

In General Ledger there is (among other files)
GJW (work) which is a volatile area that I want to stay out of
GJD (detail journal)
GJH (header journal)

seems to me that each journal consists of 2 letters then 4 digits the 2 letters are source like IN inventory BL billing and so forth the 4 digits are assigned sequentially & I have no idea where it keeps track of next # to assign (we have on occasion had to do some repairs when we ran out of #s & it would have helped had I been able to figure that out

GJH has one record with summary of the stuff for each journal GJD has one record for each of the transactions in there there is some coding with respect to has this been posted or not, is there an unresolved error, etc. From what you describing, sure sounds like a corrupted journal

Now if this was where I work, the solution would be DELETE THE WHOLE JOURNAL AND START OVER but if the data coming from inventory or billing or some place that it is not practical to start over, then key in the replacement stuff as a corrected journal

In other words when it is all mucked up, we do not try to repair it, we try to get the job done with the least amount of hassle for everyone

If you want to do that, you will need to make darn sure there are no GJD records on this journal, in addition to making the GJH record go away. Another possibility is to change the record-id so that the data is invisible to BPCS but still there to examine further.

It helps to look at the layout of journals where the transactions done with, in good shape, so you can see what is the normal pattern.

Normally in BPCS we have XYZ is the physical file XYZL## is logical access path there are a few cases of XYXJ## join two or more files and you just found one of those in GLD

I have found that you cannot use the J join files as the place to go to do some corrections, you have to do that in the physical or standard logical files

V405CD came with source code, and like everything else in BPCS it is Security by Obscurity (good luck on finding things if no one tells you about BPCSDOC and how to access HELP without having to run the programs to figure out how the screens are interconnected) ... normally in any given library there is the execution code and Q-whatever-language-SRC with the source code for that library, but base BPCS (prior to all the PTF REL Y2K BMR etc.) was stored in library BPCS405CDS (S for source) not in the standard BPCS *LIBL library list.

In later versions of BPCS, instead of source code, there is AS/Set, and you pay extra to get access to source code and/or AS/Set, which is like a precompiler of the source code.

you wrote:

Hi Everyone,

Whilst posting a manual Payroll Journal I was advised by a user that the
'system crashed'.  - After the crash occurred they re-entered the manual
journal and managed to post it successfully.

Unfortunately when the Trial Balance is run they have a discrepancy of
$248613.85.  I have had a look in GJH and found there is a journal entry
which appears as follows which contains the description for the journal
that the user reported as having crashed.

Rcd ID = JP
Company = 60
Year = 2004
Period = 3
Journal Entry = 586
Total Debits = 0
Total Credits = 0
Nbr of Recs = 0
Entered Debits = 478351.38
Entered Lines = 33

I have had a look for the corresponding detail in GJD - but there is no
trace of the transaction.

I had a look at the Trial Balance program and noted that it Reads through a
joined logical GJDJ01.

I have tried to do a Journal Inquiry with BPCS to view journal 586 - but it
says there are no journal entries in the range.

To add to the difficulty there is no source on their AS/400 and no SQL or
selective query ability so everything has to be done by copyfile and then
runqry *N.

Should I just take a copy of this header record for safe keeping and then
DFU it out to get rid of it or are there other files that I should be
concerned about.

If anyone could help me (I am definitely a non accountant) it would be
great.

Regards,


Kylea White
Analyst/Programmer

Focal Systems Pty Ltd
Level 1, Hyatt Centre,
123 Adelaide Terrace,
East Perth   WA   6004
Australia


Phone:  61 8 9223 7900
Fax:        61 8 9223 7979
Email:  kwhite@xxxxxxxxxxxxxxxxxxx
Web:  www.focalsystems.com.au


_______________________________________________
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.

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