开云体育

How do the values of REGION JCL paramater and the SORT parameter MAIN relate to one another. I suspect that REGION might need to be a bit larger than MAIN, but I cannot find any specific

http://www.legac-e.co.uk/JCLdocs/CAP3390.pdf is a 3390 no key capacity table. Goes all the way down to 22 byte records. gmx.com@groups.io> wrote:

Sergio, thank you for your curiosity, and for bringing this question up here. Here is a link to the book you asked

Thank you all :) Since it was mentioned before, I knew that gaps had something to do, but I didn’t thought that all that “wasted” space was only because of gaps. And also, I didn’t know how

Gentlemen, Thank you for your contributions, it looks like we finally found real answer. I have found the last peace of it: In this text we see that there is four gaps that accompany each member in

Andre's response containing a hex editor's output was to your, Sergio's, question regarding space usage with a PDS. I have read with interest the various responses with regard to actual hardware

Dear all, With a standard R0 on a track there remains 1729 user data cells on a 3390 track. Number of cells needed is C + K + D Where C = 10 K = 0 (if no key written) DN = (DL + 6) / 232 D = 9 +

Per IBM, the most efficient block size for a 3390 is 27,998 bytes, which allows two per track: https://www.ibm.com/docs/en/zos/2.4.0?topic=devices-direct-access-storage That is less than 28,320

You can't have block that big. You write two blocks with two sets of interecord gap. And that table already assumes key length of 0. There is a second table for key length

"The table you attached proves that you will only get 1 block per track at a block size of 28320. " There's no Keys, so the K field is omitted. C = 5 bytes. D = 28320 bytes. Looks to me like 2 of

The table you attached proves that you will only get 1 block per track at a block size of 28320.? It’s easy enough test before you post maybe?you should do that.

Everyone, Also, please remember that the CKD format on 3390 DASD is emulated. The actual format of the DASD is in cells, so there is some wastage trying to make the CKD format work, with there being

If, in the above picture, the white space is supposed to represent that part of the track that cannot be used to hold any accessible "thing" then the above picture is not accurate. The white space

Andre, Despite what you may think, there are gaps everywhere on the DASD surface.? I dont know what hex dump you are looking at, but it isn't going to show the gaps.? If you are looking at a hex

The first track would contain the Directory block, the EOF Directory block, and the rest with PDS data blocks. <procritic@...> wrote:

Well OK, then please provide your calculations concerning this problem. Why there is free space at the end of PDS dataset that takes more than 2480 bytes? You have said: " A pds has 256 byte blocks

Hello James, It is not a hardware limitation, because when we allocate sequential dataset it uses all space, but only in case of PDS we see that a lot of space left unused. Try it yourself, allocate

I have mislead no one. I have been working with this since 1982. There is overhead that can’t be seen with the tools that are publicly available. Laddie Hanus

Have you performed the calculation at http://www.bitsavers.org/pdf/ibm/dasd/3390/GX26-4577-0_3390_Reference_Summary_Jun8 9.pdf page 10 - Determining tack capacity James Campbell

Roops, You can try using the Acetest application that comes with ISPF. It is documented in the ISPF .DOC file. It is just so much better than TSO Test - especially when using it in fullscreen mode