Re: RFE to enhance GDGORDER in JCL

[Elardus Engelbrecht]

Robert A. Rosenberg wrote:

>>Could work, but it is not always known that there are indeed 5 generations. 
>>Lizette wants the oldest and the access method should find that oldest entry 
>>no matter what the quantity of versions there are.

>I may not have worded my comment correctly. All I was saying was that in a GDG 
>with 5 generations, going DSN=GDGBASE,GDGORDER=FIFO was the equivalent of a 
>concatenation using relative generation numbers and listing them in oldest 
>(-4) to newest (0) generation number. I also noted (or implied) that this 
>method relieves the user from knowing the number of generations currently in 
>use.

Many thanks for kindly explaining this. I am fully with you on this one. 
Perhaps I also worded my comment incorrectly, but this is IBM-MAIN where each 
person is kindly helping others.

Thanks Robert for your kind explanation. I value your posts and I learn from 
them too.

All of the very best for you!

Groete / Greetings
Elardus Engelbrecht

Today I learned something new:

I am *NOT* using Google anymore, because my wife always knows everything and is 
always right... *sigh* 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RFE to enhance GDGORDER in JCL

[Robert A. Rosenberg]

At 00:38 -0600 on 01/13/2016, Elardus Engelbrecht wrote about Re: RFE 
to enhance GDGORDER in JCL:



 >IOW: //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO when there are 5
generations yields:

Could work, but it is not always known that there are indeed 5 
generations. Lizette wants the oldest and the access method should 
find that oldest entry no matter what the quantity of versions there 
are.


I may not have worded my comment correctly. All I was saying was that 
in a GDG with 5 generations, going DSN=GDGBASE,GDGORDER=FIFO was the 
equivalent of a concatenation using relative generation numbers and 
listing them in oldest (-4) to newest (0) generation number. I also 
noted (or implied) that this method relieves the user from knowing 
the number of generations currently in use.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RFE to enhance GDGORDER in JCL

[Elardus Engelbrecht]

Lizette Koehler wrote:

>I created my fist RFE, so be gentle.

"Really Fine Enhancement!" ;-D

>Use the GDGORDER parameter for a DD that specifies the base name of a GDG data 
>set (a GDG-all request). This keyword specifies the order in which the 
>individual generation data sets (GDSs) will be concatenated.

'Concatenated' - means you want to READ them in another order. No writing to 
GDG of course.

>This RFE is to request that the GDGORDER on JCL apply not only to the base but 
>the individual generation numbers as well.

That is a good RFE.

>If you think this would be beneficial, please vote.

I have. Only once! I want to vote 1 million times, but no... ;-)


J.P. wrote:

>"Your request is not going to end well. "

Really? This is an enhancement. Currently the logic is from youngest to oldest, 
but she wants to reverse the reading from the oldest to youngest. I believe 
there is a table (in the address space) used by that access method which gets 
all the GDG versions and then list them one by one based on available catalog 
entries and JCL DD entries at STEP level. After that, that list is then made 
available to the program in the JCL. All she asks is, simply reverse the order 
in a control block or area where that GDG version lists are stored temporarily.


Robert A. Rosenberg wrote:
 
>I can not see the RFE text to comment ...

Did you registered?

>IOW: //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO when there are 5 
generations yields:

Could work, but it is not always known that there are indeed 5 generations. 
Lizette wants the oldest and the access method should find that oldest entry no 
matter what the quantity of versions there are.

Currently as John said, only method is to get the GDG base, get the # of 
versions and move on from oldest to youngest. Tedious, but only method 
available which may or may not meddle with that DISP=(OLD,DELETE).

Good luck Lizette, you will need all the help. I remember your previous posts 
on this subject.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RFE to enhance GDGORDER in JCL

[J. P.]

You are asking IBM to provide a new access method to read the file(s) backward 
with your request.  And there is no guarantee that the actual access method 
invoked by the program(s) involved will be compatible with your new backwards 
access method (lets call it LBAM, shall we?).  For example, the program might 
be written to use BSAM (or even EXCP) while your new LBAM is only setup to 
support QSAM.  
  
Your request is not going to end well.  
  
J.P. 
  
Lizette recently posted: 

I created my first RFE, so be gentle.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=81822

Use the GDGORDER parameter for a DD that specifies the base name of a GDG data 
set (a GDG-all request). This keyword specifies the order in which the 
individual generation data sets (GDSs) will be concatenated.

This RFE is to request that the GDGORDER on JCL apply not only to the base but 
the individual generation numbers as well.

For example.  If I code //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO   I can 
get to the oldest entry.
I would also like to see

//GDG  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO
//GDG  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO
and so forth.

This is to allow the reading of GDG Base backwards and forward as well as get 
selected entries.

If you think this would be beneficial, please vote.

Thank you
Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RFE to enhance GDGORDER in JCL

[John McKown]

On Tue, Jan 12, 2016 at 2:06 PM, J. P.  wrote:

> You are asking IBM to provide a new access method to read the file(s)
> backward with your request.  And there is no guarantee that the actual
> access method invoked by the program(s) involved will be compatible with
> your new backwards access method (lets call it LBAM, shall we?).  For
> example, the program might be written to use BSAM (or even EXCP) while your
> new LBAM is only setup to support QSAM.
>

​I don't think that's what ​Lizette is asking for. Assume that there exists
GDG.G0002V00 through GDG.G0007V00 in the GDS. Normally GDG(0) gets you
GDG.G0007V00. That is the _highest_ "goovoo" number in the GDS. Lizette
wants a way to do a relative generation ask for the _lowest_ "goovoo" in
the GDS. So that it would be possible have a series of identical jobs run
to process each member of the GDS from "oldest" to "newest". I.e.

