Hi Marna, I will respond in a different order. As for staying "current", yes, that would be a good idea, unfortunately, it's unrealistic to decide it has to be that way. I would imagine a very large number of sites are still running 2.1 and 2.2, in fact, I know that to be true.
Next, using CICS, DBV2 or IMS serverpac as a sample/example. There are a great many sites who do not have CICS or DB2 or IMS, I can name 30 just off the top of my head. How will they "practice"? How will they "learn the process now?" Are you penalizing them because they use Adabas or Oracle instead of DB/2 or IMS? You don't even have to answer because the only correct response is in the affirmative. Cost of two manufacturing processes? Do you know how long Serverpac and CBIPO co-existed? It was a lot longer than 6 months. Is the cost for IBM to manufacture, somehow higher than the cost of the client to install? In fact, who cares? Part of the cost of doing business is making life easier for the client. I don't remember IBM so blatantly applying unnecessary force to the client base like this. You are also assuming that systems programmers have the time to throw away to do a "test" installation in those first several months. It's patently ludicrous to expect the client base to "jump" on the upgrade in the first 6 months or completely lose the ability to install it later via a method that they are familiar with. Having said all of this, I am not disagreeing that there are advantages to the new way. I have installed CICS and DB/2 several times at several sites int he past few months alone, and have used both methods and can compare them. But no one asked me for my opinion on whether one was better than the other or if I thought people (who have not experience or very little with z/OSMF) will be able to handle the new way. I still think it's extremely short-sighted and even belligerent of IBM to make this type of decision without what seems like any thought at all for the customer(s). The installation methodology isn't supposed to be a challenge for sites in the middle of a release. The proper way to do this would be to make 2.5 Serverpac or z/OSMF, and at 2.5+x change to z/OSMF only. Splitting the method int he middle fo a release is just plain silly, and unnecessarily complex for the customer. The least you could have done was have a 2.5.1 that was the split. I can imagine asking a client, "well, you want to move to 2.5. Did you order the Serverpac or the z/OSMF version, and oh, by the way, did you install z/OSMF yet?" Has it occurred to IBM that a significant number of sites still don't have z/OSMF running (successfully)? I actually think you are serious that if they are running 2.2 that they should order 2.4 before it goes away. That's not really going to help them if they don't migrate until 2.7. If they have not moved to 2.4 by now, changing the installation method isn't going to make them jump up and order 2.4 and move to it really fast so that they can maybe go to 2.5. Sites don't operate like that. If they only migrate once every 8 years, why would they bother ordering 2.3, and 2.4 and 2.5, when they won't migrate until 2.6 or 2.7? You probably seriously think they will consider going to the interim releases. Which is the reason they only install once every 8 years now. IBM making it even more difficult is just going to exacerbate the problem. Sites are not going to migrate until they are good and ready. Actually, many of them have quite good reasons for not migrating very often. The best thing for IBM to do is pay attention to the why's of it, not ignore it. I do believe that the purpose of moving to z/OSMF based installation is to make it "easier" for the newbies, but taking something that's already pretty easy and making it "easier" is a waste of money and time. z/OSMF is just the latest iteration of IBM's attempt to replace the Systems Programmer with a "lesser being" :) Instead of providing a way to train people to understand how to do "systems programmer things", homogenizing the process to make it "seem" easier is not the way to go. I have a silly analogy-type question, that strangely enough fits this. Would you allow or condone a 5 year old operating an automatically operated "self-drive" vehicle? Sorry for the soap box-ing, but really, what were you guys thinking when you decided to switch the imple On Sun, 7 Mar 2021 09:27:55 -0600, Marna WALLE <mwa...@us.ibm.com> wrote: >Brian, >I would like to assure you that this decision was not taken lightly, and was >taken with all those considerations (and others) to extend both ordering types >for as long as was feasible. > >Some points I would like to make: > >- the z/OS ServerPac for z/OSMF is extremely similar to the CICS, Db2,and IMS >ServerPac for z/OSMF. What is different? The Workflows which contain the >configuration and verification, since they are product-specific. Where can >you see those Workflow steps today? By looking at your z/OS CustomPac dialog >JCL jobs you ran for your last z/OS installation. Those are the Workflow >steps you'll see. So the "differences" are simply the way you submit the JCL >jobs. Do you want to see how you lay down the data sets and assign them to >volumes and catalogs, and how that is different with z/OSMF vs. ISPF? Look >today at the CICS, IMS, and Db2 z/OSMF ServerPac. That is how it will be done >- with the z/OS addition that you'll be able to use (or not use) a new master >catalog, as you desire. > >- providing a "dual" method of installing the z/OS release (and other IBM >products) requires two software manufacturing processes, for existing and >every new product that GA's during that time. I'm sure I don't need to mention >that the costs of have two production processes for every product in the IBM >catalog is not insignificant. Now, that is what we are doing right now for >CICS, IMS, and Db2, so that customers can have that choice right now for the >non-z038 SREL products. It is expected that you set up and learn this process >now, so that when the z/OS SREL arrives, it is not a unknown method of >installing. Keep in mind, these "dual" paths and costs have been ongoing >since September 2019. This overlap has been going on for a while, at varying >levels for the product set. > >- As you mention, if you still want to see z/OS itself in z/OSMF ServerPac, >then order z/OS V2.5 between Sept 2021 and January 2022. Install it. Throw >it away. That would then be your "test order". That is how it will install >should you re-order z/OS V2.5 (or a later release) when you are ready to >install it. > >- You mention that the service on the ServerPac, if you keep it un-installled, >will need more PTFs. Yes, if you insist that you must install a CustomPac >ServerPac after that path is gone, it will age as any old ServerPac order will >age. This is no different than ordering a z/OS release in ServerPac before it >is end-of-marketing, putting it on the shelf, and having to install many PTFs >today. I've seen lots of customers do that for z/OS V2.3, when they were on >V2.1 and weren't ready to move yet. Always, I recommend that if your z/OS >release is still orderable and yours has aged, order another one with current >service. > >- You mention anyone running below z/OS V2.3, will have a harder path to z/OS >V2.5. I would say that anyone on V2.2 or lower, wishing to go to z/OS V2.5, >will have a harder path if they don't stay within the coexistence policy, and >are not service supported. And this has little to do with how the ServerPac >is packaged. I know you are involved in quite a few of those "long jumps" and >all of the added complications they bring since there is no coexistence >support, but I don't think that using z/OSMF to install V2.5 will be one of >those largest concerns. Many of the installation and configuration >enhancements were rolled back pre-V2.3 when they were released. I would >install all the z/OSMF PTFs on those older systems to help as much as possible >to get z/OSMF Software Management and Workflows up and running on the sandbox >driving system. That should be done right now, unless the Customized Offering >Driver (COD) is the better (and longer) path for the situation. Customers on >V2.2 should be going to V2.4, which is orderable right now - do not delay. >So, for z/OS V2.2 customers, I see no z/OSMF requirement impediment. > >-Marna WALLE >z/OS System Installation and Upgrade >IBM Poughkeepsie > > > > >- > >---------------------------------------------------------------------- >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
