"Greg Price" <procegrog@...> writes:

On 2020-12-06 2:45 AM, Patrik Schindler wrote:

today I was wondering, how much unallocated space I have available
on the various volumes

I use the LISTVOL command on TSO for this - not sure if it is on TK4-
or not.

Cheers,
Greg

It's there. At least on my tk4- Update 8 system

<#secure method=pgpmime mode=sign>

DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)

nope.

Two things:

1) With RECFM=FB, the block's size must be a multiple of the record length. Plainly 28332
isn't a multiple of 80.

2) There are overheads in a block. In a Count-Key-Data disk type (such as a 3390), a data
block is preceeded by a count block and (possibly) a key block. In a physical 3390 blocks
are (were) stored in sets of 32 bytes (? so long since I've needed to know) - which includes
ECC data.

So each of these three block types takes a multiple of 32 bytes. While a count block is 5
bytes long (fwiw, 1 byte for record's number on track, 2 bytes for the length of the key block
(obviously zero if unkeyed) and two bytes for the length of the data block) it still consumes 32
bytes on the track.

In addition there are inter block gaps - in a 3390, each a multiple of 32 bytes. Both between
the count, key and data blocks and between sets of CKD blocks. I forget their sizes.


has actual maximum block size at various blocks per track values. The maximum block size
to store 2 blocks per track is 27998. Any size larger means one block per track, and any size
larger than 32760 requires low level access techniques.

So 27998 is the largest realistic block size for most purposes. Rounding down to a multiple
of 80 bytes gives
DCB=(LRECL=80,BLSKIZE=27920,RECFM=FB)

In addition, taking some other things from this thread, in MVS type systems,

- data sets are allocated in, at a minimum, units of tracks. A one byte data set consumes at
least a whole track.

- data sets are allocated in extents - which can range in size from a track to an entire disk.
Once a track is allocated to a dataset, it is not available to another dataset.

If you are looking at 'how full is a disk', you really need to look at two things:

- how many tracks are allocated to a dataset
- how much of each dataset's allocation is actually occupied by data. My recollection of Linux
and Windows is that unused space within a file's allocation is going to be somewhat less than
1 KB. In MVS is an be an entire disk.

You might also find IEHLIST of use.

/iehlist.htm
((plain) MVS's version is much the same.) One advantage it seems to have is that it can
provide each data set's "LAST BLK(TTTT-R)" - that is you can calculate how much of the
data set's allocation is, in fact, unused .

Obviously, as others have mentioned, this, as with IBHLSPAC, is the 'logical' space inside
the disk. If the track is compressed, it doesn't relate to how much space each track
consumes in the hosting Linux/Windows environment. An allocated track full of zeros takes
less space than a 'free' track full of random stuff left over from when it was used.


James Campbell




On 5 Dec 2020 at 17:30, Joe Monk wrote:

Patrik,

Youre conflating a couple of concepts.

1 is LRECL - this is the size of 1 record
2 is BLKSIZE - this is the size of 1 block

The only reason we care about bytes in the mainframe world is for blocking
factor, how many records can I fit in 1 block, which can fit on a track?
So, we only care about the number of bytes per track for that reason. A track
is always a fixed number of bytes. A cylinder is ALWAYS 15 tracks.

Example: on a 3390, a track is 56,664 bytes. If I have 80 byte fixed
records, then I can fit 708 records on a track. BUT - when using QSAM,
efficient dasd usage mandates half-track blocking, or 1 block should be
about 28,332 bytes. This means 1 block should be about 354 records...

So in JCL:

DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)

Joe

On Sat, Dec 5, 2020 at 4:42 PM Patrik Schindler <poc@...> wrote:

Hello Jay,

Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:

Take a look at

Thanks a lot, will do and report back. From the sample output, it?s not
too helpful for a rookie like me: I don?t yet have a feeling (or better:
deep understanding) for juggling with cylinders and tracks. I?m used to
bytes, but isn?t the size (in byte) per track device dependent?

Maybe an additional column with percentage-used would be more helpful for
a first glance? I?ll see if I could bring this thing into TK4-, and maybe I
can enhance the source. Tomorrow. Here?s nearly midnight...

:wq! PoC

--
This email has been checked for viruses by AVG.

Hello Joe,

Am 06.12.2020 um 00:30 schrieb Joe Monk <joemonk64@...>:

Youre conflating a couple of concepts.

So it seems. Thanks for your explanation!

:wq! PoC

Hello Jeff,

Am 06.12.2020 um 00:07 schrieb Jeff Bassett <bassettj@...>:

Well - your comment of being helpful to a rookie....
You see, in the MAINFRAME world (except now z/LINUX) - allocation is done in three ways
BLKs - BLOCKS -
TRKS - tracks
CYL - cylinders -

So - BYTES is of no use....

I don’t think it’s *no* use, but maybe less useful? When I want to create a dataset for some kind of tabular data, this equates to a record length. This one I think of in Bytes. But again, maybe this is just my habit coming from stream-oriented platforms. Also OS/400 doesn’t bother the user with tracks and blocks, so yes, this whole concept is very unusual to me. :-)

