Home > Archive > Cobol > January 2006 > Re: [OT] IBM Mainframe DSLIST to Dataset w/ Wildcards?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: [OT] IBM Mainframe DSLIST to Dataset w/ Wildcards?
|
|
| Joe Zitzelberger 2006-01-13, 7:55 am |
| In article <dpmakt$leg$1@reader2.panix.com>, docdwarf@panix.com ()
wrote:
> All righty... here's how we're spending some slow time here. Datasets get
> generated on a biw ly basis with the format:
>
> USERID01.TAnnnnn.Pooo.Ddddhhmm.node
>
> ... where nnnnn represents a division, ooo is a pay period, ddd = 'Julian'
> date, hhmm = time and .node is any one of four possible values. The
> primary criterion of selection will be ooo, the pay period.
>
> (Pay period is designated as single-digit year and 01 - 27, a biw ly
> cycle; research has determined that the earliest datasets are P0, year
> 2000, and that no P9 exist.)
>
> (I know... but I didn't design the naming convention.)
>
> Folks in corner offices want these deleted and their wills be done... but
> I'm looking to automate the task since there are about 14,000 datasets
> involved, spread out over five USERIDs... oh, and most - but not all - are
> in MIGRAT1 or MIGRAT2 status.
>
> Now... if I use the (Library Function) 3.4 Data Set List Utility I can
> specify a wildcarded string - eg USERID02.TA*.P0* - and the P command-line
> option; if I log off and Keep my listing dataset I can then use it as
> input to a DFSORT, taking the listings of
>
> USERID02.TA11111.P001.NODE1
> USERID02.TA11111.P001.NODE2
> USERID02.TA22222.P001.NODE1
> USERID02.TA22222.P002.NODE2
>
> ... etc. and editing/reformatting them to create another file, consisting
> of...
>
> HDELETE USERID02.TA11111.P001.NODE1
> HDELETE USERID02.TA11111.P001.NODE2
> HDELETE USERID02.TA22222.P001.NODE1
> HDELETE USERID02.TA22222.P002.NODE2
>
> ... and use that as a SYSTSIN for an IKJEFT01. For the datasets that
> aren't archived I can do this again and create an IDCAMS input of
>
> DELETE USERID02.TA33333.P026.NODE3
>
> ... and get rid of the last.
>
> Combining an interactive task, a logoff/logon sequence and a batch job in
> this way - while it will work - offends my sense of elegance; while I have
> a solution I'm looking for a better one.
>
> What I'd like to do is find a utility that does in batch what the Data Set
> List Utility does in the foreground, something that I can feed a string
> like USERID02.TA*.P0* and have it generate the listing of the datasets
> that I can feed to a SYSOUT and pass to the DFSORT edit/reformat step.
>
> Might anyone be able to suggest where I might look to find such a utility?
>
> Thanks much!
>
> DD
The TSO manual documents an interface called ICF, I think that means
something like Interactive Catalog Facility, but I could be totally
wrong.
Anyway, it is very easy to use, you can do what amount to DSL calls
inside of Cobol programs. You can ask for all datasets that fit a mask,
for example USERID%%.**.NODEXYZ and repeated calls will return the next
dataset.
I think I could dig up an example program if needed...
| |
|
| In article <zberger-9B801C.23542112012006@ispnews.usenetserver.com>,
Joe Zitzelberger <zberger@knology.net> wrote:
>In article <dpmakt$leg$1@reader2.panix.com>, docdwarf@panix.com ()
>wrote:
[snip]
>
>The TSO manual documents an interface called ICF, I think that means
>something like Interactive Catalog Facility, but I could be totally
>wrong.
>
>Anyway, it is very easy to use, you can do what amount to DSL calls
>inside of Cobol programs. You can ask for all datasets that fit a mask,
>for example USERID%%.**.NODEXYZ and repeated calls will return the next
>dataset.
>
>I think I could dig up an example program if needed...
I've been given a solution using ADRDSSU... but I'm always willing to take
a gander at another'n. It would be greatly appreciated, Mr Zitzelberger.
Thanks much!
DD
|
|
|
|
|