Barbara,
Sorry I haven't been able to reply sooner, but I wanted to research what
you had to say and run some tests. My comments below.
Regards,
Tom Conley
On 8/7/2014 3:11 AM, Barbara Nitz wrote:
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.)
I have no idea about licensing in Germany. In the US, 1090 is the
product code for the PartnerWorld for Developers (PWD) zPDT offering,
RD&T is 1091. They are essentially the same, running an ADCD on top of
zPDT. The ADCD release for RD&T is currently running 6-9 months behind
the ADCD for PWD, primarily due to testing the Rational development
components for compatibility.
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.
I'm working with IBM on the support issues with RD&T, so stay tuned.
I'll also see if we can get that out to other areas of the world. As
for DASD, on my current z/OS V1R13 ADCD system, I have a few volumes
that are tight, but the vast majority of the volumes I have off the ADCD
have hundreds of free cylinders.
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.
PAVs are not supported, so for me, EAVs are for gaining experience and
proof of concept.
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.
I'm running OpenSUSE on an ASUS system with 1Gb Ethernet with no issues.
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.
That sounds like a bug in zPDT, and you should be fully supported for that.
I don't think a high schooler or college kid would be able to handle these
situations easily.
But they would be able to learn how to handle them. Prior to RD&T,
there were no options for anyone outside a mainframe shop to learn a
mainframe. For me, I get plenty of performance from my ASUS I7.
ShowMVS tells me it's running 53 Mips. That's plenty for me and it
screams compared to my P390. Sure, I/O is still slow, but this isn't
for production, it's for testing, learning, and maybe a little
development. Is it perfect? Not yet, but consider how long it took us
to get IBM to the point where they decided to make z/OS available to the
masses. I don't want them changing their mind, so I'm choosing to work
with IBM to make this offering better. Stay tuned.
Barbara
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
