开云体育

Mark Waterbury wrote:

A couple of thoughts... (adding some historical perspective)...

[...]

Also, I am not sure that it matters as much with emulated DASD
-- does anyone know if Hercules emulates DASD so closely as to
actually "waste" the additional space required for inter-record
gaps, etc.?

Ohh! Me! Me! I know! :)

The answer is: for NON-compressed CKD dasd, there would indeed be "wasted" (sort of) space on a track for poorly chosen block sizes. However, such "wasted" space wouldn't be noticeable from the host's point of view. That is to say, for NON-compressed CKD dasd, the size of Hercules's dasd image file is fixed and varies directly according to device type (e.g. 3350, 3390, etc), and Hercules's CKD dasd logic directly indexes into the file to reach the desired track. If an inefficient block size was used, there would simply be unused (i.e. "wasted") space (room) remaining in that track's file position slot.

For COMPRESSED dasd however (CCKD/CCKD64), there would be essentially *ZERO* "wasted" space, as each track's data is compressed and consumes only as much file space in the emulated dasd image's file as would be needed to hold that compressed track. (The entire track -- i.e. ALL data blocks (i.e. CKD "records") contained on that track -- is compressed into one chunk of compressed data, and only as much file space as would be needed to hold that chunk of data would actually be consumed in the dasd image file.(*))

But regardless of whether the dasd image is uncompressed or compressed (CKD vs. CCKD/CCKD64), Hercules does NOT reserve (consume) any file space for inter-record gaps.

------------
(*) We're of course ignoring the compressed dasd image "free space" issue here as it has nothing to do with track blocksize efficiency. Free space is just an artifact (overhead) of Hercules's compressed dasd design.


Hope that helps!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

