开云体育

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.

Kevin Monceaux wrote:

I follow the list via e-mail also. I'm inclined to treat
edited messages much like I treat broken threads. I rarely
follow broken threads. If I've already read an original
message, I'm not going to reread an edited message and try
to figure what's been changed.

I hear you, Kevin. HOWEVER...

As for me, I do just the opposite:

When I receive an email marked "[Edited Message Follows]", I *delete* the original message and keep *ONLY* the new ("edited") message.

Doing so ensures my replies (should I wish to reply to what the author said) pertains to what the original author actually intended to say. It ensures only *accurate* information is retained and only *inaccurate* information is discarded.

Threading is not really an issue for me. Outlook considers subsequent edited messages that might be received as part of the same thread anyway, and, like you, I don't use the groups.io web interface anyway, so threading issues are really a non-issue for me.

But IMO it's important to NOT disregard/delete the author's edited message. IMO it's better to do as I do, and simply delete the *original* email instead, and keep *only* the subsequent "edited" message.

Just my 2 cents. <shrug>

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

mail: fish@...

Kevin

I am in full agreement. However, if I make a serious mistake in a message i.e. Assembler F versus Assembler G, I submit a correction. ?For a typo it really does not matter.

The owner of groups.io may be interested in your concern that a second edited message should perhaps be marked “edited”. Contact him with your feature request.
--
Regards,
Bernie (did 360 assembler programming on IBM Model 75 in late 1960s)

On Sun, Dec 06, 2020 at 08:51:36PM +0000, Jeremy Nicoll wrote:

There's no button.... because I read the traffic by email. Worse, when
a (slightly different, I suppose) message arrives, there's nothing in its
text that shows what was changed.

I follow the list via e-mail also. I'm inclined to treat edited messages
much like I treat broken threads. I rarely follow broken threads. If I've
already read an original message, I'm not going to reread an edited message
and try to figure what's been changed.





--

Kevin



Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.