Re: BLKSIZE=3120
Did you get a Reason Code? In a message dated 07/26/13 00:46:05 Central Daylight Time, d10j...@us.ibm.com writes: specification is still there, exists, I apparently lost that battle -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Jim, The LOG dataset can stay 3120 because most of the entries would not fill a block. It is the OUTPUT DCB that needs to have BLKSIZE=0 Regards, John K Jim Mulder from the IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 07/26/2013 12:45:34 AM: From: Jim Mulder d10j...@us.ibm.com To: IBM-MAIN@listserv.ua.edu Date: 07/26/2013 09:15 AM Subject: Re: BLKSIZE=3120 Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? I looked at the current TRANSMIT/RECEIVE code, and it still specifies BLKSIZE=3120 when it creates a LOG data set, and still hardcodes BLKSIZE=3120 on its DCB for the log data set. I engaged in battle with the former TSO developers a long time ago (maybe over 20 years ago, maybe even before the advent of System Determined Blocksize). I wanted them to at least remove the BLKSIZE=3120 on the DCB so that if someone (like me) was sensible enough to allocate his own log dataset with an efficient BLKSIZE, TRANSMIT/RECEIVE would cease to override that on the DCB and thus no longer change the BLKSIZE to 3120. Since the stupid DCB specification is still there, exists, I apparently lost that battle. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
The XMIT/RECEIVE log (named according to your IKJTSO00 specification) would not necessarily benefit automatically from big blocks. This data set is MODed onto by each XMIT or RECEIVE action. Hence it typically consists of (perhaps very) many small physical blocks regardless of labelled BLKSIZE. The more it's used, the worse performance it gets on READ access. If you think of it, it's worthwhile now and again EDIT this log file and SAVE it. This rewrites data back to the labelled BLKSIZE. Subsequent READ access will be much improved even at 3120. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jim Mulder d10j...@us.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 07/25/2013 10:46 PM Subject:Re: BLKSIZE=3120 Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? I looked at the current TRANSMIT/RECEIVE code, and it still specifies BLKSIZE=3120 when it creates a LOG data set, and still hardcodes BLKSIZE=3120 on its DCB for the log data set. I engaged in battle with the former TSO developers a long time ago (maybe over 20 years ago, maybe even before the advent of System Determined Blocksize). I wanted them to at least remove the BLKSIZE=3120 on the DCB so that if someone (like me) was sensible enough to allocate his own log dataset with an efficient BLKSIZE, TRANSMIT/RECEIVE would cease to override that on the DCB and thus no longer change the BLKSIZE to 3120. Since the stupid DCB specification is still there, exists, I apparently lost that battle. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Fri, 26 Jul 2013 01:45:34 -0400, Jim Mulder wrote:
A customer (mildly) complained ...
Clearly, it wasn't I.
... TRANSMIT/RECEIVE would cease to override that on the DCB and thus
no longer change the BLKSIZE to 3120. Since the stupid DCB
specification is still there, exists, I apparently lost that battle.
For an example of how pernicious this can be, imagine the
result of the JCL below (or run it, if you haven't the imagination).
No point in trying PMR on it. Clearly WAD; customer error. But
it strikes me as a data integrity problem. At least, TRANSMIT
should fail with invalid DCB attributes.
I hate JCL!
//
//XMITBLK JOB 505303JOB,'Paul Gilmartin',
// MSGLEVEL=(1,1),REGION=0M
//*
//USERCOUTPUT JESDS=ALL,DEFAULT=YES,
// CLASS=R,PAGEDEF=V0648Z,CHARS=GT12
//*
//* Doc: TSO TRANSMIT overrides BLKSIZE to 3120
//*
//*.+|+|+|+|+|+|+|+|
//STEP1EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=(,)
//SYSIN DD DUMMY
//SYSUT2DD DISP=(,CATLG),UNIT=SYSALLDA,SPACE=(1000,(1000,,5)),
// DSN=SYSUID..TEMP.TRANSMIT(ATTACH)
//SYSUT1DD DISP=SHR,BLKSIZE=27920,DSN=SYS1.MACLIB(ATTACH)
//*
//*.+|+|+|+|+|+|+|+|
//STEP2EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=(,)
//SYSTSIN DD *
transmit X.Y DSNAME('SYS1.MACLIB(ATTACH)') outddname(OUTFILE) seq
//*
//OUTFILE DD DISP=OLD,DSN=SYSUID..TEMP.TRANSMIT(XMIT)
//INFILEDD DISP=SHR,DSN=SYS1.MACLIB(ATTACH)
//*
//*.+|+|+|+|+|+|+|+|
//STEP3EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=(,)
//SYSIN DD DUMMY
//SYSUT2DD SYSOUT=(,)
//SYSUT1DD DISP=SHR,
// DSN=SYSUID..TEMP.TRANSMIT(ATTACH)
//*
//
:w ! submit $MVS_HOST
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Looks similar to the HUGE problem (g) with having old catalogs still defined with IMBED and REPLICATE. Another hanger-on from days of yore that no one deemed worthy to keep current with changing technology. Bill Fairchild Franklin, TN - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, July 22, 2013 12:28:26 PM Subject: Re: BLKSIZE=3120 I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAME You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 15:32:37 -0400, Jim Mulder wrote: If there are any restrictions, they should be APAR'ed. 3120, 6160, 6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM products still ship these crappy blocksizes. It's why I submitted a SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? Changing AMATERSE to avoid assigning a blocksize of 6144, so that SDB can to its thing, appears to be a fairly easy code change, and I do anticipate that it will get done at some point in the future. There's a precedent for IBM's accepting APARs against products that thwart SDB. From OW43702: PROBLEM CONCLUSION: Module IRXIOLAR has been changed to allow the specification of BLKSIZE=0 for the TSO/E REXX command EXECIO in order to allow the user to specify system determined block size. I don't know how much a precedent is worth, nor what IBM's policy is in such cases. And it did break things, incidentally fixed by OW46399: ERROR DESCRIPTION: ABEND013-20 opening subsystem dataset. The blksize passed to open was 0. The lrecl was other than 80. Open processing does not select a proper default. RC20 MSGIEC141I IGG0199G PROBLEM CONCLUSION: Code modified to change the default blksize calculation to take into account the lrecl specified. I asked IBM to mark OW43702 PE, fixed by OW46399. IBM declined, calling OW43702 WAD. I saved the entire ugly transcript. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Maybe they are keeping current; NOT worrying about differences that are moot? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: DASDBILL2 dasdbi...@comcast.net Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 25 Jul 2013 22:42:06 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Looks similar to the HUGE problem (g) with having old catalogs still defined with IMBED and REPLICATE. Another hanger-on from days of yore that no one deemed worthy to keep current with changing technology. Bill Fairchild Franklin, TN - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, July 22, 2013 12:28:26 PM Subject: Re: BLKSIZE=3120 I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAME You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? I looked at the current TRANSMIT/RECEIVE code, and it still specifies BLKSIZE=3120 when it creates a LOG data set, and still hardcodes BLKSIZE=3120 on its DCB for the log data set. I engaged in battle with the former TSO developers a long time ago (maybe over 20 years ago, maybe even before the advent of System Determined Blocksize). I wanted them to at least remove the BLKSIZE=3120 on the DCB so that if someone (like me) was sensible enough to allocate his own log dataset with an efficient BLKSIZE, TRANSMIT/RECEIVE would cease to override that on the DCB and thus no longer change the BLKSIZE to 3120. Since the stupid DCB specification is still there, exists, I apparently lost that battle. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
retired mainframer wrote: snip With a blocksize of 3120, 15 blocks fit on a track for a total of 585 records. Almost a 50% improvement. My preference is 6160 (reasonably efficient for both 3390 and 3380 - yes we have very old archived datasets which occasionally must be restored) which will allow 616 records per track. We previously had a similar discussion for load modules where 32760 is optimal for the Binder but not necessarily for IEBCOPY. (Interestingly, perhaps, this topic keeps coming up, both inside and outside IBM, over two decades after I did the original research that led to our recommendation to block system software load libraries at 32760. That recommendation stands.) It's only IEBCOPY COPY operations that can behave suboptimally when copying load modules across different device types when moving blocks that are not good submultiples of the destination device's track length. This should be largely irrelevant today unless people still have 3380s defined (does anyone, still?), but see below. IEBCOPY COPYMOD, though, has no trouble at all reblocking load modules that are blocked at* 32760, and behaves in much the same way the Binder does. Whenever you copy a load library it costs nothing to use COPYMOD instead of copy. And, if you do that after allocating the destination load library at a higher block size than the source load library, you just might gain performance and reduce the space required for the data set. (This stops being true once the size of the largest possible text block falls below the destination data set's block size.) * Both the Binder and IEBCOPY use the block size only to set the maximum size of a text block to be written, and write shorter ones under some conditons. All the other records are typically written in short blocks. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Then that would either be April 1988 or December 1988, depending on whether DFP 3.1 shipped with MVS/ESA 3.1.0 or 3.1.0e. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Ed Gould edgould1...@comcast.net To: IBM-MAIN@listserv.ua.edu, Date: 07/23/2013 05:39 AM Subject:Re: BLKSIZE=3120 Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Jim, Good memory. My memory is a bit different (not by much though). DFP 3.1 first offered SDB TSOe (I think) at 2.1 ++ many PTF's for Rexx . I recall having not to implement XA for REXX (not being fully ready and SWA (above) not being fully supported by vendors. In one case I had to change the (CA's) source code and the other had to wait for a ZAP from Compuware. I was not a happy camper and was calling the vendors daily for an update. Put back my installation by about a month. I had egg on my face at work. Ed On Jul 22, 2013, at 9:03 PM, Jim Mulder wrote: Long prior to the advent of SDB, I had formed the habit of omitting BLKSIZE in my Rexx EXECs. The Rexx function library was smart: it chose good BLKSIZEs and/or I didn't much care about fractional deviations from absolute optimality. And, for all I knew (and didn't care) it adapted well to different device types. If I may quibble a bit with the reference to Long prior to the advent of SDB: REXX on MVS was introduced in TSO/E Version 2.1 for MVS/XA and MVS/ESA. I don't remember exactly when that was shipped, but I think it would have been in the 1987-1988 timeframe. I don't remember exactly when SDB was introduced, but I found an APAR OY19694 which was opened on January 5, 1989 for an SDB- related issue. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Tom Marchant :: Sent: Monday, July 22, 2013 1:36 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: BLKSIZE=3120 snip :: :: AFAIK, Innovation (FDR, etc.) still ships their products without SMP/E, :: and :: their installation is (IMO) one of the best. IIRC, Quickref is another :: that is :: not installed with SMP/E. The QuickRef installation dialog allows you to choose whether to use SMP/E or not. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 13:36:01 -0400, Thomas Conley pinnc...@rochester.rr.com wrote: Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? Taking the risk of starting another flame war here... Are there still any shops that have actual SLED? In today's world of emulated DASD, would it really still hold true that using smaller block sizes is actually wasting space? After all, these bytes are in the end physically written to FBA devices with 512 byte sectors, no? In the old days, there were inter-record gaps that took up space, but is this still the case? And even if the emulation is so good that it simulates those, what is happening with the actual capacity of the physical disks. Is that being eaten by simulated IRG? Thanks for shedding some light on this, whoever knows the internals of these current DASD boxes, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
W dniu 2013-07-23 12:32, Jantje. pisze: Taking the risk of starting another flame war here... Are there still any shops that have actual SLED? In today's world of emulated DASD, would it really still hold true that using smaller block sizes is actually wasting space? After all, these bytes are in the end physically written to FBA devices with 512 byte sectors, no? In the old days, there were inter-record gaps that took up space, but is this still the case? And even if the emulation is so good that it simulates those, what is happening with the actual capacity of the physical disks. Is that being eaten by simulated IRG? 3390 (E)CKD disks are emulated nowadays, but the emulation covers also nter-records gaps. So it's still waste of REAL space if you user RECFM=F,LRECL=80. You will waste great part of emulated tracks doing so. Note, there was (still is?) architecture developed by Storagetek, sold as Iceberg, IBM RVA, STK, SVA, SVAA, etc.In this architecture all data are compressed before written to disk, so, your tracks will still be half-emptuy, but they will take less real stroage than full-populated ones. Unfortunately those arrays had some issues with both scalability and performance, especially for sequential processing. BTW: funny things became occuring when your data were not as compressible as DASD engineers assumed. BTW2: nowadays the largest FBA (real) disks use 4k sectors. Compatibility problems with older OSes apply as usual. ;-) -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 21:25:23 -0400, Robert A. Rosenberg wrote: At 16:51 -0500 on 07/22/2013, Tom Marchant wrote about Re: BLKSIZE=3120: Most PTFs should be able to be applied, restored and applied again without issues. This is an issue since the design of RESTORE is broken due to its poor handling of SUPS/PREs If I can Apply a SYSMOD I should be able to restore it without needing to also restore any SYSMODs it PREs. You and I can disagree about whether the design of RESTORE is broken. The point that I was trying to make is that some PTFs are poorly constructed, with the result that they will not restore properly, given the rules for restore. In other cases, the PTF seems to restore ok, but when an attempt is made to apply it again, it fails because of something that was left behind. As to the way RESTORE was designed to take the elements from the distribution zone, you have two choices. You can restore prerequisites or you can accept the prerequisites. If you don't want to accept the prerequisites, why not? If you want to keep your distribution zone in its current state, you can always clone your distribution zone and relate your target zone to the copy of the distribution zone. Then you can accept the maintenance to your cloned zone in preparation for the RESTORE. It isn't that big a deal. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
I believe that the net result of coding smaller blocksizes does result in being able to store less data. If you had 1,000 volumes all defined as 3390-9s, and each volume had 100 datasets that filled the volume blocked at 512 bytes, you would store a fraction of the data if you blocked each of those datasets at 1/2 track blocking. That is a function of the z/OS archictecture. I don't know exactly how the data is stored on the tracks, but I believe that the result of smaller blocksizes means that you will store a lot less data. Ron Hawkins probably is the best definitive source on this subject. Eric Bielefeld Retired z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Jantje. jan.moeyers...@gfi.be Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 23, 2013 5:32 AM Subject: Re: BLKSIZE=3120 Taking the risk of starting another flame war here... Are there still any shops that have actual SLED? In today's world of emulated DASD, would it really still hold true that using smaller block sizes is actually wasting space? After all, these bytes are in the end physically written to FBA devices with 512 byte sectors, no? In the old days, there were inter-record gaps that took up space, but is this still the case? And even if the emulation is so good that it simulates those, what is happening with the actual capacity of the physical disks. Is that being eaten by simulated IRG? Thanks for shedding some light on this, whoever knows the internals of these current DASD boxes, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
It is certainly true that BLKSIZE= values now have less importance than they had on spnning physical CKD DASD, but that is not very important. It is almost irrelevant. I/O performance is very much better for large BLKSIZE= values. This is now indeed the principal rationale for using them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
I can't speak to all (most?) of the current architecture boxes, but to attempt to answer Jantje's question, yes the boxes I'm familiar with will definitely store less data on small block sizes. I am not speaking of the boxes that do thin provisioning because I haven't used this feature, but on IBM DS6800, EMC Symm (VMAX and DX4 w/o thin provisioning), and older HP/Hitachi XP arrays, when the physical disk was carved up into logical volumes for the emulated 3390 on top of them, storage was reserved for the physical capacity of the emulated drives. Thus if I carved up physical disk into 3390-9 volumes, the array would reserve 8.3 GB of physical space per 3390-9 volume. Rex From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Eric Bielefeld [eric-ibmm...@wi.rr.com] Sent: Tuesday, July 23, 2013 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I believe that the net result of coding smaller blocksizes does result in being able to store less data. If you had 1,000 volumes all defined as 3390-9s, and each volume had 100 datasets that filled the volume blocked at 512 bytes, you would store a fraction of the data if you blocked each of those datasets at 1/2 track blocking. That is a function of the z/OS archictecture. I don't know exactly how the data is stored on the tracks, but I believe that the result of smaller blocksizes means that you will store a lot less data. Ron Hawkins probably is the best definitive source on this subject. Eric Bielefeld Retired z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Jantje. jan.moeyers...@gfi.be Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 23, 2013 5:32 AM Subject: Re: BLKSIZE=3120 Taking the risk of starting another flame war here... Are there still any shops that have actual SLED? In today's world of emulated DASD, would it really still hold true that using smaller block sizes is actually wasting space? After all, these bytes are in the end physically written to FBA devices with 512 byte sectors, no? In the old days, there were inter-record gaps that took up space, but is this still the case? And even if the emulation is so good that it simulates those, what is happening with the actual capacity of the physical disks. Is that being eaten by simulated IRG? Thanks for shedding some light on this, whoever knows the internals of these current DASD boxes, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
As others have already stated, the physical disk space to represent an emulated 3390 volume is only data-dependent if you are dealing with log-mapped emulated DASD storage, like the Iceberg RVA, where each write of an emulated track goes to a new physical location in the DASD subsystem. I suspect most of the emulated 3390's these days are fixed-mapped, which means when you define a 3390 drive you allocate physical space capable of storing the maximum possible 56,664 bytes per 3390 track for as many tracks/cylinders as are in the emulated 3390 volume. For fixed-mapped drives, if you choose to write blocks that only allow fewer bytes to be used per 3390 track, that doesn't affect the physical drive space allocated for the track and the difference can't be used for anything else. So on fixed-mapped emulated 3390's, throwing away emulated track capacity with a poor choice of block size is also throwing away real physical DASD space. Spreading the same amount of data over more blocks and emulated tracks increases the CPU overhead of reading/writing the data in z/OS (more buffers and blocks to manage, and either longer channel programs or more channel programs to run), and would also end up spreading the data over more real physical tracks on the DASD subsystem, which would surely raise the overhead there as well, even if that impact on performance might be hard to measure. Joel C Ewing On 07/23/2013 12:20 PM, Eric Bielefeld wrote: I believe that the net result of coding smaller blocksizes does result in being able to store less data. If you had 1,000 volumes all defined as 3390-9s, and each volume had 100 datasets that filled the volume blocked at 512 bytes, you would store a fraction of the data if you blocked each of those datasets at 1/2 track blocking. That is a function of the z/OS archictecture. I don't know exactly how the data is stored on the tracks, but I believe that the result of smaller blocksizes means that you will store a lot less data. Ron Hawkins probably is the best definitive source on this subject. Eric Bielefeld Retired z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Jantje. jan.moeyers...@gfi.be Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 23, 2013 5:32 AM Subject: Re: BLKSIZE=3120 Taking the risk of starting another flame war here... Are there still any shops that have actual SLED? In today's world of emulated DASD, would it really still hold true that using smaller block sizes is actually wasting space? After all, these bytes are in the end physically written to FBA devices with 512 byte sectors, no? In the old days, there were inter-record gaps that took up space, but is this still the case? And even if the emulation is so good that it simulates those, what is happening with the actual capacity of the physical disks. Is that being eaten by simulated IRG? Thanks for shedding some light on this, whoever knows the internals of these current DASD boxes, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
As with almost everything else, the answer is it depends. For large sequential datasets as you described, I agree. But consider a card image PDS (JCL, source, etc) where most members average around 400 records. Half block on a 3390 is 349 records. The first member will occupy 2 blocks on the first track. The second member's first block will not fit on the track. The net result is that 300 records worth of space on track 1 is wasted. With a blocksize of 3120, 15 blocks fit on a track for a total of 585 records. Almost a 50% improvement. My preference is 6160 (reasonably efficient for both 3390 and 3380 - yes we have very old archived datasets which occasionally must be restored) which will allow 616 records per track. We previously had a similar discussion for load modules where 32760 is optimal for the Binder but not necessarily for IEBCOPY. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Eric Bielefeld :: Sent: Tuesday, July 23, 2013 10:21 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: BLKSIZE=3120 :: :: I believe that the net result of coding smaller blocksizes does result :: in :: being able to store less data. If you had 1,000 volumes all defined as :: 3390-9s, and each volume had 100 datasets that filled the volume blocked :: at :: 512 bytes, you would store a fraction of the data if you blocked each of :: those datasets at 1/2 track blocking. That is a function of the z/OS :: archictecture. :: :: I don't know exactly how the data is stored on the tracks, but I believe :: that the result of smaller blocksizes means that you will store a lot :: less :: data. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Riddle me this. Which one transfers fastest? RU size maxbufrs, transmission speed,compression, Consistent, repeatable, less than 4k? In a message dated 7/23/2013 4:34:00 P.M. Central Daylight Time, retired-mainfra...@q.com writes: Almost a 50% improvement. My preference is 6160 (reasonably efficient for both 3390 and 3380 - yes we have very old archived datasets which occasionally must be restored) which will allow 616 records per track. We previously had a similar discussion for load modules where 32760 is optimal for the Binder but not necessarily for IEBCOPY. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Where's Shai Hess when we need him? Sent from Tony's iPhone. On Jul 23, 2013, at 1:10 PM, John Gilmore jwgli...@gmail.com wrote: It is certainly true that BLKSIZE= values now have less importance than they had on spnning physical CKD DASD, but that is not very important. It is almost irrelevant. I/O performance is very much better for large BLKSIZE= values. This is now indeed the principal rationale for using them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Ed, That is a very small subset these days. AFAIK - OBJ Decks from compilers, TSO XMIT datasets, TRSMAIN (though I think this is 6k) and a few others are still dependent on 3120 blksize. However, I would think allowing your users to specify BLKSIZE=0 would be a benefit. Unless you have one of the above, should be okay. Most Mainframe Storage ADMINs, could probably have ACS code that will override the SDB to the appropriate BLKSIZE based on the function. Or change control products (CHANGEMAN, ENDEVOR) could also override the specification of BLKSIZE=0. Just my 2 cents worth. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? If such restrictions are known to still exist, can anyone help with any specifics? Thanks in advance... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Last time I explored this issue, the problem went beyond 'help'. In many cases of 'product allocated' files, existing output blocksize was overridden by 3120 regardless of how it was set ahead of time. I really don't think that BLKSIZE=0 will cause a problem. You just may not get what you bargained for. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU, Date: 07/22/2013 09:28 AM Subject:Re: BLKSIZE=3120 Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On 7/22/2013 9:28 AM, Charles Mills wrote: I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Good to know. I suppose for errors in help, rather than in the manual, I've got to go the PMR/APAR route as opposed to an RFC. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Gilbert has a zap on CBT file 183 to overlay 3120 with zero in the OUTPUT DCB of XMIT. It may have to be reworked. Regards, John K IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 07/22/2013 11:28:26 AM: From: Charles Mills charl...@mcn.org To: IBM-MAIN@listserv.ua.edu Date: 07/22/2013 11:28 AM Subject: Re: BLKSIZE=3120 Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
W dniu 2013-07-22 18:08, Ed Jaffe pisze: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? Well, IMHO it's not restriction, it is just allocation default. Good default in very old days, but not very bad today. Note, The difference between ~3k and optimal ~27k seem to be large, but the effects (performance, space used) give no big difference. BTW: DB2, LOGGER, MQ, and many many VSAM exploiters do use blocks 4kB. Is it far from 3kB? Of course you can try the above datasets with other (SDB) blocksize, and I bet nothing will break. Why didn't they change it? Well, it time to re-start the following subthreads: - TSO is moribound - if it isn't broken don't fix it (see latest implementation as IMBED for catalogs). Regards -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On 7/22/2013 12:08 PM, Ed Jaffe wrote: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? If such restrictions are known to still exist, can anyone help with any specifics? Thanks in advance... Ed, If there are any restrictions, they should be APAR'ed. 3120, 6160, 6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM products still ship these crappy blocksizes. It's why I submitted a SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. I *know* I tell customers to allocate a file 27920, upload from the PC, and run RECEIVE against it, so I know that works -- or at least I am not getting customer complaints. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 22, 2013 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 W dniu 2013-07-22 18:08, Ed Jaffe pisze: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? Well, IMHO it's not restriction, it is just allocation default. Good default in very old days, but not very bad today. Note, The difference between ~3k and optimal ~27k seem to be large, but the effects (performance, space used) give no big difference. BTW: DB2, LOGGER, MQ, and many many VSAM exploiters do use blocks 4kB. Is it far from 3kB? Of course you can try the above datasets with other (SDB) blocksize, and I bet nothing will break. Why didn't they change it? Well, it time to re-start the following subthreads: - TSO is moribound - if it isn't broken don't fix it (see latest implementation as IMBED for catalogs). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
3120 * 15 = 46800 / 55996 = 83.58% of maximum. On Mon, Jul 22, 2013 at 12:41 PM, Charles Mills charl...@mcn.org wrote: Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. I *know* I tell customers to allocate a file 27920, upload from the PC, and run RECEIVE against it, so I know that works -- or at least I am not getting customer complaints. Charles -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On 7/22/2013 10:41 AM, Charles Mills wrote: Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. This finding is consistent with John Kalinich's post where he describes the availability of a ZAP on CBT File 183 to change XMIT's hard-coded BLKSIZE=3120 to BLKSIZE=0. The hard-coded BLKSIZE=3120 in XMIT's DCB will override (and replace) the customer BLKSIZE=27920 specification in the Format-1 disk label. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
83.58% is hardly the end of the world IMHO. 27920 x 2 ~= 99.7% Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Monday, July 22, 2013 11:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 3120 * 15 = 46800 / 55996 = 83.58% of maximum. On Mon, Jul 22, 2013 at 12:41 PM, Charles Mills charl...@mcn.org wrote: Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. I *know* I tell customers to allocate a file 27920, upload from the PC, and run RECEIVE against it, so I know that works -- or at least I am not getting customer complaints. Charles -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 22, 2013 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 W dniu 2013-07-22 18:08, Ed Jaffe pisze: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? Well, IMHO it's not restriction, it is just allocation default. Good default in very old days, but not very bad today. Note, The difference between ~3k and optimal ~27k seem to be large, but the effects (performance, space used) give no big difference. BTW: DB2, LOGGER, MQ, and many many VSAM exploiters do use blocks 4kB. Is it far from 3kB? Of course you can try the above datasets with other (SDB) blocksize, and I bet nothing will break. Why didn't they change it? Well, it time to re-start the following subthreads: - TSO is moribound - if it isn't broken don't fix it (see latest implementation as IMBED for catalogs). Regards -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zak
Re: BLKSIZE=3120
If there are any restrictions, they should be APAR'ed. 3120, 6160, 6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM products still ship these crappy blocksizes. It's why I submitted a SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? I have seen an AMATERSE requirement that was submitted for this and we did investigate the AMATERSE code. AMATERSE doesn't require the blocksize of the output data set for a pack operation to be 6144. If a blocksize has not already been determined before AMATERSE tries to OPEN the data set, then AMATERSE assigns a blocksize of 6144, which was a reasonable thing to do when AMATERSE was designed (before the existence of SDB). If you explicitly assign a blocksize when you allocate the data set, AMATERSE will use your blocksize. Changing AMATERSE to avoid assigning a blocksize of 6144, so that SDB can to its thing, appears to be a fairly easy code change, and I do anticipate that it will get done at some point in the future. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
A few months ago I assisted a customer who was having difficulty installing SimpList. The installation instructions specify the sequential data set the XMIT files are uploaded to MUST be allocated as BLKSIZE=3120, but the installer specified BLKSIZE=0. I don't remember exactly what problem this caused, but I do know that once the BLKSIZE was changed to 3120 the installation went smoothly. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Mon, 22 Jul 2013 15:32:37 -0400 From: d10j...@us.ibm.com Subject: Re: BLKSIZE=3120 To: IBM-MAIN@LISTSERV.UA.EDU If there are any restrictions, they should be APAR'ed. 3120, 6160, 6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM products still ship these crappy blocksizes. It's why I submitted a SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? I have seen an AMATERSE requirement that was submitted for this and we did investigate the AMATERSE code. AMATERSE doesn't require the blocksize of the output data set for a pack operation to be 6144. If a blocksize has not already been determined before AMATERSE tries to OPEN the data set, then AMATERSE assigns a blocksize of 6144, which was a reasonable thing to do when AMATERSE was designed (before the existence of SDB). If you explicitly assign a blocksize when you allocate the data set, AMATERSE will use your blocksize. Changing AMATERSE to avoid assigning a blocksize of 6144, so that SDB can to its thing, appears to be a fairly easy code change, and I do anticipate that it will get done at some point in the future. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Interesting. Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, July 22, 2013 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
FTP has some bizarre default, something like RECFM=U, BLKSIZE=511. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dave Salt Sent: Monday, July 22, 2013 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 A few months ago I assisted a customer who was having difficulty installing SimpList. The installation instructions specify the sequential data set the XMIT files are uploaded to MUST be allocated as BLKSIZE=3120, but the installer specified BLKSIZE=0. I don't remember exactly what problem this caused, but I do know that once the BLKSIZE was changed to 3120 the installation went smoothly. Dave Salt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
We prefer to have SMP/E installs for all our program products and specifically ask when researching new products to be selected. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Duffy Nightingale Sent: Monday, July 22, 2013 12:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Small product with just a few libraries and fairly stand-alone is ok via XMIT. Especially if it is mostly maintained by replacement. Anything more complex is helped by SMP/E, but even with IBM (and CA) when done with SMP/E, there is still usually half or more of the install doing configurations and tailoring. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Duffy Nightingale Sent: Monday, July 22, 2013 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Interesting. Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, July 22, 2013 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 15:32:37 -0400, Jim Mulder wrote: AMATERSE assigns a blocksize of 6144, which was a reasonable thing to do when AMATERSE was designed (before the existence of SDB). If you explicitly assign a blocksize when you allocate the data set, AMATERSE will use your blocksize. ITYM TRSMAIN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 12:16:00 -0700, Duffy Nightingale wrote: we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? IMO, well-implemented SMP/E packaging is preferable to non-SMP/E. However, non-SMP/E packaging is far preferable to poorly implemented SMP/E packaging. Getting it right is difficult and some vendors do a very poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. AFAIK, Innovation (FDR, etc.) still ships their products without SMP/E, and their installation is (IMO) one of the best. IIRC, Quickref is another that is not installed with SMP/E. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Tom Marchant said: AFAIK, Innovation (FDR, etc.) still ships their products without SMP/E, and their installation is (IMO) one of the best. IIRC, Quickref is another that is not installed with SMP/E. SimpList can be added to that list as well. One reason is because many developers want to try SimpList by installing it in their own private libraries, and they don't have access to SMP/E. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Mon, 22 Jul 2013 15:35:49 -0500 From: m42tom-ibmm...@yahoo.com Subject: Re: BLKSIZE=3120 To: IBM-MAIN@LISTSERV.UA.EDU On Mon, 22 Jul 2013 12:16:00 -0700, Duffy Nightingale wrote: we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? IMO, well-implemented SMP/E packaging is preferable to non-SMP/E. However, non-SMP/E packaging is far preferable to poorly implemented SMP/E packaging. Getting it right is difficult and some vendors do a very poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. AFAIK, Innovation (FDR, etc.) still ships their products without SMP/E, and their installation is (IMO) one of the best. IIRC, Quickref is another that is not installed with SMP/E. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 16:41:12 -0400, Dave Salt wrote: SimpList can be added to that list as well. One reason is because many developers want to try SimpList by installing it in their own private libraries, and they don't have access to SMP/E. Shame on IBM for transmogrifying SMP/E into a product that presents an ineffable threat to system integrity, and for tolerating that situation, apparently indefinitely! Prior to that all programmers had access to SMP/E and could install products for trial in their own private libraries. On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote: IMO, well-implemented SMP/E packaging is preferable to non-SMP/E. However, non-SMP/E packaging is far preferable to poorly implemented SMP/E packaging. Getting it right is difficult and some vendors do a very poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. Where can I find some Rules of Thumb; an SMP/E style checker? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Ed: Some time ago (before the binder IIRC) the input into the link editor had a max block size of 3200 (if memory serves me). I think with the binder the restriction has been removed. Ed On Jul 22, 2013, at 11:28 AM, Charles Mills wrote: I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 15:53:01 -0500, Paul Gilmartin wrote: On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote: IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. Where can I find some Rules of Thumb; an SMP/E style checker? I'm not aware of either. There is the Packaging Rules manual, but there is much that is not covered there. It is focused primarily on correct SYSMOD construction. Some other considerations for what I would call proper SMP/E packaging include: o Providing useful system holds as necessary o Using Fix Categories and SOURCEID to simplify maintenance o Providing frequently updated downloadable Enhanced Hold data for errors o Proper SUPs for error holds when a PTF resolves the error o Having a data base of APARs and PTFs that customers can search o Cross-product dependencies (IF...REQ) where applicable o It should NEVER be recommended that a customer use BYPASS(ID) or BYPASS(REQ) o Network delivery for products and service The products and maintenance should be thoroughly tested. In order for the testing to be thorough, many permutations need to be tested. Most PTFs should be able to be applied, restored and applied again without issues. This is not likely an exhaustive list. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 09:08:12 -0700, Ed Jaffe wrote: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: Is there any difference between explicitly specifying BLKSIZE=0 and simply omitting BLKSIZE? Except in COBOL? A War Story: Long prior to the advent of SDB, I had formed the habit of omitting BLKSIZE in my Rexx EXECs. The Rexx function library was smart: it chose good BLKSIZEs and/or I didn't much care about fractional deviations from absolute optimality. And, for all I knew (and didn't care) it adapted well to different device types. Suddenly I started getting Sx13 in old debugged EXECs. It seems that Rexx had deferred BLKSIZE selection to SDB, and SDB was doing a poorer job of selecting BLKSIZE than Rexx. In fact, it was (as then documented!) selecting BLKSIZE=80 for all subsystem data sets (JES and UNIX). RECFM=VBA,LRECL=137, BLKSIZE=80 worked poorly. But when I reported the problem, IBM had the fix at hand. Worked. But IBM warned me: o The repair was designed for JES, and was not certain to work for UNIX files. (Worked OK.) o The repair necessarily violated the _published_ specification of BLKSIZE=80, and if another customer complained, it might be necessary to revert it. o I was advised to stop deferring BLKSIZE and specify it explicitly in all my code. Considerably ironic that a consequence of SDB was that I was advised not to rely on it. (It's better now.) Is there any hope that COBOL will come to trust SDB when BLKSIZE is omitted, or would that necessarily entail a standards violation? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
At 16:51 -0500 on 07/22/2013, Tom Marchant wrote about Re: BLKSIZE=3120: Most PTFs should be able to be applied, restored and applied again without issues. This is an issue since the design of RESTORE is broken due to its poor handling of SUPS/PREs If I can Apply a SYSMOD I should be able to restore it without needing to also restore any SYSMODs it PREs. IOW: If it PREs SYSMOD1 which has Elements EL1 and EL2 and contains only a new EL1, then a restore should be able to just select EL1 from SYSMOD1 and not need to also restore SYSMOD1 (along with its PREs which then need to be Applied again). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Long prior to the advent of SDB, I had formed the habit of omitting BLKSIZE in my Rexx EXECs. The Rexx function library was smart: it chose good BLKSIZEs and/or I didn't much care about fractional deviations from absolute optimality. And, for all I knew (and didn't care) it adapted well to different device types. If I may quibble a bit with the reference to Long prior to the advent of SDB: REXX on MVS was introduced in TSO/E Version 2.1 for MVS/XA and MVS/ESA. I don't remember exactly when that was shipped, but I think it would have been in the 1987-1988 timeframe. I don't remember exactly when SDB was introduced, but I found an APAR OY19694 which was opened on January 5, 1989 for an SDB-related issue. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
You can still use native SMP/E in batch to retain control of your system
installs/maintenance: just do CBIPO instead of IBM's 'recommended'
installs (the distribution tapes should still be in the original format).
IBM had been trying to force us to use their SMP/E 'dialogs' since the
mid/late eighties; but we took no notice. Next IBM tried to force us to
use SystemPak, CustomPak, You-name-it-Pak etc. (as it was called then).
A bank asked me to install it for them in '99. So I did, I checked it -
and it was riddled with bugs (e.g. PROCs were written in lower case, and
why the heck did SystemPak need the master catalog password to install a
product anyway?). I raised a PMR with IBM about that and I got the
following answers.
- Level 1 said it was a 'wonderful product' and that all their customers
wanted it; so I replied that it was full of errors; escalate.
- Level 2 said that IBM had found that many of its customers could not
afford to hire sysprogs and that SystemPak allowed them to install
products without needing ditto; I replied again that it was full of
errors, that if IBM were so clever and their customers were so stupid
then why was it that IBM could not find e.g. the hlq of the current
PARMLIB instead of asking their customers to type it in a panel etc.;
escalate.
- Level 3 said (verbatim) I never said that I agreed with it; so I
replied Thanks, you can close the PMR.
I then told the bank that SystemPak was full of errors and suggested
rewriting it for them - such that it would be 100% compatible with IBM's
version (in case IBM eventually fixed it), but without the bugs and
hassle. The bank said OK. So I wrote and installed my own version of
SystemPak for them.
IBM then spent several weeks calling and asking me to explain how I had
fixed their SystemPak, so they could tell their developers in Canada -
but forgot to mention how much they would pay me for that (tut tut).
Later, at a different company in 2000, I found that IBM had still not
fixed their SystemPak bugs. It's a pity I cannot remember the PMR number
I raised in '99 (I left it behind, at the bank).
IBM is following Microsoft's lead, because 99% of its customers are
computer illiterate but also have 99% of the money. So why bother with
the 1% of us who know how to avoid wasting CPU cycles, VS and DASD space
- but who thereby prevent IBM from selling more hardware - when there
are 'oodles' of customers out there to whom IBM can sell 10 times more
hardware than they actually need, and who believe that to follow IBM's
'recommendations' is the correct and proper way to avoid making
mistakes? (It used to be called FUD.)
I would suggest that you stick with native SMP/E if you do not want IBM
to take it away from you ('out of support', as they say). You can create
your own CSIs by REPRO'ing the production ones (and then preferably into
a single VSAM KSDS as this is *not* recommended by IBM), then
UCLIN-changing them to point at your global/DLIB/TLIB zones and their
datasets (which you can also copy from the production ones) etc.
BTW TRSMAIN supports BLKSIZE=27648 for LRECL=1024 and IPCS supports
BLKSIZE=24960 for LRECL=4160, and you can ZAP any LMOD's hard-coded DCB
BLKSIZE to be whatever you want it to be - if it insists on overriding
yours.
Cheers, Chris Poncelet
Paul Gilmartin wrote:
On Mon, 22 Jul 2013 16:41:12 -0400, Dave Salt wrote:
SimpList can be added to that list as well. One reason is because many
developers want to try SimpList by installing it in their own private
libraries, and they don't have access to SMP/E.
Shame on IBM for transmogrifying SMP/E into a product that presents
an ineffable threat to system integrity, and for tolerating that
situation, apparently indefinitely! Prior to that all programmers
had access to SMP/E and could install products for trial in their own
private libraries.
On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote:
IMO, well-implemented SMP/E packaging is preferable to non-SMP/E.
However, non-SMP/E packaging is far preferable to poorly implemented
SMP/E packaging. Getting it right is difficult and some vendors do a very
poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly,
it is better that they not bother.
Where can I find some Rules of Thumb; an SMP/E style checker?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
In 025801ce86f6$64021d20$2c065760$@mindspring.com, on 07/22/2013 at 09:13 AM, Lizette Koehler stars...@mindspring.com said: AFAIK - OBJ Decks from compilers, TSO XMIT datasets, TRSMAIN (though I think this is 6k) and a few others are still dependent on 3120 blksize. My recollection is that the 3120 limit for compilers, linkage editor and binder were lifted a long time ago. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
In 7455665327418361.wa.m42tomibmmainyahoo@listserv.ua.edu, on 07/22/2013 at 04:51 PM, Tom Marchant m42tom-ibmm...@yahoo.com said: This is not likely an exhaustive list. o Don't use RELFILE for ++ APAR or ++ PTF -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
In 00a401ce870f$e7dd43e0$b797cba0$@soundsoftware.us, on 07/22/2013 at 12:16 PM, Duffy Nightingale du...@soundsoftware.us said: I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? At some shops, being unable to install a fix for a single bug is a major issue. The point of SMP/E is not to just use it as a packaging tool for the entire product but also to use it as a tracking tool for individual fixes. To keep your customers happy when they ask for SMP/E packaging, you have to not only use it but to use it properly. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Jim, Good memory. My memory is a bit different (not by much though). DFP 3.1 first offered SDB TSOe (I think) at 2.1 ++ many PTF's for Rexx . I recall having not to implement XA for REXX (not being fully ready and SWA (above) not being fully supported by vendors. In one case I had to change the (CA's) source code and the other had to wait for a ZAP from Compuware. I was not a happy camper and was calling the vendors daily for an update. Put back my installation by about a month. I had egg on my face at work. Ed On Jul 22, 2013, at 9:03 PM, Jim Mulder wrote: Long prior to the advent of SDB, I had formed the habit of omitting BLKSIZE in my Rexx EXECs. The Rexx function library was smart: it chose good BLKSIZEs and/or I didn't much care about fractional deviations from absolute optimality. And, for all I knew (and didn't care) it adapted well to different device types. If I may quibble a bit with the reference to Long prior to the advent of SDB: REXX on MVS was introduced in TSO/E Version 2.1 for MVS/XA and MVS/ESA. I don't remember exactly when that was shipped, but I think it would have been in the 1987-1988 timeframe. I don't remember exactly when SDB was introduced, but I found an APAR OY19694 which was opened on January 5, 1989 for an SDB- related issue. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
