That's what I was afraid of. Sounds like there's a need for some good GDG enhancement requests! --
Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 5/8/2010 at 7:54 AM, in message <[email protected]>, "Joel C. Ewing" <[email protected]> wrote: > We had exactly the same issue with user-demand of production jobs where > users need to stage data for the run and multiple runs with different > data may need to be queued when the job can't run immediately. Standard > GDG JCL support which, when you don't know how many generations exist, > only makes it possible to address the most current generation, or all > generations concatenated in "backwards" LIFO order, is pretty useless > for this purpose. > Our solution was to have a "STAGE" step in the demand process that > queues the data as the next generation of a job-specific GDG, and a > "DESTAGE" step for the production job that uses REXX code to locate the > oldest GDG generation, copy it to a fixed file name for processing by > the job stream, and delete it. In effect we use this process to turn > GDG's into a First-In-First-Out stack, which makes them much more > useful. As long as you know the queue depth can't exceed 255 (max GDG > limit value), it works quite well. > > Another approach that we have taken for some EDI data interchange > processes to/from other installations is to use some form of timestamp > as part of the file name to guarantee uniqueness and imply processing > order. Since JCL doesn't include features to support this approach, > this generally requires some application on the MVS side that is able to > do dynamic allocation and catalog query (e.g., REXX in batch TSO) in > order to work with dynamic dataset names and select which files to process. > Joel C Ewing > > On 05/08/2010 07:12 AM, McKown, John wrote: >>> -----Original Message----- >>> From: IBM Mainframe Discussion List >>> [mailto:[email protected]] On Behalf Of Frank Swarbrick >>> Sent: Friday, May 07, 2010 5:48 PM >>> To: [email protected] >>> Subject: Re: Amazing article. >>> >>> It is useful to be able to receive the "second" generation >>> before processing the "first". It is less useful that if >>> this happens you have to make a JCL change to be able to >>> process the older generation once a newer generation has been created. >>> >>> Are there standard ways of dealing with this? >>> >>> Signed, new MVS person. >>> -- >>> >>> Frank Swarbrick >> >> Not any from IBM that I am aware of. IBM's method implys a "stack" of GDGs, > where (0) is always the newest one created. So if you're JCL refers to the > current gen, it gets the youngest. There is not an IBM way to process them > from oldest to youngest. Now, in a z/OS UNIX paradigm, using DoveTailed > Technologies (love those people!), you could do it with their "catsearch" > program. Similar to: >> >> #!/bin/sh >> catsearch MY.GDG.BASE.G* |\ >> while read gdg_entry; do >> my_program ${gdg_entry} >> end >> >> >> You could also probably embed this is a REXX program similar to: >> >> /* rexx */ >> stdout.0=0 >> stderr.0=0 >> call bpxwunix "/usr/local/bin/catsearch TSH009.PDS.P*",,stdout.,stderr. >> do i=0 to stdout.0 >> say "Found DSN:"stdout.i >> end >> do i=0 to stderr.0 >> say "Error:"stderr.i >> end >> >> Where I have the "found DSN" SAY instruction, run your application. >> >> -- >> John McKown >> Systems Engineer IV >> IT >> >> Administrative Services Group >> >> HealthMarkets(r) > ... >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- 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
