Disk spanning file attribute?



Help for IBM's record-oriented filesystem VSAM, ESDS, KSDS, RRDS, LDS and Storage management Subsystems

Disk spanning file attribute?

Postby aouverson » Mon Jan 10, 2011 11:36 pm

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
aouverson
 
Posts: 2
Joined: Mon Jan 10, 2011 11:25 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Disk spanning file attribute?

 

Re: Disk spanning file attribute?

Postby Robert Sample » Mon Jan 10, 2011 11:56 pm

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.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: Disk spanning file attribute?

Postby Akatsukami » Tue Jan 11, 2011 12:02 am

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 "*".
"You have sat too long for any good you have been doing lately ... Depart, I say; and let us have done with you. In the name of God, go!" -- what I say to a junior programmer at least once a day
User avatar
Akatsukami
Global moderator
 
Posts: 1053
Joined: Sat Oct 16, 2010 2:31 am
Location: Bloomington, IL
Has thanked: 6 times
Been thanked: 51 times

Re: Disk spanning file attribute?

Postby steve-myers » Tue Jan 11, 2011 1:06 am

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.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: Disk spanning file attribute?

Postby dick scherrer » Tue Jan 11, 2011 4:20 am

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Disk spanning file attribute?

Postby aouverson » Tue Jan 11, 2011 4:29 am

The step that allocates the file in question is this:

//*********************************************************************
//**    MOVE THE BUNDLE TAPE TO DASD                                 **
//*********************************************************************
//STEP040  EXEC PGM=IEBGENER
//*
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DSN=PROD.SYS66.B001.AFPDS300.BUNDLE,               
//             DISP=(OLD,CATLG,CATLG)
//SYSUT2   DD  DSN=PROD.SYS66.FWORKTMP.B001.AFPDS300.BUNDLE,     
//             DISP=(,CATLG,),
//             UNIT=SPROD,
//             SPACE=(CYL,(2000,200),RLSE),
//             DCB=(LRECL=12884,BLKSIZE=27998,RECFM=VBM)
//SYSIN    DD  DUMMY
//*
aouverson
 
Posts: 2
Joined: Mon Jan 10, 2011 11:25 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Disk spanning file attribute?

Postby dick scherrer » Tue Jan 11, 2011 9:12 am

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Disk spanning file attribute?

Postby steve-myers » Tue Jan 11, 2011 11:39 am

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.
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times


Return to VSAM/SMS

 


  • Related topics
    Replies
    Views
    Last post