RE: [SYSTEM21] Failed GLUPDATE Job (originally subject was erroneously "RPG Question")

[Richard_Caldicott@xxxxxxxxxxxxxxx]

Glad it worked out.  Carl does a great job in recovery situations.

Richard Caldicott
Director of Implementations
& Efficiencies
Tandy Brands Accessories
817-548-0090 extn 146


                                                                                
                                                        
                      "Brunk, Kevin"                                            
                                                        
                      <KBrunk@xxxxxxxxxx        To:       "System 21 Users" 
<system21@xxxxxxxxxxxx>                                     
                      om>                       cc:                             
                                                        
                      Sent by:                  Subject:  RE: [SYSTEM21] Failed 
GLUPDATE Job (originally subject was  erroneously "RPG  
                      system21-bounces@m         Question")                     
                                                        
                      idrange.com                                               
                                                        
                                                                                
                                                        
                                                                                
                                                        
                      09/09/2004 07:23                                          
                                                        
                      AM                                                        
                                                        
                      Please respond to                                         
                                                        
                      System 21 Users                                           
                                                        
                                                                                
                                                        
                                                                                
                                                        




Richard,

We eventually worked with Carl @ GEAC who worked with us (almost all day)
to resolve this.  Your solution was almost exactly what we did.  The
exception was that we first posted a reversal of the 4 lines (of the 37,000
possible) that had posted, and in OEP65 all we had to do was blank out
GLUP65.  We didn't have to set the print flag.  We also had to flag the
original GL session (the failed one) as cancelled.  We print about 3000
invoices a day and they are being printed on demand, so we knew that within
seconds of our updating the GLUP65 flag, an invoice would be printed. We
then, also, had to do an invoice post and then run the AFI, and restart the
GLUPDATE background job.  Doing all this has seemed to fix the problem and
get us back to where we were.

Carl was terrific, by the way, he stayed with us throughout the day as we
checked and double checked each step as we proceeded.  Great support from
GEAC in this case.

==Kevin Brunk (for Donna!)



-----Original Message-----

From: system21-bounces@xxxxxxxxxxxx [mailto:system21-bounces@xxxxxxxxxxxx]
On Behalf Of Richard_Caldicott@xxxxxxxxxxxxxxx

Sent: Wednesday, September 08, 2004 10:46 AM

To: System 21 Users

Subject: RE: [SYSTEM21] RPG question



What concerns me here is the error that was creating the error report. My
guess is that it is the same one repeated multiple times. Do you know what
the error is and what is the status of UPDNOG on FLP007? You may also wish
to consider consolidating your AFI postings to create fewer FLP008 records
per run. The other issue here is that your invoices have been posted to A/R
- rerunning the AFI portion will mean that you could loose the link between
A/R and OE, if you use it.

If you check everything out and decide to correct the data I would suggest
SQLing the company code on both FLP007 & FLP008 to 'XX' (providing that
isn't a valid company for you) - you can remove these at a later date. You
should be able to access the FLP007 records by session but the FLP008
records probably need to be accessed with a range of DOCREFs and UPDNOG =
0.

After verifying that the G/L error you got before isn't a problem (or you
fix the issue) and having corrected your AFI rules you can set the print
flag on OEP65 records to 'S' and the GLUP65 to blank. If you then process a
dummy invoice for $1, you should pull through the new extract. This will of
course generate new invoice copies too which you will probably want to
discard.

I haven't had chance to double check all these notes so you will want to
RUN A TEST before trying this in live just in case I missed a setting.

Oh, and I'm still concerned about the G/L error....................

Richard Caldicott

Director of Implementations

& Efficiencies

Tandy Brands Accessories

817-548-0090 extn 146



"Thomas, Donna"

<DThomas@wabutler. To: "System 21 Users" <system21@xxxxxxxxxxxx>

com> cc:

Sent by: Subject: RE: [SYSTEM21] RPG question

system21-bounces@m

idrange.com

09/08/2004 09:02

AM

Please respond to

System 21 Users







I'm wondering if anyone has ever had to recover a failed GLUPDATE job?

We update our invoices in GL using AFI, which is driven by posting rules in
FIP45. On 9/7/04, the AFIGLUPDAT job produced a 13,000 page EXCEPTIONS -
DEFAULT ACCOUNT POSTINGS report (FI551PT3). The error message was ' Rule
not found'. We have since determined that the AFI posting rule in our FIP45
records is no longer on the system because a new newly numbered rule has
been made effective. The FLP008 records were created with the actual
account as the GL account number, but when background job GLUPDATE tried to
process those FLP008 records, the program GL161, looped and produced a
spool file so large, it caused a critical storage warning on our system.
There are approximately 130,000

FLP008 records that have this problem that haven't been processed by
GLUPDATE.

The UPDNOG (Update Number General Ledger) is still 0 for the FLP008 records
in the session, which leads me to believe general ledger accounts have not
been updated with this information. Is that correct?

I'm trying to determine how to recover from this. I am thinking of deleting
the FLP008 and associated FLP007 records for this session and then updating
the FIP45 records to use the correct AFI posting rule, re-running the
AFIGLUPDAT and seeing if the new FLP007 and FLP008 records would process
through the GLUPDATE job. Will this recovery work?

If not, how do I recover this?

We are using version 3.5.0b of System 21, if that matters.

== Donna Thomas

The Butler Company.

==Kevin Brunk
The Butler Company
5600 Blazer Parkway
Dublin, OH 43017-7545
TEL: 614-659-1666
FAX: 614-659-1667



**********************************************************************
CONFIDENTIALITY NOTICE:  The information transmitted in this message is
intended only for the person or entity to which it is addressed and may
contain confidential and/or privileged material.  Any review,
retransmission, dissemination or other use of this information by persons
or entities other than the intended recipient is prohibited.  If you
received this in error, please contact the sender and destroy all copies of
this document.  Thank you.
The Butler Company
**********************************************************************

_______________________________________________
This is the System 21 Users (SYSTEM21) mailing list
To post a message email: SYSTEM21@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/system21
or email: SYSTEM21-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/system21.