> For me, > the breakthrough here is that IBM is agreeing to license z/OS to ANYONE,
That's not how it works for us. An RD&T system (and I have been maintaining ours for almost two years now, but RDT has been around longer than that) has licenced the z1090 code (RD&T) and that code only. That's what you pay for in the renewal fees. What you download (or get via DVD) is the z1090 code and as a 'bonus' the current version of an ADCD system. That ADCD system is NOT supported by IBM using the z1090 licence. If you experience a bug on that z/OS, you cannot report it to IBM, since that passport advantage thing only covers z1090, not z/OS. (And let me tell you, I cannot even get into passport advantage, as my IBM id is somehow tied to 'real' support, aka servicelink. My boss has to renew the licence in the dongle.) If you have other ways of reporting z/OS problems, that's fine. But I have been told by a very reliable source in IBM software support for z/OS, that problems experienced on RDT/zPDT systems are explicitly excluded from support. If they think of looking at the cpu id. You are not entitled to download ptfs or any other type of maintenance. Never mind that it would be hard to install that maintenance on that ADCD system, since ADCD comes on crammed-to-the-gills mod3 DASD. While all libraries are set up to allow extents, there isn't any room left to extent the library to. And they're all 99-100% used as far as tracks go. Depending on the version of RDT you bought you may get a newer set of ADCD things that are set up to include a coupling facility. I have been told that it requires either another dongle or at least a new licence to download into the existing dongle. We don't use that, so I don't know if that is more expensive or not. RDT does not support AUTOIPL, and last time I checked there weren't any plans to support it. On the other hand, RDT does support EAVs, although usage is mostly discouraged because it takes too long for IO operations to complete. I don't think things like hiperpav are emulated, if they are even configured, so IOSQ time on an EAV would be an issue. If you run z1090 code on SUSE Linux, be aware that it doesn't handle 1Gb lines (not sure that that is the correct word for it). FTP slows to an absolute crawl due to packets getting rejected and resent. Once you configure the throughput to only be 100MB (and not 1G anymore), things are fine again. And z1090 code is fairly easily rattled if z/OS is up and running and a data set copy operation from an external drive runs at the same time. I saw all kinds of hardware errors in z/OS including spin loops. And recently there was a spin loop where ACR gave up and issued a synchdest message that I should stop processor zero manually. Well, when I had figured out how to issue that command to Linux, the synchdest prompt was gone (partly due to my own stupidity). When I attempted to reIPL z/OS, the stopping of that processor 0 failed, too, and when restarting, it could not read its licence. Consequently z/OS didn't come up. We ended up restarting the underlying Linux box. I don't think a high schooler or college kid would be able to handle these situations easily. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
