Two DASD incompatibilities I know of from OS/390. Dropping ISAM and adding EAVs DSCBs to the VTOC. PDSE V2 I'm not sure of. Possibly the various extended attributes. Drop the ISAM first and don't use the new facilities until you are certain you don't need to go back.
On Fri, Sep 6, 2019 at 7:41 AM Brian Westerman <[email protected]> wrote: > > Well, you know what they say about assumptions. That definitely applies to > your assumptions here. How did you get into ACM, did you buy a membership or > something?:) > > I really don't mean to sound flippant or like I'm trying to degrade your > abilities or anything, but you don't seriously believe all that stuff you > wrote, do you? There hasn't been a totally incompatible dataset level change > sent out for a good many years, and by that I actually mean so far this > millennium), and IBM is not about to change that kind of thing in a simple > release change. Something like that would result in a version change at the > very least if not a complete OS name change. Remember that this op is > converting from 2.1 to 2.4, (and I don't think he means MVS/XA 2.1 to z/OS > 2.4, I believe he means z/OS 2.1 to z/OS 2.4), but with the possible > exception of ISAM and some old DL/1 structures that would have to be > addressed ahead of time even that conversion is doable if you discard the > processor change necessary and only count the data. Did you possibly forget > that one of the things that sets the IBM mainframe apart from everything else > is the VERY long pedigree of backwards compatibility? > > The whole idea of the way IBM manages z/OS is not going to be placed at > jeopardy, just because they want to come out with a new dot.release. :) > > If it was meant to "scare" the OP into going through a completely unnecessary > installation of z/OS 2.2 or 2.3 then you really should be ashamed of that. > Almost everything you said was (at best) unwarranted. It was almost like > reading something in one of those "this is an example of fake news" sites. > > If the OP were converting from OS/390 to z/OS 2.4 he could STILL share the > dasd. I should know, I still do conversions for people from OS/390 to z/OS > 2.x, I did 3 of them just this year, and while the mainframe CPU can't handle > the two systems at the same time, the dasd and the datasets do. Doing "long > jump" migrations is almost always a hardware issue, not a software or dataset > issue. > > If you want to perform unnecessary installations on your time at your site, > that's completely up to you, but when someone asks a serious question and you > come up with a bunch of FUD, it just serves to undermine what I thought was > supposed to be the purpose of this site, which I had thought was to provide a > forum for people to get help and exchange ideas, not to try to scare them > with half baked assumptions and leading questions which seem to be written > solely for no useful purpose. > > I am positive that I have likely performed more long jump conversions than > you, and I would be willing to bet that I have performed in just the past two > years more operating systems conversions period, than you have performed in > your entire professional life as a systems programmer, if you even are one, > which based on your response I'm not quite certain of. While doing a lot of > migrations and conversions doesn't make me perfect, it does mean that I am (a > lot) less likely to be wrong about this than you are. > > Again, I know it sounds harsh, but this is one of my hot buttons. When > people try to talk about IBM's N+ "suggestion" as if it's anything other than > that, "a suggestion". About 10% of the long jump migrations I have performed > were done through IBM for their client sites, not for any of our existing > clients. I have yet to have a failure to complete a migration on time and as > promised. > > Again, I'm very sorry if I have insulted you in any way, that was not my > intention, but I am really and truly surprised at the lack of restraint and > knowledge about what is involved in a conversion or migration or even in > simply sharing dasd and other resources shown in your response. > > So, please excuse my harsh response, but I didn't want the OP to think that > you knew anything about what you were saying. While you did phrase > everything as if you were merely trying to point out possibilities that I may > have overlooked, you were just so far from correct that I could not allow it > to go UN-commented upon. > > Sorry, > > Brian > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
