RE: MONMSG CPF2130 was: CL program

["Lapeyre, Francis" <FLAPEYRE@xxxxxxxx>]

Yes, but in this case, the error processing is the same. 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Wayne McAlpine
Sent: Tuesday, January 31, 2006 4:25 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: MONMSG CPF2130 was: CL program

You can do a global message monitor for CPF2130 and another for CPF0000 and
specify different GOTO's.

Lapeyre, Francis wrote:
> Yes there is (the global MONMSG CPF0000). Anyway, if you get a 
> CPF3142, the file isn't in QTEMP, so how could a CRTDUPOBJ fail? (All 
> our programs use adopted authority, so that won't be a problem).
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of 
> rob-tksaTn4SAz0AvxtiuMwx3w@xxxxxxxxxxxxxxxx
> Sent: Tuesday, January 31, 2006 12:20 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: MONMSG CPF2130 was: CL program
> 
> Like that code...
> But there is no checking to see what happens if the CRTDUPOBJ fails. 
> Which seems to happen a lot here.  And not because it already exists in
the TOLIB.
> 
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> "Lapeyre, Francis" <FLAPEYRE@xxxxxxxx> Sent by: 
> midrange-l-bounces@xxxxxxxxxxxx
> 01/31/2006 11:34 AM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> 
> 
> To
> "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx> cc
> 
> Fax to
> 
> Subject
> RE: MONMSG CPF2130 was: CL program
> 
> 
> 
> 
> 
> 
> Here is what I am doing in a program (duplicating a physical and an 
> associated logical into QTEMP):
> 
> /* Clear temporary decrypted file. Create (as a clone of AROCC)      */ 
> /* if not found. Also create AROCCL6 logical.                        */ 
>              CLRPFM     FILE(QTEMP/AROCC) 
>              MONMSG     MSGID(CPF3142) EXEC(CRTDUPOBJ OBJ(AROCC) + 
>                           FROMLIB(&COMMONLIB) OBJTYPE(*FILE) + 
>                           TOLIB(QTEMP)) 
>              CHKOBJ     OBJ(QTEMP/AROCCL6) OBJTYPE(*FILE) 
>              MONMSG     MSGID(CPF9801) EXEC(CRTDUPOBJ OBJ(AROCCL6) + 
>                           FROMLIB(&COMMONLIB) OBJTYPE(*FILE) + 
>                           TOLIB(QTEMP))
> 
> The program could possibly get called more than once in a job, so 
> there is no sense in deleting and recreating it every time it's called 
> - the file just needs to be empty.
> You can't do a CLRPFM on a logical, obviously, so I'm just checking 
> for existence and duplicating it if not found.
> 
> Francis Lapeyre
> IS Dept. Programmer/Analyst
> Stewart Enterprises, Inc.
> E-mail: flapeyre@xxxxxxxx
> 
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of 
> rob-tksaTn4SAz0AvxtiuMwx3w@xxxxxxxxxxxxxxxx
> Sent: Tuesday, January 31, 2006 10:21 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: MONMSG CPF2130 was: CL program
> 
> 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
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.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.

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