View previous topic :: View next topic |
Author |
Message |
theenigma Beginner
Joined: 09 Jan 2003 Posts: 15 Topics: 6
|
Posted: Thu Jan 09, 2003 1:31 am Post subject: Find the Physical Size of a File on Tape/ Disk |
|
|
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 |
|
Back to top |
|
|
semigeezer Supermod
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
|
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). |
|
Back to top |
|
|
Bill Dennis Advanced
Joined: 03 Dec 2002 Posts: 579 Topics: 1 Location: Iowa, USA
|
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 |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12370 Topics: 75 Location: San Jose
|
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.
Code: |
//STEP0100 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=YOUR INPUT FILE NAME,
// DISP=SHR
//SORTOUT DD DUMMY
//SYSIN DD *
SORT FIELDS=(1,1,CH,A)
/*
|
In the sysout you will find something like this
FILESIZE 3400 BYTES
Hope this helps...
cheers
kolusu |
|
Back to top |
|
|
theenigma Beginner
Joined: 09 Jan 2003 Posts: 15 Topics: 6
|
Posted: Fri Jan 10, 2003 4:21 am Post subject: |
|
|
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 |
|
Back to top |
|
|
DaveyC Moderator
Joined: 02 Dec 2002 Posts: 151 Topics: 3 Location: Perth, Western Australia
|
Posted: Fri Jan 10, 2003 7:10 am Post subject: |
|
|
theenigma,
Quote: |
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.
|
I could read 1000000 records into 1 buffer in virtual memory. for DASD you can read the VTOC as has been suggested or for tapes get the block count from the label. All this information is available in the DFSMS manuals... _________________ Dave Crayford |
|
Back to top |
|
|
Bill Dennis Advanced
Joined: 03 Dec 2002 Posts: 579 Topics: 1 Location: Iowa, USA
|
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 |
|
Back to top |
|
|
semigeezer Supermod
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
|
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. |
|
Back to top |
|
|
vattikonda Beginner
Joined: 09 Jan 2003 Posts: 15 Topics: 5
|
Posted: Fri Jan 10, 2003 7:31 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|
|