CKD devices use the full track capacity, even if empty. CCKD(64)
compresses the data and nothing for empty tracks. VSAM uses 4K block
maximum (except z/OS versions going to 18k that reduces I/O but
doesn't increase space utilization). So a 4k or 6k block size or less
is pretty reasonable.

On Sun, Dec 13, 2020 at 2:17 PM Mark Waterbury
<mark.s.waterbury@...> wrote:

All:

A couple of thoughts... (adding some historical perspective)...

Back in the day, DASD space was very expensive, especially the larger devices like 3350s when they were new, and 3380s when they were first available. So, it made sense to expend extra manual effort to carefully calculate the best possible blocksizes for each dataset on DASD, based on the target device type and the application requirements for the dataset.

But, nowadays, with emulated DASD, and the price per megabyte of disk space having fallen by several orders of magnitude, I question the wisdom of expending ANY extra time or energy on these calculations.

Far better to just stick religiously with some standard block sizes, such as the good old IPO recommended RECFM=FB,LRECL=80,BLKSIZE=3120 for source libraries or RECFM=U,BLKSIZE=6144 for load module libraries. Those sizes work well across all device types, and allow you to easily copy or move datasets from one device type to another with impunity.

Also, I am not sure that it matters as much with emulated DASD -- does anyone know if Hercules emulates DASD so closely as to actually "waste" the additional space required for inter-record gaps, etc.?

Also, I would never suggest or recommend "over-allocating" or "cramming" more physical blocks on an emulated track than could ever be placed on a "real" DASD track, just in case you ever wanted or needed to save the dataset to tape and restore it to a "real" DASD device.

All the best,

Mark S. Waterbury

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Bob Polmanter wrote:

This is a complicated subject and as with many things there is
more than one good answer. Selecting a good blocksize depends
on what your goal is.

If your goal is purely to maximize DASD space utilization, then
you should definitely use full track blocking (for 3350 devices
and older), and half-track blocking (for 3375 devices and newer).

<chomp! LOTS of good info/advice!>

There is a lot more that could be said, but hopefully this provides
a view of some of the other aspects of deciding on a blocksize.

WELL said, Bob! :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

This is a complicated subject and as with many things there is more than one good answer.? Selecting a good blocksize depends on what your goal is.

If your goal is purely to maximize DASD space utilization, then you should definitely use full track blocking (for 3350 devices and older), and half-track blocking (for 3375 devices and newer).? This minimizes any waste due to the inter-block gaps.? It also has the benefit of reducing the number of i/o operations.

But sometimes a large blocksize is not necessarily the best choice.? A good example is a dataset that is accessed directly, that is, you are accessing different blocks of the dataset not in a sequential order. Imagine for instance a payroll file, with 100-byte records, blocksize 19000 (to fit fully on a 3350 track), each record containing employee number, name and address, and other payroll information.? You want to retrieve the record for a certain employee by number.? A table or index tells you that the record you want is in block 52, record 27 within that block.? I only want the 100 bytes of that record, but I’ve got to read the whole block to get at it. ?That’s 18,900 bytes that I don’t need.? For this kind of file, a smaller blocksize is usually better, even at the cost of some additional DASD space overhead. Usually for direct files, a block size around 4K is the best choice.

In MVS 3.8, the largest blocksize allowed is 32760 bytes (not 32767 or 32768!).? As previous poster mentioned, if you use that blocksize against say, a 3380 device with its 47K track size, about 23K will be wasted.? The system will not write data in the remaining 23K.? Why not? ?You told it you wanted your block size to be 32760!? Hence the reason to use one-half of a track as the blocksize, because it ensures the whole track will be used as much as possible.? The only time the system will write less than the full specified blocksize is for the last block in the dataset:? if there is not enough data to fill out the entire last (or only) block then the system will write what is known as a short block.

If you are adept at using the access method macros, you can certainly prepare a program that will write 32760 blocks on a 3380 track and follow it with a 23,000-odd byte block to fill out the entire track.? But it’s a lot of extra work; you have to do track space calculations, and write frequent short blocks.? But it can be done. The point is that the system won’t do it automatically though.? Just use half-track blocking on 3375/3380/3390 devices and then the system will take care of it for you, efficiently.

VSAM datasets can have a CI size (control interval size) of up to 32768, but this is a sort of ‘virtual blocksize’.? The true physical block size written to the track never exceeds 4096 bytes in VSAM.? But this is really another discussion entirely and I wouldn’t dwell on it.? I only mention it briefly since another previous poster mentioned VSAM CIs.

Yet another poster asked about using smaller blocksizes for datasets that contain smaller amounts of data, such as a PDS full of JCL members, or macros, or copy books.? You can certainly block them smaller or larger depending on your needs.? But if you know you have a lot of small members you can get better utilization with small blocksizes because the partitioned dataset access methods are smart enough to start the next member’s data block after the end of the last block of the previous member if the blocksize is small enough to fit into the remaining space on the track.? If you choose a larger blocksize, then you may not be able to fit the block on a partially filled track thereby wasting space.? This is why many PDS datasets containing JCL, macros, etc., are often blocked at 3120 or 6160.

There is a lot more that could be said, but hopefully this provides a view of some of the other aspects of deciding on a blocksize.

Regards,

Bob

Usually, the small files are in a PDS library. That writes all the
records in one block, and the next member will be after a inter record
gap. Even with these, use a large block size for what members have a
large number of records. I. E. a 27,998 half track block size hold
349 records of 80 bytes, or 698 records per track. If it was a
separate file, you would be assigned a whole track or more to a file.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

On Sun, 13 Dec 2020 16:37:55 +0000, "Jeff Bassett"
<bassettj@...> wrote:

Hi Jeff,


Some few questions if you allow me. (Warning! Absolute noob here!)

If I do understand the blocking reasoning, all these starts from
thinking that one is willing to write a large amount of data. If the
task at hand handles small amount of data that won't fit one large
block, the smaller blocksize can make a better use of the disk space.
Am I correct in think this way?

An example embedding a question, in a "CNTL" dataset, usually a PDS,
JOBs are small texts that many times wont fill a single average block,
a 115 cards deck will fill about 9KiB. The question, does in a PDS a
physical can be shared by different members? If not, a JOB deck with
a jobcard and few jobsteps will hardly fill a single block, (almost)
regardless the blocksize.

Ok, my point (if any) is like you said YMMV. The best blocksize will
mostly depend on what kind of information is being stored. Although
the simple math points to those numbers, perhaps knowing the data
content can make a better use of the tracks if one considers the block
fill by data contents.


HTH

Patrik,
Remember in the previous posts - each block has some amount of
overhead. So - to have the absolute BEST utilization - you want the
fewest number of blocks per track.

Now, blocks are addressed in a half-word - Max 32767 - so - using the
DISK capacity table - (there is also a command for each type in the
TK4- system To help you calculate the BEST block size on a GIVEN
track size (since we have multiple DASD TYPES ) -from TSO command -
type TSO HELP BLKSPTRK

The actual programs are in SYS2.CMDLIB
BLKSPTRK (devtype devtype ...)
BLKSIZE(<size or #count> <size or #count> ...)
KEYLEN(length length ...)

Or there is also another set of pgms
BLKxxxxx (look in sys2.cmdlib)

For instance BLK3390

So for a GIVEN record size - and DASD type - there are optimum block
sized - to use the space most effectively.

For instance - if you are using 80 byte records - or card images...
you have seen the calculations... however, lets say you want to store
some PRINT OUTS - that are LRECL 133 (these are really 132 bytes -
plus a 1 byte Carriage control in the first byte ) OR - certain OLDER
UTILITIES - when they were originally written to OLDER standards -
and use LRECL 121 - OR - you might have LONGER print records - 3211s
were capable of 150 character lines with a smaller type face - (I.E -
what I am trying to point out - YOUR MILEAGE MAY VARY - just because
it is PRINT RECORDS) - Here are a couple of examples - The trick is
to know - the LENGTH of the LRECL - and the TYPE of disk you are
using... This is why occasionally you see things - like - HAD to
REBLOCK for 3350 -

I used BLK3390 133 to produce the following -table

3390 BLOCKSIZE SUMMARY; LRECL=133 KEY LENGTH=0
BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION
--------- ------------ ------------ -----------
133 72 72 16.9%
2,926 16 352 82.6%
3,059 15 345 81.0%
3,325 14 350 82.2%
3,724 13 364 85.4%
4,123 12 372 87.3%
4,522 11 374 87.8%
5,054 10 380 89.2%
5,719 9 387 90.8%
6,517 8 392 92.0%
7,448 7 392 92.0%
8,778 6 396 92.9%
10,773 5 405 95.1%
13,566 4 408 95.8%
18,354 3 414 97.2%
RECOMMENDED-->27,930 2 420 98.6%
32,718 1 246 57.7%

FOR BLKSIZE 27,930 AND 100,000 RECORDS, ALLOCATE:
477 BLOCKS, 239 TRACKS, OR 16 CYLINDERS
***


So, you can do the arithmetic - or use tools - already provided -
clearly it helps to understand what the tools do...

Now here is a similar table generated by BLK3380 133
3380 BLOCKSIZE SUMMARY; LRECL=133 KEY LENGTH=0
BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION
--------- ------------ ------------ -----------
133 74 74 20.7%
2,394 16 288 80.7%
2,660 15 300 84.0%
2,926 14 308 86.3%
3,059 13 299 83.8%
3,458 12 312 87.4%
3,857 11 319 89.4%
4,256 10 320 89.6%
4,788 9 324 90.8%
5,453 8 328 91.9%
6,251 7 329 92.2%
7,448 6 336 94.1%
9,044 5 340 95.2%
11,438 4 344 96.4%
15,428 3 348 97.5%
RECOMMENDED-->23,408 2 352 98.6%
32,718 1 246 68.9%

FOR BLKSIZE 23,408 AND 100,000 RECORDS, ALLOCATE:
569 BLOCKS, 285 TRACKS, OR 19 CYLINDERS
***
I hope this is helpful.

-J-


-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Patrik
Schindler Sent: Sunday, December 13, 2020 10:40 AM
To: [email protected]
Subject: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-

Hello Joe,

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

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...

Thanks. Q: Can you elaborate on ?efficient dasd usage mandates
half-track blocking“? Why not more? Or less? What’s the reason behind
?迟飞辞“?

:wq! PoC

Roxo

--
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <mvs@...> | Editor?
Except where explicitly stated I speak on my own behalf.| VI !!
PU5RXO | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!

Before each physical block of data, there is a fixed amount of space
you can't use, called an inter record gap. The smaller the physical
block of data, the more blocks will fit on a track, with more space
tied up in inter record gaps. If you specify an 80 byte block size,
you get 78 blocks of 80 bytes for 12.4% of the disk space, while a
half track block size of 27,998 will let you use 98.8% of the disk
space.



A 3390 track is composed of 1,729 cells of 34 bytes. Each physical
block of data takes 20 blocks for the inter record gap plus 20 bytes
of data. Larger blocks add blocks of 34 bytes up to 32K total. Plus
you have to do an I/O for each physical block, so you cut down that
overhead a great deal

On FBA devices (non-mainframe) this is hidden from you because it is
set up as 512 or 4096 bytes per physical block without the count or
key portion.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Patrik,

Simple: QSAM (and most of the other *AM's in MVS3.8j) are limited by the I/O subsystem to writing AT MOST 32767 bytes in one I/O operation to any device due to halfword length fields.

So on tracks that are larger than 32K the most efficient usage of the track is to have two blocks each less than 32K because one 32K block wastes (for instance) 56K - 32K = 24K bytes of external 3390 formatted storage. Most of the *AM's can't use the rest of the track so 24KL of that space it is "wasted ", i.e. unusable.

The one exception of which I am aware is that VSAM has the ability to disconnect physical block size written to each track from the "logical" size (i.e., the CI size, Control Interval) at least in current MVS releases, but I am not sure that exists at the MVS3.8j level. I have seen VSAM files that have CISZ=32760 with physical block size around 19K (3 blocks per 56K track) on more recent MVS versions.

Of course, one can say "but what difference does that make when the "disk" is just a physical file on the host file system, why care about logical track usage?". But at the OS level we have, there are definite limits on how large those "disks" and files stored on them can logically be. Cylinder count and I think also track count are limited to a halfword, so you can't have a file (or a disk extent) larger than 32K cylinders (or maybe 64K? but that may only be in more current MVS versions). Those in the know better than I can correct me on that, but my point is that there are logical limits in the OS that need to be known and respected.

Anyway, that's why two blocks per track is considered "efficient DASD usage".

Peter

Patrik,
Remember in the previous posts - each block has some amount of overhead.
So - to have the absolute BEST utilization - you want the fewest number of blocks per track.

Now, blocks are addressed in a half-word - Max 32767 - so - using the DISK capacity table - (there is also a command for each type in the TK4- system
To help you calculate the BEST block size on a GIVEN track size (since we have multiple DASD TYPES ) -from TSO command - type TSO HELP BLKSPTRK

The actual programs are in SYS2.CMDLIB
BLKSPTRK (devtype devtype ...)
BLKSIZE(<size or #count> <size or #count> ...)
KEYLEN(length length ...)

Or there is also another set of pgms
BLKxxxxx (look in sys2.cmdlib)

For instance BLK3390

So for a GIVEN record size - and DASD type - there are optimum block sized - to use the space most effectively.

For instance - if you are using 80 byte records - or card images... you have seen the calculations... however, lets say you want to store some PRINT OUTS - that are LRECL 133 (these are really 132 bytes - plus a 1 byte Carriage control in the first byte ) OR - certain OLDER UTILITIES - when they were originally written to OLDER standards - and use LRECL 121 - OR - you might have LONGER print records - 3211s were capable of 150 character lines with a smaller type face - (I.E - what I am trying to point out - YOUR MILEAGE MAY VARY - just because it is PRINT RECORDS) -
Here are a couple of examples - The trick is to know - the LENGTH of the LRECL - and the TYPE of disk you are using...
This is why occasionally you see things - like - HAD to REBLOCK for 3350 -

I used BLK3390 133 to produce the following -table

3390 BLOCKSIZE SUMMARY; LRECL=133 KEY LENGTH=0
BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION
--------- ------------ ------------ -----------
133 72 72 16.9%
2,926 16 352 82.6%
3,059 15 345 81.0%
3,325 14 350 82.2%
3,724 13 364 85.4%
4,123 12 372 87.3%
4,522 11 374 87.8%
5,054 10 380 89.2%
5,719 9 387 90.8%
6,517 8 392 92.0%
7,448 7 392 92.0%
8,778 6 396 92.9%
10,773 5 405 95.1%
13,566 4 408 95.8%
18,354 3 414 97.2%
RECOMMENDED-->27,930 2 420 98.6%
32,718 1 246 57.7%

FOR BLKSIZE 27,930 AND 100,000 RECORDS, ALLOCATE:
477 BLOCKS, 239 TRACKS, OR 16 CYLINDERS
***

So, you can do the arithmetic - or use tools - already provided - clearly it helps to understand what the tools do...

Now here is a similar table generated by BLK3380 133
3380 BLOCKSIZE SUMMARY; LRECL=133 KEY LENGTH=0
BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION
--------- ------------ ------------ -----------
133 74 74 20.7%
2,394 16 288 80.7%
2,660 15 300 84.0%
2,926 14 308 86.3%
3,059 13 299 83.8%
3,458 12 312 87.4%
3,857 11 319 89.4%
4,256 10 320 89.6%
4,788 9 324 90.8%
5,453 8 328 91.9%
6,251 7 329 92.2%
7,448 6 336 94.1%
9,044 5 340 95.2%
11,438 4 344 96.4%
15,428 3 348 97.5%
RECOMMENDED-->23,408 2 352 98.6%
32,718 1 246 68.9%

FOR BLKSIZE 23,408 AND 100,000 RECORDS, ALLOCATE:
569 BLOCKS, 285 TRACKS, OR 19 CYLINDERS
***
I hope this is helpful.

-J-

Hello Joe,

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

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...

Thanks. Q: Can you elaborate on ?efficient dasd usage mandates half-track blocking“? Why not more? Or less? What’s the reason behind ?迟飞辞“?

:wq! PoC

Hello Mike,

Am 09.12.2020 um 19:54 schrieb Mike Schwab <Mike.A.Schwab@...>:

Its not. I think it came out in the early 1990s.

Thanks to you and others for clarification!

:wq! PoC

On Sat, 2020-12-05 at 07:07 -0800, marcoxa@... wrote:

Hi Harold

yes, thanks. I do follow the groups.io forum about SATK, although I
have not played with it.

From the examples I gather that ASMA/SATK does not a syntax that is
different from the other IBM assemblers (apart from the "high level"
features of HLASM), is that correct?

Essentially,

NAME OPERATION OPERANDS REMARKS

Yes, that is the general syntax. In addition to instructions
(everything except the latest PoO) there is a macro capability quite
compatible with what one you would be used to and for the really strong
users, macro libraries.

The assembler can be tailored to whatever hardware environment for
which the software is targeted, zArch or S/360 and anything in between.

with NAME being 8 character long and spaces meaningful (Cfr., "High
Level Assembler for z/OS & z/VM & z/VSE - Language Reference -
Version 1 Release 6").

At least that is what I gathered.

Yup.

All the best

Marco

There are a few additions and some constraints, all of which I believe
are documented in the ASMA.pdf manual.

--
Marco Antoniotti
Somewhere over the rainbow

You can check the system if SMS managed with

D SMS,A

Cheers,
Rob

Its not. I think it came out in the early 1990s.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Hello,

what’s the correct way to check myself if SMS (Storage Management Subsystem) is available/installed (in TK4-)?

:wq! PoC

I am total agreement the way the group is configured now. ?

I did not know an edited email message was clearly marked (so there should be no confusion on what duplicate ?email to delete)

--
Regards,
Bernie (did 360 assembler programming on IBM Model 75 in late 1960s)

Hello!
So that's the reason. It seems to surface all over the Groups IO
region...... Dave are we the moderators for this group? I know we do
the same over at the H390-VM one, but wasn't sure about here.
Especially since I do not see the messages regarding message approval
for first time posts.

By the way Fish that two cents you provided seems to be a trifle sticky.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."

On Sun, Dec 6, 2020 at 1:28 PM Dave Wade <dave.g4ugm@...> wrote:

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Jeremy
Nicoll
Sent: 06 December 2020 17:58
To: ML - H390-MVS-io <[email protected]>
Subject: Re: [H390-MVS] IBM Assembler History

On Sun, 6 Dec 2020, at 17:43, Ham Radio wrote:

[Edited Message Follows]

Why do I (and presumably other people too) get two copies of some
messages, the latter one always seemingly starting with that [text]?

Because they use the web interface to submit the message, then change it
after submission. The group owner or a moderator with permission can disable
message editing so they would have to reply to their own message to amend.

--
Jeremy Nicoll - my opinions are my own.

Dave
G4UGM

And this message is sponsored by the Rebel Alliance to Restore the
Republic again.