|
View previous topic :: View next topic
|
| Author |
Message |
PRIDHVIRAJ NANDARAPU
New User
Joined: 11 Apr 2007
Posts: 4
Location: India
|
|
|
|
Hi all,
I want to know how to read the absolute number of a GDG dataset.
For example consider the GDG A.B.G.GxxxxVnn. here XXXX is the absolute number and nn is the version number.
I need to know how to read absolute number in the JCL itself. my requirement is to send an alert to user if the GDG reachs the limit to 250.
With Regards,
Prudhvi. |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
What do you mean reaches the limit 250 ?
What's the problem here ? if it reaches 250 the next generation will be 251 and generation 0001 will be dropped. |
|
| Back to top |
|
|
PRIDHVIRAJ NANDARAPU
New User
Joined: 11 Apr 2007
Posts: 4
Location: India
|
|
|
|
| According to the business requirements we need to store the data of 10 years. so we need to preserve all datasets. So once a GDG reaches its limit then the user should be alerted to create a new base. |
|
| Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
You can use SAS to resolve a DDNAME to a DSNAME:
| Code: |
//SASSTEP EXEC SAS
//SAS.SASLOG DD SYSOUT=*
//SAS.SYSDUMP DD SYSOUT=*
//SAS.SASLIST DD SYSOUT=*
//GDGIN DD DISP=SHR,DSN=GDG.NAME(0)
//GDGOUT DD DSN=GDGOUT,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),RECFM=FB,LRECL=80
//SYSIN DD *
DATA _NULL_;
INFILE GDGIN JFCB=JFCBIN;
FILE GDGOUT;
LENGTH DSNAME $ 44;
IF _N_ = 1 THEN
DO;
DSNAME = SUBSTR(JFCBIN,1,44);
PUT DSNAME;
END;
RUN;
/*
|
|
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
How often is a new GDG generation created. In the past I have used different GDGs for different accumulations.
Daily = project.dataid.DLY.GnnnnV00
Monthly = project.dataid.MTH.V1.GnnnnV00
Monthly = project.dataid.MTH.V2.GnnnnV00
Where on the first day of each month the daily GDGs were concatenated onto two different versions of a monthly GDG, and all of the daily GDG versions were deleted once the integrity of the output tapes had been verified.
For 7 years we had a GDG base defined as 90 instead of 84, which gave a little xtra data retention. Also note the use of two copies of long term retention copies. Just in case one version becomes unusable. It is also a good idea to read these datasets periodically to ensure that the recording media is in good condition, and if not then to recreate the appropriate copy from the backup version. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
In your job that creates the (+1), run the IDCAMS LISTCAT report to a file, then read it into a program (SAS, COBOL, whatever) and find the LIMIT and the last gen#. Compare and have the program act accordingly.
I would not wait until the LIMIT has been reached, but rather when one is within a few weeks of it, to ensure time to react.
Also, if the LIMIT has been reached, I'd kill the job (COND or IF) to prevent loss. |
|
| Back to top |
|
|
PRIDHVIRAJ NANDARAPU
New User
Joined: 11 Apr 2007
Posts: 4
Location: India
|
|
|
|
| my job runs twice a day and so it creates two entries daily. I found a solution like i am storing the date and generation number in a table at the time of creation of GDG entry and then i am checking it for the limit. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
Why are you checking the limit, if you read what I've done in the past in situations like this, there is no need to generate more work for yourself at all ............... unless you really want to.
Using the GDG methodology I have described previously, there is no manual intervention. Everything is scheduled via the schedule package. |
|
| Back to top |
|
|
|
|
