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 +0000, Seymour J Metz <[email protected]> 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 <[email protected]> on behalf of Brian Westerman <[email protected]> Sent: Saturday, September 7, 2019 10:38 PM To: [email protected] 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 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 multi-jump, just because I said so. In this case, it's a fact that the OP doesn't "have" to do a multi-jump to support 100% of their systems and sub-systems. Period, slam-dunk, drop-the-mic, end of dispute and never should have been a question about the response to his question. The OP doesn't need to worry about ever ordering or even thinking about z/OS 2.3 to get to z/OS 2.4 from z/OS 2.1 in s disconnected LPAR environment. This is sort of like selling your car and trying to keep the seats. In some cases that might actually work, but it's not something you can guarantee or bet the farm on and in almost all cases it's not even necessary because you will likely get new seats with your new car. In this OP's case, the new seats will look and feel just like his old seats only without all of the holes and patched holes. (reading this again, car seats seems really dumb, but I can't think of a better analogy right now:) Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
