Sorry I wasn't able to jump in several days ago. Back to back customer briefings, conferences, and long travel has made it hard for me to catch up on IBM-MAIN until this weekend. I certainly don't want to beat a dead horse on this - I know that this has been well hashed at this point and this topic has probably closed itself out. Some points did come to my mind which I heard faintly brushed on, which I think were not fully surfaced. Because I'd like this archive to contain some additional information for those searching on it in the future, I'll offer two points:
1) Long Jumps: although I know several customers that make long jumps with the help of experienced z/OS staff, and they do go successfully, it still is not a "done deal" and should not be done as a matter of course. The risk for problems is non-zero, and you would be on a path that is not well-grooved. If any problems indeed did surface, the client should be fully prepared to take a "fix forward" posture, especially if a fallback is attempted (which is not something that we are prepared to try to re-create in IBM Service and then fix). What kind of problems could you see? Well, if you look at all the V2.2 coexistence PTFs for V2.4 that's a pretty good list of what you might see doing a V2.1 to V2.4 upgrade. I'd take that list and do individual research on each and every one of those APARs if you want to plan a Long Jump. It doesn't matter if that was a New Function APAR or a release FMID that introduced the function causing the incompatibility. In a V2.4 ServerPac, it doesn't matter how that function got there; it is there in the target libraries. If it needed coexistence (or "preconditioning"), it might affect your Long Jump and you need to understand what it does and try to avoid those behaviors before a fallback, if it is possible to do so. btw: I'm sure it's obvious, but I'd take the V2.1 -> V2.3 Workflow and add the steps for the V2.3 -> V2.4 Workflow to give me the full list of changes to expect. 2) Sysplex: I think it is clear in the z/OS Planning for Installation book, that coexistence, fallback, and migration are for both concurrently shared (sysplex) and not concurrently shared (single single time-sliced) environments: "Coexistence occurs when two or more systems at different software levels share resources. The resources could be shared at the same time by different systems in a multisystem configuration, or they could be shared over a period of time by the same system in a single-system configuration." To me, the appender's question about a sysplex told us about his environment, but it didn't make a difference. It still fell into the "coexistence, fallback, migration" support category and needed coexistence APARs (or minimally, research into coexistence APARs) to know what to plan for. -Marna WALLE z/OS System Install and Upgrade IBM Poughkeepsie ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
