IBM Mainframe Forum

Good Morning all,
I have setup a management class to migrate CICS dump datasets with a retention limit of 1;

Expire after Days Non-usage . : 15
Expire after Date/Days . . . . : 15
Retention Limit . . . . . . . : 1
Migration Attributes
Primary Days Non-usage . : 1
Level 1 Days Date/Days . : 60
Command or Auto Migrate . : BOTH


GDG Management Attributes
# GDG Elements on Primary : 2
Rolled-off GDS Action . . : MIGRATE

These datasets are allocated in the CICS regions SYSMDUMP DD - these datasets are not getting migrated like I expected, and I'm assuming it’s because the GDG(s) are always in use ENQUEDED, is this a correct assumption?
Should I get the CICS folks to pre-allocate the GDG in a prior step and do a disp=shr on the dataset in the DFHSIP step? or will I get the same results, any help would be appreciated.

Thanks
Peter

Peter_Mann wrote:...These datasets are allocated in the CICS regions SYSMDUMP DD - these datasets are not getting migrated like I expected, and I'm assuming it’s because the GDG(s) are always in use ENQUEDED, is this a correct assumption?
Should I get the CICS folks to pre-allocate the GDG in a prior step and do a disp=shr on the dataset in the DFHSIP step? or will I get the same results, any help would be appreciated.

I think your theory is correct, but I doubt your proposed solution will work.There are two ENQ locks here:

• One lock is to protect the GDG base. This is always an exclusive ENQ, and it exists for the life of the job.
• The other lock is the dataset ENQ. Once an eclusive lock is acquired it cannot be downgraded to a shared lock. In other words, DISP=NEW in one step gets an exclusive lock that is not downgraded to a shared lock when the next step specifies DISP=SHR.

GDG datasets are usually a good idea, but I'm not so sure this is an appropriate use, mostly because of the management issues you have already discovered. I think you need to retain more generations.

A shared lock can be upgraded to an exclusive lock, but not in JCL. if you specify DISP=SHR in one step and DISP=OLD in a subsequent step you hold an exclusive lock for the life of the job to the last step that uses the dataset.

Well, I got into a foot in mouth situation. The lock for the GDG base is not always exclusive.

I ran this JCL.The WAIT command is a sleep command, in this case for 1 minute and 0 seconds. The two jobs ran in parallel. There was no problem with dataset ENQs since all datasets specified DISP=SHR.

I then changed the DISP=SHR to DISP=OLD for the two GDG datasets. The second job was blocked by a dataset ENQ for the GDG base, even though the GDG was not being altered in any way, and the two datasets were, in fact, different datasets.

I was with you Steve on you first response, it makes perfect sense, and I shoud have tested my theory as you did. If I remember correctly, the last place I worked used my proposed method (pre-allocate, DISP=SHR next step), and I believe this worked, and I think I have your old wait program from our Boeing days

Thanks so much for your response.
Peter( Carmen )

steve-myers wrote:Well, I got into a foot in mouth situation. The lock for the GDG base is not always exclusive.

I ran this JCL.

Select all

//XXXXXXA  JOB (12345678),XXXXXX,MSGCLASS=H,
//        MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID
//JOBLIB   DD  DISP=(SHR,PASS),DSN=XXXXXX.LOAD
//         DD  DISP=(SHR,PASS),DSN=XXXXXX.OLOAD
//A       EXEC PGM=IKJEFT01
//SYSTSPRT DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=SHR,DSN=XXXXXX.TESTGDG(0)
//SYSUT2   DD  SYSOUT=*
//SYSIN    DD  DUMMY
//SYSTSIN  DD  *
CALL *(IEBGENER)
TIME
WAIT FOR(1:0)
TIME
//XXXXXXB  JOB (12345678),XXXXXX,MSGCLASS=H,
//        MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID
//JOBLIB   DD  DISP=(SHR,PASS),DSN=XXXXXX.LOAD
//         DD  DISP=(SHR,PASS),DSN=XXXXXX.OLOAD
//A       EXEC PGM=IKJEFT01
//SYSTSPRT DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=SHR,DSN=XXXXXX.TESTGDG(-1)
//SYSUT2   DD  SYSOUT=*
//SYSIN    DD  DUMMY
//SYSTSIN  DD  *
CALL *(IEBGENER)
TIME
WAIT FOR(1:0)
TIME

The WAIT command is a sleep command, in this case for 1 minute and 0 seconds. The two jobs ran in parallel. There was no problem with dataset ENQs since all datasets specified DISP=SHR.

I then changed the DISP=SHR to DISP=OLD for the two GDG datasets. The second job was blocked by a dataset ENQ for the GDG base, even though the GDG was not being altered in any way, and the two datasets were, in fact, different datasets.

Steve, I tried a similar approach;

//ALOCGDG EXEC PGM=IEFBR14
//DD1 DD DSN=ODTECPV.TEST.GDG01(+1),DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(TRK,(1,1))
//WAIT EXEC PGM=WAIT,PARM='001505'
//STEPLIB DD DSN=ODTECPV.TEST.LOAD,DISP=SHR
//DD2 DD DSN=ODTECPV.TEST.GDG01(+1),DISP=SHR
I ran the BR14 step twice to get GEN 1 and GEN 2 allocated, then ran the above JCL (sleep) 15 mins 05 seconds, the BR14 created GEN 3, then I went to 3.4 and deleted GEN 1 + 2, so I think, in theary, HSM will be able to MIGRATE the datasets not in use. does this sound correct?
Thanks

I think HSM allocates the datasets using their true name rather than by their relative generation, so the issue about the ENQ on the GDG base does not apply. The issue about downgrading the dataset ENQ from exclusive to shared in the job does apply.

I don't believe I ever encountered the batch WAIT program you used. I think the WAIT TSO command was part of the Boeing Helicopters MVS system ( though not elsewhere in Boeing) while I was there in the 1990s, though I brought it there from prior employment.

Steve, the HSM allocation is something I have to test also, but again that makes more sense what you've said.
yeah, looking again at the WAIT code, it's something, I got from K. Guenther, it works well enought for me.
thanks again. take care
Peter (Carmen )

HSM does the allocate the full name (not relative gen)......

Thanks Mike, I've fought the battle - I lost - the CICS Sysprog is going to manage the dumps, and it there's an issue with CICS regions not comming up due to space issues (DUMP VOLUMES), the SOP is to contact her, not me.
Have a good weekend and Thanks.
Peter