RE: CL Error handling

["Jim Wiant" <Jim.Wiant@xxxxxxxxxxxxxxxx>]

There can be a lot of different error messages depending upon exactly
how the RPG program might die. RNX..., CPF...., etc.

Code a MONMSG CPF0000 and MONMSG RNX0000 after the program and those
monitors should trap any RPG error. Then you can clean up the output
accordingly.

If you want to be more precise you could code some intentional errors in
the program and see what errors are returned to the CL. Then monitor
specifically for those.

Alternately, you could make sure all file operations in your RPG are
trapped (i.e. READ(E), OPEN(E), etc.) and then if any action fails (if
%ERROR) return a status code back to the CL indicating everything didn't
work as normal. The CL could then correct any issues.

3rd option: use transaction processing in the CL (i.e. start commitment
control in the CL), use ROLLBACK and COMMIT logic in the RPG program),
and let the RPG/transaction processing handle rolling back any changes.
This can be more effort, but depending upon the job stream structure can
automatically correct many things for you - regardless of exactly how
the error occurred.


JPW



 

 

The bitterness of poor quality remains long after low pricing is
forgotten! 

 

Cautillo, Leon M.



HI I have a CL that calls an RPG program which writes out file. In case
there are array index errors or other such errors, I am not sure how to
then cancel the program, and to then clear the output file since it is
not
complete.

Thanks,
Steve
This message has been sent from Foodstuffs (Auckland) Limited ("Foodstuffs").

The information contained in this message and or attachments 
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, or taking of any action in reliance upon, this 
information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from any 
system and destroy any copies.

The views and opinions expressed in this message may be those
of the individual and not necessarily those of Foodstuffs, 
and are not given or endorsed by it.

Please note that this communication does not designate an 
information system for the purposes of the Electronic 
Transactions Act 2002.