IBM Mainframe Forum

Hello,

I'm running into an issue where I have a job that allocates and deletes a very large file everytime its run. This job calls a program to process the records in this file. The issue is that when this file spans multiple disk packs, the other program incorrectly processes some data. The even bigger issue is that no error codes or abends are issued when this happens. We only know it has occured because some of the output is blank.

My question is, is there any utility that would let me know if the allocated PDS spans multiple disk packs. If it does, I just want to abend the job and rerun. I've been trying to looking into the functionality of IEBGENNER, or IDCAMS to possibly check some file attribute, and have been unsuccessful. Possibly a batch file-aid call?

Any suggestions?

Thanks,

Andy

Have you talked to your site storage management group? They are your best source of help since storage management policies vary considerably from site to site and they are the ones who know your site.

LISTCAT will tell how many (and which) volumes the data set is allocated on. Use the VOLUMES keyword on the command; check for lines containing the token "VOLSER" and a volser not equal to "*".

Mr. Sample and Akatsukami apparently forgot that a PDS dataset cannot extend to multiple volumes.

There is no dataset attribute that prevents a non-PDS data set from going onto multiple volumes. I think I recall some issues with a dataset with RECFM=VBS having logical records over more than one volume, but that was years ago.

Hello,

I suspect there is more than one "partial-truth" in the initial post or on that system.

It will probably help if the dataset info for the file is posted as well as the SELECT and FD from the problem program. The JCL for the step might be helpful as well.

The step that allocates the file in question is this:

Hello,

Now please post the remainder of the requested info. . .

Why is the input old,catlg,catlg ? Unacceptable on every system i've worked on in many, many years.

The output is not a PDS so why is PDS mentioned in the initial post? Part of allocating a PDS is to specify some number of directory blocks and none are shown in the posted jcl.

The DCB attributes of the SYSUT2 data set seem to me to be very unusual. I do not believe I've ever encountered a printing device that would really accept 12879 byte records, though printer datasets using "Advanced Function Printing" input might want extremely long logical records since each logical record should be a page or a binary image of some sort. The use of an explicit BLKSIZE like this is not usually advised, though I regard the odds that IBM will ever introduce a disk device with a different track geometry than the 3390 as extremely low. Still, to cover this chance I'd specify DCB=(LRECL=12884,RECFM=VBM,DSORG=PS), which I believe will generate the same DCB attributes on a 3390 as the DCB in the JCL.

I have to admit when I read the initial post I, too, thought PDS was an error, but since it was explicitly mentioned I decided to take the post as it stood.

As dick scherrer mentioned, the use of DISP=(SHR,CATLG,CATLG) for the SYSUT1 DD statement appears to me to be strange. If the dataset is not actually cataloged, the JCL as shown won't work. so there is no dataset to catalog, unless the DD statement is overridden with a UNIT= and VOL=SER parameter. If this is done DISP=(SHR,CATLG,CATLG) should be in the override, not in the base JCL; the base JCL should specify DISP=(SHR,KEEP) or just DISP=SHR.

As has been mentioned before, there is no JCL parameter to explicitly prevent a dataset from being extended to a second volume, though UNIT=(SPROD,1) might work if UNIT=SPROD allocates only a disk device since modern disk devices cannot be unloaded.