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:[email protected]] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: [email protected] 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? 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 [email protected] with the message: INFO IBM-MAIN
