Attributes of zowe zos-files list data-set --a

[plavjanik]

Hello,

I am using Zowe CLI command zowe zos-files list data-set "MFAAS.SYSVIEW" --a and it returns response like this:

  dsname: MFAAS.SYSVIEW.R1500.CNM4ZSAM
  blksz:  32720
  catnm:  ICF.USERID.USERCATA
  cdate:  2017/11/03
  dev:    3390
  dsntp:  LIBRARY
  dsorg:  PO-E
  edate:  ***None***
  extx:   1
  lrecl:  80
  migr:   NO
  mvol:   N
  ovf:    NO
  rdate:  2020/06/25
  recfm:  FB
  sizex:  20
  spacu:  TRACKS
  used:   15
  vol:    MFAAS2
  vols:   MFAAS2

I would like to calculate the size of the dataset in bytes. I would like to understand the meaning of sizex and spacu. Is sizex size in the spacu units or it is in tracks or different units? What are the possible values for spacu?

[FALLAI-Denis]

I think:
« sizex » is the number of « spaceu » (space unit) allocated units.
« sizeu » if the number of « spaceu » used units, (less or equal to « sizex »).
« spaceu » can be « blocks », « tracks » or « cylinders ».
For standard disk, a cylinder is a group of 15 tracks.
For recent disk « 3390-x », a track is 56664 bytes, (less for older disks).
A block can’t exceed 1 cylinder (15 tracks).

File space is used according « blocksize », wich is a multiple of « recordsize » (for fixed record format). But allocation is made by « tracks » by system.
« Tracks » and « cylinder » are rarelly exact multiples of « blocksize »: a gap (wasted space) is added to fill « tracks » or « cylinders ».

In current sample:

• blocksize = 32720 (multiple of recordsize 80)
• a block needs 1 track (56664 - 32720 = 23944 wasted space for each allocated track / used block)
• 20 allocated tracks = 1 133 280 bytes
• 15 used tracks = 849 960 bytes
• 15 used blocks = 490 800 bytes

This is theoric.
Nowadays IBM disks are emulated. the loss of disk space due to the difference between blocks and tracks may be less

[FALLAI-Denis]

Missing informations:

• primary allocation (initial)
• secundary allocation (increment)

[t1m0thyj]

I would like to calculate the size of the dataset in bytes. I would like to understand the meaning of sizex and spacu. Is sizex size in the spacu units or it is in tracks or different units? What are the possible values for spacu?

IBM documents the meaning of the data set attribute names returned by the z/OSMF REST API here:

Property	Description	Required
spacu	Space units	No
sizex	Data set size in tracks, long format (12 bytes)	No

The documentation seems rather vague here. It appears that sizex is always in tracks, and there are no details provided for spacu.

[FALLAI-Denis]

Hi @t1m0thyj

The mvs system only knows how to manage disk space by means of track allocation...
Even if we ask for allocation in bytes (or kilobytes, or megabytes), or allocations in cylinders, the mvs system will always come back to allocations in tracks.
The problem is that the size in bytes of a track depends on the type of disc used...

What I kept in my notes:

   Unit  Bytes/Track    Tracks/Cyl.    Cyls./Vol.  Megabytes/Vol.

   3380A    47,476         15            885            630
   3380E    47,476         15          1,770          1,260
   3380K    47,476         15          2,655          1,890

   3390-M1  56,664         15          1,113            946
   3390-M2  56,664         15          2,226          1.892
   3390-M3  56,664         15          3,339           2.83  
   3390-M9  56,664         15         10,017           8.51 
   3390-M27 56,664         15         32,760          27.84
   3390-M54 56,664         15         65,520          55.68
      
   3390-EAV                          262,668

In addition, a track may not be fully used because it depends on the blocking mode (fixed or variable) and the size of the block. So there is usually some loss because it is rare for the size of a block to match the size of a multiple of tracks.
This is why it is recommended to have a block size either closer to half the size of a track, or closer to a multiple of the size of a track.
Today in modern systems, we no longer declare the size of the block and we let the system manage it (by means of the DFHSMS services).

If you want a size in bytes, you have to calculate from the size of the block and the number of blocks allocated or used.
But for that it is necessary to determine the number of blocks by a calculation and one falls back on the problem of the size of the track because the number of blocks is calculated compared to the size of the track.

• how many blocks can we put in a track? calculate integer part of (n * tracks) / (block size), number of tracks needed depending on block size and track size.
• depending on the number of tracks used, calculate the number of blocks that this represents.
• multiply the number of blocks by the size of the block = size in bytes of the file.

All disks can be considered to have a track size of 56,664 bytes (3380 disks should only be found in museums now, except perhaps for some specific z/OS functions that have never been updated and which still work with 3380 disks... we do have mvs system code which is still in 24-bit addressing).