MVSFORUMS.com

theenigma · Beginner Joined: 09 Jan 2003 Posts: 15 Topics: 6

hai all,

I urgently need to find out the Physical Size of a File on Tape/ Disk using either a COBOL Program or a JCL.

Plz plz do come out with a solution.

thanx
a very worried enigma

semigeezer · Posted: Thu Jan 09, 2003 2:20 am Post subject:

I don't know what to do with tape, but dasd files can be evaluated. Doing it yourself is tricky, but you can either use ISPF utilities such as DSINFO, or Rexx's or CLIST's LISTDSI functions. Depending on what information you need, you may have to work a bit with the output of these. For example, if you are looking for # of bytes that is definitely not easy. You probably need to read the file. But if you just want, say, allocated tracks, these functions can do it. If you want to do it yourself, you need to be able to look at VTOCs (reading various types of DSCBs). It has been a while since I used the MVS utilities, but I'm sure there are some that will list these things for you (maybe IEHLIST?). Have a look at the utilities manual(s).

Bill Dennis · Posted: Thu Jan 09, 2003 9:11 am Post subject:

Likewise for tape, if you need actual byte count, you'll have to read the file. If you want approximate, your tape mgmt system probably has inquiry functions that can return you the block count and block size.
Do you know your tape mgmt system? CA-1, TLMS, etc.

Bill

kolusu · Posted: Thu Jan 09, 2003 9:28 am Post subject:

theenigma,

check the sysout messages from the following job and you will find the filesize.

theenigma · Beginner Joined: 09 Jan 2003 Posts: 15 Topics: 6

Thanx for the response, however, i have a couple of things to say..

semigeezer and Bill Dennis

i have tried to calculate the size from the blkcnt, blksize etc but it does not give the exact size of the file and even if it does, how is that conclusive(how can i validate it?).

kolusu

That was good but, it still doesnt give the physical size, its the memory space requested in main/ virtual memory and thats not equivalent to the physical memory.

any other suggestion, is more than welcome

thanx
still a worried enigma

DaveyC · Posted: Fri Jan 10, 2003 7:10 am Post subject:

theenigma,

Bill Dennis · Posted: Fri Jan 10, 2003 11:27 am Post subject:

theenigma,

As you noted, calculating based on blksz, blkct is NOT exact, but approximate for tape or disk (especially with VB files). To get the exact size you MUST read thru the file. Use kolusu's example. Don't look at the memory used messages, but rather a line such as "FILESIZE xxx,xxx bytes" or " NUMBER OF BYTES SORTED: xxxxxx".

Bill

semigeezer · Posted: Fri Jan 10, 2003 5:10 pm Post subject:

On disk, it isn't block count that you care about. it is # of tracks because that is the minimum physical unit of space a data set can take up. LISTDSI et al give SYSUSED, SYSUNITS, etc from which you can figure out the used number of tracks. Another reason to ignore the block count is that there is no gaurantee that the blocks are the same size. Even an FBS data set will usually have a non-'standard' last block.

vattikonda · Beginner Joined: 09 Jan 2003 Posts: 15 Topics: 5

theenigma,

To validate the results try these:
For datasets on tape - type in TSO DFRMM which will lead to the tape management list. From there option 1 (user), option 2 (dataset). With your dataset in there you will get all the required info of the dataset (# of volumes, volume numbers, date created, when expiring, Total blocks, block size typically 32760 etc.,). Total blocks times block size would give you the total size of file you are looking for.

For datasets on disk - from ISPF 3.4 you can get info on howmany blocks it has occupied and the block size... which should give your info.

One other easy way if you are running your job is - within messages look for your DDNAME. The EXCPs associated with the DDNAME identifies the number of blocks it used. So # of blocks times block size is the total size of the file.

Hope this helps...

Cheers,
Vattikonda