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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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: 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
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
