Re: MONMSG CPF2130 was: CL program

[Wayne McAlpine <wayne.mcalpine@xxxxxxxxxxxxxxxxx>]

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.