FTP and New GDG Level dataset



TSO Programming, ISPF, SDF, SDSF and PDF, FTP, TCP/IP Concepts, SNA & SNA/IP etc...

FTP and New GDG Level dataset

Postby Net » Wed Jul 21, 2010 11:28 pm

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.
Net
 
Posts: 2
Joined: Wed Jul 21, 2010 11:23 pm
Has thanked: 0 time
Been thanked: 0 time

Re: FTP and New GDG Level dataset

 

Re: FTP and New GDG Level dataset

Postby dick scherrer » Wed Jul 21, 2010 11:53 pm

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 :?
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: FTP and New GDG Level dataset

Postby Net » Wed Jul 21, 2010 11:55 pm

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.
Net
 
Posts: 2
Joined: Wed Jul 21, 2010 11:23 pm
Has thanked: 0 time
Been thanked: 0 time

Re: FTP and New GDG Level dataset

Postby dick scherrer » Thu Jul 22, 2010 12:03 am

Thanks for the followup :)

Good luck,

d
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: FTP and New GDG Level dataset

Postby NicC » Thu Jul 22, 2010 1:03 am

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
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Re: FTP and New GDG Level dataset

Postby steve-myers » Thu Jul 22, 2010 2:44 am

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!
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times


Return to TSO & ISPF

 


  • Related topics
    Replies
    Views
    Last post