Page 1 of 1

FTP and New GDG Level dataset

PostPosted: Wed Jul 21, 2010 11:28 pm
by Net
I have a Job (JCL) that does a GET FTP to retrieve and save a new (+1) GDG dataset. When referencing this dataset in the next step of the same job, do I use (+1) or (+0)? I know that usually it would be (+1), but there are some exceptions, IE: permits. Any help would be appreciated.

Thanks for your time.

Re: FTP and New GDG Level dataset

PostPosted: Wed Jul 21, 2010 11:53 pm
by dick scherrer
Hello and welcome to the forum,

Suggest you consider using a non-gdg dataset name in the ftp and then copy this to the +1.

Once the +1 is created it is known as +1 thru the remaining jcl steps.

but there are some exceptions, IE: permits.
What is a permit :?

Re: FTP and New GDG Level dataset

PostPosted: Wed Jul 21, 2010 11:55 pm
by Net
Thanks, have been considering using your suggestion of non-gdg. A number of other jobs in our system do it that way. We just already had these set up as GDG.

A permit is something we use from a DSUTIL proc that permits certain people/groups to datasets within the batch job execution. Usually done at the end of a batch job for any/all datasets created in the job execution. Saves time if certain people always need access to these datasets.

Re: FTP and New GDG Level dataset

PostPosted: Thu Jul 22, 2010 12:03 am
by dick scherrer
Thanks for the followup :)

Good luck,

d

Re: FTP and New GDG Level dataset

PostPosted: Thu Jul 22, 2010 1:03 am
by NicC
Actually, it is usually best to stop the job after creating the +1 and then later jobs can reference as (0) - saves confusion and makes restarting easier as you do not need to change the relative generation to (0) in downstream steps

Re: FTP and New GDG Level dataset

PostPosted: Thu Jul 22, 2010 2:44 am
by steve-myers
Net wrote:I have a Job (JCL) that does a GET FTP to retrieve and save a new (+1) GDG dataset. When referencing this dataset in the next step of the same job, do I use (+1) or (+0)? I know that usually it would be (+1), but there are some exceptions, IE: permits. Any help would be appreciated.

Thanks for your time.
Actually this raises several issues that I do not know the answer to
  • At least in "reguar" JCL the use of relative generations establishes a fixed link that is valid through the life of the job. In other words if, at the start of the job a dataset has absolute generations G1500V00, G1501V00 and G1502V00, then relative generation +1 will generate G1503V00, relative generation +2 will generate G1504V00, and so on. Now the FTP server in z/OS is a job that may run for weeks, or even months. Does this JCL rule apply for the life of the FTP "job?"
  • In dynamic allocation, you specify a relative generation using same dynamic allocation key as a member name. In other words,
    DC AL2(DALMEMBR,1,2),CL2'+1'
    This actually makes some sort of sense since a relative generation is specified as a sort of member name in JCL
    DSNAME=GDGBASE(+1)
The base part of your query does not make any sense in any event: you can't "retrieve" a +1 generation until it has been created (e.g., "saved.") I presume you really meant
//A       EXEC PGM=FTP,PARM='remote-server'
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
 ...  (statements to logon to the remote server)
GET REMOTE-FILE GDGBASE(+1)
//B       EXEC PGM=your-program
//GDGDS    DD  DISP=OLD,DSNAME=GDGBASE(+1)
I think, but I don't know this to be a fact, JCL like this will work as I think you expect.

I would not want try try something equivalent to this in a TSO session!