TSO PROFILE NOPREFIX.

Then try to access ?your dataset.

Joe

On Sat, Dec 26, 2020 at 10:27 AM Pedro Pinheiro <prppedro@...> wrote:

Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,

Att.,

-trp

Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,

Att.,

-trp

Hello,

"The records that comprise a newly created data set must be presented for writing in ascending order by key."

Source:

Does this mean that I need to at least write one record with some arbitrary key value, and later (DISP=MOD) can add more records which are not necessarily in order with the key value already in the first record?

I want to find some practical use for a batch workflow involving collection of data and generating reports of it in TK4-. I decided to postpone VSAM to later when I feel skilled enough to create interactive applications using KICKS.

Thanks!

:wq! PoC

Hello Mike,

Am 20.12.2020 um 18:57 schrieb Mike Schwab <Mike.A.Schwab@...>:

> Hercules CCKD(64) releases the space to condense the host file in the background.

May I ask what exactly you mean by ?release“? Overwrite them with a constant value, so a high compression ratio is achieved?

On I/O-heavy loads, could it be beneficial to not use compression at all? Moshix (the mainframe video guy) claimed, that today, CPUs are so fast, that it barely matters. What’s your opinion?

:wq! PoC

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