//SOMESTEP EXEC PGM=SOMEPROG
//SYSPRINT DD SYSOUT=*
//INPUT DD DISP=(OLD,DELETE),DSN=GDG(0),GDGORDER=FIFO

In the above, the first time the job with the step is run, GDG.G0002V00 is
processed and deleted. The second time it is run, GDG.G0003V00 is processed
and deleted. And so forth. There is no way to do this using current JCL.
The only way that I know is to run something which does in inquire on the
GDS, get the oldest GDS entry, then do a dynamic allocate on it, and
finally process it.


>
> Your request is not going to end well.
>
> J.P.
>
> Lizette recently posted:
>
> I created my first RFE, so be gentle.
>
> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=81822
>
> Use the GDGORDER parameter for a DD that specifies the base name of a GDG
> data set (a GDG-all request). This keyword specifies the order in which the
> individual generation data sets (GDSs) will be concatenated.
>
> This RFE is to request that the GDGORDER on JCL apply not only to the base
> but the individual generation numbers as well.
>
> For example.  If I code //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO   I
> can get to the oldest entry.
> I would also like to see
>
> //GDG  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO
> //GDG  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO
> and so forth.
>
> This is to allow the reading of GDG Base backwards and forward as well as
> get selected entries.
>
> If you think this would be beneficial, please vote.
>
> Thank you
> Lizette
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Werner Heisenberg is driving down the autobahn. A police officer pulls
him over. The officer says, "Excuse me, sir, do you know how fast you
were going?"
"No," replies Dr. Heisenberg, "but I know where I am."

Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

He's about as useful as a wax frying pan.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Fw: Re: RFE to enhance GDGORDER in JCL

[Lizette Koehler]

IBM is already supplying the process to read the oldest or the newest with 
GDGORDER=LIFO or GDGORDER=FIFO.  I am just asking that they allow the GDGORDER 
to pick up the GDG relative number where GDGORDER is specified (LIFO is the 
default so -1, -2 would behave the same).  I am asking if GDGORDER=FIFO is 
specified, that it also be used with the relative gen number.

So with John's example G0001V00 - G0007V00.

//GDGDD  DD DISP=SHR,DSN=GDGBASE(0)   = G0007V00

//GDGDD  DD DISP=SHR,DSN=GDGBASE(-1)  = G0006V00  

//GDGDD  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO   = G0001V00 

//GDGDD  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO  = G0002V00 

  I did not ask for a new way to specify the Relative Gen number.  So I would 
expect the user would need to be careful when reading oldest to youngest.  Same 
errors should occur should a user ask for the GDGORDER=FIFO with -3 and -3 does 
not exist.

and so on.

GDGORDER only reads the base backwards.  I wanted something that could target a 
relative GDG Number forwards or backwards.

I did open a case to IBM on this, and they suggested the RFE since they liked 
the idea.

Lizette
 

-Original Message-
>From: "J. P." 
>Sent: Jan 12, 2016 1:06 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: RFE to enhance GDGORDER in JCL
>
>You are asking IBM to provide a new access method to read the file(s) backward 
>with your request.  And there is no guarantee that the actual access method 
>invoked by the program(s) involved will be compatible with your new backwards 
>access method (lets call it LBAM, shall we?).  For example, the program might 
>be written to use BSAM (or even EXCP) while your new LBAM is only setup to 
>support QSAM.  
>  
>Your request is not going to end well.  
>  
>J.P. 
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RFE to enhance GDGORDER in JCL

[Robert A. Rosenberg]

I can not see the RFE text to comment but from the description I see 
nothing about the order of reading the records in the generation but 
only the order of the generations in the concatenation.


IOW: //GDG  DD DISP=SHR,DSN=GDGBASE,GDGORDER=FIFO when there are 5 
generations yields:


//GDG  DD DISP=SHR,DSN=GDGBASE(-4)
// DD DISP=SHR,DSN=GDGBASE(-3)
// DD DISP=SHR,DSN=GDGBASE(-2)
// DD DISP=SHR,DSN=GDGBASE(-1)
// DD DISP=SHR,DSN=GDGBASE(0)

This has the advantage that you do not need to list each relative 
generation (as above) and/or need to know the generation count.



At 14:06 -0600 on 01/12/2016, J. P. wrote about Re: RFE to enhance 
GDGORDER in JCL:


You are asking IBM to provide a new access method to read the 
file(s) backward with your request.  And there is no guarantee that 
the actual access method invoked by the program(s) involved will be 
compatible with your new backwards access method (lets call it LBAM, 
shall we?).  For example, the program might be written to use BSAM 
(or even EXCP) while your new LBAM is only setup to support QSAM. 


Your request is not going to end well. 

J.P.

Lizette recently posted:

I created my first RFE, so be gentle.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=81822

Use the GDGORDER parameter for a DD that specifies the base name of 
a GDG data set (a GDG-all request). This keyword specifies the order 
in which the individual generation data sets (GDSs) will be 
concatenated.


This RFE is to request that the GDGORDER on JCL apply not only to 
the base but the individual generation numbers as well.


For example.  If I codeI can get to the oldest entry.
I would also like to see

//GDG  DD DISP=SHR,DSN=GDGBASE(0),GDGORDER=FIFO
//GDG  DD DISP=SHR,DSN=GDGBASE(-1),GDGORDER=FIFO
and so forth.

This is to allow the reading of GDG Base backwards and forward as 
well as get selected entries.


If you think this would be beneficial, please vote.

Thank you
Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN