Re: not using SMPe
On 17/03/2023 9:20 am, Jeremy Nicoll wrote: But doesn't the vendor already have to understand whether or not separate changes they've made to their product affect each other? In theory yes, in practice you rely a lot on the compiler to verify calls between modules etc. It's much easier to do in source code than with object modules, and in high level languages the compiler does the checking much more accurately than any other process could. Shipping exactly what you built rather than individual pieces of it is much easier and less error prone. Obviously larger thing like an operating systems have components that are updated individually, but for a moderately sized self contained application full replacement makes a lot of sense. It's also usually less work for the customer - as long as the installation is well designed so customization doesn't have to be repeated. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On Wed, 15 Mar 2023, at 23:10, Andrew Rowley wrote: > Not everyone loves chasing pre-req chains in SMP/E. Plus the > vendor needs to track it all somehow and build those chains. But doesn't the vendor already have to understand whether or not separate changes they've made to their product affect each other? Even if every successive release of a product is shipped with every potential function included, there still needs to be documentation that explains if you turn feature X on then be aware of the effects that will have on feature Y, or that features P and Q can't both be in use, or ... -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Thanks On Wednesday, March 15, 2023 at 09:15:59 PM EDT, Andrew Rowley wrote: On 16/03/2023 12:01 pm, Warren Brown wrote: > Andrew, I have been out for a while. Is there a replacement for SMPE ? > Warren There have always been ways to deliver software without using SMP/E e.g. datasets dumped to tape. As people have noted, you can also deliver what is effectively a full replacement via SMP/E. Serverpac etc. could probably be considered a non-SMP/E install, even though what you are installing is a SMP/E environment. But now, yes, there is an official IBM supported non-SM/PE installation method using a z/OSMF portable software instance. A PSI can also deliver a SMP/E environment of course. -- Andrew Rowley Black Hill Software -- 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: not using SMPe
On 16/03/2023 12:01 pm, Warren Brown wrote: Andrew, I have been out for a while. Is there a replacement for SMPE ? Warren There have always been ways to deliver software without using SMP/E e.g. datasets dumped to tape. As people have noted, you can also deliver what is effectively a full replacement via SMP/E. Serverpac etc. could probably be considered a non-SMP/E install, even though what you are installing is a SMP/E environment. But now, yes, there is an official IBM supported non-SM/PE installation method using a z/OSMF portable software instance. A PSI can also deliver a SMP/E environment of course. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Andrew, I have been out for a while. Is there a replacement for SMPE ? Warren On Wednesday, March 15, 2023 at 06:15:29 PM EDT, Andrew Rowley wrote: On 15/03/2023 8:33 am, Jay Maynard wrote: > That's because SMP/E and its power are only truly present in the z/OS and > predecessors world. Everyone else thinks of applying maintenance as a > matter of replacing the entire product, instead of individual fixes that > are automatically maintained and managed. The problem with individual fixes rather than full replacement is that it means the interface for every individually replaceable component is fixed. The relationships between all components need to be tracked, and any interface change needs corresponding pre-reqs or co-reqs for everything that uses it. That had to be done anyway when everything was coded in assembler. With high level languages it becomes much easier to do at compilation time. The compiler will find the relationships and make sure all dependent changes happen. Separate modules also limit compiler optimizations, because calls between routines are one of the common opportunities for optimization (inlining etc). It's still possible to ship individual fixes if necessary, but that is done in source code using git etc., still shipped as a full replacement. You end up with a branch or tag in git that represents the exact code that a customer is running. There is much more overhead and opportunity for error shipping individual components than full replacement. With the bandwidth etc. available now full replacement makes much more sense. -- Andrew Rowley Black Hill Software -- 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: not using SMPe
On 16/03/2023 9:33 am, Ed Jaffe wrote: Not true. It simply means if you change the (non-fixed) interface, you must re-issue all affected components. OK yes... I did say that you could change the interface with corresponding pre and co-reqs. And if you just want to change one of the dependent components, you then need to go back and install the other fix, and end up changing all the other dependencies, plus anything they pull in etc... Not everyone loves chasing pre-req chains in SMP/E. Plus the vendor needs to track it all somehow and build those chains. That said, we have been having great luck lately using ++JARUPD instead of ++JAR for many of our Java-based components and people seem to like it! OMG WTF I hadn't discovered ++JARUPD. That sounds like a terrible idea. Java is a bit of a special case because it is JIT compiled, so you do get compiler optimizations from inlining etc. But I don't see the point of partial updates to jar files. You throw away all the checking that the javac compiler did when it compiled the code, and errors are more likely to slip through and be discovered by the customer rather than in the build environment. Even more so now with JPMS, which is complex enough just building a jar file. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On 3/15/2023 3:15 PM, Andrew Rowley wrote: The problem with individual fixes rather than full replacement is that it means the interface for every individually replaceable component is fixed. Not true. It simply means if you change the (non-fixed) interface, you must re-issue all affected components. [snip] There is much more overhead and opportunity for error shipping individual components than full replacement. With the bandwidth etc. available now full replacement makes much more sense. I agree that limited bandwidth was the reason for much of the service strategy we have today. That said, we have been having great luck lately using ++JARUPD instead of ++JAR for many of our Java-based components and people seem to like it! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On 15/03/2023 8:33 am, Jay Maynard wrote: That's because SMP/E and its power are only truly present in the z/OS and predecessors world. Everyone else thinks of applying maintenance as a matter of replacing the entire product, instead of individual fixes that are automatically maintained and managed. The problem with individual fixes rather than full replacement is that it means the interface for every individually replaceable component is fixed. The relationships between all components need to be tracked, and any interface change needs corresponding pre-reqs or co-reqs for everything that uses it. That had to be done anyway when everything was coded in assembler. With high level languages it becomes much easier to do at compilation time. The compiler will find the relationships and make sure all dependent changes happen. Separate modules also limit compiler optimizations, because calls between routines are one of the common opportunities for optimization (inlining etc). It's still possible to ship individual fixes if necessary, but that is done in source code using git etc., still shipped as a full replacement. You end up with a branch or tag in git that represents the exact code that a customer is running. There is much more overhead and opportunity for error shipping individual components than full replacement. With the bandwidth etc. available now full replacement makes much more sense. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On Wed, 15 Mar 2023 09:30:33 -0700, Michael Stein wrote: >... >Then a SMP build process would build or rebuild the targets needing >changes from the current configuration to the new desired configuration. >So any PTF could be removed, at least as long as the pile of MODs still >contained the older MODs needed. > VMSES/E has some such capability. It supports successively restoring patches to any level, not obstructed by the ACCEPT operation which largely limits to one particular level. And a recent plaint here concerned SMP/E's lack of a facility to APPLY an earlier PTF completely before APPLYng a later one, except by manual intervention driven by HOLDDATA. "make" does that better. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
commenting on previous merged emails: > Yes, there are indeed Linux package managers. They don't get beyond the > "replace the entire package" level. THey have no concept of individual > fixes and their interactions. > Are they as powerful as SMP? No, but they fill a similar niche. They are more powerful than SMP (and to me scary). They run scripts as root and can do anything to your system... SMP is mostly contained, it's going to replace some modules. One thought I had a long time ago on SMP was that a slightly different design of SMP would only forward build the target libraries never save them and recopy them back from the saved version (for restore). Instead, this alternate would keep a pile of MODs, a dependency database, and a local configuration database. A new PTF or function would add MODs and dependencies. APPLY and RESTORE would adjust the local configuration database to say what modules and versions the target libraries would contain. Then a SMP build process would build or rebuild the targets needing changes from the current configuration to the new desired configuration. So any PTF could be removed, at least as long as the pile of MODs still contained the older MODs needed. Since this would require keeping may previous levels of modules and more processing I can see why this wasn't likely possible back when disks were smaller and more expensive and processors slower. As well, the real SMP back then included the old LMOD in it's links so "unknown to SMP" CSECTs didn't get lost. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On Tue, 14 Mar 2023 20:49:24 -0500, Jay Maynard wrote: >Yes, there are indeed Linux package managers. They don't get beyond the >"replace the entire package" level. THey have no concept of individual >fixes and their interactions. > There's a hazard. Customers come to fear possible collateral damage from maintenance and demand that when possible each PTF address only one issue and have no prerequisites. This leads to cafeteria-style maintenance where the customer can choose among so many configurations that it's unlikely that the supplier will have tested each. The customer risks installing an untested configuration. If one fails it reinforces the customer's ,minimalism. Regenerative maintenance phobia. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
In Linux, the package version, sub-version, and sub-sub-version level indicate maintenance level and play a role roughly analogous to highest PTF level, with each new maintenance level of a package fixing one or more numbered bug reports, which are a rough analogy to an APAR. So one package having a dependency on another package being at some minimal level is similar to requiring a dependent PTF in zOS. One big difference in the Linux world is that almost all packages are dependent on the version of the Linux operating system and are re-installed when a new Linux version is installed. The Linux world assumes interface changes are not upward compatible, requiring most packages to be rebuilt for each new Linux version, and that can include packages that would be thought of as application code in the MVS world. There is a wide disparity in Linux package complexity. Some may be a single file, others a huge number of files; but the smallest unit that can be replaced by maintenance is always an entire package. Joel C Ewing On 3/15/23 06:24, Seymour J Metz wrote: They do, however, have the concept of dependency among packages. The configuration control software that I mentioned does quite a bit more. Are they as powerful as SMP? No, but they fill a similar niche. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay Maynard [jaymayn...@gmail.com] Sent: Tuesday, March 14, 2023 9:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: not using SMPe Yes, there are indeed Linux package managers. They don't get beyond the "replace the entire package" level. THey have no concept of individual fixes and their interactions. On Tue, Mar 14, 2023 at 7:14 PM Seymour J Metz wrote: There are a lot of people using package managers in the Linux world, and a lot of software available as, e.g., deb, rpm, files. To say nothing of, e.g., cvs, git, SCCS, svn. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay Maynard [jaymayn...@gmail.com] Sent: Tuesday, March 14, 2023 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: not using SMPe That's because SMP/E and its power are only truly present in the z/OS and predecessors world. Everyone else thinks of applying maintenance as a matter of replacing the entire product, instead of individual fixes that are automatically maintained and managed. On Tue, Mar 14, 2023 at 4:22 PM Ed Jaffe wrote: SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless since they always do full product replacements. Jay Maynard -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
They do, however, have the concept of dependency among packages. The configuration control software that I mentioned does quite a bit more. Are they as powerful as SMP? No, but they fill a similar niche. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay Maynard [jaymayn...@gmail.com] Sent: Tuesday, March 14, 2023 9:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: not using SMPe Yes, there are indeed Linux package managers. They don't get beyond the "replace the entire package" level. THey have no concept of individual fixes and their interactions. On Tue, Mar 14, 2023 at 7:14 PM Seymour J Metz wrote: > There are a lot of people using package managers in the Linux world, and a > lot of software available as, e.g., deb, rpm, files. To say nothing of, > e.g., cvs, git, SCCS, svn. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Jay Maynard [jaymayn...@gmail.com] > Sent: Tuesday, March 14, 2023 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: not using SMPe > > That's because SMP/E and its power are only truly present in the z/OS and > predecessors world. Everyone else thinks of applying maintenance as a > matter of replacing the entire product, instead of individual fixes that > are automatically maintained and managed. > > On Tue, Mar 14, 2023 at 4:22 PM Ed Jaffe > wrote: > > > SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless > > since they always do full product replacements. > > > Jay Maynard > > -- > 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 > -- Jay Maynard -- 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: not using SMPe
I coined the term "stupidity above and beyond the call of duty" for such incidents. Richard Feynman (ז״ל) would have referred to it as "cargo cult systems programming". -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [0468385049d1-dmarc-requ...@listserv.ua.edu] Sent: Tuesday, March 14, 2023 10:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: not using SMPe Hi Ed, Thank you for the compliment! (Yeshiva training really pays off for arguing logically.) Now that I'm telling bank stories (this should really be a separate thread) ... At the same bank ... One day (1990), a colleague comes over and asks for help with his batch job failing. I looked at it and noticed that he was running the Sterling Forest Put Edit facility. (I had not needed to run this for several years.) I explained to him that since the advent of ++HOLD "cards", this was no longer necessary and a total waste of time. He said: "Yeah, but, the Group Leader said it had to be done." I took a deep breath and walked with him over to the Group Leader's desk. Me: "Excuse me for asking, but, why are you asking your colleague to waste time on this useless activity?" GL: "Ah ... you do not understand banking. We have always done it this way." I rolled my eyes at the TL and then promptly left. Later, when my colleague and I were out of sight and earshot of the TL, my colleague said that the TL said: "Don't talk to David anymore." (I gave this GL "Dino" as a nickname because they were busy barking orders all day long and reminded me of The Flintstones' character.) (I always say about banks (and I've worked at a bunch) that if they were even slightly intelligent, how much more they could earn for their shareholders.) Regards, David On 2023-03-14 21:44, Ed Jaffe wrote: > On 3/14/2023 6:05 PM, David Spiegel wrote: >> Hi Ed, >> I knew that there were means of ensuring integrity and that's why I >> asked the question. > > It was a brilliant question! > > His ignorance about why he should trust tape was the same reason he > distrusted the communication line. > > -- 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: not using SMPe
Hi Ed, Thank you for the compliment! (Yeshiva training really pays off for arguing logically.) Now that I'm telling bank stories (this should really be a separate thread) ... At the same bank ... One day (1990), a colleague comes over and asks for help with his batch job failing. I looked at it and noticed that he was running the Sterling Forest Put Edit facility. (I had not needed to run this for several years.) I explained to him that since the advent of ++HOLD "cards", this was no longer necessary and a total waste of time. He said: "Yeah, but, the Group Leader said it had to be done." I took a deep breath and walked with him over to the Group Leader's desk. Me: "Excuse me for asking, but, why are you asking your colleague to waste time on this useless activity?" GL: "Ah ... you do not understand banking. We have always done it this way." I rolled my eyes at the TL and then promptly left. Later, when my colleague and I were out of sight and earshot of the TL, my colleague said that the TL said: "Don't talk to David anymore." (I gave this GL "Dino" as a nickname because they were busy barking orders all day long and reminded me of The Flintstones' character.) (I always say about banks (and I've worked at a bunch) that if they were even slightly intelligent, how much more they could earn for their shareholders.) Regards, David On 2023-03-14 21:44, Ed Jaffe wrote: On 3/14/2023 6:05 PM, David Spiegel wrote: Hi Ed, I knew that there were means of ensuring integrity and that's why I asked the question. It was a brilliant question! His ignorance about why he should trust tape was the same reason he distrusted the communication line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Yes, there are indeed Linux package managers. They don't get beyond the "replace the entire package" level. THey have no concept of individual fixes and their interactions. On Tue, Mar 14, 2023 at 7:14 PM Seymour J Metz wrote: > There are a lot of people using package managers in the Linux world, and a > lot of software available as, e.g., deb, rpm, files. To say nothing of, > e.g., cvs, git, SCCS, svn. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Jay Maynard [jaymayn...@gmail.com] > Sent: Tuesday, March 14, 2023 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: not using SMPe > > That's because SMP/E and its power are only truly present in the z/OS and > predecessors world. Everyone else thinks of applying maintenance as a > matter of replacing the entire product, instead of individual fixes that > are automatically maintained and managed. > > On Tue, Mar 14, 2023 at 4:22 PM Ed Jaffe > wrote: > > > SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless > > since they always do full product replacements. > > > Jay Maynard > > -- > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On 3/14/2023 6:05 PM, David Spiegel wrote: Hi Ed, I knew that there were means of ensuring integrity and that's why I asked the question. It was a brilliant question! His ignorance about why he should trust tape was the same reason he distrusted the communication line. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Hi Ed, I knew that there were means of ensuring integrity and that's why I asked the question. Regards, David On 2023-03-14 18:52, Ed Jaffe wrote: On 3/14/2023 3:07 PM, David Spiegel wrote: I went over to the 2nd in command VM guy and asked why I would have to wait a week for delivery of a tape when it could he delivered electronically in under an hour. He had this irrational xenophobia against it and since he was the gatekeeper, his manager wouldn't budge either. I asked him to explain this M'shugaas (Yiddish for insanity) and he retorted: "Ahh ... you do not understand banking. How do you know that IBM will not flip a bit when the data is compressed/uncompressed?" I retorted: "Even if you get a tape, how do you know the the object code is intact?" He had no answer for this. Both transfer mechanisms were protected by CRC (cyclic redundancy checking)... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
There are a lot of people using package managers in the Linux world, and a lot of software available as, e.g., deb, rpm, files. To say nothing of, e.g., cvs, git, SCCS, svn. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay Maynard [jaymayn...@gmail.com] Sent: Tuesday, March 14, 2023 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: not using SMPe That's because SMP/E and its power are only truly present in the z/OS and predecessors world. Everyone else thinks of applying maintenance as a matter of replacing the entire product, instead of individual fixes that are automatically maintained and managed. On Tue, Mar 14, 2023 at 4:22 PM Ed Jaffe wrote: > SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless > since they always do full product replacements. > Jay Maynard -- 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: not using SMPe
On 3/14/2023 3:07 PM, David Spiegel wrote: I went over to the 2nd in command VM guy and asked why I would have to wait a week for delivery of a tape when it could he delivered electronically in under an hour. He had this irrational xenophobia against it and since he was the gatekeeper, his manager wouldn't budge either. I asked him to explain this M'shugaas (Yiddish for insanity) and he retorted: "Ahh ... you do not understand banking. How do you know that IBM will not flip a bit when the data is compressed/uncompressed?" I retorted: "Even if you get a tape, how do you know the the object code is intact?" He had no answer for this. Both transfer mechanisms were protected by CRC (cyclic redundancy checking)... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Hi Gil, This reminds me of a story ... I say that a lot, just ask my kids. Way back in the late late '80s, I worked at a national Canadian bank. They had been used to getting tapes from IBM when they ordered maintenance (for both VM and MVS) and would not even consider VNET compressed maintenance delivered electronically. Of course, most Canadian shops had already been getting electronic data by this time. I went over to the 2nd in command VM guy and asked why I would have to wait a week for delivery of a tape when it could he delivered electronically in under an hour. He had this irrational xenophobia against it and since he was the gatekeeper, his manager wouldn't budge either. I asked him to explain this M'shugaas (Yiddish for insanity) and he retorted: "Ahh ... you do not understand banking. How do you know that IBM will not flip a bit when the data is compressed/uncompressed?" I retorted: "Even if you get a tape, how do you know the the object code is intact?" He had no answer for this. Incidentally his manager had a well-deserved nickname "FH". (The "H" is an abbreviation for "head".) Regards, David On 2023-03-14 17:45, Paul Gilmartin wrote: On Tue, 14 Mar 2023 14:21:34 -0700, Ed Jaffe wrote: ... For such products, the value-add SMP/E provides is often just RECEIVE ORDER, but even that is dependent upon the software vendor standing up a RECEIVE ORDER server back at the "Ranch." Our sheriff deemed the MVS "Ranch" an outlaws' hideout; wouldn't tolerate RECEIVE ORDER, requiring that all product be delivered in .zip files for consistency. I packaged the SMPNTS, README.html, and JCL in the .zip. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On Tue, 14 Mar 2023 14:21:34 -0700, Ed Jaffe wrote: >... >For such products, the value-add SMP/E provides is often just RECEIVE >ORDER, but even that is dependent upon the software vendor standing up a >RECEIVE ORDER server back at the "Ranch." > Our sheriff deemed the MVS "Ranch" an outlaws' hideout; wouldn't tolerate RECEIVE ORDER, requiring that all product be delivered in .zip files for consistency. I packaged the SMPNTS, README.html, and JCL in the .zip. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
That's because SMP/E and its power are only truly present in the z/OS and predecessors world. Everyone else thinks of applying maintenance as a matter of replacing the entire product, instead of individual fixes that are automatically maintained and managed. On Tue, Mar 14, 2023 at 4:22 PM Ed Jaffe wrote: > SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless > since they always do full product replacements. > Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On 3/14/2023 5:40 AM, Bill Giannelli wrote: Just curious, is it possible and do some companies NOT use SMPe for z/OS software updates? thanks Bill The z/OSMF Portable Software Instance format does not require SMP/E. Websphere uses Installation Manager. SMP/E use for products like Java, NodeJS, Zowe, etc. is almost pointless since they always do full product replacements. For such products, the value-add SMP/E provides is often just RECEIVE ORDER, but even that is dependent upon the software vendor standing up a RECEIVE ORDER server back at the "Ranch." -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
On Tue, 14 Mar 2023 12:46:59 -0700, Tom Brennan wrote: >... >So I went back to my desk determined to map/dump the tape contents and >do the install without knowing what SMP was. About 10 minutes later I >gave up and looked for someone else to help :) > Sounds like the Good Old Days when (most) use of SMP/E didn't require RACF privileges. But we had a customer who didn't follow our instructions to RECEIVE FROMNTS but insisted on GIMUNZIP and RECEIVE from data sets. I learned this, alas, when I made a packaging error which passed our installation instructions but broke in GIMUNZIP. We apologized and asked the customer (diplomatically) to follow the instructions for the current release and I fixed it in the current release. IIRC my error was that I coded a certain option value as "0" which FROMNTS accepted where GIMUNZIP requires that the option be omitted entirely. >On 3/14/2023 11:43 AM, Seymour J Metz wrote: >> >> Yes, and it is a *VERY* bad idea. >> A User once requested" "Please package your product simply with TRANSMIT rather than SMP/E." "IBM doesn't do it that way" "Oh, yes they do. For example ..." He cited a product from a recently acquired ISV that IBM hadn't yet converted. I can't recall whether the "User" was a customer or a co-worker who wanted to simplify integration testing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Wow... I didn't think it was even possible. When I first started with MVS training I was given a few fairly easy non-SMP vendor tapes to install. All contained IEBCOPY or similar files, and install JCL I could understand. But when I got my first SMP tape, I was told to take it over to a lead sysprog for help. I still remember him saying, "Sure, I can help you with that, as soon as I finish this, and this, and that, and those..." as he pointed to various stacks of manuals, tapes, and dumps in his cubicle. So I went back to my desk determined to map/dump the tape contents and do the install without knowing what SMP was. About 10 minutes later I gave up and looked for someone else to help :) On 3/14/2023 11:43 AM, Seymour J Metz wrote: Yes, and it is a *VERY* bad idea. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Tuesday, March 14, 2023 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: not using SMPe Just curious, is it possible and do some companies NOT use SMPe for z/OS software updates? thanks Bill -- 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: not using SMPe
Yes, and it is a *VERY* bad idea. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Tuesday, March 14, 2023 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: not using SMPe Just curious, is it possible and do some companies NOT use SMPe for z/OS software updates? thanks Bill -- 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: not using SMPe
Hi Steve, Thanks for your answer! Also, more specifically, for IBM software itself. Is it possible? Or is it an IBM requirement? Just curious, as it was asked of me. Not planning on doing it without SMPe! To use IEBUPDTE IEBCOPY.you end up doing manually what SMPe does automatically in the first place! thanks Bill On Tue, 14 Mar 2023 09:13:01 -0400, Steve Thompson wrote: >On 3/14/2023 8:40 AM, Bill Giannelli wrote: >> Just curious, is it possible and do some companies NOT use SMPe for z/OS >> software updates? >> thanks >> Bill > >I take it from your question that you have software provided by >third parties and do not see an associated CSI for them? > >Yes, there are some companies that provide updates via IEBUPDTE, >and IEBCOPY, sometimes using ZAP. Don't know how many of those >are still viable today. > >Steve Thompson > >-- >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: not using SMPe
On 3/14/2023 8:40 AM, Bill Giannelli wrote: Just curious, is it possible and do some companies NOT use SMPe for z/OS software updates? thanks Bill I take it from your question that you have software provided by third parties and do not see an associated CSI for them? Yes, there are some companies that provide updates via IEBUPDTE, and IEBCOPY, sometimes using ZAP. Don't know how many of those are still viable today. Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: not using SMPe
Hi Bill, If there are companies that do this, they're certifiably insane. Imagine opening a case with IBM. The IBM person asks: "Is PTF AB12345 APPLYd?" Regards, David On 2023-03-14 08:40, Bill Giannelli wrote: Just curious, is it possible and do some companies NOT use SMPe for z/OS software updates? thanks Bill -- 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