In the early days - this was somewhat of a challenge - there are SEVERAL places to get the DISK capacity tables -
Here is one -

Thanks for that reference! So, it would be not too much overhead nowadays to have this list being available in a standardized data set in an MVS environment, to help calculations, right? For rookies like me? ;-)

The actual number of cylinders - the PHYSICAL disks (the most recent - are all emulated in software - and the physical storage is not a component

I know that this changed years ago, but the OS heritage still requires to be backwards compatible.

You see, my friend - I don't think in BYTES, just like YOU don't think in Cylinders…

Yes, I see. :-)

But then, I still miss an easy solution to have a quick overview about used and free disk space. Just like df does in UNIX or USS in z/OS. Even a percentage per volume would be helpful for a quick glance. But I'm learning more and more, there’s almost nothing done quick with MVS and possibly with it’s descendants. ;-) From my retrocomputing viewpoint, this is very interesting, something completely different and thus enjoyable. From my viewpoint as a (Linux) sysadmin, it’s really cumbersome to get a sense of achievement before giving up because the annoyance level crossed my individual threshold level. :-)

:wq! PoC

Hello Greg,

Am 06.12.2020 um 07:11 schrieb Greg Price <procegrog@...>:

today I was wondering, how much unallocated space I have available on the various volumes

I use the LISTVOL command on TSO for this - not sure if it is on TK4- or not.

Bingo, that’s it! Still the numbers are telling me nothing, because I need to manually compare with what’s available, but this is at least a built-in immediately usable.

Thanks a lot!

:wq! PoC

开云体育

Indeed, the LISTVOL is in TK4-

listvol?????????????????????????????????????????? ?
?VOLUME? DEV USAGE OPN ------ FREE ------ --CONTG--
? NAME? NMBR COUNT CNT CYLS TRKS NUM DSCB CYLS TRKS
?SORT01? 131???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT02? 132???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT03? 133???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT04? 134???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT05? 135???? 0?? 0 0199 0000 001 0473 0199 0000
?SORT06? 136???? 0?? 0 0199 0000 001 0473 0199 0000
?WORK00? 140???? 0?? 0 0554 0000 001 1361 0554 0000
?MVSRES? 148??? 31? 11 0285 0075 003 1306 0283 0024
?SMP001? 149???? 0?? 0 0516 0007 001 1360 0516 0007
?SMP002? 14A???? 0?? 0 0506 0010 001 1360 0506 0010
?SMP003? 14B???? 0?? 0 0531 0011 001 1360 0531 0011
?SMP004? 14C???? 0?? 0 0514 0012 001 1354 0514 0012
?HASP00? 152???? 1?? 0 0000 0000 000 0699 0000 0000
?PAGE00? 160???? 3?? 0 0000 0000 000 0237 0000 0000
?PAGE01? 161???? 2?? 0 0000 0000 000 0238 0000 0000
?WORK01? 170???? 0?? 0 0957 0000 001 1171 0957 0000
?WORK02? 180???? 0?? 0 0884 0000 001 0740 0884 0000
?WORK03? 190???? 0?? 0 1112 0000 001 0698 1112 0000
?MVSCAT? 191???? 1?? 0 1053 0040 005 0635 1045 0003
?PUB000? 240???? 9?? 3 0343 0089 008 1306 0318 0015
?PUB010? 241???? 0?? 0 0547 0020 002 1347 0547 0018
?MVSDLB? 248???? 4?? 1 0196 0023 001 1289 0196 0023
?PUB001? 270???? 1?? 0 0924 0003 002 1162 0924 0000
?PUB011? 271???? 0?? 0 0954 0001 001 1166 0954 0001
?PUB002? 280???? 0?? 0 1618 0028 006 0681 1618 0000
?PUB012? 281???? 0?? 0 1569 0005 003 0715 1569 0000
?PUB003? 290???? 0?? 0 1060 0029 005 0652 1060 0000
?PUB013? 291???? 0?? 0 1987 0001 002 0688 1987 0000
?READY????????

Cheers,
Rob ??????????????????????????????????

On 2020-12-06 2:45 AM, Patrik Schindler wrote:

today I was wondering, how much unallocated space I have available on the various volumes

I use the LISTVOL command on TSO for this - not sure if it is on TK4- or not.

Cheers,
Greg

开云体育

Patrick,
Well - your comment of being helpful to a rookie....
You see, in the MAINFRAME world (except now z/LINUX) - allocation is done in three ways
BLKs - BLOCKS -
TRKS - tracks
CYL - cylinders -

So - BYTES is of no use....
Yes, Track size is dependant upon the DASD type - as are the number of tracks per cylinder - and even number of cylinders per volume.

In the early days - this was somewhat of a challenge - there are SEVERAL places to get the DISK capacity tables -
Here is one -

Now, TODAY - we only use 3390 - and even that has gone somewhat crazy -
We used to have just as the table refenced above - M1, M2, M3, M9 - THEN - came M27, then M54, - all with increasing numbers of cylinders.

