This seems to come up every few months. I have agreed to present a "session" at the next share that (hopefully) will put this issue to rest. There is so much FUD about this particular issue that it gets funny.
There is NOTHING,NOTHING,NOTHING against migrating to the current version of z/OS directly from ANY version of z/OS, or even going back at least to OS/390 2.7. Not only that, but with proper planning you can fall back as well. All it takes is planning. Obviously there are incompatibilities, but they aren't in the catalog that's for sure. I have performed well over 100 migrations/conversions from "back" levels of the OS to the "then and now" current level of the OS. Compatibility isn't ever a problem, the only problems that happen are when you fail to plan. Can you update the catalogs from a newer version of the OS and still be okay on your old version, the answer is YES. Should you do that without planning things out properly, the answer is NO. Will there be problems falling back? If you don't plan things out, the answer is YES. If you were migrating from 1.9 to 1.10 and didn't plan it out, you would have problems falling back. In fact, if you were just putting maintenance on your running 1.10 system and you didn't plan things out, you're going to have a problem falling back. There are NO problems migrating your 1.7 JES spool data to the newest version. You can use NJE, you can use Spool offload. Can you use NJE under TCP, can you MAS the different versions of JES together? The answer is "it depends" on if that support is available for the version your moving from. Now, obviously, there are some things that you can't do on some conversions/migrations. Just as a quick example, you may not be able to create an IODF from an older version of the OS that can be used fully by the newer version, and there are many other "issues" as well that can cause you some small headaches. The problems are all well known and well documented at this point in time, so there is no reason for not knowing this up front when you convert. NO ONE wants to do a migration of more than one OS level at a jump. Who in there right mind would want to jump from z/OS 1.1 to 1.10 by first going to 1.3, then 1.5 then 1.7, then 1.9, then 1.10? You couldn't even get most of those versions at this point in time so even thinking about multiple jumps is silly. I can imagine how many systems programmers would be strung up by the users if they were told to spend a month testing a new release of z/OS only to be told "now lets do it again a couple more times with ANOTHER version that we have no plans on actually running"!! If the question was "is there a spool compatibility issue backing out from 1.10 back to 1.7 should a backout become necessary". The answer is that you should (any time you migrate to anything) backup your data, and offload your spool data and restore it on the other end. If you need to move back from 1.10 to 1.7, you again backup your data and offload the spool data and restore it on the other end. It doesn't matter how far you are jumping. Backup the data, offload the spool, (unless you are going to use NJE and co-exist these systems), then it's just a backup that you need. If the question was "can you read a 1.7 spool with a 1.10 JES, the answer is YES, but why would you want to? That in itself is a very poor migration plan. What are you saving by doing that, 15 minutes? Look at the cost if ANYTHING were to happen, and it doesn't even have to be related to 1.10 or 1.7, what if you had a DASD problem? What if it rains on Tuesday? Your plan should never be to jump first and think about recovery later. ALWAYS plan for things to NOT work, ALWAYS plan for things to break. If you don't have a plan, STOP until you do. Sorry for the soapbox speech (again), but IBM does NOT want you to have to perform multiple jumps to get to your target release. On the other hand, it's not fair for IBM to have to test every possible fallback for you. Believe me, IBM does NOT want to make it difficult for you to migrate to the newest version of the OS. As I previously said, there is a lot of FUD on this issue, you have to just look past it and create a proper plan that makes sense. Don't be afraid to ask questions, and don't assume that the answer you get is going to be the right one. You should ALWAYS have a plan, and ALL plans should have contingencies for what to do, (and when to do it), if things don't work out. Falling back to the old version is never fun, but it isn't traumatic either. I will be willing to bet that if you plan for the fall back, that even if you don't need to use it, you are NOT wasting your time. Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
