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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 51f14a3a.9090...@phoenixsoftware.com, on 07/25/2013 at 08:54 AM, Ed Jaffe edja...@phoenixsoftware.com said: SMP/E is not a self-contained, APF authorized program. It invokes various utilities (in fact, any program you choose!) that were *never* intended to run authorized and therein lies the problem. Perhaps a requirement that SMP/E attach utilities with RSAPF=YES, with appropriate housekeeping, would address the issue. Part of it would have to be using a storage key nor available to the utilities. -- 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, 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 6690423002905817.wa.paulgboulderaim@listserv.ua.edu, on 07/25/2013 at 12:51 PM, Paul Gilmartin paulgboul...@aim.com said: Back in the day, wasn't it impossible for LINKLIST to contain a mixture of authorized and unauthorized libraries? From OS/VS2 Planning and Use Guide, GC28-0600-2: Authorized Program Facility (APF) The authorized program facility (APF) limits the use of sensitive system and (optionally) user services and resources to authorized system and user programs. The authorization consists of a code that is specified when the program is link edited. For a program to be authorized, it must be link edited with this code and reside in either the SYS l.LINKLIB or SYS l.SVCLIB data sets, or the link pack area. The SYSl.LINKLIB, SYSl.SVCLIB, and SYSl.LPALIB Or didn't you want to go that far back? -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 4931a2db-c8b1-4622-94d1-fbacde9f1...@comcast.net, on 07/24/2013 at 04:56 PM, Ed Gould edgould1...@comcast.net said: Since IEBCOPY need APF That's changed. -- 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
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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On 7/26/2013 7:19 AM, Shmuel Metz (Seymour J.) wrote: In 51f14a3a.9090...@phoenixsoftware.com, on 07/25/2013 at 08:54 AM, Ed Jaffe edja...@phoenixsoftware.com said: SMP/E is not a self-contained, APF authorized program. It invokes various utilities (in fact, any program you choose!) that were *never* intended to run authorized and therein lies the problem. Perhaps a requirement that SMP/E attach utilities with RSAPF=YES, with appropriate housekeeping, would address the issue. Part of it would have to be using a storage key nor available to the utilities. I had not thought of that, but I agree it's certainly worth considering as an alternative to unauthorized SMP/E. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Wed, 2013-07-24 at 16:32 -0700, retired mainframer wrote: I don't think SMPE's APF attribute is the root of the problem. It's likely that SMPE still needs APF for e.g. ESTAE CANCEL=NO. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 51ee77c7.5070...@bremultibank.com.pl, on 07/23/2013 at 02:32 PM, R.S. r.skoru...@bremultibank.com.pl said: 11. The idea of SMP/E is to have one CSI and all the products, components in that. Nonsense. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 4589494201288586.wa.dlikensinfosecinc@listserv.ua.edu, on 07/23/2013 at 06:41 AM, Donald Likens dlik...@infosecinc.com said: I have been working with SMP/E since before there was an E (SMP) (over 40 years) and I believe shops that limit themselves to SMP/E installed products are simply causing themselves extra work. I might agree for a single CSECT product, but certainly not for a product with dozens of components. I am a consultant and a software developer. Recently had two installs. One from IBM using SMP/E and another not using SMP/E. Both products were of similar size and complexity. The installation for the none SMP/E installation took under a day. The installation for the SMP/E installed product took about a week and cost my client much more money (consulting fees). The Devil is in the details. Where did the time go? Were the two cases really similar, or just the product sizes. If a shop required an SMP/E maintained product, I guess I would create a CSI etc. but I would download it like a serverpac. Does that mean that all of your service would be in levelsets? You might lose some potential customers if so. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In fbecf4fe-4c6b-4d33-8e44-215adefea...@comcast.net, on 07/23/2013 at 03:14 PM, Ed Gould edgould1...@comcast.net said: IF the consultant uses SMPE to install the product (and he/she doesn't do anything off the books) any decent sysprog can come in and figure out what he/she did in with a minimum of effort. I've sometimes had to spend time figuring out what the correct CSI is. SMP/E can be very nice, but their is still a role for documentation. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On 7/24/2013 7:17 PM, Paul Gilmartin wrote: As of 1.13, IEB[C]OPY is AC=0. (But there is an AC=1 version kept for those who feel they need it (why?).) IEWL (IEWBLINK) is AC=0. AMASPZAP is AC=01 (why?) AMASPZAP needs AC=1 to zap disk labels. It can be safely called in an unauthorized environment to perform the traditional function of zapping load modules and program objects. AMASPZAP is not an impediment to an unauthorized SMP/E. I believe that as of z/OS 1.13 *none* of the programs invoked by SMP/E require authorization. But, as you pointed out in an earlier post, SMP/E itself uses Wait for DSNAME in dynamic allocation, which does require authorization. That's a minor and rarely-needed feature but, if it's important to someone, I believe it would not be very difficult to provide this capability in a way that does not require SMP/E to be authorized. Of course any program that runs AC=1 assumes the responsibility of performing its own SAF checking. I believe this is true also for any program linked AC=0 into an APF authorized library where it may be attached by an AC=1 program. I think the real problem is the fact that SMPE somehow abuses APF to bypass normal security checks for some of its processing. Until IBM decides to correct that (removing APF seems like it would be effective but also seems like overkill), an equitable solution that addresses the needs of both sysprogs and non-sysprogs is likely to be elusive. Why overkill? If it's unnecessary, it's safer and more useful without it. abuses? It's possible. It's possible that development added a new function and hadn't the resources to code the necessary SAF checks. It's even possible that some specified function of SMP/E requires bypassing normal security checks, although that seems highly unlikely. SMP/E is not a self-contained, APF authorized program. It invokes various utilities (in fact, any program you choose!) that were *never* intended to run authorized and therein lies the problem. You cannot change the rules of MVS to require that every unauthorized program residing in an authorized library follow the rules for authorized programs on the off-chance that one of them might one day be invoked by SMP/E in an authorized environment. That would be lunacy. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Jul 25, 2013, at 8:05 AM, Shmuel Metz (Seymour J.) wrote: Of course that is an issue and there is a basic rule to follow. DOCUMENT, DOCUMENT, DOCUMENT. I have been able to pick up on install with 1 piece of paper and maybe a tape. I have seen installations send an object deck on a tape (another extreme was an object deck in punched cards!) the person who installed one product hid it in an undocumented CSI and it took some digging just to find the CSI as he didn't bother to document it, I had to guess the name. What a PITA. Of course he was a short term consultant. Since then I have suggested the consultants stay away from installs. Ed I've sometimes had to spend time figuring out what the correct CSI is. SMP/E can be very nice, but their is still a role for documentation. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Thu, 25 Jul 2013 08:54:34 -0700, Ed Jaffe wrote: SMP/E is not a self-contained, APF authorized program. It invokes various utilities (in fact, any program you choose!) that were *never* intended to run authorized and therein lies the problem. But those programs must come from authorized libraries, else SMP/E ABENDs. And it is the installation's responsibility to protect authorized libraries. But read on ... You cannot change the rules of MVS to require that every unauthorized program residing in an authorized library follow the rules for authorized programs on the off-chance that one of them might one day be invoked by SMP/E in an authorized environment. That would be lunacy. Back in the day, wasn't it impossible for LINKLIST to contain a mixture of authorized and unauthorized libraries? (Aren't things better nowadays?) So programs to go in LINKLIST were, willy-nilly, placed in authorized libraries. Add inertia to get to the present situation. Is SMP/E the only (IBM-supplied) authorized program that allows the user to specify utility names (in fact, any program you choose!)? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 014401ce887f$d11bb080$73531180$@mindspring.com, on 07/24/2013 at 08:09 AM, Lizette Koehler stars...@mindspring.com said: I do not want them to be able to rec/app/acc fixes on my zones. Then don't give them write access to the data sets in your zone. -- 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
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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Back when IBM created the FACILITY class resource names for SMPE I surmised there was an obscure hole through which a zone dataset could be updated despite lack of update access via the dataset profile. I started to experiment with a test CSI to try to hack into an answer. I would have been in the position of the minister that sinks a hole-in-one on the Sabbath. Who'd believe me and who can I tell? Lack of time and the company's eagerness to show me the door prevailed. On 7/25/2013 9:47 AM, Shmuel Metz (Seymour J.) wrote: In 014401ce887f$d11bb080$73531180$@mindspring.com, on 07/24/2013 at 08:09 AM, Lizette Koehler stars...@mindspring.com said: I do not want them to be able to rec/app/acc fixes on my zones. Then don't give them write access to the data sets in your zone. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On 7/23/2013 5:21 PM, Paul Gilmartin wrote: On Tue, 23 Jul 2013 17:58:16 -0600, Roger Bolan wrote: Application programmers should be able to use SMP/E. [snip] A voice of reason. And it was safe, or at least believed to be safe, until IO11698/IO12263. This would make a good SHARE requirement. The goal should be to remove APF authorization from SMP/E and, at the same time, remove the SAF checking that was recently introduced to limit who could use SMP/E. Originally, SMP/E required authorization only because IEBCOPY required it. Now that IEBCOPY no longer requires authorization (as of z/OS 1.13), it would seem easy to remove the AC(1) binder attribute from SMP/E. Right? No so fast! It's entirely possible that additional features were added to SMP/E over the years that work only because it's APF authorized. If so, those features will need to be identified and additional development will be required to find a way to provide similar function from unauthorized SMP/E. Clearly, someone at IBM needs to work on this. SMP/E should go back to being a utility that anyone can use--just just a privileged few. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
I might slightly disagree with removing the SAF and APF requirements. From a sysprog perspective, I can allow my applications groups access to LIST functions but NOT REC/APP/ACC. This is beneficial. I do not mind if they want to look, I just do not want them to touch. In fact I would encourage them or anyone to be able to research fixes. I do not want them to be able to rec/app/acc fixes on my zones. If a shop wants to make it open, then just make UACC on the facilities open. And as for APF. It is another protection in the system. Since an APF authorized library can control to some extent the ability to modify some storage areas, I think this is also fine. Some of the functions in SMP/E could be dangerous if allowed to run amuck. Now if Kurt Q. would chime in, it would be helpful. But from my perspective, I am happy with how things have become. I was not a supporter of the new facility classes, but now I am. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Wednesday, July 24, 2013 8:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) On 7/23/2013 5:21 PM, Paul Gilmartin wrote: On Tue, 23 Jul 2013 17:58:16 -0600, Roger Bolan wrote: Application programmers should be able to use SMP/E. [snip] A voice of reason. And it was safe, or at least believed to be safe, until IO11698/IO12263. This would make a good SHARE requirement. The goal should be to remove APF authorization from SMP/E and, at the same time, remove the SAF checking that was recently introduced to limit who could use SMP/E. Originally, SMP/E required authorization only because IEBCOPY required it. Now that IEBCOPY no longer requires authorization (as of z/OS 1.13), it would seem easy to remove the AC(1) binder attribute from SMP/E. Right? No so fast! It's entirely possible that additional features were added to SMP/E over the years that work only because it's APF authorized. If so, those features will need to be identified and additional development will be required to find a way to provide similar function from unauthorized SMP/E. Clearly, someone at IBM needs to work on this. SMP/E should go back to being a utility that anyone can use--just just a privileged few. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On 7/24/2013 8:09 AM, Lizette Koehler wrote: I might slightly disagree with removing the SAF and APF requirements. From a sysprog perspective, I can allow my applications groups access to LIST functions but NOT REC/APP/ACC. This is beneficial. I do not mind if they want to look, I just do not want them to touch. In fact I would encourage them or anyone to be able to research fixes. I do not want them to be able to rec/app/acc fixes on my zones. This is accomplished in SMP/E (and all other system utilities) by granting the appropriate access to the data sets being manipulated. In this case, READ access to the CSI as well as target/DLIB data sets would seem appropriate. If a shop wants to make it open, then just make UACC on the facilities open. But, the integrity exposure--which I have purposely tried to refrain from mentioning directly--still remains! SMP/E's FACILITY class resources do not eliminate the exposure, rather they limit it to jobs that can be run by trusted individuals. Some might call this a kludge. At best, it's a Band-Aid fix. And as for APF. It is another protection in the system. Since an APF authorized library can control to some extent the ability to modify some storage areas, I think this is also fine. Some of the functions in SMP/E could be dangerous if allowed to run amuck. You have this exactly backwards. APF authorization of SMP/E is the reason the exposure exists in the first place. Removal of that attribute completely solves the problem. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Wed, 24 Jul 2013 07:59:47 -0700, Ed Jaffe wrote: Originally, SMP/E required authorization only because IEBCOPY required it. ... It's entirely possible that additional features were added to SMP/E over the years that work only because it's APF authorized. If so, those features will need to be identified and additional development will be required to find a way to provide similar function from unauthorized SMP/E. S99WTDSN is a case in point. Can be suppressed with NOWAIT in DDDEFs. Clearly, someone at IBM needs to work on this. SMP/E should go back to being a utility that anyone can use--just just a privileged few. I agree wholeheartedly. Can a business case be presented to IBM? Of course, one can force SMP/E to run unauthorized simply by adding an unauthorized STEPLIB or by ATTACHing it from an unauthorized program. A mildest form of the putative requirement might be to waive the RACF requirement when SMP/E is running unauthorized. (If SMP/E nonetheless threatens system integrity when it runs unauthorized, the z/OS Statement of Integrity is violated. http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.html ) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
EJ has all but made my point for me. The question who should be able to use SMP/E and the question who should have write access to system libraries can be and need to be disentangled. We sysprogs tend to think about this problem in these narrow terms, but it is a more general one. Consider two application development groups, one for ap A and another for ap B. The members of the ap A group should not have write access to the Ap B group's libraries and vice versa. The principle involved is the same. 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Wed, 24 Jul 2013 08:09:38 -0700, Lizette Koehler wrote: I do not want them to be able to rec/app/acc fixes on my zones. Who said anything about _your_ zones? Just use data set protections. If a shop wants to make it open, then just make UACC on the facilities open. Thereby opening the ineffable system integrity threat to everyone in the shop? Now if Kurt Q. would chime in, it would be helpful. IBM has declared its intention not to be teased into disclosing more details of the integrity hazard. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
This issue is a modern reincarnation of an old bugaboo dating to the lifetime of the original non-E SMP. At one time it was more or less verboten in many shops for a non-Sysprog to use IPCS. Not because of what a user might see in storage but because IPCS required access to SYS1.PARMIB. That allocation was hard coded in the product, and many auditors at the time believed that PARMLIB contained keys to the kingdom itself. Never mind that an application programmer could point IPCS to a SYSMDUMP to shortcut debugging. No PARMLIB, no IPCS. In response to GUIDE (and perhaps SHARE) requirements, IBM finally allowed the parmllib allocation to point to any user-accessible library. Ed J is right that it's APF authorization that spooks many today to lock SMP/E away from those without proper 'security clearance'. It's time to make this valuable tool available to people who could use it to the benefit of their employers. . . 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: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 07/24/2013 08:48 AM Subject:Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU EJ has all but made my point for me. The question who should be able to use SMP/E and the question who should have write access to system libraries can be and need to be disentangled. We sysprogs tend to think about this problem in these narrow terms, but it is a more general one. Consider two application development groups, one for ap A and another for ap B. The members of the ap A group should not have write access to the Ap B group's libraries and vice versa. The principle involved is the same. 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Wed, Jul 24, 2013 at 10:09 AM, Lizette Koehler stars...@mindspring.com wrote: I might slightly disagree with removing the SAF and APF requirements. From a sysprog perspective, I can allow my applications groups access to LIST functions but NOT REC/APP/ACC. This is beneficial. I do not mind if they want to look, I just do not want them to touch. In fact I would encourage them or anyone to be able to research fixes. I do not want them to be able to rec/app/acc fixes on my zones. If a shop wants to make it open, then just make UACC on the facilities open. And as for APF. It is another protection in the system. Since an APF authorized library can control to some extent the ability to modify some storage areas, I think this is also fine. Some of the functions in SMP/E could be dangerous if allowed to run amuck. Now if Kurt Q. would chime in, it would be helpful. But from my perspective, I am happy with how things have become. I was not a supporter of the new facility classes, but now I am. Lizette The files should have appropriate RACF authority defined on the files. I. E. z/OS files only updated by system programmers but readable by application programs. Application programmer files only updated by Applications programmers who work on that Application, etc. A function that could impact the running system memory should need facility authorization. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Ed, Since IEBCOPY need APF we are in a which comes first the chicken or the egg. Ed On Jul 24, 2013, at 9:59 AM, Ed Jaffe wrote: On 7/23/2013 5:21 PM, Paul Gilmartin wrote: On Tue, 23 Jul 2013 17:58:16 -0600, Roger Bolan wrote: Application programmers should be able to use SMP/E. [snip] A voice of reason. And it was safe, or at least believed to be safe, until IO11698/IO12263. This would make a good SHARE requirement. The goal should be to remove APF authorization from SMP/E and, at the same time, remove the SAF checking that was recently introduced to limit who could use SMP/E. Originally, SMP/E required authorization only because IEBCOPY required it. Now that IEBCOPY no longer requires authorization (as of z/OS 1.13), it would seem easy to remove the AC(1) binder attribute from SMP/E. Right? No so fast! It's entirely possible that additional features were added to SMP/E over the years that work only because it's APF authorized. If so, those features will need to be identified and additional development will be required to find a way to provide similar function from unauthorized SMP/E. Clearly, someone at IBM needs to work on this. SMP/E should go back to being a utility that anyone can use--just just a privileged few. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
I don't think SMPE's APF attribute is the root of the problem. There are numerous APF programs that are safely usable by users with extremely variable privileges and authorities (e.g., IEBOPY, AMASPZAP, and Binder). I think the real problem is the fact that SMPE somehow abuses APF to bypass normal security checks for some of its processing. Until IBM decides to correct that (removing APF seems like it would be effective but also seems like overkill), an equitable solution that addresses the needs of both sysprogs and non-sysprogs is likely to be elusive. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Ed Jaffe :: Sent: Wednesday, July 24, 2013 8:00 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) :: :: On 7/23/2013 5:21 PM, Paul Gilmartin wrote: :: On Tue, 23 Jul 2013 17:58:16 -0600, Roger Bolan wrote: :: :: Application programmers should be able to use SMP/E. :: :: [snip] :: :: A voice of reason. And it was safe, or at least believed to be safe, :: until :: IO11698/IO12263. :: :: This would make a good SHARE requirement. The goal should be to remove :: APF authorization from SMP/E and, at the same time, remove the SAF :: checking that was recently introduced to limit who could use SMP/E. :: :: Originally, SMP/E required authorization only because IEBCOPY required :: it. Now that IEBCOPY no longer requires authorization (as of z/OS 1.13), :: it would seem easy to remove the AC(1) binder attribute from SMP/E. :: Right? No so fast! It's entirely possible that additional features were :: added to SMP/E over the years that work only because it's APF :: authorized. If so, those features will need to be identified and :: additional development will be required to find a way to provide similar :: function from unauthorized SMP/E. :: :: Clearly, someone at IBM needs to work on this. SMP/E should go back to :: being a utility that anyone can use--just just a privileged few. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Wed, 24 Jul 2013 16:32:41 -0700, retired mainframer wrote: I don't think SMPE's APF attribute is the root of the problem. There are numerous APF programs that are safely usable by users with extremely variable privileges and authorities (e.g., IEBOPY, AMASPZAP, and Binder). As of 1.13, IEB[C]OPY is AC=0. (But there is an AC=1 version kept for those who feel they need it (why?).) IEWL (IEWBLINK) is AC=0. AMASPZAP is AC=01 (why?) Of course any program that runs AC=1 assumes the responsibility of performing its own SAF checking. I believe this is true also for any program linked AC=0 into an APF authorized library where it may be attached by an AC=1 program. I think the real problem is the fact that SMPE somehow abuses APF to bypass normal security checks for some of its processing. Until IBM decides to correct that (removing APF seems like it would be effective but also seems like overkill), an equitable solution that addresses the needs of both sysprogs and non-sysprogs is likely to be elusive. Why overkill? If it's unnecessary, it's safer and more useful without it. abuses? It's possible. It's possible that development added a new function and hadn't the resources to code the necessary SAF checks. It's even possible that some specified function of SMP/E requires bypassing normal security checks, although that seems highly unlikely. I suspect the flaw isn't aboriginal; more plausibly it was introduced by some function added recently. My favorite candidate suspects are Java, Unix System Services, and Internet. I wonder what happens if I supply my own directory in place of //SMPCPATH DD? Etc. -- 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
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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
I have been working with SMP/E since before there was an E (SMP) (over 40 years) and I believe shops that limit themselves to SMP/E installed products are simply causing themselves extra work. I am a consultant and a software developer. Recently had two installs. One from IBM using SMP/E and another not using SMP/E. Both products were of similar size and complexity. The installation for the none SMP/E installation took under a day. The installation for the SMP/E installed product took about a week and cost my client much more money (consulting fees). I think SMP/E is required for products as complicated as the operating system, DB2, or CICS because it keeps track of the maintenance installed but for products that can be version controlled a non-SMP/E install is much quicker and easier. The product I develop does not use SMP/E simply because it is not needed. If a shop required an SMP/E maintained product, I guess I would create a CSI etc. but I would download it like a serverpac. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
W dniu 2013-07-23 13:41, Donald Likens pisze: I have been working with SMP/E since before there was an E (SMP) (over 40 years) and I believe shops that limit themselves to SMP/E installed products are simply causing themselves extra work. I am a consultant and a software developer. Recently had two installs. One from IBM using SMP/E and another not using SMP/E. Both products were of similar size and complexity. The installation for the none SMP/E installation took under a day. The installation for the SMP/E installed product took about a week and cost my client much more money (consulting fees). I think SMP/E is required for products as complicated as the operating system, DB2, or CICS because it keeps track of the maintenance installed but for products that can be version controlled a non-SMP/E install is much quicker and easier. The product I develop does not use SMP/E simply because it is not needed. If a shop required an SMP/E maintained product, I guess I would create a CSI etc. but I would download it like a serverpac. IMHO some people think consider SMP/E a black magic. SMP/E is IBM standard, it's always good to adhere the standards, but: - if you install the product in separate CSI (with no cross-link DDDEFs), then there is no interaction between the product and any other component. - if you provide service as replacement of whole modules/libraries/all the product, then internal dependencies give no value. - if your product checks required dependencies at runtime level, then it's pointless to use SMP/E for that. - it is much easier to install simple product by using XMIT format and RECEIVE few libraries. - it XMIT itself does not precludes further SMP/E process, it can be a method to omit the tape or pax/zip archives. SMP/E is overcomplicated, non error-free and definitely not error-proof (and idiot-proof). Some examples: 1. IBM Encryption Facility v1. Two loadmodules were added to SYS1.LINKLIB, 50k+ lines of sysout. Overcomplication. There is an option to install it in separate CSI, but then nothing is installed (AFAIR due to lack or pre-req's in the separate zone).Of course no clue about it. 2. IBM CCCA, delivered as a part of Debug Tool. It's vry old tool, last change/update happened many years ago. Unfortunately ther is a mistake in description of one component. And THERE IS NO WAY TO FIX IT! It CANNOT be fixed by PTF, the only way to fix it is the following: SET BDY (TARGET). UCLIN. REP SAMP(ABJ058) RMID(H09F210). ENDUCL. SET BDY (DLIB). UCLIN. REP SAMP(ABJ058) RMID(H09F210). ENDUCL. You can order up-to-date package with the latest service and you will still get the same old error and still NO CLUE about it, unless you know it.First time I met it in 2006, nothing happened since then. It's still not fixed and no clue. 3. HOLD(ACTION) informing that ...you have to apply the PTF. THIS PTF containing the action. Other HOLD(ACTION)'s informing about DOC changes, DB2 binds, etc. etc.There are plenty of misnamed HOLDs. 4. Job samples with REGION=4M at IEFBR14 step as well as at GIMSMP step. In first case it's only funny, for the second one itwon't work. 5. Program Directory. It's related to SMP/E in some way (strictly or loosely - your choice). PGMdir describes non-existent world of Product Tapes, while it's known for years that you get CBPDO (or other) tapes. So you have to interpret the description in a way applicable to real world. It's like description of the travel by a horse when driving new car on the highway. 6. Memo to users, readme first. The only information is print Memo to Users Extension. 7. Installation tape. It's happened to me many years ago. I've got 40 carts in the box, but SMP/E treat it as THE TAPE. Singular. It's multi-volume TAPE. When miexed with nonexistent product tapes it's really misleading. 8. Some products are installed using SMP/E every module is under strict version control, but later ...you have to unpax some big archive and continue installation completely out of SMP/E control. SMP/E is used to apply the installation package, a kind of SETUP.EXE. In such case any update means another SETUP.EXE. And we have both complexity of SMP/E and no control of the SMP/E. One of the examples is WAS. The installation of WAS is a nightmare, don't even try to change any RACF username or any other detail - you will never know what is hardcoded! 9. SMP/E is not enough to install the product. Even wih job samples you sometimes have to perform many actions not covered by the installation process. It's not only allocation of the libraries (out of SMP/E but usually in samples), but also LPA, LNKLST, APF, PARMLIB, operational datasets, and many, many other activities, required to make the product working. Usually it's called post installation activities, but it's simply part of the installation, completely out of SMP/E scope. 10. Cross-dependencies. When
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Your no interaction between the product and any other component implicitly includes it, but perhaps it should be explicitly stated that this means the non-SMP/E product, or a product with its own SMP/E zones, may not require the installation of any elements in libraries owned by any other product or SMP/E zone. While it is acceptable to have a non-owning product or zone reference and use elements in a library associated with some other SMP/E zone, it should be mandatory that only one zone owns any given library and FMIDs in that zone own all elements in the library. You can get away with violating that rule if the element names are still all unique, but it is a bad idea to do so. And, so that one SMP/E zone always knowns the state of all elements in an owned library, any local customization to a product maintained by SMP/E should either be applied via USERMOD or to separate non-SMP/E local libraries. JC Ewing On 07/23/2013 07:32 AM, R.S. wrote: W dniu 2013-07-23 13:41, Donald Likens pisze: I have been working with SMP/E since before there was an E (SMP) (over 40 years) and I believe shops that limit themselves to SMP/E installed products are simply causing themselves extra work. I am a consultant and a software developer. Recently had two installs. One from IBM using SMP/E and another not using SMP/E. Both products were of similar size and complexity. The installation for the none SMP/E installation took under a day. The installation for the SMP/E installed product took about a week and cost my client much more money (consulting fees). I think SMP/E is required for products as complicated as the operating system, DB2, or CICS because it keeps track of the maintenance installed but for products that can be version controlled a non-SMP/E install is much quicker and easier. The product I develop does not use SMP/E simply because it is not needed. If a shop required an SMP/E maintained product, I guess I would create a CSI etc. but I would download it like a serverpac. IMHO some people think consider SMP/E a black magic. SMP/E is IBM standard, it's always good to adhere the standards, but: - if you install the product in separate CSI (with no cross-link DDDEFs), then there is no interaction between the product and any other component. - if you provide service as replacement of whole modules/libraries/all the product, then internal dependencies give no value. - if your product checks required dependencies at runtime level, then it's pointless to use SMP/E for that. - it is much easier to install simple product by using XMIT format and RECEIVE few libraries. - it XMIT itself does not precludes further SMP/E process, it can be a method to omit the tape or pax/zip archives. SMP/E is overcomplicated, non error-free and definitely not error-proof (and idiot-proof). Some examples: 1. IBM Encryption Facility v1. Two loadmodules were added to SYS1.LINKLIB, 50k+ lines of sysout. Overcomplication. There is an option to install it in separate CSI, but then nothing is installed (AFAIR due to lack or pre-req's in the separate zone).Of course no clue about it. 2. IBM CCCA, delivered as a part of Debug Tool. It's vry old tool, last change/update happened many years ago. Unfortunately ther is a mistake in description of one component. And THERE IS NO WAY TO FIX IT! It CANNOT be fixed by PTF, the only way to fix it is the following: SET BDY (TARGET). UCLIN. REP SAMP(ABJ058) RMID(H09F210). ENDUCL. SET BDY (DLIB). UCLIN. REP SAMP(ABJ058) RMID(H09F210). ENDUCL. You can order up-to-date package with the latest service and you will still get the same old error and still NO CLUE about it, unless you know it.First time I met it in 2006, nothing happened since then. It's still not fixed and no clue. 3. HOLD(ACTION) informing that ...you have to apply the PTF. THIS PTF containing the action. Other HOLD(ACTION)'s informing about DOC changes, DB2 binds, etc. etc.There are plenty of misnamed HOLDs. 4. Job samples with REGION=4M at IEFBR14 step as well as at GIMSMP step. In first case it's only funny, for the second one itwon't work. 5. Program Directory. It's related to SMP/E in some way (strictly or loosely - your choice). PGMdir describes non-existent world of Product Tapes, while it's known for years that you get CBPDO (or other) tapes. So you have to interpret the description in a way applicable to real world. It's like description of the travel by a horse when driving new car on the highway. 6. Memo to users, readme first. The only information is print Memo to Users Extension. 7. Installation tape. It's happened to me many years ago. I've got 40 carts in the box, but SMP/E treat it as THE TAPE. Singular. It's multi-volume TAPE. When miexed with nonexistent product tapes it's really misleading. 8. Some products are installed using SMP/E every module is under strict version
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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
I too have experience that predates the 'E' in SMP/E, but I have more respect for this tool than I can say. A few quick queries hints at what my current z/OS CSI manages: MOD- 79,869 LMOD - 31,153 MAC- 8,545 PNL- 13,494 All of these elements are mapped completely, including their relationship with each other and the maintenance history behind them: 17,286 SYSMODs from basic product component (FMID) to our local modifications (USERMODs). I understand the appeal of the quick-and-dirty download-and-go approach, particularly for a consultant brought to town for a product install. It's fast, it's tidy, and it's over before the smoke clears. Then bye-bye to Ms. C, who moves on to the next town in dire need of a competent sheriff. But life goes on in each town. Next month or next year, some fix or enhancement is required. Who will do that and how? Who will know--or remember--exactly what state the product was left in after the last dust-up? SMP/E knows and remembers forever. . . 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: Joel C. Ewing jcew...@acm.org To: IBM-MAIN@LISTSERV.UA.EDU, Date: 07/23/2013 06:59 AM Subject:Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Your no interaction between the product and any other component implicitly includes it, but perhaps it should be explicitly stated that this means the non-SMP/E product, or a product with its own SMP/E zones, may not require the installation of any elements in libraries owned by any other product or SMP/E zone. While it is acceptable to have a non-owning product or zone reference and use elements in a library associated with some other SMP/E zone, it should be mandatory that only one zone owns any given library and FMIDs in that zone own all elements in the library. You can get away with violating that rule if the element names are still all unique, but it is a bad idea to do so. And, so that one SMP/E zone always knowns the state of all elements in an owned library, any local customization to a product maintained by SMP/E should either be applied via USERMOD or to separate non-SMP/E local libraries. JC Ewing On 07/23/2013 07:32 AM, R.S. wrote: W dniu 2013-07-23 13:41, Donald Likens pisze: I have been working with SMP/E since before there was an E (SMP) (over 40 years) and I believe shops that limit themselves to SMP/E installed products are simply causing themselves extra work. I am a consultant and a software developer. Recently had two installs. One from IBM using SMP/E and another not using SMP/E. Both products were of similar size and complexity. The installation for the none SMP/E installation took under a day. The installation for the SMP/E installed product took about a week and cost my client much more money (consulting fees). I think SMP/E is required for products as complicated as the operating system, DB2, or CICS because it keeps track of the maintenance installed but for products that can be version controlled a non-SMP/E install is much quicker and easier. The product I develop does not use SMP/E simply because it is not needed. If a shop required an SMP/E maintained product, I guess I would create a CSI etc. but I would download it like a serverpac. IMHO some people think consider SMP/E a black magic. SMP/E is IBM standard, it's always good to adhere the standards, but: - if you install the product in separate CSI (with no cross-link DDDEFs), then there is no interaction between the product and any other component. - if you provide service as replacement of whole modules/libraries/all the product, then internal dependencies give no value. - if your product checks required dependencies at runtime level, then it's pointless to use SMP/E for that. - it is much easier to install simple product by using XMIT format and RECEIVE few libraries. - it XMIT itself does not precludes further SMP/E process, it can be a method to omit the tape or pax/zip archives. SMP/E is overcomplicated, non error-free and definitely not error-proof (and idiot-proof). Some examples: 1. IBM Encryption Facility v1. Two loadmodules were added to SYS1.LINKLIB, 50k+ lines of sysout. Overcomplication. There is an option to install it in separate CSI, but then nothing is installed (AFAIR due to lack or pre-req's in the separate zone).Of course no clue about it. 2. IBM CCCA, delivered as a part of Debug Tool. It's vry old tool, last change/update happened many years ago. Unfortunately ther is a mistake in description of one component. And THERE IS NO WAY TO FIX IT! It CANNOT be fixed by PTF, the only way to fix it is the following: SET BDY (TARGET). UCLIN. REP SAMP(ABJ058) RMID(H09F210). ENDUCL. SET
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On 2013-07-23, at 08:53, Skip Robinson wrote: I understand the appeal of the quick-and-dirty download-and-go approach, particularly for a consultant brought to town for a product install. It's fast, it's tidy, and it's over before the smoke clears. Then bye-bye to Ms. C, who moves on to the next town in dire need of a competent sheriff. But life goes on in each town. Next month or next year, some fix or enhancement is required. Who will do that and how? Who will know--or remember--exactly what state the product was left in after the last dust-up? And if Ms. C were to oblige the customer and perform an installation with SMP/E, she'd have to be granted the special privileges now needed for SMP/E, over and above the authority to modify the data sets actually needed for the product. Will auditors be entirely happy with that? Grrr. I suppose Ms. C can back-seat drive for a member of the systems staff with suitable privileges. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
SMP/E is imperfect. What is not? That conceded, it has no viable competitors. It should also, I think, be used in place of its notional competitors for applications maintenance. The idea that applications must be maintained using something 'simpler and easier to use' is delusional. None of the above is an argument for not urging improvements and extensions upon IBM. 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Tue, 23 Jul 2013 06:41:37 -0500, Donald Likens wrote: If a shop required an SMP/E maintained product, I guess I would create a CSI etc. but I would download it like a serverpac. There is much more to an SMP/E maintained product than create a CSI etc. A CSI is worthless unless maintenance is delivered in the form of properly constructed PTFs. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Thanks Lizette and others, We have a pretty solid process for tracking releases, fixes, changes, updates, etc. In 23 years there was only one confusion when a customer did not apply a fix as requested but we figured that our pretty quickly. We are going to look into the SMP/E process however. We do like to keep our customers happy! Thanks much to everyone who commented. Duffy -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, July 22, 2013 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) Just taking this to a new thread Personally I prefer SMP/E installs. It provides the following Ease of installation Ease of verifying Maint Levels Ease of upgrades or phase outs. When I have NON SMP/E installs they tend to be just simple IEBCOPY from here to here. Then it is up to me to ensure a way to validate what is in production, what is in test, what maintenance levels are available. There have been some NON SMP/E install products that have done a good job with the three points. But I have to make sure it is documented, my team mates can find (or use) my documentation and that the process is bullet proof. If it cannot pass the Lizette Test for bullet-proofness, then I really do not want the product in my shop. At one of my previous lives, I was supporting an OEM product that was NON-SMP/E installed. It was a nightmare. They process was a bare bones TSO XMIT install. But I had no way to very if I had the current version of software or not. It took many iterations before I found a naming convention that would at least look like it could identify what version of the product I was running in sand box and everywhere else. I think if you have one or two LPARs it is not so bad. But when you are looking at 5 or more LPARs or more than one PLEX to maintain software on, the SMP/E is a big benefit. But, if you have a solid process that covers my concerns, I may not gripe too much over a non-SMP/E install. Lizette -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, -- 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
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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Jul 23, 2013, at 9:53 AM, Skip Robinson wrote: - SNIP SMP/E knows and remembers forever. . . Skip, Excellent point and put better than I did in my reply. The worst thing a manager can do is to hire a consultant to install products and then after X many months the consultant leaves and the people are left to put together the pieces. IF the consultant uses SMPE to install the product (and he/she doesn't do anything off the books) any decent sysprog can come in and figure out what he/she did in with a minimum of effort. Even if the employee is working from home its easy to get up to speed. We had one person that work from home and she installed a product and it utterly failed as she show horned it in rather than following the install via smp/e (after all she worked from home cough cough cough). Nobody could figure out how to implement it (nobody wanted to touch it as it was installed haphazard. The product never got used and several thousand dollars went down the drain. Ed -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Paul, Sigh... there is installed and then there is INSTALLED. No application programmer would/should be granted access to update to any system library if that is what you complaining about too bad, If you are talking SMPE Again the smpe libraries are essentially keys. Now they are OK for an auditor or management to READ them but NOT for lowly programmers. If you want SMPE for the average joe programmer again the answer should be NO. There are some things (albiet few things) that application should not be using. Ed On Jul 23, 2013, at 10:03 AM, Paul Gilmartin wrote: On 2013-07-23, at 08:53, Skip Robinson wrote: I understand the appeal of the quick-and-dirty download-and-go approach, particularly for a consultant brought to town for a product install. It's fast, it's tidy, and it's over before the smoke clears. Then bye- bye to Ms. C, who moves on to the next town in dire need of a competent sheriff. But life goes on in each town. Next month or next year, some fix or enhancement is required. Who will do that and how? Who will know--or remember--exactly what state the product was left in after the last dust-up? And if Ms. C were to oblige the customer and perform an installation with SMP/E, she'd have to be granted the special privileges now needed for SMP/E, over and above the authority to modify the data sets actually needed for the product. Will auditors be entirely happy with that? Grrr. I suppose Ms. C can back-seat drive for a member of the systems staff with suitable privileges. -- 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
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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Tue, 23 Jul 2013 16:05:34 -0500, Ed Gould wrote: Sigh... there is installed and then there is INSTALLED. No application programmer would/should be granted access to update to any system library if that is what you complaining about too bad, If you are talking SMPE Again the smpe libraries are essentially keys. Now they are OK for an auditor or management to READ them but NOT for lowly programmers. If you want SMPE for the average joe programmer again the answer should be NO. There are some things (albiet few things) that application should not be using. Elitism. SMP/E should be just a tool to be used with appropriate protection of resources. Until about 3 years ago, the fact was (believed to be) that with proper data set protection SMP/E was no more dangerous than any other tool. You seem to be asserting that use of SMP/E should be restricted to an elite cadre, but in your previous submission: On Tue, 23 Jul 2013 15:14:10 -0500, Ed Gould wrote: ... We had one person that work from home and she installed a product and it utterly failed as she show horned it in rather than following the install via smp/e (after all she worked from home cough cough cough). Nobody could figure out how to implement it (nobody wanted to touch it as it was installed haphazard. The product never got used and several thousand dollars went down the drain. Was this before or after the sea change of 3 years ago? In those happy days gone by, she would have needed no more permissions to use SMP/E than to perform the shoehorn installation. I don't know her job description. Would she nowadays be granted the extraordinary privileges required to use SMP/E? Was she applications or systems? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
There is too much pussyfooting going on here. IBM clearly has knowledge of a security exposure that is SMP/E-linked. I have no notion what this linkage is, but what it is will emerge, and we may hope that IBM has eliminated it before then. Absent this problem it would be entirely possible to use SMP/E to maintain an application or applications without providing their maintainers with concomitant access to the system libraries used to maintain the operating system itself. If, as I think it is, this is Paul Gilmartin's point, he is right. 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Tue, 23 Jul 2013 17:58:16 -0600, Roger Bolan wrote: Application programmers should be able to use SMP/E. They just should never be updating the system zones and libraries. As an application developer I have for years maintained my own sandbox CSI with my own global, target and dlib zones. I can do whatever I want in there with my own zones and my own libraries without affecting the system or anybody else on it. I can test the installation of products, ++APARS, and PTFs and recreate the scenarios of customers who get themselves into trouble. It has been invaluable. A voice of reason. And it was safe, or at least believed to be safe, until IO11698/IO12263. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Paul: Heck if they (application programmer) wanted to create their own CSI's and maintain it for application code go for it. I don't think IBM would be equipped to handle application types calling them on the 1-800 number though. If you want the systems group to handle call's better hire another sysprog. ED On Jul 23, 2013, at 6:35 PM, Paul Gilmartin wrote: On Tue, 23 Jul 2013 16:05:34 -0500, Ed Gould wrote: Sigh... there is installed and then there is INSTALLED. No application programmer would/should be granted access to update to any system library if that is what you complaining about too bad, If you are talking SMPE Again the smpe libraries are essentially keys. Now they are OK for an auditor or management to READ them but NOT for lowly programmers. If you want SMPE for the average joe programmer again the answer should be NO. There are some things (albiet few things) that application should not be using. Elitism. SMP/E should be just a tool to be used with appropriate protection of resources. Until about 3 years ago, the fact was (believed to be) that with proper data set protection SMP/E was no more dangerous than any other tool. You seem to be asserting that use of SMP/E should be restricted to an elite cadre, but in your previous submission: On Tue, 23 Jul 2013 15:14:10 -0500, Ed Gould wrote: ... We had one person that work from home and she installed a product and it utterly failed as she show horned it in rather than following the install via smp/e (after all she worked from home cough cough cough). Nobody could figure out how to implement it (nobody wanted to touch it as it was installed haphazard. The product never got used and several thousand dollars went down the drain. Was this before or after the sea change of 3 years ago? In those happy days gone by, she would have needed no more permissions to use SMP/E than to perform the shoehorn installation. I don't know her job description. Would she nowadays be granted the extraordinary privileges required to use SMP/E? Was she applications or systems? -- 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
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
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
SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Just taking this to a new thread Personally I prefer SMP/E installs. It provides the following Ease of installation Ease of verifying Maint Levels Ease of upgrades or phase outs. When I have NON SMP/E installs they tend to be just simple IEBCOPY from here to here. Then it is up to me to ensure a way to validate what is in production, what is in test, what maintenance levels are available. There have been some NON SMP/E install products that have done a good job with the three points. But I have to make sure it is documented, my team mates can find (or use) my documentation and that the process is bullet proof. If it cannot pass the Lizette Test for bullet-proofness, then I really do not want the product in my shop. At one of my previous lives, I was supporting an OEM product that was NON-SMP/E installed. It was a nightmare. They process was a bare bones TSO XMIT install. But I had no way to very if I had the current version of software or not. It took many iterations before I found a naming convention that would at least look like it could identify what version of the product I was running in sand box and everywhere else. I think if you have one or two LPARs it is not so bad. But when you are looking at 5 or more LPARs or more than one PLEX to maintain software on, the SMP/E is a big benefit. But, if you have a solid process that covers my concerns, I may not gripe too much over a non-SMP/E install. Lizette -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, -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Lizette: Well said. In the past 40+ years I have done all types of installs. SMPE in the end simplifies installation. I have frequently rejected a product just because that it is not installed via SMPE. I have seen everything from an IEBCOPY to quite complicated installation procedures. Yes it can be cumbersome to install via SMPE but every sysprog that I have worked with (except some well lets say amateur types) have generally liked SMPE(for IM) It is far easier to figure out levels of products with SMPE IMO. I have seen OEM's supply fixes with zaps (and use IDRDATA rather than SMPE) and when all is said and done the level of the product was almost always up in the air and made problem determination less straight forwardas IDRdata is not in a dump. Ed On Jul 22, 2013, at 3:46 PM, Lizette Koehler wrote: Just taking this to a new thread Personally I prefer SMP/E installs. It provides the following Ease of installation Ease of verifying Maint Levels Ease of upgrades or phase outs. When I have NON SMP/E installs they tend to be just simple IEBCOPY from here to here. Then it is up to me to ensure a way to validate what is in production, what is in test, what maintenance levels are available. There have been some NON SMP/E install products that have done a good job with the three points. But I have to make sure it is documented, my team mates can find (or use) my documentation and that the process is bullet proof. If it cannot pass the Lizette Test for bullet-proofness, then I really do not want the product in my shop. At one of my previous lives, I was supporting an OEM product that was NON-SMP/E installed. It was a nightmare. They process was a bare bones TSO XMIT install. But I had no way to very if I had the current version of software or not. It took many iterations before I found a naming convention that would at least look like it could identify what version of the product I was running in sand box and everywhere else. I think if you have one or two LPARs it is not so bad. But when you are looking at 5 or more LPARs or more than one PLEX to maintain software on, the SMP/E is a big benefit. But, if you have a solid process that covers my concerns, I may not gripe too much over a non-SMP/E install. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@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- m...@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, -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Folks, Does anybody have any guidelines for making a product SMP/E installable ??. Yes, I've been thru the manuals but what I don't find are recommendations and or 'gotchas' ... Any advice and or direction would be appreciated. Kind Regards. Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Monday, July 22, 2013 4:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) Lizette: Well said. In the past 40+ years I have done all types of installs. SMPE in the end simplifies installation. I have frequently rejected a product just because that it is not installed via SMPE. I have seen everything from an IEBCOPY to quite complicated installation procedures. Yes it can be cumbersome to install via SMPE but every sysprog that I have worked with (except some well lets say amateur types) have generally liked SMPE(for IM) It is far easier to figure out levels of products with SMPE IMO. I have seen OEM's supply fixes with zaps (and use IDRDATA rather than SMPE) and when all is said and done the level of the product was almost always up in the air and made problem determination less straight forwardas IDRdata is not in a dump. Ed On Jul 22, 2013, at 3:46 PM, Lizette Koehler wrote: Just taking this to a new thread Personally I prefer SMP/E installs. It provides the following Ease of installation Ease of verifying Maint Levels Ease of upgrades or phase outs. When I have NON SMP/E installs they tend to be just simple IEBCOPY from here to here. Then it is up to me to ensure a way to validate what is in production, what is in test, what maintenance levels are available. There have been some NON SMP/E install products that have done a good job with the three points. But I have to make sure it is documented, my team mates can find (or use) my documentation and that the process is bullet proof. If it cannot pass the Lizette Test for bullet-proofness, then I really do not want the product in my shop. At one of my previous lives, I was supporting an OEM product that was NON-SMP/E installed. It was a nightmare. They process was a bare bones TSO XMIT install. But I had no way to very if I had the current version of software or not. It took many iterations before I found a naming convention that would at least look like it could identify what version of the product I was running in sand box and everywhere else. I think if you have one or two LPARs it is not so bad. But when you are looking at 5 or more LPARs or more than one PLEX to maintain software on, the SMP/E is a big benefit. But, if you have a solid process that covers my concerns, I may not gripe too much over a non-SMP/E install. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@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- m...@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
SMP/E conventions (was: BLKSIZE=3120)
On Mon, 22 Jul 2013 16:51:51 -0500, Tom Marchant wrote: 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: This briefly mentions tape construction, but makes no mention of packaging for network delivery. I submitted an RCF on this a couple years ago, which was received favorably, but no action is evident. I'm awaiting the z/OS 2.1 version with bated breath. o Providing useful system holds as necessary We try to. Feedback welcome. If any customer has attempted such feedback that hasn't reached me, try again. o Using Fix Categories and SOURCEID to simplify maintenance We don't. I believe Fix Categories is new; we haven't caught up. What's needed for SOURCEID? Would partitioning according to our monthly regression test cycle be of value? o Providing frequently updated downloadable Enhanced Hold data for errors We provide HOLDDATA; not Enhanced. But a customer has complained in this list that while timely it's poorly organized. We use IBM's HOLDSYS categories. o Proper SUPs for error holds when a PTF resolves the error We do. FSVO proper. Through 3 corporate ownerships we have never had a problem tracking system compatible with IBM's naming conventions, so our resolving PTFs SUP the PE SYSMOD ID, not an incident ID. This is legal according to SMP/E (although I have repeatedly needed to submit RCFs whenever an SMP/E manual inadvertently asserts otherwise.) I don't know how this is likely to work if a level-set PTF both SUPs a SYSMOD ID and uses that in an RMID operand of an element. But we've never generated such a level-set PTF. o Having a data base of APARs and PTFs that customers can search Don't know. o Cross-product dependencies (IF...REQ) where applicable We try. o It should NEVER be recommended that a customer use BYPASS(ID) or BYPASS(REQ) Our policy. Violated once by a rogue tech support person, with disastrous results. We have since reinforced the policy. o Network delivery for products and service We're a small appendage in a large corporation. Our downloadable service is simply SYSMODs with inline elements, zipped according to corporate standard. Nothing similar to ShopZ. For similar reasons our downloadable products are SMP/E RECEIVE FROMNETWORK file hierarchies, all zipped. If we tried to come closer to IBM's conventions, I imagine a network wonk's asking, FTP!? What do you want to use that old thing for? 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. I believe no vendor is capable of testing, e.g., all possible combinations of ten PTFs with no declared interactions (Cartesian product: 2**10). For major PTFs (SPEs), RESTORE is usually tested collaterally to iterative development. Minor PE PTFs are likely to be tested and go to field with no RESTORE tested. This has not been a problem. Except...: We deal with an ISV cross-compiler vendor who doesn't understand the mechanism of SMP/E RESTORE processing. I believe we've circumvented most of the problems they've introduced on this account. But I need to sit down and talk with them at length about the difficulties they're causing. This is not likely an exhaustive list. Any comments on post-APPLY link edit and script processing? We don't do this; it might simplify some processing at the cost of weaker control. Any comments on tailoring of data set names and attributes? The z/OS 2.1 symbol processing in SYSIN data sets will be a godsend for this, but only after all our customers have migrated to a z/OS level that provides such support. -- 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 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
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Mon, 22 Jul 2013 21:25:23 -0400, Robert A. Rosenberg wrote: 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). Several releases ago, at OS/390 V2R5.0 SMP/E, SMP/E introduced the Improved load module build processing, which for building _new_ load modules during _APPLY_ processing supported fetching ++MOD elements from the GLOBAL zone. Alas, it does not support such selection when updating a load module as in RESTORE, nor selecting other element types such as ++MAC from the GLOBAL zone. It's a pity that SMP/E did not follow through to provide such function as you (and I) want for greater flexibility of RESTORE. If that were done, ACCEPT would become a needless function. IBM has stated that the design objective of RESTORE is to reset objects to an ACCEPTed level; as such it performs its function admirably and needs no enhancement. You and I feel differently from IBM here. The corresponding VM facilities, VMFMERGE and VMSES/E have no requirement for a function analogous to ACCEPT. Accordingly, they provide the flexibility we'd like to see in SMP/E RESTORE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
