On Dec 7, 2012, at 7:22 AM, McKown, John wrote:
I'd lay good odds that most of the DCB oriented stuff will stay
RMODE(24) until the end of the age of mainframes. So much code is
dependent on 3 byte addresses that even if IBM wanted to update it,
end users would revolt when their applications which used 3 byte
addresses from the 1980s abended. I remember the nastiness when SWA
went above the line and what was an address became a token.
Everybody had to either keep SWA below the line (an option), or
rewrite their code to use the SWAREQ(?) macro instead of "chain
chasing".
John:
I was involved in this issue and had opened several problems when
various vendors did not support it.
One vendor ran with it on the first phone call and had a solution
next day. One vendor said well maybe in the next release. The vendor
happened to supply the source for the module in question so I went a
digging. It took me all of 5 minutes to find it and less that five
minutes to code the changes up. I called the vendor and told them not
to bother as I fixed it and then they had the gull to ask me for the
change. I suggested a free years worth of the use of the product and
they wouldn't hear of it. I said good by. I was sick and tired of
some vendors attitude on the the SWA issue most did a decent job
(except for one). The vendor who was a hold out is a well known
vendor who is discussed on this list often (usually in not a
complementary tones, this is one of the reasons, IMO). The code
change was miniscule and trivial in the case of several vendors. I
would not defend them in any case.
Ed
I wish that IBM would "wise up". Guess what I/O interface already
allows AMODE(64) callers. The UNIX I/O calls have both AMODE(31)
and AMODE(64) variants (BPX1* and BPX4*). I wish that IBM would
extend these to allow access to standard z/OS data sets. A PDS
could be viewed as a subdirectory, with each member being a file.
I've read that PDSE's can even have member names > 8 characters,
but I've not run across one yet which does. (We're a small shop and
don't have much advanced software installed).
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
[email protected] * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain
confidential or proprietary information. If you are not the
intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. HealthMarkets(r) is the
brand name for products underwritten and issued by the insurance
subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM
and The MEGA Life and Health Insurance Company.SM
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]]
On Behalf Of Mike Schwab
Sent: Thursday, December 06, 2012 6:10 PM
To: [email protected]
Subject: Re: LOAD and DELETE macro instructions
I am wondering if z/OS 2.x will bring 64 bit address constants
into the
operating system so everything can run above the 2GB bar.
On Thu, Dec 6, 2012 at 5:19 PM, John Gilmore <[email protected]>
wrote:
Shmuel says:
| AMODE(64) is not appropriate for a module that is not executable.
Peter Relson---I am now wary of paraphrasing him---appears to judge
that AMODE is moot for tables. I have said and say that AMODE(64)
is
not just appropriate but desirable for a read-only module that
contains doubleword ADCONs.
Take your pick; or consult an augur, who will to wield his lituus in
helping you make your choice.
John Gilmore, Ashland, MA 01721 - USA
--------------------------------------------------------------------
-
-
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
