How to delete 2 GDG member in different steps

Question

I defined a Generation Data Group (GDG) with limit parameter as 5, and let's put (1,2,3,4,5) as members(suppose 5 is current position).

I use a job which has 2 steps each will try to delete a member using IEFBR14 utility.

//STEP10   EXEC PGM=IEFBR14
//SYSOUT   DD  SYSOUT=*
//SYSDEL   DD  DSN=DATA.TEST.GDG(-1),
//             DISP=(MOD,DELETE,DELETE)
//****************************************
//STEP20   EXEC PGM=IEFBR14
//SYSOUT   DD  SYSOUT=*
//SYSDEL   DD  DSN=DATA.TEST.GDG(-2),
//             DISP=(MOD,DELETE,DELETE)

I wish I can get result as (1,2,5), but in fact (1,3,5) was left, member 2 and member 4 was deleted ? it seems after step 1, there is a commit operation, can anybody can help me with this?

But on the other hand, if I try to delete member (0), and member (-2), the result is as what I expected.

//STEP10   EXEC PGM=IEFBR14
//SYSOUT   DD  SYSOUT=*
//SYSDEL   DD  DSN=DATA.TEST.GDG(0),
//             DISP=(MOD,DELETE,DELETE)
//****************************************
//STEP20   EXEC PGM=IEFBR14
//SYSOUT   DD  SYSOUT=*
//SYSDEL   DD  DSN=DATA.TEST.GDG(-2),
//             DISP=(MOD,DELETE,DELETE)

I get the result (1,2,4), member 3 and member 5 were deleted.

One question, why are you using 2 steps ???, are the DSN's on Cart ???. You could used one step and 2 DD's. Also you do not need SYSOUT for IEFBR14 — Bruce Martin, Oct 14 '13 at 07:12

Parushuram · Answer 1 · 2013-10-18T09:24:42.650

JOB1 deletes the Members 2 and 4. Here is how it works.

enter code here
//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=DATA.GDG.TEST(-1),DISP=(MOD,DELETE,DELETE)
//*
//STEP2  EXEC PGM=SORT            <==note:i added this step for TEST purpose  only
//SORTIN DD DSN=DATA.GDG.TEST(-1),DISP=SHR
//SORTOUT DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSIN  DD *
 OPTION COPY
