MVSFORUMS.com

suryavenkat_sharma · Beginner Joined: 06 Jul 2004 Posts: 3 Topics: 2

In my job i have one input file and i need to know how many bytes this file has occupied. This size i need to write into the output file. Can any one please help me?

kolusu · Posted: Tue Jul 06, 2004 9:31 am Post subject:

suryavenkat_sharma,

The simple method of calculating the filesize is

superk · Advanced Joined: 19 Dec 2002 Posts: 684 Topics: 5

Determining the byte count of a dataset might be tricky, unless you want to write your own program (compute number of records X the length of each record). I'm looking to see if there is any existing STANDARD utility that returns a byte count (it will probably be something that runs under USS). No luck yet.

suryavenkat_sharma · Beginner Joined: 06 Jul 2004 Posts: 3 Topics: 2

Thank you Kolusu. I tried this and i got it now. Thanks superk.
Thanks,
Surya Venkat sharma.

kolusu · Posted: Tue Jul 06, 2004 10:10 am Post subject:

suryavenkat_sharma,

If you have easytrieve at your shop then the following JCl will give you the desired results.

Cogito-Ergo-Sum · Posted: Tue Jul 06, 2004 12:06 pm Post subject:

Kolusu,
Isn't the 'file size as a product of number of records and LRECL' true for FB datasets? In case of VB, the sum of RDW for all records should give the file size.
_________________
ALL opinions are welcome.

Debugging tip:
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
-- Sherlock Holmes.

semigeezer · Posted: Tue Jul 06, 2004 12:16 pm Post subject:

No. Not that either. For both FB and especially VB, there can be extra bytes on disk either in unused blocks, or unused tracks. So finding out how 'how many bytes this file has occupied' is not the same thing as finding out how many bytes you would read if you read the file one byte at a time. I'm not sure how to do it, but I think you'd have to find the various DSCBs, calculate the number of tracks and the track size and then do the multiplication (of course, it is worse if the data set spans unlike volumes). One of the utilities might provide enough information for that (IEHLIST?) but I haven't checked. Normally this would be done in assembler using various macros (OBTAIN, etc). Although there is rarely much use for this information, it always amazed me that there is no single command to find it.

semigeezer · Posted: Tue Jul 06, 2004 12:21 pm Post subject:

Actually, on 2nd thought, it is worse than that. Not only do we now have compressed files, but most DASD these days is simulated in RAID devices, striped data sets, and other virtual DASD mechanisms. So reliably finding the real physical amount that a data set occupies is probably impossible. The best you can probably do is to find the amount that MVS *thinks* it is occupying (per my last post).

Cogito-Ergo-Sum · Posted: Tue Jul 06, 2004 12:30 pm Post subject:

semigeezer · Posted: Tue Jul 06, 2004 12:35 pm Post subject:

I think 'rarely' is changing though. MVS systems are interacting with other systems more frequently now than before. For example, MVS systems participate in storage area networks (SANs), can use NFS, use (non-standard) FTP, and expose the file systems in other ways. It would be nice if, for example, FTP listings could show calculated sizes. I'd have thought that once MVS started playing in the 'client/server' game back in the early 90s the need to show file sizes would have been evident. That is why I'm surprised there is no single command or macro to calculate it.