DSLIST in batch?

DaveV · Posted: Wed Oct 13, 2021 8:07 pm

Hi all - is there a simple way to capture the output of 3.4 (DSLIST) in batch? I know how to run LISTCAT and am aware of DCOLLECT as well, but what I am looking for is to produce a simple list of ALL datasets on our system in a simple linear format that I can download to a text file on the PC. The DSN names would be sufficient, but date created/date referenced would be nice as well. Any thoughts/responses appreciated!

Joerg.Findeisen · Posted: Wed Oct 13, 2021 8:24 pm

See ibmmainframes.com/about68154.html

DaveV · Posted: Wed Oct 13, 2021 8:37 pm

Is there another way besides REXX?

sergeyken · Posted: Wed Oct 13, 2021 10:59 pm

sergeyken · Posted: Thu Oct 14, 2021 12:33 am

Again, and again, and again:

This topic has nothing to do with neither JCL, nor VSAM.

Joerg.Findeisen · Posted: Thu Oct 14, 2021 3:46 am

Pete Wilson · Posted: Tue Oct 19, 2021 2:34 pm

There's various OEM products out there that could do this so you you should check with your Storage or Sysprog team, or perhaps your Performance team to see what is available in your site.

NOTE: Including creation and last reference dates means accessing the physical volumes to get that which will make it take a lot longer than just a catalog search for names only.

Joerg.Findeisen · Posted: Wed Oct 20, 2021 10:24 am

Basically you can also use NAVIQUEST (ISMF in Batch), although it might take ages to complete on large installations.

steve-myers · Posted: Sun Jan 02, 2022 11:23 pm

Is something like this what you have in mind?

steve-myers · Posted: Tue Jan 11, 2022 5:48 am

The batch DSLIST program is ready for evaluation. Send me, steve-myers, a PM with your E-mail, and I'll send you a file consisting of a unloaded PDS containing an evaluation copy of the program. They have made it moderately difficult to get to the PM page. From the home page of the web site, click on the Forum link. On that page click on the PM link. This link uses awfully small characters and it's hard to see.

I do ask that you install it, try it, and let me know about any issues you have. I won't promise to correct them, but I'll try. The final distribution will be through cbttape.org.

Joerg.Findeisen · Posted: Tue Jan 11, 2022 7:06 am

@Steve: I personally would change the order of the columns. DSN Volume..
Q: What do you do with Multi Volume Datasets? ISPF displays a plus sign after the volume name.

steve-myers · Posted: Tue Jan 11, 2022 8:44 pm

I deliberately chose to put the data set name on the right, for two reasons:

- Since the output is VBA, the SYSPRINT data set will be smaller. The program truncates the output line at the end of the data set name.
- Most testing was done in TSO, so all of the data set attributes, which represents quite a lot of code, was readily available on the terminal.

I will look into your idea about multi-volume data sets. This is not trivial, especially if the data set is the object of an alias as the alias name follows the volume list.

steve-myers · Posted: Wed Jan 19, 2022 12:07 am

The offer of an evaluation copy of DSLIST for batch has been withdrawn; there have been no takers.

Some time in the next month it will appear in CBT tape. I will announce its availability in this thread.

steve-myers · Posted: Thu Jan 20, 2022 8:37 pm

DSLIST is now available on cbttape.org. It is "file" 1025.

It is distributed in source, so the proposal to rearrange the output line can be easily accomplished.

steve-myers · Posted: Fri Jan 21, 2022 11:26 pm

Joerg.Findeisen · Posted: Sat Jan 22, 2022 2:26 pm

@Steve: Is it possible to extend the field for Allocated and Used by two digits at least? I get wrong results when I test against a very large SA-Dump Dataset residing on 15x Model-54 in our shop.

I do get this as:

steve-myers · Posted: Sat Jan 22, 2022 10:05 pm

The internal calculation for allocated and used space is correct, but it only displays the rightmost 6 digits after converting the rightmost 7 digits, so 10,000,001 tracks will display as 000001. You run into a problem of output line space vs output line width. Internally, converting 9 digits to display 7 or 8 (or even 9) is not a major problem, but then we run into the issue of line width. When I was preparing the update I posted yesterday I found the basic line width was 118 bytes (with the RDW), so there is 7 available bytes for LRECL=125. Of course, you can expand the LRECL to 137 quit easily, though the page header requires some recalculation to fill out the 137 bytes.

Now it was my guess that there were very few data set with more than 1,000,000 tracks, and 6 digits would be adequate for most data sets. This leave me with inserting separator characters, which have its own set of line width issues (999,999 becomes 7 characters, not 6). I find that 1000001 is quite difficult to interpret, much more so than, say, 125346; 1,000,001 is relatively easy to interpret compared to 1000001.

I will look into expanding allocated and used tracks for the next update, if any defects are reported.

FWIW, while testing the update it got an S002 ABEND, so my first guess was the output line got too long, so I checked that first. It turned out the sub header line was too long; I forgot to remove the right DATA SET NAME text. After I corrected that goof it ran fine.

Joerg.Findeisen · Posted: Sat Jan 22, 2022 11:42 pm

I will test the new Update once it is released. Thank you for taking care of the issues.

steve-myers · Posted: Sun Jan 23, 2022 10:17 pm

The present version of DSLIST does not support data sets with extended attributes. The largest possible "regular" data set is 491505 tracks on one volume - well below 999999 tracks. Worse, I do not have any "extended" volumes to practice on, just pseudo 3390-9 volumes.

steve-myers · Posted: Thu Feb 17, 2022 11:40 pm

DSLIST with extended volume support appears to be working, though it will require more testing.

I have other programs that compute allocated space. The first one I tested failed miserably. I then examined the extent entry in the format 8 DSCB. It did not appear to have valid data: FFFF 0000 for the start of the one and only extent for the data set. Last night I realized it was perfectly OK. Start cylinder 000FFFF is the first cylinder after the track managed space, this made the end extent 004001E after it was normalized to 0010040E (cylinder 0010040 head E).

Since DSLIST does the same calculation I then tried it. It reported 315 allocated tracks, so the basic algorithm was correct. I then went back to the first program and went over its calculation. I discovered (I think) two bugs. After I corrected the bugs it worked! It requires more testing before I send anything to CBT.