/*
//STEP3 EXEC PGM=IEFBR14
//DD2  DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE,DELETE)

if we have a look at the JESYMSG, we can find the messages as below:

IEF142I GDGTST STEP1 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0004V00               DELETED,   DDNAME=DD1  <==(-1) to 5
**please note here in STEP2 the GDG member refered is 03 not 04 as expected**
IEF142I GDGTST STEP2 - STEP WAS EXECUTED - COND CODE 0000
IGD104I DATA.GDG.TEST.G0003V00               RETAINED,  DDNAME=SORTIN <==(-1) to 4

IEF142I GDGTST STEP3 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0002V00               DELETED,   DDNAME=DD2 <==(-2) to 4

The first time you use a relative generation number for a generation data group within a job, the system establishes the relationship between the relative generation number and the absolute generation number. The system maintains this relationship throughout the job.(reference: z/OS MVS JCL user's guide-APPENDIX B)

For example, if you create a generation data set with a relative generation number of (+1), the system recognizes any subsequent reference to (+1) throughout the job as having the same absolute generation number.

(+1)--> adding a member raltive to most recently added member(i.e.,(0))
(+2)-->(+1) to (+1)
(+3)--> (+1) to (+2)

likewise, in the JOB1 that you posted the reference is set to (-1) i.e, G0004V00 at the starting of the job. This (-1) relationship is maintained throughout the job. result of STEP2 in the job psosted by me proves this point.

so to achieve the result (1,3,5) give (-1) in both the steps(STEP10 and STEP20) of JOB1. that will work. above results are for JES2, not sure about JES3

and for JOB2 in Main question:

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=DATA.GDG.TEST(0),DISP=(MOD,DELETE,DELETE)
//SYSOUT  DD SYSOUT=*
//STEP2  EXEC PGM=SORT
//SORTIN DD DSN=DATA.GDG.TEST(-1),DISP=SHR
//SORTOUT DD DUMMY
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN  DD *
  OPTION COPY
/*
//STEP3 EXEC PGM=IEFBR14
//DD2  DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE)
//SYSOUT DD SYSOUT=*
//STEP4 EXEC PGM=IEFBR14
//MODEL1 DD DSN=DATA.GDG.TEST(-1),DISP=(MOD,DELETE)

the JESYMSG is as below:

IEF142I GDGTST STEP1 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0005V00           DELETED,   DDNAME=DD1
IEF142I GDGTST STEP2 - STEP WAS EXECUTED - COND CODE 0000
IGD104I DATA.GDG.TEST.G0004V00           RETAINED,  DDNAME=SORTIN
IEF142I GDGTST STEP3 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0003V00           DELETED,   DDNAME=DD2
IEF142I GDGTST STEP4 - STEP WAS EXECUTED - COND CODE 0000
IGD105I DATA.GDG.TEST.G0004V00           DELETED,   DDNAME=MODEL1

as I have explained earlier, the relationship between absolute and relative GDG is established when the job encounters the RELATIVE referencing for the FIRST time. so here in this job, it encounters(0) for the first time. so when the initiator issues ENQ at each step, the generation numbers will be resolved with reference to (0) in JOB2. if we Observe here it deleted(0,3,4)--> for(0),(-2),(-1) in STEP1, STEP3,STEP4. that means, it didn't commit after the execution of eachstep. Reference to (-1) in STEP4 is resolved in relation to (0), which is established in STEP1.

lets consider one more example as below: if I add one morestep STEP5 like below to above job

 //STEP1 EXEC PGM=IEFBR14
 //DD1   DD DSN=DATA.GDG.TEST(-0),DISP=(MOD,DELETE,DELETE)
 //SYSOUT  DD SYSOUT=*
 //STEP2  EXEC PGM=SORT
 //SORTIN DD DSN=DATA.GDG.TEST(-1),DISP=SHR
 //SORTOUT DD DUMMY
 //SYSOUT DD SYSOUT=*
 //SYSPRINT DD SYSOUT=*
 //SYSIN  DD *
   OPTION COPY
 /*
 //STEP3 EXEC PGM=IEFBR14
 //DD2  DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE,DELETE)
 //SYSOUT DD SYSOUT=*
 //STEP4 EXEC PGM=IEFBR14
 //MODEL1 DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE)
//STEP5 EXEC PGM=IEFBR14
//DD2  DD DSN=DATA.GDG.TEST(-1),DISP=(MOD,DELETE,DELETE)
//STEP6 EXEC PGM=IEFBR14
//DD2  DD DSN=DATA.GDG.TEST(-2),DISP=(MOD,DELETE,DELETE)

it deletes(0,3,2,4)--> because at the starting of STEP4 it encountered a Ambiguity, so it resolved the reference against the catologue. For STEP6, again it has ambiguity so again it tries to resolve the reference according to the catologue, now as there are not enough generation members present(as we have created only 5 members and deleted 4 already),it throws the message like below:

IEF286I GDGTST STEP6 DD2 - DISP FIELD INCOMPATIBLE WITH DSNAME
IEF272I GDGTST STEP6 - STEP WAS NOT EXECUTED.

The joys of working with GDG's. What results do you get for the second job from the original question? One might expect to see members 5 and 2 deleted as opposed to 5 and 3? — NealB, Oct 17 '13 at 17:30
@NEALB:added some more points to the answer, could you please check it. — Parushuram, Oct 18 '13 at 09:26
I've got a link for the reference you want, but the more up-to-date z/OS User guide, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/iea2b550/APPENDIX1.1.2.6 — Bill Woodger, Oct 18 '13 at 16:26
`If a DD statement in a multiple-step job tries to delete or uncatalog any generation data set *except* the oldest in a GDG, catalog management can lose orientation within the data group. This could cause the deletion, uncataloging, or retrieval of the wrong data set when you later refer to a specific generation. Therefore, if you delete a generation data set in a multiple-step job, do not refer to any older generations in later job steps.` Is the key quote, I think. If doing it, only delete the oldest generation. Definitely don't reference an older generation than one which has been deleted. — Bill Woodger, Oct 18 '13 at 16:28
You can incorporate the link and the quote in your answer. For me it is bad enough to attempt to create more than one generation in one job, let alone delete them :-) — Bill Woodger, Oct 18 '13 at 16:30

How to delete 2 GDG member in different steps

1 Answers1