Re: GDG Question
Fred, This is NOT a ThruPut Manager problem. If you bypass ThruPut Manager you will get ... IEF286I IEFBR14 STEPNAME DD1 - DISP FIELD INCOMPATIBLE WITH DSNAME ThruPut Manager is simply reporting what IBM would have report. The 1st step that references that GDG, via the relative generation, resolves the base and subsequent steps use that base. As it appears that you ALWAYS want to delete/create G0001V00, why not code the ABSOLUTE data set name in this job's JCL? And, as you have ThruPut Manager, there are ways of recognizing this job and converting the JCL without any user intervention. You could automatically translate the name to a sequential data set name or your could change this job's (0) to G1V00. Dan Fred Kaptein wrote: Using DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1) is not valid on our system, as we use ThruPut Manager. This JCL results in the following error message DTMI DD1 - DISP FIELD INCOMPATIBLE WITH DSNAME -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GDG Question
Hello, I have a question on GDGs We have a GDG data set GDG.DSNAME.G0001V00 and append data into this data set throughout the day. We then run a batch job where we do the following: 1. Read GDG.DSNAME(0) 2. Delete GDG.DSNAME(0) as follows //DELETE EXEC PGM=IEFBR14 //DD1DD DSN=GDG.DSNAME(0), // DISP=(OLD,DELETE,DELETE) 3. Allocate a new GDG.DSNAME(+1) as follows: //ALLOC EXEC PGM=IEFBR14,COND=(4,LE) //DD1 DD DSN=ISM.SMF.ZHAD011(+1), // DISP=(NEW,CATLG,DELETE),UNIT=3390, // SPACE=(CYL,(50,50)) The ALLOC step actually allocates GDG dataset GDG.DSNAME.G0002V00 Besides changing SMS or running two batch jobs, is there any way to completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Why not use DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1)? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Fred Kaptein Sent: Tuesday, January 18, 2011 11:29 AM To: IBM-MAIN@bama.ua.edu Subject: GDG Question Hello, I have a question on GDGs We have a GDG data set GDG.DSNAME.G0001V00 and append data into this data set throughout the day. We then run a batch job where we do the following: 1. Read GDG.DSNAME(0) 2. Delete GDG.DSNAME(0) as follows //DELETE EXEC PGM=IEFBR14 //DD1DD DSN=GDG.DSNAME(0), // DISP=(OLD,DELETE,DELETE) 3. Allocate a new GDG.DSNAME(+1) as follows: //ALLOC EXEC PGM=IEFBR14,COND=(4,LE) //DD1 DD DSN=ISM.SMF.ZHAD011(+1), // DISP=(NEW,CATLG,DELETE),UNIT=3390, // SPACE=(CYL,(50,50)) The ALLOC step actually allocates GDG dataset GDG.DSNAME.G0002V00 Besides changing SMS or running two batch jobs, is there any way to completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 18 Jan 2011 11:29:25 -0600, Fred Kaptein wrote: is there any way to completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00 No. If GDG.DSNAME(0) is GDG.DSNAME.G0001V00, then GDG.DSNAME(+1) will be GDG.DSNAME.G0002V00 for any reference in that job. This is documented pretty clearly in the JCL manuals. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Using DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1) is not valid on our system, as we use ThruPut Manager. This JCL results in the following error message DTMI DD1 - DISP FIELD INCOMPATIBLE WITH DSNAME -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
It's unclear to me why you want to use a GDG at all. Or why you bother deleting and recreating it. Your step (3) could simply be writing into GDG.NAME(0) with IEBGENER using DISP=OLD and with SYSUT1 as DD DUMMY and you'd accomplish pretty much the same thing as a delete/allocate. But if you must use GDGs, then your step 3 could submit another job to do the allocation, or you could use a job scheduler to run the allocation in a separate job after the deletion finishes. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
My first thought is why use a gdg at all in this situation? Wouldn't a plain data set work just as well. Second is GDG's (relative and absolute) are updated at the END of the job, NOT the end of each step (as best I remember). Relative (0) will be G0001 throughout the job, so (+1) will be G0002 no matter what. else happens. If you Try to alloc ANOTHER (+1) it will tell you G0002 already exists. You have to alloc (+2) to get to G0003 From: Fred Kaptein fred.kapt...@hp.com To: IBM-MAIN@bama.ua.edu Date: 01/18/2011 09:40 AM Subject:GDG Question Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hello, I have a question on GDGs We have a GDG data set GDG.DSNAME.G0001V00 and append data into this data set throughout the day. We then run a batch job where we do the following: 1. Read GDG.DSNAME(0) 2. Delete GDG.DSNAME(0) as follows //DELETE EXEC PGM=IEFBR14 //DD1DD DSN=GDG.DSNAME(0), // DISP=(OLD,DELETE,DELETE) 3. Allocate a new GDG.DSNAME(+1) as follows: //ALLOC EXEC PGM=IEFBR14,COND=(4,LE) //DD1 DD DSN=ISM.SMF.ZHAD011(+1), // DISP=(NEW,CATLG,DELETE),UNIT=3390, // SPACE=(CYL,(50,50)) The ALLOC step actually allocates GDG dataset GDG.DSNAME.G0002V00 Besides changing SMS or running two batch jobs, is there any way to completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Or why not just allocate a standard PS file and then clear it when you are done with it? *don* On Tue, Jan 18, 2011 at 12:43 PM, McKown, John john.mck...@healthmarkets.com wrote: Why not use DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1)? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Fred Kaptein Sent: Tuesday, January 18, 2011 11:29 AM To: IBM-MAIN@bama.ua.edu Subject: GDG Question Hello, I have a question on GDGs We have a GDG data set GDG.DSNAME.G0001V00 and append data into this data set throughout the day. We then run a batch job where we do the following: 1. Read GDG.DSNAME(0) 2. Delete GDG.DSNAME(0) as follows //DELETE EXEC PGM=IEFBR14 //DD1DD DSN=GDG.DSNAME(0), // DISP=(OLD,DELETE,DELETE) 3. Allocate a new GDG.DSNAME(+1) as follows: //ALLOC EXEC PGM=IEFBR14,COND=(4,LE) //DD1 DD DSN=ISM.SMF.ZHAD011(+1), // DISP=(NEW,CATLG,DELETE),UNIT=3390, // SPACE=(CYL,(50,50)) The ALLOC step actually allocates GDG dataset GDG.DSNAME.G0002V00 Besides changing SMS or running two batch jobs, is there any way to completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
I don't think you need either the delete or the allocate. Just use DSN=GDG(0),DISP=OLD for the step that writes data into the GDG. DISP=OLD and open for output will allow you to rewrite the whole dataset starting at the beginning. OTOH if you are truly just appending data (and don't use a trailer record with a record count) you can just use DSN=GDG(0),DISP=MOD. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Fred Kaptein Sent: Tuesday, January 18, 2011 12:29 PM To: IBM-MAIN@bama.ua.edu Subject: GDG Question Hello, I have a question on GDGs We have a GDG data set GDG.DSNAME.G0001V00 and append data into this data set throughout the day. We then run a batch job where we do the following: 1. Read GDG.DSNAME(0) 2. Delete GDG.DSNAME(0) as follows //DELETE EXEC PGM=IEFBR14 //DD1DD DSN=GDG.DSNAME(0), // DISP=(OLD,DELETE,DELETE) 3. Allocate a new GDG.DSNAME(+1) as follows: //ALLOC EXEC PGM=IEFBR14,COND=(4,LE) //DD1 DD DSN=ISM.SMF.ZHAD011(+1), // DISP=(NEW,CATLG,DELETE),UNIT=3390, // SPACE=(CYL,(50,50)) The ALLOC step actually allocates GDG dataset GDG.DSNAME.G0002V00 Besides changing SMS or running two batch jobs, is there any way to completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 2011-01-18 at 13:27 -0500, Tom Marchant wrote: If GDG.DSNAME(0) is GDG.DSNAME.G0001V00, then GDG.DSNAME(+1) will be GDG.DSNAME.G0002V00 for any reference in that job. The GDG name table (GDGNT, mapped by IEFZB429, pointed to from the JCT) contains a list of GDG base names, and their base (+0) generation numbers. It is this static table that resolves relative generation numbers in JCL. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
There are too many JCL changes in other batch jobs, to change this to a non-GDG file. Reusing the same file without deleteing and reallocating the data set is an option. Thank you for your responses, we will take them into consideration. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
If you only have one generation anyway, why not set the limit to 1. Then when you create the new file the old one just goes away. Thank you and have a Terrific day! Jonathan Goossen Tape Specialist ACT Mainframe Storage Group 651-361-4541 From: Fred Kaptein fred.kapt...@hp.com To: IBM-MAIN@bama.ua.edu Date: 01/18/2011 03:48 PM Subject:Re: GDG Question Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu There are too many JCL changes in other batch jobs, to change this to a non-GDG file. Reusing the same file without deleteing and reallocating the data set is an option. Thank you for your responses, we will take them into consideration. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
You could add an IEBGENER Step to copy the GDG.DSNAME.G0002V00 back into a dataset named GDG.DSNAME.G0001V00 if you like. //GDGEXEC PGM=IEBGENER,COND=(0,NE) //SYSOUT DD SYSOUT=(,),OUTPUT=(*.JCL) //SYSPRINT DD SYSOUT=(,),OUTPUT=(*.JCL) //SYSUT1 DD DSN=GDG.DSNAME(+1),DISP=SHR, //SYSUT2 DD DSN=GDG.DSNAME.G0001V00, // DISP=(NEW,CATLG,DELETE, .. //SYSINDD DUMMY Hutchison, Gregory A. Oregon DOT DMVIS phone:503-945-7081 fax:503-945-5220 gregory.hutchi...@odot.state.or.us -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Fred Kaptein Sent: Tuesday, January 18, 2011 1:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question There are too many JCL changes in other batch jobs, to change this to a non-GDG file. Reusing the same file without deleteing and reallocating the data set is an option. Thank you for your responses, we will take them into consideration. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
On Thu, 29 Jan 2009 15:36:19 -0600, Frank Swarbrick wrote: On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant wrote: Maybe. If the gener abends, the XMIT group will be kept. If it fails with a non-zero return code, they will be deleted. Thanks for the warning. I tested it out by forcing an out of space condition and got a D37-04 abend, so I think(!) I'm ok here. That's one error condition. Other conditions might cause it to end with a non-zero return code and no abend. You might want to consider Scott's suggestion of using sort with PARM=ABEND. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
On Fri, 30 Jan 2009 07:12:46 -0600, Tom Marchant m42tom- ibmm...@yahoo.com wrote: On Thu, 29 Jan 2009 15:36:19 -0600, Frank Swarbrick wrote: On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant wrote: Maybe. If the gener abends, the XMIT group will be kept. If it fails with a non-zero return code, they will be deleted. Thanks for the warning. I tested it out by forcing an out of space condition and got a D37-04 abend, so I think(!) I'm ok here. That's one error condition. Other conditions might cause it to end with a non-zero return code and no abend. You might want to consider Scott's suggestion of using sort with PARM=ABEND. OK, I will stop being stubborn. :-) PGM=SORT,PARM=ABEND it is! Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
-snip-- Tom Marchant wrote: On Thu, 29 Jan 2009 15:36:19 -0600, Frank Swarbrick wrote: On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant wrote: Maybe. If the gener abends, the XMIT group will be kept. If it fails with a non-zero return code, they will be deleted. Thanks for the warning. I tested it out by forcing an out of space condition and got a D37-04 abend, so I think(!) I'm ok here. That's one error condition. Other conditions might cause it to end with a non-zero return code and no abend. You might want to consider Scott's suggestion of using sort with PARM=ABEND. --unsnip- Or use an additional step, conditionally executed, to do the deletes. -- Rick -- Remember that if you're not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
First I want to thank everyone for all of their ideas. After due consideration, here is what I think we'll end up doing. I'm going to create two GDG datasets: /* IDCAMS COMMAND */ DEFINE GENERATIONDATAGROUP - (NAME(PROD.XMIT.TXNFILE) - LIMIT(6) - ) /* IDCAMS COMMAND */ DEFINE GENERATIONDATAGROUP - (NAME(PROD.APPL.TXNFILE) - LIMIT(5) FOR(7) - ) Every day we'll receive an FTP of a new generation into PROD.XMIT.TXNFILE. On non-business days we won't do any further processing of the file. On a business day we'll have two jobs. The first one will look very much like this: //GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A //BACKUP EXEC PGM=IEBGENER //SYSUT1 DD DISP=(OLD,DELETE,KEEP),DSN=PROD.XMIT.TXNFILE //SYSUT2 DD DISP=(NEW,CATLG,DELETE),DSN=PROD.APPL.TXNFILE(+1), // SPACE=(...) //SYSINDD DUMMY //SYSPRINT DD DUMMY // This will copy all of the data from all of the generations of the XMIT file to a new generation of the APPL file. If the copy succeeds then all of generations of the XMIT file are deleted. If it fails (out of space, or whatever) the XMIT generations remain so we can rerun when the issue is resolved. Job 2 (a totally separate job from job 1) will actually process the newest generation of the APPL file; DD being something like: //TXNFILE DD DISP=SHR,DSN=FJS.APPL.TXNFILE(0) Job 2 can be rerun as necessary. We'll keep 5 generations of TXNFILE for testing purposes. This is pretty simple to understand, does not require any special software or clever coding, and seems to be close to bulletproof. The only concerns I have are: 1) What if the same file is transmitted twice? This requires someone realizing it occured, but the solution seems to be as simple as deleting the duplicate generation before running step 1. If someone does not realize it before step 1 is run (thus copying the duplicate generation to the APPL file and deleting the XMIT generations) then we'd have to retransmit all generations to be processed. But this doesn't happen often and is almost always caused by the automated process failing and a manual process being the cause of the duplicates. 2) As I think was mentioned recently, when a GDG is processed without generation qualification it processes them newest to oldest. Annoying! They should go oldest to newest. But in the end my process has to sort the records anyway, so it doesn't really matter that they are not in chronological order. Can anyone think of anything I missed? This almost seems a bit too simple. :- ) Thanks! Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick fswarbr...@gmail.com wrote: First I want to thank everyone for all of their ideas. After due consideration, here is what I think we'll end up doing. I'm going to create two GDG datasets: /* IDCAMS COMMAND */ DEFINE GENERATIONDATAGROUP - (NAME(PROD.XMIT.TXNFILE) - LIMIT(6) - ) /* IDCAMS COMMAND */ DEFINE GENERATIONDATAGROUP - (NAME(PROD.APPL.TXNFILE) - LIMIT(5) FOR(7) - ) Every day we'll receive an FTP of a new generation into PROD.XMIT.TXNFILE. On non-business days we won't do any further processing of the file. On a business day we'll have two jobs. The first one will look very much like this: //GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A //BACKUP EXEC PGM=IEBGENER //SYSUT1 DD DISP=(OLD,DELETE,KEEP),DSN=PROD.XMIT.TXNFILE //SYSUT2 DD DISP=(NEW,CATLG,DELETE),DSN=PROD.APPL.TXNFILE(+1), // SPACE=(...) //SYSINDD DUMMY //SYSPRINT DD DUMMY // This will copy all of the data from all of the generations of the XMIT file to a new generation of the APPL file. If the copy succeeds then all of generations of the XMIT file are deleted. If it fails (out of space, or whatever) the XMIT generations remain so we can rerun when the issue is resolved. Job 2 (a totally separate job from job 1) will actually process the newest generation of the APPL file; DD being something like: //TXNFILE DD DISP=SHR,DSN=FJS.APPL.TXNFILE(0) Job 2 can be rerun as necessary. We'll keep 5 generations of TXNFILE for testing purposes. This is pretty simple to understand, does not require any special software or clever coding, and seems to be close to bulletproof. The only concerns I have are: 1) What if the same file is transmitted twice? This requires someone realizing it occured, but the solution seems to be as simple as deleting the duplicate generation before running step 1. If someone does not realize it before step 1 is run (thus copying the duplicate generation to the APPL file and deleting the XMIT generations) then we'd have to retransmit all generations to be processed. But this doesn't happen often and is almost always caused by the automated process failing and a manual process being the cause of the duplicates. 2) As I think was mentioned recently, when a GDG is processed without generation qualification it processes them newest to oldest. Annoying! They should go oldest to newest. But in the end my process has to sort the records anyway, so it doesn't really matter that they are not in chronological order. Can anyone think of anything I missed? This almost seems a bit too simple. :- ) Thanks! Frank One presumption here is that your application can handle input data that is not in the order each GDS was created -- remember your GENER step will concatenate the generations in sequence, from (-0) to (-nn). Also, I always recommend not using IEBGENER, rather use PGM=SORT with PARM=ABEND, and do a SORT FIELDS=COPY, so that you get the benefit of a direct ABEND for any reason, rather than a COND CODE 0012. Maybe a space abend will percolate a step-failing SB37, but I just don't trust it. And consider that if you must sort your data, then you can use the SORT utility step, if you must get your data back into some expected sequence. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick wrote: On a business day we'll have two jobs. The first one will look very much like this: //GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A //BACKUP EXEC PGM=IEBGENER //SYSUT1 DD DISP=(OLD,DELETE,KEEP),DSN=PROD.XMIT.TXNFILE //SYSUT2 DD DISP=(NEW,CATLG,DELETE),DSN=PROD.APPL.TXNFILE(+1), // SPACE=(...) //SYSINDD DUMMY //SYSPRINT DD DUMMY // This will copy all of the data from all of the generations of the XMIT file to a new generation of the APPL file. If the copy succeeds then all of generations of the XMIT file are deleted. If it fails (out of space, or whatever) the XMIT generations remain so we can rerun when the issue is resolved. Maybe. If the gener abends, the XMIT group will be kept. If it fails with a non-zero return code, they will be deleted. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant m42tom- ibmm...@yahoo.com wrote: On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick wrote: On a business day we'll have two jobs. The first one will look very much like this: //GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A //BACKUP EXEC PGM=IEBGENER //SYSUT1 DD DISP=(OLD,DELETE,KEEP),DSN=PROD.XMIT.TXNFILE //SYSUT2 DD DISP=(NEW,CATLG,DELETE),DSN=PROD.APPL.TXNFILE(+1), // SPACE=(...) //SYSINDD DUMMY //SYSPRINT DD DUMMY // This will copy all of the data from all of the generations of the XMIT file to a new generation of the APPL file. If the copy succeeds then all of generations of the XMIT file are deleted. If it fails (out of space, or whatever) the XMIT generations remain so we can rerun when the issue is resolved. Maybe. If the gener abends, the XMIT group will be kept. If it fails with a non-zero return code, they will be deleted. Thanks for the warning. I tested it out by forcing an out of space condition and got a D37-04 abend, so I think(!) I'm ok here. Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
On Thu, 29 Jan 2009 13:53:45 -0600, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Thu, 29 Jan 2009 12:35:37 -0600, Frank Swarbrick wrote: On a business day we'll have two jobs. The first one will look very much like this: //GDGTST3A JOB NOTIFY=SYSUID,MSGCLASS=X,CLASS=A //BACKUP EXEC PGM=IEBGENER //SYSUT1 DD DISP=(OLD,DELETE,KEEP),DSN=PROD.XMIT.TXNFILE //SYSUT2 DD DISP=(NEW,CATLG,DELETE),DSN=PROD.APPL.TXNFILE(+1), // SPACE=(...) //SYSINDD DUMMY //SYSPRINT DD DUMMY // This will copy all of the data from all of the generations of the XMIT file to a new generation of the APPL file. If the copy succeeds then all of generations of the XMIT file are deleted. If it fails (out of space, or whatever) the XMIT generations remain so we can rerun when the issue is resolved. Maybe. If the gener abends, the XMIT group will be kept. If it fails with a non-zero return code, they will be deleted. -- Tom Marchant For clarification, a non-zero COND CODE does not invoke ABNORMAL processing for the DISP= parameter. Only a job-step terminating with a USER or SYSTEM ABEND condition would cause the datasets to be deleted. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
Hello, This might run into trouble if you need to open lots of datasets due to holidays. Suppose, your program always defines the last 3 datasets (0), (-1) and (-2) with the corresponding DD statements in your JCL. However, you'll have some program logic to determine what day of the week it is. On Tuesday to Friday, only open and read the last dataset. On Monday, open and read all three. This would take a level of 'abstracting' between your processing and the datasets so you wouldn't need multiple ways to process data from different datasets. I'm assuming your logic would be the same for each dataset. Than again, somebody might be able to dream up some conditional JCL for running an IEBGENER to concatenate the 3 datasets into one temporary dataset on Monday's and just copy the current one to a temporary dataset on Tuesday to Friday. Nice Day, Eric Verwijs -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: 2009-01-27 8:04 PM To: IBM-MAIN@bama.ua.edu Subject: New GDG question Consider the following... A file is received (via FTP) 7 days a week from somewhere. The FTP writes to generation +1. Problem: The program that uses the file(s) runs only every business day. On a regular Tuesday-Friday it needs to only read the most recent generation (0). But on Monday it needs to read (0), (-1) and (-2). And of course there are holidays to consider. Thoughts on how this can be addressed? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
One way of doing is by having the processing job to the following: 1) Add a step to backup all gens of the FTP GDG //backup exec pgm=Iebgener //sysut1 dd dsn=FTP.FILES,disp=shr Backup all gens //sysut2 dd dsn-FTP.FILES.BACKUP, disp=etc... 2) In the step that process the FTP GDG file have it process all Gens //backup exec pgm=apppgm //input dd dsn=FTP.FILES,disp=(old,delete,keep) Process all gens //...etc Based on the assumption that only 1 file per day is FTPd - Monday's job would process 3 gens of the files Tuesday - Friday jobs would only process only 1 gen of the file -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf Of frederick.verw...@hrsdc-rhdsc.gc.ca Sent: Wednesday, January 28, 2009 6:46 AM To: IBM-MAIN@bama.ua.edu Subject: Re: New GDG question Hello, This might run into trouble if you need to open lots of datasets due to holidays. Suppose, your program always defines the last 3 datasets (0), (-1) and (-2) with the corresponding DD statements in your JCL. However, you'll have some program logic to determine what day of the week it is. On Tuesday to Friday, only open and read the last dataset. On Monday, open and read all three. This would take a level of 'abstracting' between your processing and the datasets so you wouldn't need multiple ways to process data from different datasets. I'm assuming your logic would be the same for each dataset. Than again, somebody might be able to dream up some conditional JCL for running an IEBGENER to concatenate the 3 datasets into one temporary dataset on Monday's and just copy the current one to a temporary dataset on Tuesday to Friday. Nice Day, Eric Verwijs -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: 2009-01-27 8:04 PM To: IBM-MAIN@bama.ua.edu Subject: New GDG question Consider the following... A file is received (via FTP) 7 days a week from somewhere. The FTP writes to generation +1. Problem: The program that uses the file(s) runs only every business day. On a regular Tuesday-Friday it needs to only read the most recent generation (0). But on Monday it needs to read (0), (-1) and (-2). And of course there are holidays to consider. Thoughts on how this can be addressed? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
Frank, You have received several suggestions on this. Here's one more that we do with data that we get from our parent company. If you have access to somebody who can make a minor modification to the FTP send commands on the other end, you could have them simply change their FTP commands to do an append instead of a replace. Then have them just FTP the data into generation 0 of the GDG. When you run your job, just use generation 0 and as the last step of the job, create an empty +1 generation. The other benefit of this type of scenario is that if for some reason the other end neglected to send a file, you aren't re-processing yesterday's data. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Tuesday, January 27, 2009 7:04 PM To: IBM-MAIN@bama.ua.edu Subject: New GDG question Consider the following... A file is received (via FTP) 7 days a week from somewhere. The FTP writes to generation +1. Problem: The program that uses the file(s) runs only every business day. On a regular Tuesday-Friday it needs to only read the most recent generation (0). But on Monday it needs to read (0), (-1) and (-2). And of course there are holidays to consider. Thoughts on how this can be addressed? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG question
WY back when (mid 70s), i can remember doing an UNCATLG, RENAME, CATLG to convert a Gv00 to G0001v00. Now i see that it may not have been necessary? KENNETH E. THOMPSON Programmer Analyst Sr. Professional CSC 1222 Spruce Street, Room 7.204, St. Louis, MO 63103 North American Public Sector | p:+1.314.552.3342 | f:+1.314.552.3281 | kthompso...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG question
WY back when (mid 70s), i can remember doing an UNCATLG, RENAME, CATLG to convert a Gv00 to G0001v00. Now i see that it may not have been necessary? I can't speak to the 1970's, but I never needed it in 1981. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG question
Actually I think it was way back then. I seem to recall not quite so far back (early to mid 80s) that when we first installed our 4381 with XA 2.1.7 that the training I got back then said I needed to perform unnatural acts when a GDG hit to keep it going. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kenneth E Thompson Sent: Tuesday, January 27, 2009 8:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG question WY back when (mid 70s), i can remember doing an UNCATLG, RENAME, CATLG to convert a Gv00 to G0001v00. Now i see that it may not have been necessary? KENNETH E. THOMPSON Programmer Analyst Sr. Professional CSC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG question
Based on Ted's comment about not needing to do anything strange with GDG rolling in 1981, maybe my training course was wrong... Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Tuesday, January 27, 2009 8:46 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG question Actually I think it was way back then. I seem to recall not quite so far back (early to mid 80s) that when we first installed our 4381 with XA 2.1.7 that the training I got back then said I needed to perform unnatural acts when a GDG hit to keep it going. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kenneth E Thompson Sent: Tuesday, January 27, 2009 8:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG question WY back when (mid 70s), i can remember doing an UNCATLG, RENAME, CATLG to convert a Gv00 to G0001v00. Now i see that it may not have been necessary? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG question
Based on Ted's comment about not needing to do anything strange with GDG rolling in 1981, maybe my training course was wrong... I don't know about that, but I was a JCL Jockey, in production support, in 1981. And, unless, what I loosely call my mind, has failed completely (possible), we never did anything special with GDG's. And, we never had a roll-over problem. I believe we were on SE2, and I know we used few, if any, CVOLs. Of course, they say the mind is the second thing to go, and I'll be dash-burned if I can remember what the first one was. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Barry: Excellent response. I am somewhat perturbed though by IBM's response as being OCO. IBM, I believe (for a large $$ donation) will give out certain non disclosure items. Yet I am somewhat mystified as to why IBM needs to classify a catalog record layout as OCO. We know of at least one vendor that has gotten assurances from the catalog people that a field in the catalog will be propagated when copied to another catalog. Doesn't that alone say IBM cannot do OCO on the layout of the catalog record(s)? My take is that they can't now put the genie back in the bottle. Ed --- On Mon, 1/26/09, Barry Merrill ba...@mxg.com wrote: ---SNIP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
New GDG question
Consider the following... A file is received (via FTP) 7 days a week from somewhere. The FTP writes to generation +1. Problem: The program that uses the file(s) runs only every business day. On a regular Tuesday-Friday it needs to only read the most recent generation (0). But on Monday it needs to read (0), (-1) and (-2). And of course there are holidays to consider. Thoughts on how this can be addressed? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
One easy way is for the daily job to process all generations of the dataset, then delete them when it's captured the data. There are variations on that theme using that would involve copying the FTP generations to a workday generation if you need to keep the input. One thing I've learned, you can't trust somewhere, they will send yesterdays data again, then send today's, send todays twice, send nothing, have a transmit problem, or something to ruin your sleep Frank Swarbrick wrote: Consider the following... A file is received (via FTP) 7 days a week from somewhere. The FTP writes to generation +1. Problem: The program that uses the file(s) runs only every business day. On a regular Tuesday-Friday it needs to only read the most recent generation (0). But on Monday it needs to read (0), (-1) and (-2). And of course there are holidays to consider. Thoughts on how this can be addressed? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
Well, this may be a bit too clever But it works flawlessly for me. At 1 second past midnight, I run some REXX which produces a series of JCL SET SYMBOL statements and stores these statements in a production JCL Procedure library. (send me a PM and I'll send you an example of what JCL this REXX produces...) Anyway, these statements are included in many production jobs and these jobs in turn include other JCL based on the value(s) of these set statements. One of the set statements is CDOW (for Current Day of Week). So, on a Monday, the value of the CDOW symbol is MON. Any jobs that needs to run different JCL based on the day of the week, would have a statement like // INLUCDE MEMBER=JCLCDOW Each day the job runs, it brings in a different set of canned JCL. There is also a SET symbol for CBOW and CEOW for Current Beginning of Week and Current End of Week. These values are 1 or 0, as in True or False. These symbols can then be used in COND statements which would execute, or not, a step the first or last day of the week. This is based on YOUR BOW and EOW. It could also be used to bring in one series of JCL for the BOW or not. The same goes for EOW. The job streams that depend on this process run every day and never fail. Of course, the JCL is well documented in case the runaway garbage truck ever strikes me... Oh, in another thread I noted that I alias all of my SMF GDG's so they can be accessed with an English name, i.e. TS.SMFDATA.DAILY.JAN2709 or TS.SMFDATA.MONTHLY.JAN2009, instead of TS.SMFDATA.DAILY(0) or is it (-1) or (-2), etc The REXX code that produces the SET symbol statements also produces a series of similarly named symbols, but are prefixed with SMF (as in SMFDOW, SMFBOW, etc...). Since SMF is one day behind and the CDOW is not the same as SMFDOW. The values of these SMF set symbols allow me to generate the alias name for the related GDG... As I said, works like a charm. HTH Gary Green Never use a 2x4 when a 2x6 will do just as well! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Tuesday, January 27, 2009 8:04 PM To: IBM-MAIN@bama.ua.edu Subject: New GDG question Consider the following... A file is received (via FTP) 7 days a week from somewhere. The FTP writes to generation +1. Problem: The program that uses the file(s) runs only every business day. On a regular Tuesday-Friday it needs to only read the most recent generation (0). But on Monday it needs to read (0), (-1) and (-2). And of course there are holidays to consider. Thoughts on how this can be addressed? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
I have several possible solutions for you, some free some not. 1) The company I work for markets a product called SyzAuto which allows you to schedule JOBs (or tasks or commands) based on Day of Week, Month, and various frequencies) with IF logic etc. Most job scheduling systems allow for this also, but ours is permanently discounted 50% off ($2,500) for members of IBM-Main and current Syzygy Clients. look at www.syzygyinc.net for more information if you're interested. 2) I have a free version of the above which performs some of the functions of the above, although without support, does not contain the special z/OS and z/series processor routines and without a lot of the extra bells an whistles. 3) I have a program which you can execute as the first (or any step) of your job and will set the condition code to a different value based on the day of week, plus I have another one that will set a condition code based on whether or not that JOB has has run that day. Both require you to perform the appropriate condition code checking in your job. The Holiday issue would have to be addressed with Option 1 (possibly option 2 although not as easily), or you could modify the programs to handle holidays, it's not a really big deal to do that. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New GDG question
I've handled this scenerio in the past by having the ftp write to a non-gds dsn. Then have the transfer trigger an IEBGENER that concatenates (0) gen with the non-gds to create (+1) gen. This can then run any number of times until the business day processes the files by just calling the (0) gen and then when successful, create a new empty (+1). One advantage is that your gds generation number remain unique and so its a no brainer if/when someone wants to restore one from backup. Brian On Wed, Jan 28, 2009 at 8:04 AM, Frank Swarbrick fswarbr...@gmail.comwrote: Consider the following... A file is received (via FTP) 7 days a week from somewhere. The FTP writes to generation +1. Problem: The program that uses the file(s) runs only every business day. On a regular Tuesday-Friday it needs to only read the most recent generation (0). But on Monday it needs to read (0), (-1) and (-2). And of course there are holidays to consider. Thoughts on how this can be addressed? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
You may have been thinking of the post about GDG 'wrap bit' processing? http://www-1.ibm.com/support/docview.wss?uid=isg1II07276 Jack Kelly 202-502-2390 (Office) Jerry Fuchs jerry.fu...@wendysarbys.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 01/19/2009 02:16 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject GDG Question It seems to me that I saw a thread that stated when you hit GV00 you will be unable to create (+1). Is this correct? How did you handle this situation? Just delete all generations or create a new GDG? THI Jerry Fuchs Senior Systems Engineer Wendy's Arby's Group One Dave Thomas Blvd. Dublin, Ohio 43017 (614) 764-3594 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
It seems to me that I saw a thread that stated when you hit GV00 you will be unable to create (+1). Is this correct? No, GDG's have wrapped for aeons. Even the so-called bad wrapping problem is rare, since the maximum you can have is 255. I've never seen the problem, in my almost 30 years. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
You may be recalling this incident from 2005: Change 23.219 The ICF Catalog 05 record variable GATGEN should have VMAC6156 been input as PIB.2., instead of one byte, and variable VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on, Aug 29, 2005 to mark that this GDG member has wrapped; i.e., its generation number has exceeded . If GATWRAP is on, GATGEN=GATGEN-32768 to contain the correct Gen number. This discovery was precipitated by IGD07001I ABENDs in production, which occurred when a GDG that had GATWRAP on for some members, and GATWRAP off for others, when that GDG generation number goes from 999 to 1000. Normally, when all members of a GDG have wrapped, the next catalog action turns off the wrap bit in all of the catalog records. For a normal GDG, that should happen when the +256th gen is created after wrap, as only 255 members can exist in the catalog. But this site had had a very old application that originally created +1 thru +5 each day, and then deleted +1 thru +4, leaving only +5 in the catalog. However, back when Clinton was President, an application change was made that created on +1 thru +3 and deleted only +1 and +2, so there were 2 old GVoo's left in the catalog. When the GDG wrapped, and when the create of +1 would have created G1000V00, those old GVoo's still had their wrap bit off, and the production job failed: IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122 Return Code 140: Inconsistent or conflicting arguments were provided. Reason Code 122: Catalog G1000Vxx will cause the GDG to exceed the limit of 10,999. Programmer Response: Clean up the GDG in error then catalog G1000Vxx. The site found Information APAR II07276, which explained how wrap works, but it says to 'see the Z page for internal details of the wrap bit interface'. So the site asked IBM Support: We need to identify other GDGs that have the same exposure to causing ABENDs. Can I look at the 'Z' page? Does the 'wrap bit' appear in SMF 61, 65, 66 ICF Catalog records? IBM Level 2 Catalog Support refused to answer the quite valid question, with this answer: Unfortunately, the 'Z' page in our info APARs refer to information meant for IBM eyes only, for helping us get to problem determination quicker. We are not at liberty to dicuss any control block internals that are not provided in our published manuals. As for information in SMF records relating to this, this info would be included in the updated record portion portion of the SMF record, however we cannot discuss offsets for those either. I am sorry I cannot be more helpful. Please let me know if there are any other questions that I can answer for you. Even escalation to my IBM Poughkeepsie z/OS support did not convince IBM Level 2 Catalog Support to identify which bit is the GATWRAP bit. The ICF Support and Developers hid behind OCO, Object Code Only, as the reason they could not provide catalog record documentation (but DSECTS are NOT CODE!). So I suggested the site could create a GDG and force it to wrap, and by examining SMF records, we concluded that first bit of GATGEN was the GATWRAP bit. Then, I remembered I still had lots of archaic printed manuals, and located the very old MVS/XA Catalog Diagnosis Reference for DFP Release 1.2, which confirmed that the GATWRAP bit was indeed the first bit of the GATGEN field in the 05 Catalog Record! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
John Kington wrote: Are you haevy user of GDGs created *more frequently* than daily? We run a batch job to copy off smf and ims log data whenever a switch occurs. Just our kind of normal. Well... I do use GDG for SMF, but I create one generation a day and use DISP=MOD for further offloads. BTW: In your scenario you don't know how old data do you have! The data can be rolled off depending on the amount, not depending on age. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Well... I do use GDG for SMF, but I create one generation a day and use DISP=MOD for further offloads. Risky choice. What happens if the offloading job fails for some reason? You could lose all the accumulated data. BTW: In your scenario you don't know how old data do you have! The data can be rolled off depending on the amount, not depending on age. Do you expect your SMF data to be dumped more than 255 times a day? The key is to switch at midnight, consolidate, and then delete the day's dumps. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Ted MacNEIL wrote: Well... I do use GDG for SMF, but I create one generation a day and use DISP=MOD for further offloads. Risky choice. What happens if the offloading job fails for some reason? You could lose all the accumulated data. Why ? The only problem that can occur is lost record segment (VBS format). It can be easily fixed. BTW: my datasets are never filled up - multivolume, ext-PS, space constraint relief, reduce space allocation... BTW: In your scenario you don't know how old data do you have! The data can be rolled off depending on the amount, not depending on age. Do you expect your SMF data to be dumped more than 255 times a day? The key is to switch at midnight, consolidate, and then delete the day's dumps. Sounds better. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, January 21, 2009 5:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question Well... I do use GDG for SMF, but I create one generation a day and use DISP=MOD for further offloads. Risky choice. What happens if the offloading job fails for some reason? You could lose all the accumulated data. BTW: In your scenario you don't know how old data do you have! The data can be rolled off depending on the amount, not depending on age. Do you expect your SMF data to be dumped more than 255 times a day? The key is to switch at midnight, consolidate, and then delete the day's dumps. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Richards, Robert B. wrote: For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) I considered it and said no. There is no good way to avoid duplicate records during offload. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B. robert.richa...@opm.gov wrote: For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) Bob Won't touch it until the offload support is enhanced with better date selection options (which it still wasn't even in z/OS 1.10). But we've been here before... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
The thing that's always bugged me about GDG files is they way they are selected starting with the highest gen # first down to the lowest if you specify the GDG-base name on a DD. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: 21 January 2009 13:53 To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B. robert.richa...@opm.gov wrote: For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) Bob Won't touch it until the offload support is enhanced with better date selection options (which it still wasn't even in z/OS 1.10). But we've been here before... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
And some of us aren't holding our breath and have written code to ease the issue until IBM solves the problem. :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Wednesday, January 21, 2009 8:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B. robert.richa...@opm.gov wrote: For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) Bob Won't touch it until the offload support is enhanced with better date selection options (which it still wasn't even in z/OS 1.10). But we've been here before... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B. robert.richa...@opm.gov wrote: For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) Bob SMF logstream relates to the MAN dataset logging rather than the associated DUMP GDG generations, though you may find it reduces the number of generations create throughout the day, depending on your z/OS system load and MAN dataset size. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) Right! And, introduce the duplicate SMF data problem, while I'm at it? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
I prefer to order GDGs with odd generations in LIFO order followed by the even generations in FIFO order - except on the second Tuesday of the month, when I want to read the data backwards in random file sequence. Why won't IBM listen to me? You can't satisfy everyone. I suspect it was a performance choice made many years ago. For whatever reason, it is what it is. Deal with it or get over it. Nevertheless, this is a perfect situation for a little bit of subsystem code. Let the subsystem search the catalog and concatenate the files in whatever sequence you like. The thing that's always bugged me about GDG files is they way they are selected starting with the highest gen # first down to the lowest if you specify the GDG-base name on a DD. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline martin.kl...@yrcw.com wrote: I prefer to order GDGs with odd generations in LIFO order followed by the even generations in FIFO order - except on the second Tuesday of the month, when I want to read the data backwards in random file sequence. Why won't IBM listen to me? Because you're a loon? GRIN (I'm a loon too! And proud of it.) You can't satisfy everyone. I suspect it was a performance choice made many years ago. For whatever reason, it is what it is. Deal with it or get over it. Correct. I remember CVOLs. The original OS/360 catalog structure. Many of the current ills we have in this area are due to compatibility with the original CVOL structure. Nevertheless, this is a perfect situation for a little bit of subsystem code. Let the subsystem search the catalog and concatenate the files in whatever sequence you like. What we had was a program. You passed the base name as a PARM and it would dynalloc each generation and write it in ascending Goovoo sequence to another file. The actual application would then read this file in the next step. Not as good as a subsystem, but much easier to program. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 11:06:41 -0600, John McKown wrote: On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline wrote: You can't satisfy everyone. I suspect it was a performance choice made many years ago. For whatever reason, it is what it is. Deal with it or get over it. Correct. I remember CVOLs. The original OS/360 catalog structure. Many of the current ills we have in this area are due to compatibility with the original CVOL structure. I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 07:53:00 -0600, Mark Zelden mark.zel...@zurichna.com wrote: On Wed, 21 Jan 2009 07:08:13 -0500, Richards, Robert B. robert.richa...@opm.gov wrote: For SMF, the key is actually to switch to logstreams and get rid of the GDGs! :-) Won't touch it until the offload support is enhanced with better date selection options (which it still wasn't even in z/OS 1.10). But we've been here before... IEAMDBLG seems to work sufficiently for pulling yesterday's OPERLOG to a PS file (GDG) and deleteing on that boundary. Couldn't this code be generalized to work for SMF (or other) logstreams, too? If anyone's looney enough to want the cutoff at 12:17:32, I'm sure they can torture themselves to no end bastardizing the IBM-supplied sample. Regards, Art Gutowski Ford Motor Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
---snip- The thing that's always bugged me about GDG files is they way they are selected starting with the highest gen # first down to the lowest if you specify the GDG-base name on a DD. -unsnip That's because the actual generation number is stored in two's complement form, reversing the sort order. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Tom Marchant wrote: I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. The names were stored in the catalog in inverse order (the portion was complemented; i.e. C'0123' became X'0F0E0D0C'). This placed the entries with latest generation first, and explains why it was easiest to retrieve them in that sequence. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. Been there, done that! I always assumed that the complementing of generation numbers was *specifically* to achieve the reverse sequence returned in GDGALL. Date: Wed, 21 Jan 2009 11:53:01 -0600 From: m42tom-ibmm...@yahoo.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu On Wed, 21 Jan 2009 11:06:41 -0600, John McKown wrote: On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline wrote: You can't satisfy everyone. I suspect it was a performance choice made many years ago. For whatever reason, it is what it is. Deal with it or get over it. Correct. I remember CVOLs. The original OS/360 catalog structure. Many of the current ills we have in this area are due to compatibility with the original CVOL structure. I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. -- Tom Marchant _ Windows Live™ Hotmail®:…more than just e-mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 11:53:01 -0600, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Wed, 21 Jan 2009 11:06:41 -0600, John McKown wrote: On Wed, 21 Jan 2009 10:38:57 -0600, Martin Kline wrote: You can't satisfy everyone. I suspect it was a performance choice made many years ago. For whatever reason, it is what it is. Deal with it or get over it. Correct. I remember CVOLs. The original OS/360 catalog structure. Many of the current ills we have in this area are due to compatibility with the original CVOL structure. I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. -- Tom Marchant Well, I'll defer to you. I did not spend a lot of time in the fiche. What I remember, and perhaps you can correct me, is that a CVOL was much like a PDS directory. The data portion of a record was 256 bytes in length. And it had an 8 byte hardware key. The key on the record was the highest value of the node within the record. The keys on a track were always in order so that a search key GE CCW would read the correct record from the track. I also remember that the key for the GVnn portion of the node was reversed by doing an XC with 8X'FF' so that the largest goovoo number would be at the beginning of the record, thus easier to find. I.e. to find the current goovoo, the search ke GE would simply be 8X'00'. That's what I remember. But I've been getting ECC errors on my memory for a while now. grin. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
But maybe I was always wrong. Maybe it was to give a faster path to generation (0) which would probably be the most oft retrieved generation. Date: Wed, 21 Jan 2009 13:30:49 -0500 From: jayare...@hotmail.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. Been there, done that! I always assumed that the complementing of generation numbers was *specifically* to achieve the reverse sequence returned in GDGALL. _ Hotmail® goes where you go. On a PC, on the Web, on your phone. http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 13:22:42 -0500, Gerhard Postpischil wrote: Tom Marchant wrote: I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. The names were stored in the catalog in inverse order (the portion was complemented; i.e. C'0123' became X'0F0E0D0C'). This placed the entries with latest generation first, and explains why it was easiest to retrieve them in that sequence. Yes, I'd forgotten that detail. Still, it begs the question, *why* was it stored that way? I suspect that it was a design decision to simplify the retrieval of the data sets in reverse order. I don't think that either forward or reverse order would offer a significant performance advantage. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Wednesday, January 21, 2009 12:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question On Wed, 21 Jan 2009 13:22:42 -0500, Gerhard Postpischil wrote: Tom Marchant wrote: I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. The names were stored in the catalog in inverse order (the portion was complemented; i.e. C'0123' became X'0F0E0D0C'). This placed the entries with latest generation first, and explains why it was easiest to retrieve them in that sequence. Yes, I'd forgotten that detail. Still, it begs the question, *why* was it stored that way? I suspect that it was a design decision to simplify the retrieval of the data sets in reverse order. I don't think that either forward or reverse order would offer a significant performance advantage. SNIP I have an idea: DSN=A.B.C(0) and DSN=A.B.C(-1) Probably the two most used forms of access for GDS entries. Regards, Steve Thompson -- Opinions expressed by poster may not represent poster's employer's views. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Wed, 21 Jan 2009 12:39:39 -0600, John McKown wrote: On Wed, 21 Jan 2009 11:53:01 -0600, Tom Marchant wrote: I spent a *lot* of time in the microfiche, reading the CVOL code. Whatever the reason was for concatenating the generation data sets in reverse order, I don't think it was for performance. Well, I'll defer to you. I did not spend a lot of time in the fiche. What I remember, and perhaps you can correct me, is that a CVOL was much like a PDS directory. Yes. The data portion of a record was 256 bytes in length. And it had an 8 byte hardware key. The key on the record was the highest value of the node within the record. Correct The keys on a track were always in order so that a search key GE CCW would read the correct record from the track. Yes. I also remember that the key for the GVnn portion of the node was reversed by doing an XC with 8X'FF' so that the largest goovoo number would be at the beginning of the record, thus easier to find. I.e. to find the current goovoo, the search ke GE would simply be 8X'00'. Yes, or just read the first record. Perhaps J R is correct and it was done this way to be able to more efficiently retrieve the current entry. I was thinking of a performance benefit in updating the catalog or in reading the entire group. Now that I think of it, it would be a lot easier to find an older generation too. That's what I remember. But I've been getting ECC errors on my memory for a while now. Lucky you. You have ECC memory. Mine doesn't even have parity. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
This brings up a question I've had before. Why is the 'V00' not made use of? Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Just a thought Joe Aulph, Senior Systems Programmer: 850-487-8945 joe_au...@dcf.state.fl.us Scott Barry sba...@sbbworks. COM To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List ibm-m...@bama.ua Subject .edu Re: GDG Question 01/19/2009 02:41 PM Please respond to IBM Mainframe Discussion List ibm-m...@bama.ua .edu On Mon, 19 Jan 2009 14:13:34 -0500, Jerry Fuchs jerry.fu...@wendysarbys.com wrote: It seems to me that I saw a thread that stated when you hit GV00 you will be unable to create (+1). Is this correct? How did you handle this situation? Just delete all generations or create a new GDG? THI Jerry Fuchs Senior Systems Engineer Wendy's Arby's Group One Dave Thomas Blvd. Dublin, Ohio 43017 (614) 764-3594 The GDG assignment rolls from GV00 to **.G0001V00 on this condition. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
The V00 part of the GV00 number is used to create the same GDG number without impacting the GDG numbers. Say I have G0001V00 and I find that it is incorrect, I then create a G0001V01. Now let's say the G0001V01 is still the Generation 0 entry in the GDG. Then when I use DSN(0) it pulls in G0001V01 as if it were G0001V00. And the G0001V00 is gone. Best part I did not roll off any other GDGs when creating the G0001V01 entry. Lizette This brings up a question I've had before. Why is the 'V00' not made use of? Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... How did you handle this situation? Just delete all generations or create a new GDG? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, Joe Aulph, Senior Systems Programmer: 850-487-8945 joe_au...@dcf.state.fl.us Lizette Koehler stars...@mindspr ING.COM To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List ibm-m...@bama.ua Subject .edu Re: GDG Question 01/20/2009 09:16 AM Please respond to IBM Mainframe Discussion List ibm-m...@bama.ua .edu The V00 part of the GV00 number is used to create the same GDG number without impacting the GDG numbers. Say I have G0001V00 and I find that it is incorrect, I then create a G0001V01. Now let's say the G0001V01 is still the Generation 0 entry in the GDG. Then when I use DSN(0) it pulls in G0001V01 as if it were G0001V00. And the G0001V00 is gone. Best part I did not roll off any other GDGs when creating the G0001V01 entry. Lizette This brings up a question I've had before. Why is the 'V00' not made use of? Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... How did you handle this situation? Just delete all generations or create a new GDG? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
As entries are added to a GDG by DSN=...(+1), G0001V00 thru GV00 are created with the wrap bit OFF (I'll refer to these entries members of group A). After GV00 exists, the next entries created by DSN=...(+1) are G0001V00 - G0999V00 with the wrap bit ON (I'll refer to these entries as members of group B). Note that GV00 is not used. Normal processing of GDGs using DSN=...(+1) should cause older entries to roll off so that as members of group B are created, all members of group A should become uncataloged. When this happens, the system will turn off all the wrap bits in group B and it will then look like group A did in its early stages. The GDG has wrapped successfully! If for some reason an entry in group A does not roll off (i.e., an expiration date is changed so that the entry doesn't expire in a timely matter, etc.), group B will not have it's wrap bits turned off. When group B gets to G0999V00, then next attempt to create an entry by using DSN=...(+1) will fail. Manual intervention is required by the user to correct all the existing entries in the GDG before any new entries can be created. Good doc from IBM about how to correct the problem is not easily found. At 3:00 AM Sunday morning, this could really be FUN!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
David Magee wrote: [...] If for some reason an entry in group A does not roll off (i.e., an expiration date is changed so that the entry doesn't expire in a timely matter, etc.), group B will not have it's wrap bits turned off. When group B gets to G0999V00, then next attempt to create an entry by using DSN=...(+1) will fail. Manual intervention is required by the user to correct all the existing entries in the GDG before any new entries can be created. Good doc from IBM about how to correct the problem is not easily found. At 3:00 AM Sunday morning, this could really be FUN!! Actually, I think, the problem is theoretical. How often do you create new generation? Usually it's being created daily (weekly, monthly). One generation a day means 1 days to overlap. That's 27 years! Even if you are still working here, there is small chance that application didn't change and this GDG is dropped. Of course it is possible to use GDGs for cyclic jobs running hourly (still over year) or even more frequently. It is also possible that for such jobs real GDG is used, not some autoedit feature of batch scheduler (like %%ODATE in ControlM). But I think it is uncommon. Last but not least: uncommon processing x uncommon error... My €0.02 -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 2009-01-20 at 17:02 +0100, R.S. wrote: Of course it is possible to use GDGs for cyclic jobs running hourly (still over year) or even more frequently. [...] But I think it is uncommon. Commonplace here. We are heavy, regular users of GDGs. Lots and LOTS of old-master-in, transaction-file-in, new-master-out stuff. Lots of new generations that are subsequently aggregated. It's the technology that Would Not Die. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
David Andrews wrote: On Tue, 2009-01-20 at 17:02 +0100, R.S. wrote: Of course it is possible to use GDGs for cyclic jobs running hourly (still over year) or even more frequently. [...] But I think it is uncommon. Commonplace here. We are heavy, regular users of GDGs. Are you haevy user of GDGs created *more frequently* than daily? My opinion wasn't GDGs are not used, rather GDGs are usually created on daily basis or less frequently. BTW: I think that a reason why IBM didn't increase maximum LIMIT() for GDG is lack of interest: Those customers who needed it already use pseudo-GDG (batch scheduler failities). Is there any other reason? No one wants 365 generations? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
we certainly create GDG members more frequently than daily - more importantly (for us) - they are ad hoc - we simply dont know how many will be generated in a day - until they are generated (CA-IDMS transaction log and recovery journal offloads) Chris Hoelscher Senior IDMS DB2 Database Administrator Humana Inc 502-476-2538 choelsc...@humana.com The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Why does it really matter? You can only have a max of 255 entries. Just like 640K was enough memory on a PC, 255 entries is enough! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Are you haevy user of GDGs created *more frequently* than daily? We run a batch job to copy off smf and ims log data whenever a switch occurs. Just our kind of normal. BTW: I think that a reason why IBM didn't increase maximum LIMIT() for GDG is lack of interest: Those customers who needed it already use pseudo-GDG (batch scheduler failities). Is there any other reason? No one wants 365 generations? We learned to live with the limitation. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: GDG Question
The interesting question is what the intended use of the V00 part was ? And if any system actions is taken regarding changes in that part ? Regards, Thomas Berg __ Thomas Berg Specialist IT-U SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Ted MacNEIL Skickat: den 20 januari 2009 18:03 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GDG Question Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Why does it really matter? You can only have a max of 255 entries. Just like 640K was enough memory on a PC, 255 entries is enough! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
At 02:36 + on 01/20/2009, Ted MacNEIL wrote about Re: GDG Question: That is because the GDG is in a VSAM catalog. ICF catalogue -- different from VSAM. True. I was using VSAM as the alternative to CVOL catalogs. ICF is still VSAM but just a new way of handling the Catalog (as opposed to Dataset) organization. In the past when CVOL catalogs were used I think you were SOL since there was no rollover ability. I don't recall it ever being a problem, even with CVOLs. I started this business as a JCL jockey in Production Support, log before UCC7 UCC11 and their sucessors came out. We used CVOLs for almost everything except IMS -- we didn't have CICS, and DB2 wasn't available, yet. We used GDG datasets all the time, and we never had a 'roll over' problem. Since it requires that 10,000 Generations be created before there can be a need to roll the Absolute Generation number over, it would take a while and thus you might never have gotten to G. It is my impression that with CVOL support, the organization of the GDG record type had no provision for a Relative Generation Number that had an lower Absolute Generation number than a prior Relative Generation Number (ie: (0) = G0001 and (-1) = G). I seem to remember that the recommendation was to reset when you got to G9500 or so. This was not that hard a process since a simple rename (using Absolute Generation Numbers) for DASD datasets would reset the numbers and refresh the catalog. For Tape the process was a little more complex since it involved the need to copy the tapes to new volumes under new names. Since the Dataset Name in a Tape HDR1 label was only 17 Characters (not the full 44 Characters) and 9 of these were the .GVxx suffix you could create the new tape using any prefix you wanted. You then did the delete of the old GDG entries and creation of the new ones (and deleted the temporary catalog entries if you had cataloged the new tapes). Thus .GDGNAME.G9500V00 would be copied as .TEMP.GDGNAME.G0001V00 (with only .GDGNAME.G0001V00 being in the tape's HDR1 label), the .GDGNAME.G9500V00 entry (and the rest of the 95XX ones) deleted, and a new .GDGNAME.G0001V00 catalog entry created. Since all of the entries were first deleted, the new entries would be created in the correct order. There might be a need to delete and recreate the GDG Index CVOL entry since I have the impression that it contained the next Generation number to use and thus needed to be reset (since the current list of generations was not consulted in processing a (+1) request. Of course, my memory could be failing. So might mine. It has been so long that I might -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
At 09:29 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, Joe Aulph, Senior Systems Programmer: 850-487-8945 joe_au...@dcf.state.fl.us They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
At 09:06 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: This brings up a question I've had before. Why is the 'V00' not made use of? Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Just a thought All automatically created files have the v00 version number. The V01-V99 suffixes are reserved for use in creating replacement versions of a G Generation when needed (via hard coding the full absolute file name in lieu of using the (x) Relative Generation Number form of the Dataset name). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 20 Jan 2009, Ted MacNEIL wrote: Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Why does it really matter? You can only have a max of 255 entries. Just like 640K was enough memory on a PC, 255 entries is enough! - Total agreement! What I wish were a possibility would be an totally new construct with similar semantics to a GDG. But the LLQ would somehow encode the creation date time (perhaps to the nearest second). No, I don't know how to encode that into 8 printable characters. The semantics I would like would be the ability to get the current, -1, and so on entries without knowing the actual LLQ. And the ability to create a new generation symbolically (likeunto the +1). Of course, the problem is once again, what is the date time. Submition, or job initiation or step initiation or dataset open or ...? Oh, and should the encoding be for local time or GMT? OK, it's a stupid idea. -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 20 Jan 2009 11:49:05 -0600, John McKown wrote: What I wish were a possibility would be an totally new construct with similar semantics to a GDG. But the LLQ would somehow encode the creation date time (perhaps to the nearest second). No, I don't know how to encode that into 8 printable characters. Dddd.Thhmmss? The semantics I would like would be the ability to get the current, -1, and so on entries without knowing the actual LLQ. And the ability to create a new generation symbolically (likeunto the +1). Of course, the problem is once again, what is the date time. Submition, or job initiation or step initiation or dataset open or ...? I'd say allocation time. Oh, and should the encoding be for local time or GMT? GMT. Otherwise you couldn't tell what order they were created. OK, it's a stupid idea. I don't think so. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
The Vyy is the Version Number ... (allowing you to replace it up to 99 times). Are you saying that replacement versions may only be created in ascending sequence? Date: Tue, 20 Jan 2009 12:15:46 -0500 From: hal9...@panix.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu At 09:29 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, Joe Aulph, Senior Systems Programmer: 850-487-8945 joe_au...@dcf.state.fl.us They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Hmmm, why wasn't hex used for this rollover then if anyone were crazy enough to do it, they could have 65535 generations (GVxx) before rollover. Surely that is enough! I have always *tried* to avoid GDGs like the plague that they are. Guy Gardoit z/OS Systems Programming On Tue, Jan 20, 2009 at 12:20 PM, Robert A. Rosenberg hal9...@panix.comwrote: At 09:06 -0500 on 01/20/2009, Joe Aulph wrote about Re: GDG Question: This brings up a question I've had before. Why is the 'V00' not made use of? Why doesn't'GV00 roll over to G0001V01? Rather than starting over at G0001V00... Just a thought All automatically created files have the v00 version number. The V01-V99 suffixes are reserved for use in creating replacement versions of a G Generation when needed (via hard coding the full absolute file name in lieu of using the (x) Relative Generation Number form of the Dataset name). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Lizette The Vyy is the Version Number ... (allowing you to replace it up to 99 times). Are you saying that replacement versions may only be created in ascending sequence? So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
I have always *tried* to avoid GDGs like the plague that they are. They have their uses, if you understand their quirks. The biggest thing I used them for was SMF dumps. At each switch dump to a GDG. Switch at midnight, consolodate with a simple reference to the base(s). Delete if successful. Don't have to remember any names. GDGs are perfect for this function. I've had other uses, but I would keep them for this one use. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 2009-01-20 at 17:49 +0100, R.S. wrote: Is there any other reason? No one wants 365 generations? Well... if the system allowed larger limits then we'd probably use them. GDG catalog processing has always been something of a kludge (my opinion... sorry if you're lurking, Mark). GDG sphere records are too big for their own good, and GDS extension records (if you have too many datasets to fit within the sphere's MAXLRECL) are created one at a time. Years ago those extension records were never deleted until the entire GDG was deleted, but maybe that's changed -- it's been awhile since I last looked. I think of the implementation as a dancing bear; nobody cares how well the bear dances, it's simply wondrous that it dances at all. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Well, I can't imagine needing to create up to 99 replacement versions either. However, if I were to use this feature, I could well imagine making the version number meaningful. Examples might be day-of-week, month-of-year, etc. In such a scenario they could well end up going backwards ... V06 (Friday) to V02 (Monday) maybe. So, the question stands: May version numbers be created out of sequence and randomly? Date: Tue, 20 Jan 2009 13:29:56 -0500 From: stars...@mindspring.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Lizette The Vyy is the Version Number ... (allowing you to replace it up to 99 times). Are you saying that replacement versions may only be created in ascending sequence? So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Tue, 2009-01-20 at 12:18 -0600, Tom Marchant wrote: On Tue, 20 Jan 2009 11:49:05 -0600, John McKown wrote: But the LLQ would somehow encode the creation date time (perhaps to the nearest second). Dddd.Thhmmss? One second is not fine enough. In a backup application I use Dddd.Thhmmsst -- good enough for today, but not necessarily for tomorrow. Also when you append 18 characters of date/time information to a dataset name you run afoul of our 44-character limitations. It's a small embarrassment when I explain it to the k1dd13z. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
My understanding is that you would only have ONE verions number at any given time. I have not seen a case where you would have G0001V00, and G0001V01 and G0001V02. Only the G0001V02 would be in the catalog. Any other versions would not. Though I could be wrong, but that is currently my understanding. Version only allows you to replace the current Gen Number without losing the oldest GDG (due to roll off). Lizette -Original Message- From: J R jayare...@hotmail.com Sent: Jan 20, 2009 1:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Well, I can't imagine needing to create up to 99 replacement versions either. However, if I were to use this feature, I could well imagine making the version number meaningful. Examples might be day-of-week, month-of-year, etc. In such a scenario they could well end up going backwards ... V06 (Friday) to V02 (Monday) maybe. So, the question stands: May version numbers be created out of sequence and randomly? Date: Tue, 20 Jan 2009 13:29:56 -0500 From: stars...@mindspring.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Lizette The Vyy is the Version Number ... (allowing you to replace it up to 99 times). Are you saying that replacement versions may only be created in ascending sequence? So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
I forgot to add, the reason would be that DSN(0) would never know which Version to pull in should there be more than one version. That is why many shops want a different process for getting dates and times into data set names. Lizette My understanding is that you would only have ONE verions number at any given time. I have not seen a case where you would have G0001V00, and G0001V01 and G0001V02. Only the G0001V02 would be in the catalog. Any other versions would not. Though I could be wrong, but that is currently my understanding. Version only allows you to replace the current Gen Number without losing the oldest GDG (due to roll off). Lizette -Original Message- From: J R jayare...@hotmail.com Sent: Jan 20, 2009 1:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Well, I can't imagine needing to create up to 99 replacement versions either. However, if I were to use this feature, I could well imagine making the version number meaningful. Examples might be day-of-week, month-of-year, etc. In such a scenario they could well end up going backwards ... V06 (Friday) to V02 (Monday) maybe. So, the question stands: May version numbers be created out of sequence and randomly? Date: Tue, 20 Jan 2009 13:29:56 -0500 From: stars...@mindspring.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Lizette The Vyy is the Version Number ... (allowing you to replace it up to 99 times). Are you saying that replacement versions may only be created in ascending sequence? So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Yes, it's understood that there is only one version cataloged at any one time. The question remains: Must version numbers be assigned incrementally? Date: Tue, 20 Jan 2009 13:57:44 -0500 From: stars...@mindspring.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu My understanding is that you would only have ONE verions number at any given time. I have not seen a case where you would have G0001V00, and G0001V01 and G0001V02. Only the G0001V02 would be in the catalog. Any other versions would not. Though I could be wrong, but that is currently my understanding. Version only allows you to replace the current Gen Number without losing the oldest GDG (due to roll off). Lizette -Original Message- From: J R jayare...@hotmail.com Sent: Jan 20, 2009 1:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Well, I can't imagine needing to create up to 99 replacement versions either. However, if I were to use this feature, I could well imagine making the version number meaningful. Examples might be day-of-week, month-of-year, etc. In such a scenario they could well end up going backwards ... V06 (Friday) to V02 (Monday) maybe. So, the question stands: May version numbers be created out of sequence and randomly? Date: Tue, 20 Jan 2009 13:29:56 -0500 From: stars...@mindspring.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Lizette The Vyy is the Version Number ... (allowing you to replace it up to 99 times). Are you saying that replacement versions may only be created in ascending sequence? So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
-snip Total agreement! What I wish were a possibility would be an totally new construct with similar semantics to a GDG. But the LLQ would somehow encode the creation date time (perhaps to the nearest second). No, I don't know how to encode that into 8 printable characters. The semantics I would like would be the ability to get the current, -1, and so on entries without knowing the actual LLQ. And the ability to create a new generation symbolically (likeunto the +1). Of course, the problem is once again, what is the date time. Submition, or job initiation or step initiation or dataset open or ...? Oh, and should the encoding be for local time or GMT? OK, it's a stupid idea. unsnip-- Not such a stupid idea at all. At Clearing, we archived huge numbers of small reports every day. We developed a routine that incorporated the last 6 bytes of the TOD clock into the DSNAME, as the last two qualifiers. The dataset was ultimately created by a subroutine (DYNAM, from the CBTTAPE site) that was called by the report generator program. The actual report name, time and date were entered into a VSAM database, along with the true DSNAME, and made available to users via a custom-built search/print program. FDRABR, then later, HSM, managed the actual reports' location and the VSAM cluster was periodically reorged, because of the large number of splits even when we used Sequential Insert Strategy. A relatively simple-minded compression algorithm reduced the report sizes' by about 70%, on the average. Rather than use hard-coded values for dsnames, we used the PARMLIB interface, so we didn't have to re-link anything if we changed any of the hard-coded values. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
--snip-- Well... if the system allowed larger limits then we'd probably use them. GDG catalog processing has always been something of a kludge (my opinion... sorry if you're lurking, Mark). GDG sphere records are too big for their own good, and GDS extension records (if you have too many datasets to fit within the sphere's MAXLRECL) are created one at a time. Years ago those extension records were never deleted until the entire GDG was deleted, but maybe that's changed -- it's been awhile since I last looked. I think of the implementation as a dancing bear; nobody cares how well the bear dances, it's simply wondrous that it dances at all. unsnip- You should have seen how they were managed in a CVOL environment! Chewing gum, bailing wire, spit a and LOT of prayers! Between BLDL-like searches and linked-lists on disk, they were a PITA! -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman You should have seen how they were managed in a CVOL environment! Chewing gum, bailing wire, spit a and LOT of prayers! . . . So, does that mean the demise of CVOLs predated the availability of duct tape? :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
--snip -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman You should have seen how they were managed in a CVOL environment! Chewing gum, bailing wire, spit a and LOT of prayers! . . . So, does that mean the demise of CVOLs predated the availability of duct tape? :-) -jc- -unsnip-- No, only that duct tape was cheaper than CVOL maintenance/upgrades. :-) -- Rick -- Remember that if you're not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Well, having not gotten a straight answer to a straight question, I did a quick test. I had a GDG: uid.GDGTEST.G0001V00 uid.GDGTEST.G0002V00 uid.GDGTEST.G0003V00 uid.GDGTEST.G0004V00 I then allocated uid.GDGTEST.G0005V03 And I ended up with uid.GDGTEST.G0001V00 uid.GDGTEST.G0002V00 uid.GDGTEST.G0003V00 uid.GDGTEST.G0004V00 uid.GDGTEST.G0005V03 Which shows that you do not have to go through V00, V01 and V02 before getting to V03. However, I did get some other results that I found surprising. I was able to allocate uid.GDGTEST.G0002V05 uid.GDGTEST.G0002V06 uid.GDGTEST.G0002V01 uid.GDGTEST.G0003V01 which ended up cataloged but not as part of the GDG. GDGALL processing correctly allocates me uid.TESTGDG.G0005V03 uid.TESTGDG.G0004V00 uid.TESTGDG.G0003V00 uid.TESTGDG.G0002V00 uid.TESTGDG.G0001V00 Yet a DSLIST lists me uid.TESTGDG.G0001V00 uid.TESTGDG.G0002V00 uid.TESTGDG.G0002V01 uid.TESTGDG.G0002V05 uid.TESTGDG.G0002V06 uid.TESTGDG.G0003V00 uid.TESTGDG.G0003V01 uid.TESTGDG.G0004V00 uid.TESTGDG.G0005V03 I didn't think that I would be able to catalog non-GDG datasets with the same prefix as the GDG base. Have I missed something? Date: Tue, 20 Jan 2009 14:08:27 -0500 From: jayare...@hotmail.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu Yes, it's understood that there is only one version cataloged at any one time. The question remains: Must version numbers be assigned incrementally? Date: Tue, 20 Jan 2009 13:57:44 -0500 From: stars...@mindspring.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu My understanding is that you would only have ONE verions number at any given time. I have not seen a case where you would have G0001V00, and G0001V01 and G0001V02. Only the G0001V02 would be in the catalog. Any other versions would not. Though I could be wrong, but that is currently my understanding. Version only allows you to replace the current Gen Number without losing the oldest GDG (due to roll off). Lizette -Original Message- From: J R jayare...@hotmail.com Sent: Jan 20, 2009 1:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GDG Question The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Well, I can't imagine needing to create up to 99 replacement versions either. However, if I were to use this feature, I could well imagine making the version number meaningful. Examples might be day-of-week, month-of-year, etc. In such a scenario they could well end up going backwards ... V06 (Friday) to V02 (Monday) maybe. So, the question stands: May version numbers be created out of sequence and randomly? Date: Tue, 20 Jan 2009 13:29:56 -0500 From: stars...@mindspring.com Subject: Re: GDG Question To: IBM-MAIN@bama.ua.edu The Version numbers are ascending (00 to 99). I have not known of a case where you would create a descending version (99 to 00). Lizette The Vyy is the Version Number ... (allowing you to replace it up to 99 times). Are you saying that replacement versions may only be created in ascending sequence? So what your saying is the the LOCATE/CAMLIST macros (and others I suppose) never even look at the Vxx part of the DSN. Your usage of it is interesting, never thought of it myself, but lord knows I could have used it! Thank You, They look at and use it. It is just that when you catalog a GVyy it will replace an existent GVyy entry. The Vyy is the Version Number of the G dataset (allowing you to replace it up to 99 times). There can be only one version of each generation. To do this you must use an Absolute Dataset Name (GDGBASE.GVyy) not the GDGBASE(x) Relative type name. _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GDG Question
It seems to me that I saw a thread that stated when you hit GV00 you will be unable to create (+1). Is this correct? How did you handle this situation? Just delete all generations or create a new GDG? THI Jerry Fuchs Senior Systems Engineer Wendy's Arby's Group One Dave Thomas Blvd. Dublin, Ohio 43017 (614) 764-3594 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Mon, 2009-01-19 at 14:13 -0500, Jerry Fuchs wrote: It seems to me that I saw a thread that stated when you hit GV00 you will be unable to create (+1). You're mistaken. It rolls over, just as you think it should. Easy enough to verify: create a GV00 in a test GDG, then a +1 and see what you get. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
Thanks, Guess that I must have misread the thread or I was smoking something at the time. Jerry David Andrews d...@lists.duda.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 01/19/2009 02:24 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Re: GDG Question On Mon, 2009-01-19 at 14:13 -0500, Jerry Fuchs wrote: It seems to me that I saw a thread that stated when you hit GV00 you will be unable to create (+1). You're mistaken. It rolls over, just as you think it should. Easy enough to verify: create a GV00 in a test GDG, then a +1 and see what you get. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
On Mon, 19 Jan 2009 14:13:34 -0500, Jerry Fuchs jerry.fu...@wendysarbys.com wrote: It seems to me that I saw a thread that stated when you hit GV00 you will be unable to create (+1). Is this correct? How did you handle this situation? Just delete all generations or create a new GDG? THI Jerry Fuchs Senior Systems Engineer Wendy's Arby's Group One Dave Thomas Blvd. Dublin, Ohio 43017 (614) 764-3594 The GDG assignment rolls from GV00 to **.G0001V00 on this condition. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
At 13:41 -0600 on 01/19/2009, Scott Barry wrote about Re: GDG Question: The GDG assignment rolls from GV00 to **.G0001V00 on this condition. That is because the GDG is in a VSAM catalog. In the past when CVOL catalogs were used I think you were SOL since there was no rollover ability. For disks, at least you had the ability to recover by doing a rename but this was not an option with tapes (you had to copy the tape and manually rename it with an absolute name - I used to use GV01 to show it rolled over). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
That is because the GDG is in a VSAM catalog. ICF catalogue -- different from VSAM. In the past when CVOL catalogs were used I think you were SOL since there was no rollover ability. I don't recall it ever being a problem, even with CVOLs. I started this business as a JCL jockey in Production Support, log before UCC7 UCC11 and their sucessors came out. We used CVOLs for almost everything except IMS -- we didn't have CICS, and DB2 wasn't available, yet. We used GDG datasets all the time, and we never had a 'roll over' problem. Of course, my memory could be failing. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG QUESTION
G'day. If you are acessing the new file in the same JCL, the DD statement should look like: DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR(+1). If it's in another jcl then: DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR(+0). To access a one the previous generations then use (-1) or (-2) or (-3) or (-4). A minus 5 is invalid as you only have 5 generations and the most current starts off a 0. Tim Hillock Take my Advice, I'm not using it -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Terry Sambrooks Sent: Saturday, November 15, 2008 3:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: GDG QUESTION Hi Howard, I noted that Linda supplied the required answer to your query about: The executing job has the following DD in the JCL: DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR and the resulting error is: IEF212I E18823X PST0010 STEP01 DUMPIN - DATA SET NOT FOUND Can some one tell me what I'm doing wrong? It's some thing but I just can't see the problem. I WOULD ADD however that your DD statement above is valid if the GDG has associated data sets. Simply coding the base entry name on a DD statement is a means of processing ALL the generations of a GDG without resorting to concatenated DD statements for each generation. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG QUESTION
Simply coding the base entry name on a DD statement is a means of processing ALL the generations of a GDG without resorting to concatenated DD statements for each generation. Instead, the system resorts to concatenated DD statements on your behalf, albeit in reverse chronological sequence. Date: Sat, 15 Nov 2008 08:34:42 + From: [EMAIL PROTECTED] Subject: Re: GDG QUESTION To: IBM-MAIN@BAMA.UA.EDU Hi Howard, I noted that Linda supplied the required answer to your query about: The executing job has the following DD in the JCL: DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR and the resulting error is: IEF212I E18823X PST0010 STEP01 DUMPIN - DATA SET NOT FOUND Can some one tell me what I'm doing wrong? It's some thing but I just can't see the problem. I WOULD ADD however that your DD statement above is valid if the GDG has associated data sets. Simply coding the base entry name on a DD statement is a means of processing ALL the generations of a GDG without resorting to concatenated DD statements for each generation. Kind regards - Terry Terry Sambrooks _ See how Windows® connects the people, information, and fun that are part of your life http://clk.atdmt.com/MRT/go/119463819/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG QUESTION
Hi Howard, I noted that Linda supplied the required answer to your query about: The executing job has the following DD in the JCL: DUMPIN DD DISP=SHR,DSN=PCYC.TMVHSTM.TMVS04.IRR and the resulting error is: IEF212I E18823X PST0010 STEP01 DUMPIN - DATA SET NOT FOUND Can some one tell me what I'm doing wrong? It's some thing but I just can't see the problem. I WOULD ADD however that your DD statement above is valid if the GDG has associated data sets. Simply coding the base entry name on a DD statement is a means of processing ALL the generations of a GDG without resorting to concatenated DD statements for each generation. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
