RE: MONMSG CPF2130 was: CL program

Sure, but that only works if you want to ignore ALL the errors, not do
something specific when you get the error. Anyway, I always put a MONMSG
after the statements which I think may get errors, and take appropriate
action. The MONMSG CPF0000 at the top goes to a label at the end which is a
generic error handler for things that are not caught by the individual
MONMSGs. That way the program never gives a run-time error - it pages the
on-call programmer and gracefully exits. There is a RETURN statement just
before the error handling section so that normal completion won't page
anybody.

Francis Lapeyre
IS Dept. Programmer/Analyst
Stewart Enterprises, Inc.
E-mail: flapeyre@xxxxxxxx 




-----Original Message-----
From: midrange-l-bounces+flapeyre=stei.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+flapeyre=stei.com@xxxxxxxxxxxx] On Behalf Of
Booth Martin
Sent: Tuesday, January 31, 2006 10:48 AM
To: Midrange Systems Technical Discussion
Subject: Re: MONMSG CPF2130 was: CL program

If one chooses to put the monmsg at the top of the CL program, doesn't that
do it for the entire CL program?  No need to write it after every CRTDUPOBJ?


rob@xxxxxxxxx wrote:
> Yes you can CRTDUPOBJ more than one file.  You can do it a couple of ways.
> 
> 1 - Use generics and one command.
> CRTDUPOBJ OBJ(MYFILE*) FROMLIB(MYLIB) OBJTYPE(*FILE) MONMSG ...
> 
> 2 - Or single string them.
> CRTDUPOBJ OBJ(MYFILE1) FROMLIB(MYLIB) OBJTYPE(*FILE) MONMSG ...
> CRTDUPOBJ OBJ(MYFILE2) FROMLIB(MYLIB) OBJTYPE(*FILE) MONMSG...
> 
> They both have their pro's and con's.  You may like the latter method 
> if you only care that a particular object did not dup - and not why it 
> didn't dup.  But I suppose that same philosophy could be applied to the
former.
> Clean up of the objects that did dup in case of failure in the latter 
> case may be easier to handle.  Then again, if you're going to QTEMP a 
> simple CLRLIB QTEMP is quite succinct.
> 
> Rob Berendt

--
-----------------------------------
Booth Martin
http://martinvt.com
-----------------------------------
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.