开云体育

Hi Daniel, The S/M Program runs in Problem Program mode (Key 8) and is not an Authorized Program as it does not use any system services that require Authorization. The Program strictly follows the

Hi, Daniel, You would have to SYSGEN MVS 3.8J for either an "AP" or "MP" configuration to get that to work. You cannot just expect to throw additional CPUs at MVS 3.8J and expect it to work "out of

I've been playing with a SORT job to stress test my system.? It sorts 99,999,999 random 80 byte records.? The job works just fine if I am running with 1 CPU.? Run MVS with 2 CPUs and it typically

Hi Daniel, For a successful sort the REGION size definitely has to be larger than the storage that the S/M Program is allocated by use of various S/M Program parameters. As to how much larger the

Can run with REGION=6M possibly larger. End of step message shows how much memory of 24, 31, 64 bit memory was actually used. <dan@...> wrote: -- Mike A Schwab, Springfield IL

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. [email protected]> 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: