Re: z/OS 2.1 to 2.4 [EXTERNAL]
Until Jan 27 2020. https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/8/897/ENUS919-038/index.html=en_locale=en Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Dana Mitchell > Sent: 06 September, 2019 16:28 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Does anyone know for sure how long V2R3 will remain orderable? My guess > would be end of September 2019 when 2.4 goes GA? > > Sorry, my question was sort of buried underneath a previous reply. > > Dana > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Ahh, I see now. If you look closely a the toleration PTFs you will see that they are specific issues which do not apply to the vast majority of migrations and normally not to non-sysplex migrations at all, (excluding hardware toleration PTFs which didn't apply to the OP's question, but could indeed have caused problems depending on the hardware in use). You don't see too many software toleration ones for non-sysplex, if any at all. When you do, it's normally something that is changed in the FAR newer release which, in some intermediate release, may have had the option of disabling the change in format, but that at the "current" release no longer has that dual ability, so the solution (sometimes) was to add the capability to the older release, but when IBM decided to make life simple (for themselves) they simply decided that they would only need to support that backward toleration for a small number of releases (that's where the N+ stuff came from originally), but even that is not really well supported any more and you are risking a lot to rely on the N+ designation alone. I will grant you that you can very easily screw yourself by updating to a new release of something that changed the format of (for instance the MCDS in HSM), and then when you try to fall back, you find that you can no longer read that MCDS from the older HSM. The solution is normally not to update the MCDS at the new release, but "sometimes" it's not as straightforward as that and may even require a parameter which is no longer documented, or may no longer even be supported. That's not the case for the OP, and is actually beyond the scope of what can be covered in a forum like this, but in the case of the OP, since he is going from z/OS2.1 to z/OS 2.4, and is not even using a SYSPLEX, there is absolutely nothing for him to have to worry about. The complaint I had was when someone who appeared to have very little migration experience of the type needed to respond to the OP's question, responded anyway with some FUD that made it seem as if the poor OP (who is running a separate LPAR only (no sysplex)) would be playing with fire to attempt to "jump" to 2.4 from 2.1, (which was totally incorrect). Brian On Sun, 8 Sep 2019 20:04:11 +, Seymour J Metz wrote: >> I don't know what you are basing the historical accuracy of this on. I'm basing them on toleration PTFs that IBM has issued in the past and on IBM documentation of various migrations. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Saturday, September 7, 2019 10:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I don't know what you are basing the historical accuracy of this on. I perform these conversions literally all the time and I have not (even once) come across a fallback issue or a scenario that wasn't supported especially with respect to the OP's question. As I have stated many times, sysplex migrations are not the same as the OP is involved in, but would not necessarily be a drawback to a long jump at all. Obviously, no one is silly enough to try to add OS/390 and z/OS 2.4 to the same sysplex, there are LOTs of rules for sysplex levels and states. That's still not a problem with migrations, it's just a problem if you think you can migrate within that same sysplex. That doesn't keep you from having a second (new) sysplex that is being converted and then migrating the data from the old sysplex to the new one. It's a doable, although a slightly more complex migration that is not really any harder than a single system migration, but as you are dealing with multiple systems it will make the process a bit more complex and can take a little longer. In a scenario where sysplexes are concerned, and you want to stay within the sysplex at all times, you may indeed want or be tempted to install an interim system and migrate the individual systems within the sysplex to it, then to the final destination release. I have actually been exposed to sites that literally jumped 4 times and took 3 years and 6 to 8 people years just to stay within the sysplex, (and they still failed to get it right), and I have seen several that jumped a couple times and it worked fine (for them), but I would never have suggested that they HAD to do it that way (or "forced" them to do it my way for that matter). While you can certainly do the multi-jump, there are faster and easier ways to accomplish the jump, but as I have stated before, the OP didn't ask that question, so it's silly to discuss any details of process(es) that "might" be followed by some sites as opposed to ways that "other" sites might decide to go. I have absolutely zero issues with someone wanting to install the interim system and in essence m
Re: z/OS 2.1 to 2.4 [EXTERNAL]
> I don't know what you are basing the historical accuracy of this on. I'm basing them on toleration PTFs that IBM has issued in the past and on IBM documentation of various migrations. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Saturday, September 7, 2019 10:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I don't know what you are basing the historical accuracy of this on. I perform these conversions literally all the time and I have not (even once) come across a fallback issue or a scenario that wasn't supported especially with respect to the OP's question. As I have stated many times, sysplex migrations are not the same as the OP is involved in, but would not necessarily be a drawback to a long jump at all. Obviously, no one is silly enough to try to add OS/390 and z/OS 2.4 to the same sysplex, there are LOTs of rules for sysplex levels and states. That's still not a problem with migrations, it's just a problem if you think you can migrate within that same sysplex. That doesn't keep you from having a second (new) sysplex that is being converted and then migrating the data from the old sysplex to the new one. It's a doable, although a slightly more complex migration that is not really any harder than a single system migration, but as you are dealing with multiple systems it will make the process a bit more complex and can take a little longer. In a scenario where sysplexes are concerned, and you want to stay within the sysplex at all times, you may indeed want or be tempted to install an interim system and migrate the individual systems within the sysplex to it, then to the final destination release. I have actually been exposed to sites that literally jumped 4 times and took 3 years and 6 to 8 people years just to stay within the sysplex, (and they still failed to get it right), and I have seen several that jumped a couple times and it worked fine (for them), but I would never have suggested that they HAD to do it that way (or "forced" them to do it my way for that matter). While you can certainly do the multi-jump, there are faster and easier ways to accomplish the jump, but as I have stated before, the OP didn't ask that question, so it's silly to discuss any details of process(es) that "might" be followed by some sites as opposed to ways that "other" sites might decide to go. I have absolutely zero issues with someone wanting to install the interim system and in essence migrate twice, it's their life, they should use it up whatever way they want. My issues come when someone tells an OP that it absolutely MUST be done that way or scare them with the "or bad things could happen" type of warnings. Maybe you are confusing a migration with some sort of scenario where you think you will pick up your old OS/390 JES2 spool and checkpoint dataset(s) and try to use them under z/OS 2.4. Obviously that is not going to work and certainly would not work falling back to OS/390. The migration and fallback process for this is normally to offload the data and reload it when you go one way or the other, you can also (often) just NJE the data back and forth (assuming both systems are active), but the important thing is that you work this stuff out ahead of time, and installing another operating system level is rarely (if ever) going to be necessary or even provide you with a way to do it. In most cases, when you aren't in a sysplex, there is very little to be worried about (data sharing-wise). Just because you can't share something like the JES2 checkpoint or the spool itself is not a drawback or a failure in a migration, it's just something that you have to plan for and handle. Sometimes, (keeping with the JES scenario) if you are falling back far enough, there is no way to reload the data back to the spool. In a situation such as that, it's extremely easy to offload the data to some other medium other than the standard JES offload format (a writer for instance), or merely make sure whatever is in the spool when you leave is something that you no longer want or need to keep. Conversions (as opposed to migrations) have a similar set of issues. For instance, if you are using Adabas 7 and are running OS/390, you might want to install Adabas 8 when you install z/OS 2.4, and go through that conversion. Some people have that as an objective, some don't as they are happy to stay with Adabas 7 (for now). That's something that the individual will need to deal with when they build their plan. Is it "better" to convert to Adabas 8, sure it is, is it necessary, "no", is it a good idea, you bet, but it's an optional thing, not something that is necessarily forced on the site just because some guy on IBM-MAIN said that you MUST co
Re: z/OS 2.1 to 2.4 [EXTERNAL]
I don't know what you are basing the historical accuracy of this on. I perform these conversions literally all the time and I have not (even once) come across a fallback issue or a scenario that wasn't supported especially with respect to the OP's question. As I have stated many times, sysplex migrations are not the same as the OP is involved in, but would not necessarily be a drawback to a long jump at all. Obviously, no one is silly enough to try to add OS/390 and z/OS 2.4 to the same sysplex, there are LOTs of rules for sysplex levels and states. That's still not a problem with migrations, it's just a problem if you think you can migrate within that same sysplex. That doesn't keep you from having a second (new) sysplex that is being converted and then migrating the data from the old sysplex to the new one. It's a doable, although a slightly more complex migration that is not really any harder than a single system migration, but as you are dealing with multiple systems it will make the process a bit more complex and can take a little longer. In a scenario where sysplexes are concerned, and you want to stay within the sysplex at all times, you may indeed want or be tempted to install an interim system and migrate the individual systems within the sysplex to it, then to the final destination release. I have actually been exposed to sites that literally jumped 4 times and took 3 years and 6 to 8 people years just to stay within the sysplex, (and they still failed to get it right), and I have seen several that jumped a couple times and it worked fine (for them), but I would never have suggested that they HAD to do it that way (or "forced" them to do it my way for that matter). While you can certainly do the multi-jump, there are faster and easier ways to accomplish the jump, but as I have stated before, the OP didn't ask that question, so it's silly to discuss any details of process(es) that "might" be followed by some sites as opposed to ways that "other" sites might decide to go. I have absolutely zero issues with someone wanting to install the interim system and in essence migrate twice, it's their life, they should use it up whatever way they want. My issues come when someone tells an OP that it absolutely MUST be done that way or scare them with the "or bad things could happen" type of warnings. Maybe you are confusing a migration with some sort of scenario where you think you will pick up your old OS/390 JES2 spool and checkpoint dataset(s) and try to use them under z/OS 2.4. Obviously that is not going to work and certainly would not work falling back to OS/390. The migration and fallback process for this is normally to offload the data and reload it when you go one way or the other, you can also (often) just NJE the data back and forth (assuming both systems are active), but the important thing is that you work this stuff out ahead of time, and installing another operating system level is rarely (if ever) going to be necessary or even provide you with a way to do it. In most cases, when you aren't in a sysplex, there is very little to be worried about (data sharing-wise). Just because you can't share something like the JES2 checkpoint or the spool itself is not a drawback or a failure in a migration, it's just something that you have to plan for and handle. Sometimes, (keeping with the JES scenario) if you are falling back far enough, there is no way to reload the data back to the spool. In a situation such as that, it's extremely easy to offload the data to some other medium other than the standard JES offload format (a writer for instance), or merely make sure whatever is in the spool when you leave is something that you no longer want or need to keep. Conversions (as opposed to migrations) have a similar set of issues. For instance, if you are using Adabas 7 and are running OS/390, you might want to install Adabas 8 when you install z/OS 2.4, and go through that conversion. Some people have that as an objective, some don't as they are happy to stay with Adabas 7 (for now). That's something that the individual will need to deal with when they build their plan. Is it "better" to convert to Adabas 8, sure it is, is it necessary, "no", is it a good idea, you bet, but it's an optional thing, not something that is necessarily forced on the site just because some guy on IBM-MAIN said that you MUST convert to Adabas8 when you run z/OS 2.4 because allowuserkeycsa(yes) is no longer supported. There is a LOT of FUD in our profession, and it's better to look at all options before you make sweeping statements that will cause people a lot of extra work that they may not want to do or be prepared to do. Just because you believe your opinion on something is right doesn't make you right, it's just an opinion. My opinion is that you don't need to do multiple jumps, but that doesn't mean that EVERYONE must never to a
Re: z/OS 2.1 to 2.4 [EXTERNAL]
You didn't quote the context, so I don't know what the OP's environment was, but there have, historically, been DASD fallback issues both within and between sysplexes. Has there been a JES level set in z/OS V2 that changed the checkpoint or SPOOL structure automatically rather than upon explicit request, e.g., $ACTIVATE, $T, $T CKPTDEF, $T SPOOLDEF? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Friday, September 6, 2019 6:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Not between 2.1 and 2.4. The incompatibilities are between JES level sets. Those kinds of problems (when things are actively shared through the sysplex) are where being a sysplex can make a difference, the solution in those cases is that you end up with two sysplexes for the duration of your conversion. The basic process still remains about the same for a long jump with a sysplex and one without, it's just a bit more complex because as you are populating the new sysplex, you are depopulating the old one. In this case though, the OP is in LPAR mode with (maybe or maybe not) shared resources (DASD, tapes, etc,) but not a sysplex. The issue came up when someone, who should have known better, stepped in and suggested that if they did not install an intermediate release (i.e. 2.2 or 2.3) that they could be asking for trouble. The suggestion was ludicrous. Brian -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
Not between 2.1 and 2.4. The incompatibilities are between JES level sets. Those kinds of problems (when things are actively shared through the sysplex) are where being a sysplex can make a difference, the solution in those cases is that you end up with two sysplexes for the duration of your conversion. The basic process still remains about the same for a long jump with a sysplex and one without, it's just a bit more complex because as you are populating the new sysplex, you are depopulating the old one. In this case though, the OP is in LPAR mode with (maybe or maybe not) shared resources (DASD, tapes, etc,) but not a sysplex. The issue came up when someone, who should have known better, stepped in and suggested that if they did not install an intermediate release (i.e. 2.2 or 2.3) that they could be asking for trouble. The suggestion was ludicrous. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
You are mixing a problem that can happen from adding a single APAR at any time. It's not really applicable to the length of the (long or short) JUMP. A stand alone LPAR (which this OP has) is not going to be incompatible in a way that makes installing an intermediate level make any sense. Even in your case, it was something that you accidentally added to the new system without first having that support on the old system. Unfortunately it can happen, but that's what the migration guide(s) and due diligence are for, and sometimes even that can get rained on by IBM. I didn't say that they guy should blindly jump into the newer release without making sure that he addressed all of the changes. In your case, it really didn't have anything to do with the length of the migration jump (i.e. N+anything), and it's unfortunate, but that kind of thing can happen just putting on next month's put tape or the next RSU. It's something that you have to be wary of, but installing a intermediate operating system between 2.1 and 2.4 would not have changed the outcome of your problem in any way. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
It's not recent, but there have been changes in, e.g., catalog, SPOOL, that had toleration issues. In some cases, e.g., SPOOL, the new formats were not used until the installation explicitly activated them. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Brian Westerman Sent: Friday, September 6, 2019 3:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Well, you know what they say about assumptions. That definitely applies to your assumptions here. How did you get into ACM, did you buy a membership or something?:) I really don't mean to sound flippant or like I'm trying to degrade your abilities or anything, but you don't seriously believe all that stuff you wrote, do you? There hasn't been a totally incompatible dataset level change sent out for a good many years, and by that I actually mean so far this millennium), and IBM is not about to change that kind of thing in a simple release change. Something like that would result in a version change at the very least if not a complete OS name change. Remember that this op is converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible exception of ISAM and some old DL/1 structures that would have to be addressed ahead of time even that conversion is doable if you discard the processor change necessary and only count the data. Did you possibly forget that one of the things that sets the IBM mainframe apart from everything else is the VERY long pedigree of backwards compatibility? The whole idea of the way IBM manages z/OS is not going to be placed at jeopardy, just because they want to come out with a new dot.release. :) If it was meant to "scare" the OP into going through a completely unnecessary installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. Almost everything you said was (at best) unwarranted. It was almost like reading something in one of those "this is an example of fake news" sites. If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the dasd. I should know, I still do conversions for people from OS/390 to z/OS 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle the two systems at the same time, the dasd and the datasets do. Doing "long jump" migrations is almost always a hardware issue, not a software or dataset issue. If you want to perform unnecessary installations on your time at your site, that's completely up to you, but when someone asks a serious question and you come up with a bunch of FUD, it just serves to undermine what I thought was supposed to be the purpose of this site, which I had thought was to provide a forum for people to get help and exchange ideas, not to try to scare them with half baked assumptions and leading questions which seem to be written solely for no useful purpose. I am positive that I have likely performed more long jump conversions than you, and I would be willing to bet that I have performed in just the past two years more operating systems conversions period, than you have performed in your entire professional life as a systems programmer, if you even are one, which based on your response I'm not quite certain of. While doing a lot of migrations and conversions doesn't make me perfect, it does mean that I am (a lot) less likely to be wrong about this than you are. Again, I know it sounds harsh, but this is one of my hot buttons. When people try to talk about IBM's N+ "suggestion" as if it's anything other than that, "a suggestion". About 10% of the long jump migrations I have performed were done through IBM for their client sites, not for any of our existing clients. I have yet to have a failure to complete a migration on time and as promised. Again, I'm very sorry if I have insulted you in any way, that was not my intention, but I am really and truly surprised at the lack of restraint and knowledge about what is involved in a conversion or migration or even in simply sharing dasd and other resources shown in your response. So, please excuse my harsh response, but I didn't want the OP to think that you knew anything about what you were saying. While you did phrase everything as if you were merely trying to point out possibilities that I may have overlooked, you were just so far from correct that I could not allow it to go UN-commented upon. Sorry, Brian -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
https://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?q45=Z497063S01245B61~B227540X25949K69~Z966844T77753Y85 z/OS 2.2 Available Sep 30 2015, End of Marketing Jan 29 2018 End of Service Sep 30 2020. z/OS 2.1 was 2 years earlier. z/OS 2.3 was / should be 2 years later. z/OS 2.4 should be 4 years later. So z/OS 2.3 should be orderable for 2019 and most of Jan 2020. On Fri, Sep 6, 2019 at 2:39 PM Carmen Vitullo wrote: > > I believe this link is still valid > > > > > https://www.ibm.com/support/home/pages/lifecycle/?from=index_a > > > > > > > > Carmen Vitullo > > - Original Message - > > From: "Dana Mitchell" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Friday, September 6, 2019 9:27:55 AM > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Does anyone know for sure how long V2R3 will remain orderable? My guess would > be end of September 2019 when 2.4 goes GA? > > Sorry, my question was sort of buried underneath a previous reply. > > Dana > > -- > 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 -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
Carmen, It does not show an End of Marketing date for z/OS 2.3 nor an end of support. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, September 06, 2019 10:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I believe this link is still valid https://www.ibm.com/support/home/pages/lifecycle/?from=index_a Carmen Vitullo - Original Message - From: "Dana Mitchell" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, September 6, 2019 9:27:55 AM Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
I believe this link is still valid https://www.ibm.com/support/home/pages/lifecycle/?from=index_a Carmen Vitullo - Original Message - From: "Dana Mitchell" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, September 6, 2019 9:27:55 AM Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
I have not checked, but that is consistent with prior IBM practices. If you want z/OS 2.3 order immediately! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dana Mitchell Sent: Friday, September 6, 2019 9:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Probably somewhere around then. If you need it, just order it. Even if you never use it. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dana Mitchell Sent: Friday, September 6, 2019 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Does anyone know for sure how long V2R3 will remain orderable? My guess would be end of September 2019 when 2.4 goes GA? Sorry, my question was sort of buried underneath a previous reply. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Brian, So I get the fervor, but might be a little harsh? By "dataset", not sure he was talking about dataset structure, but maybe the contents of any dataset. For example, and this happened to me, and this all happened within the same z/OS release, but would just as easily occur on a z/OS long jump with no easy way to go back...A year ago, due to SNAFU with IBM hold data being incorrect for certain DFSMSHSM maintenance, a conditioning/toleration PTF was missed. The feature "enabling" PTF was IPL'd into one of systems in the sysplex that shares the HSM CDS's which happily started writing new format data into the CDS. Wasn’t noticed until the next day when data that was migrated on that updated system could not be recalled on a down leveled system, and HSM was taking errors/dumps. This is just one example In the long jump scenario, that if the need to fall back were to be utilized, HSM functions would be broken. And if HSM was the one doing the CDS backup's recovery of those might be a problem too. This is just one real life example, there could be many more. There is a *risk* of doing the long jump, mostly with regards to ability to fall back, and being honest, in all my years, we have had to fall back maybe one time.Best advice is don’t get into a position where you are out of support. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Friday, September 6, 2019 3:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Well, you know what they say about assumptions. That definitely applies to your assumptions here. How did you get into ACM, did you buy a membership or something?:) I really don't mean to sound flippant or like I'm trying to degrade your abilities or anything, but you don't seriously believe all that stuff you wrote, do you? There hasn't been a totally incompatible dataset level change sent out for a good many years, and by that I actually mean so far this millennium), and IBM is not about to change that kind of thing in a simple release change. Something like that would result in a version change at the very least if not a complete OS name change. Remember that this op is converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible exception of ISAM and some old DL/1 structures that would have to be addressed ahead of time even that conversion is doable if you discard the processor change necessary and only count the data. Did you possibly forget that one of the things that sets the IBM mainframe apart from everything else is the VERY long pedigree of backwards compatibility? The whole idea of the way IBM manages z/OS is not going to be placed at jeopardy, just because they want to come out with a new dot.release. :) If it was meant to "scare" the OP into going through a completely unnecessary installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. Almost everything you said was (at best) unwarranted. It was almost like reading something in one of those "this is an example of fake news" sites. If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the dasd. I should know, I still do conversions for people from OS/390 to z/OS 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle the two systems at the same time, the dasd and the datasets do. Doing "long jump" migrations is almost always a hardware issue, not a software or dataset issue. If you want to perform unnecessary installations on your time at your site, that's completely up to you, but when someone asks a serious question and you come up with a bunch of FUD, it just serves to undermine what I thought was supposed to be the purpose of this site, which I had thought was to provide a forum for people to get help and exchange ideas, not to try to scare them with half baked assumptions and leading questions which seem to be written solely for no useful purpose. I am positive that I have likely performed more long jump conversions than you, and I would be willing to bet that I have performed in just the past two years more operating systems conversions period, than you have performed in your entire professional life as a systems programmer, if you even are one, which based on your response I'm not quite certain of. While doing a lot of migrations and conversions doesn't make me perfect, it does mean that I am (a
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Two DASD incompatibilities I know of from OS/390. Dropping ISAM and adding EAVs DSCBs to the VTOC. PDSE V2 I'm not sure of. Possibly the various extended attributes. Drop the ISAM first and don't use the new facilities until you are certain you don't need to go back. On Fri, Sep 6, 2019 at 7:41 AM Brian Westerman wrote: > > Well, you know what they say about assumptions. That definitely applies to > your assumptions here. How did you get into ACM, did you buy a membership or > something?:) > > I really don't mean to sound flippant or like I'm trying to degrade your > abilities or anything, but you don't seriously believe all that stuff you > wrote, do you? There hasn't been a totally incompatible dataset level change > sent out for a good many years, and by that I actually mean so far this > millennium), and IBM is not about to change that kind of thing in a simple > release change. Something like that would result in a version change at the > very least if not a complete OS name change. Remember that this op is > converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS > 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible > exception of ISAM and some old DL/1 structures that would have to be > addressed ahead of time even that conversion is doable if you discard the > processor change necessary and only count the data. Did you possibly forget > that one of the things that sets the IBM mainframe apart from everything else > is the VERY long pedigree of backwards compatibility? > > The whole idea of the way IBM manages z/OS is not going to be placed at > jeopardy, just because they want to come out with a new dot.release. :) > > If it was meant to "scare" the OP into going through a completely unnecessary > installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. > Almost everything you said was (at best) unwarranted. It was almost like > reading something in one of those "this is an example of fake news" sites. > > If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the > dasd. I should know, I still do conversions for people from OS/390 to z/OS > 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle > the two systems at the same time, the dasd and the datasets do. Doing "long > jump" migrations is almost always a hardware issue, not a software or dataset > issue. > > If you want to perform unnecessary installations on your time at your site, > that's completely up to you, but when someone asks a serious question and you > come up with a bunch of FUD, it just serves to undermine what I thought was > supposed to be the purpose of this site, which I had thought was to provide a > forum for people to get help and exchange ideas, not to try to scare them > with half baked assumptions and leading questions which seem to be written > solely for no useful purpose. > > I am positive that I have likely performed more long jump conversions than > you, and I would be willing to bet that I have performed in just the past two > years more operating systems conversions period, than you have performed in > your entire professional life as a systems programmer, if you even are one, > which based on your response I'm not quite certain of. While doing a lot of > migrations and conversions doesn't make me perfect, it does mean that I am (a > lot) less likely to be wrong about this than you are. > > Again, I know it sounds harsh, but this is one of my hot buttons. When > people try to talk about IBM's N+ "suggestion" as if it's anything other than > that, "a suggestion". About 10% of the long jump migrations I have performed > were done through IBM for their client sites, not for any of our existing > clients. I have yet to have a failure to complete a migration on time and as > promised. > > Again, I'm very sorry if I have insulted you in any way, that was not my > intention, but I am really and truly surprised at the lack of restraint and > knowledge about what is involved in a conversion or migration or even in > simply sharing dasd and other resources shown in your response. > > So, please excuse my harsh response, but I didn't want the OP to think that > you knew anything about what you were saying. While you did phrase > everything as if you were merely trying to point out possibilities that I may > have overlooked, you were just so far from correct that I could not allow it > to go UN-commented upon. > > Sorry, > > Brian > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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,
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Well, you know what they say about assumptions. That definitely applies to your assumptions here. How did you get into ACM, did you buy a membership or something?:) I really don't mean to sound flippant or like I'm trying to degrade your abilities or anything, but you don't seriously believe all that stuff you wrote, do you? There hasn't been a totally incompatible dataset level change sent out for a good many years, and by that I actually mean so far this millennium), and IBM is not about to change that kind of thing in a simple release change. Something like that would result in a version change at the very least if not a complete OS name change. Remember that this op is converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible exception of ISAM and some old DL/1 structures that would have to be addressed ahead of time even that conversion is doable if you discard the processor change necessary and only count the data. Did you possibly forget that one of the things that sets the IBM mainframe apart from everything else is the VERY long pedigree of backwards compatibility? The whole idea of the way IBM manages z/OS is not going to be placed at jeopardy, just because they want to come out with a new dot.release. :) If it was meant to "scare" the OP into going through a completely unnecessary installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. Almost everything you said was (at best) unwarranted. It was almost like reading something in one of those "this is an example of fake news" sites. If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the dasd. I should know, I still do conversions for people from OS/390 to z/OS 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle the two systems at the same time, the dasd and the datasets do. Doing "long jump" migrations is almost always a hardware issue, not a software or dataset issue. If you want to perform unnecessary installations on your time at your site, that's completely up to you, but when someone asks a serious question and you come up with a bunch of FUD, it just serves to undermine what I thought was supposed to be the purpose of this site, which I had thought was to provide a forum for people to get help and exchange ideas, not to try to scare them with half baked assumptions and leading questions which seem to be written solely for no useful purpose. I am positive that I have likely performed more long jump conversions than you, and I would be willing to bet that I have performed in just the past two years more operating systems conversions period, than you have performed in your entire professional life as a systems programmer, if you even are one, which based on your response I'm not quite certain of. While doing a lot of migrations and conversions doesn't make me perfect, it does mean that I am (a lot) less likely to be wrong about this than you are. Again, I know it sounds harsh, but this is one of my hot buttons. When people try to talk about IBM's N+ "suggestion" as if it's anything other than that, "a suggestion". About 10% of the long jump migrations I have performed were done through IBM for their client sites, not for any of our existing clients. I have yet to have a failure to complete a migration on time and as promised. Again, I'm very sorry if I have insulted you in any way, that was not my intention, but I am really and truly surprised at the lack of restraint and knowledge about what is involved in a conversion or migration or even in simply sharing dasd and other resources shown in your response. So, please excuse my harsh response, but I didn't want the OP to think that you knew anything about what you were saying. While you did phrase everything as if you were merely trying to point out possibilities that I may have overlooked, you were just so far from correct that I could not allow it to go UN-commented upon. Sorry, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Since no one else has said it, aren't you are forgetting your entire DASD farm with all its system control block structures embedded within VTOCs, VVDSs, Catalogs, JES datasets, and some other individual data sets? DASD "Sharing" doesn't just have to be within a sysplex, because sharing doesn't have to be concurrent. Does IBM now guarantee that any changes to these DASD-resident structures are down-level compatible with all prior releases of z/OS with no toleration PTFs even required, or does this only apply if you are within a supported upgrade jump? If toleration PTFs are required, what does this say about system versions no longer supported for maintenance? You IPL all your processors with back-level versions of z/OS after your DASD has been touched by a later version system, then you are sharing all those structures between those two versions of z/OS, even if not concurrently, whether you run a sysplex or not. Perhaps it takes a deliberate use of new features to force an incompatibility, perhaps not. Maybe some change or update could occur just by putting a volume online or opening a data set from the new system, maybe not. One would certainly hope such compatibility issues would be prominently discussed in the migration documentation for one of the later versions of z/OS, but just because these are rare occurrences doesn't mean it shouldn't be a concern and at least researched. My assumption was always if you go beyond a "supported" jump, IBM doesn't test those scenarios and you are on your own. Perhaps you are familiar enough with z/OS 2.1 through 2.4 to be confident there are DASD-resident control block issues with such a jump, but you seem to be implying that without a sysplex, arbitrary z/OS level jumps could have no compatibility concerns and compatibility research is irrelevant. That certainly has not been true in the past. Joel C. Ewing On 9/4/19 1:23 AM, Brian Westerman wrote: > why? He said that there is no sysplex involved, just what is it that he > would not be compatible with in a fall back scenario between 2.1 and 2.4? > You would be pretty hard pressed to find something that would cause them an > issue, so long as the hardware is compatible with 2.4 they are good to go. I > also believe in being prepared for anything, but there are some things that > are a waste of time. If he were running a sysplex, even then he would > "probably" still be okay, but it's not an issue for him to even have to think > about. > > Brian > > > -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
SMPE with current HOLDDATA received: REPORT MISSINGFIX ZONES() FIXCAT( IBM.Coexistence.z/OS.V2R2, IBM.Coexistence.z/OS.V2R3). Does anyone know for sure how long V2R3 is orderable? My guess would be end of September 2019 when 2.4 is GA? Dana On Fri, 30 Aug 2019 17:19:57 +, David Spiegel wrote: >Hi Paul, >The buzzword you are hinting at is called "Toleration Maintenance". > >Regards, >David > >On 2019-08-30 12:39, Feller, Paul wrote: >> Sorry if my wording was off a little. But yes the idea is to apply any z/OS >> 2.1 fixes needed related to support of z/OS 2.3. That would get you nearer >> to a system that might allow for fall back from z/OS 2.4. I'm sure IBM >> would suggest a two step approach. Install z/OS 2.3 as soon as possible and >> then go to z/OS 2.4 later. >> >> Thanks.. >> >> Paul Feller >> AGT Mainframe Technical Support >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
why? He said that there is no sysplex involved, just what is it that he would not be compatible with in a fall back scenario between 2.1 and 2.4? You would be pretty hard pressed to find something that would cause them an issue, so long as the hardware is compatible with 2.4 they are good to go. I also believe in being prepared for anything, but there are some things that are a waste of time. If he were running a sysplex, even then he would "probably" still be okay, but it's not an issue for him to even have to think about. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: z/OS 2.1 to 2.4 [EXTERNAL]
ASM, in this context anyway, likely refers to the Natural Authorized Services Manager, which I believe (I've been out of SAG product support for many years now) is shipped in base mainframe Natural. Rather than starting yet more SAG address spaces though, I would convert the Natural Global BP to Local BPs. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Saturday, August 31, 2019 11:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: z/OS 2.1 to 2.4 [EXTERNAL] ASM is Adabas Parallel Services, I'm not sure why they didn't call it APS, but possibly they already had one by that name. ASM provides Compression, decompression, format buffer translation, sorting, retrieving, searching and updating operations all occur in parallel. So it gives better distribution of your workload across the available processors. You might already be running it and just don't know it, or just don't have the extra address space running that Natural will need. Brian -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
To the OP. I will concur with the earlier recommendation to (at least) order z/OS 2.3. Just in case. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 30, 2019 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Is there a mnemonic PGMNAME for that? Thanks, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Brian Westerman To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/09/2019 05:10 Subject:Re: z/OS 2.1 to 2.4 [EXTERNAL] Sent by:IBM Mainframe Discussion List ASM is Adabas Parallel Services, I'm not sure why they didn't call it APS, but possibly they already had one by that name. ASM provides Compression, decompression, format buffer translation, sorting, retrieving, searching and updating operations all occur in parallel. So it gives better distribution of your workload across the available processors. You might already be running it and just don't know it, or just don't have the extra address space running that Natural will need. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
ASM is Adabas Parallel Services, I'm not sure why they didn't call it APS, but possibly they already had one by that name. ASM provides Compression, decompression, format buffer translation, sorting, retrieving, searching and updating operations all occur in parallel. So it gives better distribution of your workload across the available processors. You might already be running it and just don't know it, or just don't have the extra address space running that Natural will need. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Thank you to Brian and others. I am OOO next week. We are actually pretty current on EntireX. I thought I knew all SAG products, but ASM isn't one I remember. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Friday, August 30, 2019 10:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Yes, you need to have current maintenance on your old 2.1 system, but your > ability to fall back based on what you have stated in your response makes it > so that your fallback (if necessary) will not be an issue for you. Depending > on > your product mix, I think that SAG might have a simple work around for you > for allowusekeycsa(yes), and so long as you are using the Version 8 SVC > (which still supports version 7 Adabas products like cluster services and > parallel services) you will be okay for all but a small number of products. > There are some products that you will have to update but they are likely > minor in your case (older EntireX Brokers), at least they should be because > very little depends on the actual release of the broker. There are some > special PPT entries you have to perform as well that depend on your > products, but there is an SAG page that tell you all of them. > > The only problem you will hit is with Natural, which needs to be at 4.2.4 to > not need the allowuserkeycsa(yes), this will require SAG's ASM to do this, > but I think it's free. > > I have performed several upgrades to old levels of Adabas (back to version > 7.1) for just the Natural component, and they are truly dead simple, and if > done correctly won't require you to recatalog everything in the natural > libraries either (at least not manually depending on how far back you are). > Plus, again with proper planning, you have a fallback that you can implement > within a few minutes. Remember if you upgrade Natural, you still have to > install ASM. The suggested solution SAG is to install ASM Authorized Services > Manager with all versions of Natural that use the older buffer pools and want > to convert to allowuserkeycsa(no). > > Brian > > -- > 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: z/OS 2.1 to 2.4 [EXTERNAL]
Yes, you need to have current maintenance on your old 2.1 system, but your ability to fall back based on what you have stated in your response makes it so that your fallback (if necessary) will not be an issue for you. Depending on your product mix, I think that SAG might have a simple work around for you for allowusekeycsa(yes), and so long as you are using the Version 8 SVC (which still supports version 7 Adabas products like cluster services and parallel services) you will be okay for all but a small number of products. There are some products that you will have to update but they are likely minor in your case (older EntireX Brokers), at least they should be because very little depends on the actual release of the broker. There are some special PPT entries you have to perform as well that depend on your products, but there is an SAG page that tell you all of them. The only problem you will hit is with Natural, which needs to be at 4.2.4 to not need the allowuserkeycsa(yes), this will require SAG's ASM to do this, but I think it's free. I have performed several upgrades to old levels of Adabas (back to version 7.1) for just the Natural component, and they are truly dead simple, and if done correctly won't require you to recatalog everything in the natural libraries either (at least not manually depending on how far back you are). Plus, again with proper planning, you have a fallback that you can implement within a few minutes. Remember if you upgrade Natural, you still have to install ASM. The suggested solution SAG is to install ASM Authorized Services Manager with all versions of Natural that use the older buffer pools and want to convert to allowuserkeycsa(no). Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
I will have all available (and RSU,IBM or Hiper) maintenance on. And, yes fallback is one of my larger concerns. One of my least favorite memories from the early 90s is standalone restore of catalog and SMS control dataset volumes between failed IPLs without proper fallback PTFs on. I think we were making a large jump to MVS/ESA 2.5, but I won't swear to that. Actual SLED and the 3090 took 40 minutes to IPL after and before each failure. It was quite the learning experience and I've tried to do things "right" ever since. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Pommier, Rex > Sent: Friday, August 30, 2019 8:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Tom, > > The idea is to apply 2.1 maintenance that would make 2.1 compatible with > 2.3. Since IBM won't release 2.4 compatibility maintenance for 2.1, if > there's > some that would make 2.1 co-exist with 2.3, that might make it easier for the > OP to make the jump from 2.1 to 2.4. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Marchant > Sent: Friday, August 30, 2019 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: > > Would it be a good thing to at least try to get any z/OS 2.3 compatibility > maintenance applied? > > What does that mean to someone who is running z/OS 2.1? > You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not > the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received > this communication in error, please notify us immediately by replying to this > message and destroy the material in its entirety, whether in electronic or > hard copy format. Thank you. > > > -- > 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: z/OS 2.1 to 2.4 [EXTERNAL]
Hi Paul, The buzzword you are hinting at is called "Toleration Maintenance". Regards, David On 2019-08-30 12:39, Feller, Paul wrote: > Sorry if my wording was off a little. But yes the idea is to apply any z/OS > 2.1 fixes needed related to support of z/OS 2.3. That would get you nearer > to a system that might allow for fall back from z/OS 2.4. I'm sure IBM would > suggest a two step approach. Install z/OS 2.3 as soon as possible and then > go to z/OS 2.4 later. > > Thanks.. > > Paul Feller > AGT Mainframe Technical Support > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pommier, Rex > Sent: Friday, August 30, 2019 10:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > Tom, > > The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3. > Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's > some that would make 2.1 co-exist with 2.3, that might make it easier for the > OP to make the jump from 2.1 to 2.4. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Tom Marchant > Sent: Friday, August 30, 2019 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] > > On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: > > Would it be a good thing to at least try to get any z/OS 2.3 compatibility > maintenance applied? > > What does that mean to someone who is running z/OS 2.1? > You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > -- > 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: z/OS 2.1 to 2.4 [EXTERNAL]
Sorry if my wording was off a little. But yes the idea is to apply any z/OS 2.1 fixes needed related to support of z/OS 2.3. That would get you nearer to a system that might allow for fall back from z/OS 2.4. I'm sure IBM would suggest a two step approach. Install z/OS 2.3 as soon as possible and then go to z/OS 2.4 later. Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, August 30, 2019 10:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] Tom, The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3. Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's some that would make 2.1 co-exist with 2.3, that might make it easier for the OP to make the jump from 2.1 to 2.4. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 30, 2019 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: z/OS 2.1 to 2.4 [EXTERNAL]
Tom, The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3. Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's some that would make 2.1 co-exist with 2.3, that might make it easier for the OP to make the jump from 2.1 to 2.4. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 30, 2019 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote: Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? What does that mean to someone who is running z/OS 2.1? You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 to 2.4 [EXTERNAL]
Would there be any concerns with internal changes to system dataset structures? As an example like catalogs or things like HSM CDS datasets? Going from z/OS 2.1 to z/OS 2.4 is technically not support for fallback. Would it be a good thing to at least try to get any z/OS 2.3 compatibility maintenance applied? That might get you nearer to a level that could help if you had to fallback. From the z/OS Planning for Installation manual for z/OS 2.4 z/OS V2R4 is supported for coexistence, fallback, and upgrade with the following z/OS® releases: z/OS V2R4, V2R3, and V2R2. This means that: •Coexistence of a z/OS V2R4 system with a V2R3 and V2R2 system is supported. •Fallback from a z/OS V2R4 system to a V2R3 or V2R2 system is supported. •Upgrade to a z/OS V2R4 system from a V2R3 or V2R2 system is supported. Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Friday, August 30, 2019 5:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL] I would ask they cover your cost for this as part of their product, since they are the only product you use that needs it. On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > This is the first I have seen this! That is good news. We have one > particular Financial Business application, written/distributed by outside > vendor that I have been bugging now since I put V2.3 in almost 2 years ago to > remediate. They still have not yet remediated there code, and I was > thinking this was going to hold up my implementation. > > __ > ___ > Dave Jousma > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > Rapids, MI 49546 > 616.653.8429 | fax: 616.653.2717 > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOP NM) - KLM > Sent: Friday, August 30, 2019 4:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 to 2.4 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > IBM has a payed feature called Restricted Use CSA, that allows you to keep > your applics with userkeycsa running in 2.4. > Check OA56180. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave > > Sent: 30 August, 2019 10:06 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 to 2.4 > > > > Just monoplexes. Some limited sharing of DASD. Not even GRS. > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. > > Our Natural Global Buffer Pool is one such use. > > We are quite back level with both Natural and Adabas. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Brian Westerman > > > Sent: Thursday, August 29, 2019 11:53 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS 2.1 to 2.4 > > > > > > IS your a Parallel sysplex or just LPAR environment? If not > > > parallel > > sysplex, > > > then you have nothing to worry about, except for the fact that the > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't > > > using > > it > > > now), everything else is fairly minor. If your running a sysplex, > > > then > > you > > > probably are okay, but it will depend on a lot of factors which I > > > don't > > have > > > enough information to tell you about. > > > > > > You can contact me offline if you want and we can discuss it, but > > > I > > suspect > > > that so long as you are not running some pretty old vendor > > > software or > > some > > > really crappy home grown code that you will have very few (if any) > > issues. > > > > > > Brian > > > > > > -- > > > -- > > > -- 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.
