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
