When I first read enrico-sorichetti's post I thought to disagree with it. DCOLLECT can be hard to collect since it involves IDCAMS, and it may not be vwry helpful since sensuixel is using his own list, which I gather he is creating using IGGCSI, which can be orders of magnitude quicker than IDCAMS, at least if he is collecting lists of datasets. Granted sensuixel is recreating the wheel, and he will find it painful for datasets like this one -
--FORMAT 1 DSCB--
F1 C6E4E2D9F1F1 0001 6E0063 000000 08 00 00 C9C2D4D6E2E5E2F24040404040
6F008680000000 0200 90 00 1810 0050 00 0000 82 80000001 000704 C35E 0000
0100001D000C001D000C 0101010D000C010D000C 01020095000E0095000E 0002000827
--FORMAT 3 DSCB--
03030303 0103001D0002001D0002 010400F9000E00F9000E 01050100000A0100000A
01060092000500920005 F3 01070071000900710009 00000000000000000000
00000000000000000000 00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000 0000000000000000000
sensuixel has to process the three extent entries in the Format 1 DSCB, acquire the Format 3 DSCB, process the four extent entries in the key area of the Format 3 DSCB, and any remaining extent entries in the data area of the Format 3 DSCB. If the dataset has more than 16 extents, possible for SMS managed datasets, he has to acquire the next Format 3 DSCB and continue the process. Just to add more insult, and sensuixel may not know this, if the dataset is allocated in the cylinder managed area of an "extended attribute" volume, he will be dealing with different format extent areas in different DSCBs he will have to acquire using a new parameter in the OBTAIN/CAMLST macros. Unstated here, sensuixel also has to acquire the number of tracks/cylinder in the volume; it is not safe to simply use 15. So it can get unpleasant.
Actually, while the new parameter exists in both the OBTAIN and CAMLST macros, it is really just in the CAMLST macro; if the new parameter is specified in the OBTAIN macro, it just sets the flag in the CAMLST macro.