Now, two things come into play -
The actual number of cylinders - the PHYSICAL disks (the most recent - are all emulated in software - and the physical storage is not a component
However, the control blocks and the internal architecture of how disks are referenced - by the internals of the os.

The original control blocks - kept us small for years... then, IBM finally architected a solution so we have larger disks... and larger files.

You see, my friend - I don't think in BYTES, just like YOU don't think in Cylinders...

-J-

Hello Chris,

Am 05.12.2020 um 18:01 schrieb cjar1950 via groups.io <cjar1950@...>:

You might find DISKMAP of use.

So I need to manually make a list of online DASDs, and have your example extended to several jobsteps (one per volume)?

:wq! PoC

Hello Rahim,

Am 05.12.2020 um 22:21 schrieb Rahim Azizarab via groups.io <rahimazizarab@...>:

I was contemplating coming up with a DF command for Hercules;

What do you mean with ?for Hercules“? Hercules is an Emulator. I’m searching for something like ?df“ for MVS in TK4-.

but I just found a way of telling exactly how much how much space is used on my dasd. All I had to do was to go to directory where my dasds are and type "ls -al".
It tells you exactly how many bytes each dasd has used.

I assume you’re talking about doing this in the hosting Linux OS. As much as I appreciate your help, your statement is wrong. First, by default, DASD images are on the fly compressed. So they always appear smaller from the outside than they are for the OS within Hercules. Second, I need the information how much the DASDs are actually filled with allocated datasets from *within* the OS (MVS 3.8j as in TK4-). The external size does not tell me about the used space at all.

:wq! PoC

Hello Jay,

Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:

Take a look at

Thanks a lot, will do and report back. From the sample output, it’s not too helpful for a rookie like me: I don’t yet have a feeling (or better: deep understanding) for juggling with cylinders and tracks. I’m used to bytes, but isn’t the size (in byte) per track device dependent?

Maybe an additional column with percentage-used would be more helpful for a first glance? I’ll see if I could bring this thing into TK4-, and maybe I can enhance the source. Tomorrow. Here’s nearly midnight…

:wq! PoC

Patrik,

Take a look at

Jay

On Sat, Dec 5, 2020 at 12:24 PM, Rupert Reynolds wrote:

I forget the details, but I've seen a similar job use one dataset DISP=SHR before. I can't remember the reason?

According to Jay's website : "SYSUT1 must point to an actual dataset; it is not opened, but is used as a model to extract information about the datasets on the selected volumes."

Rene FERLAND, Montreal

Rahim,

This is just some JCL I got from Jay Moseley's site. Tested it on TK4-,
and it performed.

Chris
--
<cjar1950@...>



----------------------------------------------------------------------------------------------------------------------------------
On Sat, 5 Dec 2020 17:50:00 +0000 (UTC)
"Rahim Azizarab via groups.io" <rahimazizarab@...> wrote:

Strange!!!??? What is Sys1.Proclib doing in the JCL?

//DISKMAP? JOB (001),'DISKMAP',
//? ? ? ? ? ? CLASS=A,MSGCLASS=A
//DISKMAP EXEC PGM=DISKMAP,REGION=1024K
//SYSPRINT DD? SYSOUT=*
//SYSUT1? DD? DSN=SYS1.PROCLIB,DISP=SHR
//DD1? ? ? DD? DISP=OLD,UNIT=3375,VOL=SER=PUB001
//


regards;

Rahim



??



On Saturday, December 5, 2020, 11:01:39 AM CST, cjar1950 via groups.io <cjar1950@...> wrote:

Patrik,

You might find DISKMAP of use.

//DISKMAP? JOB (001),'DISKMAP',
//? ? ? ? ? ? CLASS=A,MSGCLASS=A
//DISKMAP EXEC PGM=DISKMAP,REGION=1024K
//SYSPRINT DD? SYSOUT=*
//SYSUT1? DD? DSN=SYS1.PROCLIB,DISP=SHR
//DD1? ? ? DD? DISP=OLD,UNIT=3375,VOL=SER=PUB001
//

Chris
--
<cjar1950@...>



----------------------------------------------------------------------------------------------------------------------------------
On Sat, 5 Dec 2020 16:45:45 +0100
"Patrik Schindler" <poc@...> wrote:

Hello,

today I was wondering, how much unallocated space I have available on the various volumes of the current TK4-. Interestingly, after 15 Minutes of online research, I have not found something similarly easy to the unix ?df“ command output. Maybe I was searching for the wrong keywords?

What I found was to use the z/OS unix system services ?df“ command, which also lists conventional volume statistics. No USS in TK4-. Another approach is a Rexx procedure. Without Rexx being installed, this is also a not easy going. The online help text for TSO does not list any helpful commands. (Commands are listed, that simply do not exist, see the ?copy“ discussion a few days ago.)

I have a dim memory of having seen output for disk usages on the TSO prompt on an older version of TK4-, but I can’t recall details.

Is there an easy method to obtain disk usage statistics in stock TK4-? Easy as in ?run this existing JCL and view printer output“ or ?use this command in a TSO session“, that is.

Thanks a lot!

:wq! PoC