|
View previous topic :: View next topic
|
| Author |
Message |
Dsingh29
Active User
Joined: 16 Dec 2008
Posts: 132
Location: IBM
|
|
|
|
Hi All,
We are facing a problem of excessive time for one of our job. Its abending with S222.
S222 says " --POSSIBLE CAUSE--
LINE OR CARD ESTIMATE EXCEEDED
JCL ERROR CAUSED MOUNT REQUEST FOR INVALID OR NON-EXISTING VOLUME
REQUESTED DEVICES NOT CURRENTLY AVAILABLE "
Our generations are on tapes and sometimes are on multiple volumes and/or GRIDS.
System support told that culprit could a IEFBR14 step where job deletes all the generations of a GDG. We delete previous months generations on 31st of every month so that new month's generations start with G001.
we are using following disposition:
| Code: |
//DD1 DD DSN=my.gdg.base.name,
// UNIT=(CART,,DEFER),
// DISP=(SHR,UNCATLG,UNCATLG) |
we have also tried with
| Code: |
| DISP=(OLD,DELETE,DELETE) |
, disp=del, doesnt abend with S222 but takes considerable amount of time.
I was thinking may be we shall alter GDG attribute to EMPTY but I guess that will make new generation 32 after uncatloging previous 31 generations.
Can you please provide your inputs, as to which approach would be best suited here.
Please let me know if you need more inputs.
Many Thanks !! |
|
| Back to top |
|
 |
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India
|
|
|
|
Hi,
Have you tried IDCAMS with
| Code: |
| DELETE (WELLS.GDG.BASE.NAME) GDG FORCE |
I think IDCAMS will not perform tape mounts for DELETE statement, so this might be faster.
Im open to correction. |
|
| Back to top |
|
|
Dsingh29
Active User
Joined: 16 Dec 2008
Posts: 132
Location: IBM
|
|
|
|
Hi Vasanth,
I have researched a bit on IDCAMS, and found that it will not mount tapes for deleting dataset, therefore would be faster, as you have said. Thanks.
Your syntax will delete the gdg base also , I only want to delete the generations not the base so that new month starts with 01 generation.
I have tried deleting generations using
| Code: |
| DELETE my.gdg.generations.* |
this deletes all generations. All good till here.
But there are other files in production which might satisfy the above criteria like
my.gdg.generations.bkp which might get deleted which I dont want.
Any ideas, on how to ensure that only gdg generations are deleted and not other files satisfying the criteria.
Thanks in advance. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India
|
|
|
|
You can have another DEFINE statement in the same DELETE IDCAMS step to define GDG base again.
| Code: |
//DEF01 EXEC PGM=IDCAMS,COND=(0,LT)
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
DELETE (WELLS.GDG.BASE) GDG FORCE
DEFINE GDG (NAME(WELLS.GDG.BASE) -
LIMIT(20) -
NOEMPTY -
SCRATCH)
/*
|
You might have to change the LIMIT SCRATCH things for your requirement. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| vasanthz wrote: |
Have you tried IDCAMS with
| Code: |
| DELETE (WELLS.GDG.BASE.NAME) GDG FORCE |
|
DELETE GDG FORCE is not advisable and many shops lock it down.
If you have a generation data group with generation data sets that have migrated, and you wish to delete the group and you use the Access Method Services DELETE GDG FORCE command to delete the catalog entries for the generation data group and its generation data sets, IDCAMS does not invoke DFSMShsm. You must then issue the DFSMShsm DELETE command for each of the now-uncataloged migration copies. |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India
|
|
|
|
| @Anuj Thanks for the information. Tested it out and the uncatalogued generations are still left out, after the IDCAMS FORCE DELETE. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| vasanthz wrote: |
| @Anuj Thanks for the information. Tested it out and the uncatalogued generations are still left out, after the IDCAMS FORCE DELETE. |
Thanks for the test but I never thought to mislead you!  |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India
|
|
|
|
| Anuj, I was not doubting your post. I just wanted to see what happens internally, so tested it out. I know your posts are highly credible and reliable (: |
|
| Back to top |
|
|
Dsingh29
Active User
Joined: 16 Dec 2008
Posts: 132
Location: IBM
|
|
|
|
Hi All,
Out of the many options put forth before the client, he liked using the disp=(shr,uncatlg,keep) in the same step where the gdg generations are being read and copied into monthly backup file.
Therefore, we are doing away with any new step for explicit delete/uncatlg of gdg generations.
Not Sure how much impact it would have on overall execution time of the job, any ideas. Will it make the job execution time a little lower ? |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| Quote: |
| Out of the many options put forth before the client, he liked using the disp=(shr,uncatlg,keep) in the same step where the gdg generations are being read and copied into monthly backup file. |
Have you had a chance to discuss this with your Storge-Group as well? And do they agree? Once they are UNCATLoGed and left around, what is next to be done with them?
So far with what you put here, it sounds that your shop is SMS managed and if so, and you UNCATLG a GDS, you controdict the unstated basic definition of SMS environment that if a dataset is SMS managed, it must be cataloged otherwise you will get all sort of nasty messages. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
I did not follow this thread intially, but using NOSCRATCH does not help you? NOSCRATCH - Specifies that the generation data set is not to be removed from the VTOC of the volume on which it resides when it is uncataloged or rolled-off. But again you'd need to talk to Storage-group because when a GDS gets rolled off it will get deleted, if the following is specified in the MGMTCLAS definition:
| Quote: |
| ROLLED OFF GDS ACTION ....... EXPIRE |
and in that case, the GDG base definition will not be honored. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| Anuj Dhawan wrote: |
| So far with what you put here, it sounds that your shop is SMS managed and if so, and you UNCATLG a GDS, you controdict the unstated basic definition of SMS environment that if a dataset is SMS managed, it must be cataloged otherwise you will get all sort of nasty messages. |
But if SMS is active, will not UNCATLG and KEEP be treated as CATLG, so that the parameter as specified is equivalent to DISP=SHR? |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 592
Location: London
|
|
|
|
Boys boys!
If you're on >=ZOS 1.11 then you can use the DELETE MASK option
Refer to : publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.idak100/amsr11.htm
e.g. This will delete just the GDS's in the GDG base and not touch the GDG base itsself. You can mask a whole level with '*' but obviously that may delete more than you want, but the below is quite specific and would be safe to use. I have just tested it and it works fine.
DELETE GDG.BASE.NAME.G%%%%V00 MASK |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
| Back to top |
|
|
Rituraj Singh Rawat
New User
.jpg)
Joined: 29 Feb 2012
Posts: 13
Location: India
|
|
|
|
Please correct me if i am wrong !!
Requirement is to delete all the generations without deleting the base.
If we use the gdg base name only, we can perform this operation.
| Code: |
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USERID.TEST.MYGDG,DISP=(OLD,DELETE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY |
|
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
You are wrong
Take a look at the very first post of the topic, where the OP was using IEFBR14, which seems to have caused all of the problems.
As for the IDCAMS GDG DELETE FORCE ... why
The CSI solution I gave will delete each individual generation in its own right, so if it is tape there is no tape mount required, and if it is migrated as the command is for a specific dataset the HDELETE command is actioned through IDCAMS. |
|
| Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
| From z/os v1.11 you can avoid having IEFBR14 recall migrated datasets just to delete them. Thus the TS could stick with his original JCL rather than using IDCAMS. |
|
| Back to top |
|
|
|
|
