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
