z/OS IARV64
Tony Thigpen
understood the "bar", but my understanding has been called into question
by someone that should know so I need to verify what I think I know.
It was my understanding that addresses with bit 31 "on" (xxxxxxxx
xxxxxxxx 1xxxxxxx xxxxxxxx) are considered invalid. This was imposed due
to the convention of using the high-bit of a (32 bit) register as a
flag. So, we can use storage below the 2 GB line or above the 4 GB line,
but not between them.
Secondly, if using IARV64, you will never receive storage that includes
this 'invalid' area.
Did I have it wrong?
--
Tony Thigpen
John P. Baker
A 64-bit user private area begins at 2G and extends up to 2T.
A 64-bit shared private area begins at 2T and extends up to 512T.
A second 64-bit user private area begins at 512T and extend to 16X
(Exabyte).
John P. Baker
Bill Fairchild
You represented bit 31 incorrectly, and you have too many nibbles. It should be xxxxxxxx_8xxxxxxx. Bit 31 can be on in virtual addresses above xxxxxxx1_00000000 (e.g.,12345678_9ABCDEF0), but any addresses between 00000000_7FFFFFFF and 00000001_00000000 will cause a program interrupt. IARV64 will return only valid addresses when asked to get new storage above the bar.
The main reason for disallowing bit 31 within the 2G range from 00000000_7FFFFFFF to 00000001_00000000 was not that it was used as a flag bit, but rather that it is used by the hardware to signal 31-bit addressing for addresses between 00000000 and 7FFFFFFF when the CPU is running in 31-bit addressing mode.
z/OS is the only operating system produced by IBM that I know of that enforces this rule. The invalid range is not invalid under VM, VS1 (if it still exists), DOS/VS (or whatever it is called now), TPF, etc.
Bill Fairchild
Rocket Software
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Tony Thigpen
Sent: Thursday, December 09, 2010 6:20 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: z/OS IARV64
John P. Baker
Corrected text by removing extraneous word.
Also, see chapter 4 of publication SA22-7614-07 MVS Programming: Extended
Addressability Guide.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of John P. Baker
Sent: Thursday, December 09, 2010 7:30 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: z/OS IARV64
Tony,
A 64-bit user private area begins at 2G and extends up to 2T.
A 64-bit shared area begins at 2T and extends up to 512T. <=== removed
"private"
Tom Marchant
>You represented bit 31 incorrectly....
>It should be xxxxxxxx_8xxxxxxx. Bit 31 can be on in virtual
>addresses above xxxxxxx1_00000000 (e.g.,12345678_9ABCDEF0),
right.
>but any addresses between 00000000_7FFFFFFF and
>00000001_00000000 will cause a program interrupt.
It will produce a segment exception or a region-third exception
if the appropriate invalid bit is on. It will not produce an
addressing exception.
>IARV64 will return only valid addresses when asked to get
>new storage above the bar.
Yes, but addresses from X'80000000' to X'00000001_00000000'
_are_ valid addresses. However, IARV64 will not return addresses
within that range. This has been discussed here before. Search
the archives.
If the OP's understanding were correct, it would be impossible
to acquire a contiguous area that is 4GB in size.
--
Tom Marchant
Paul Gilmartin
>
> z/OS is the only operating system produced by IBM that I know of that enforces this rule. The invalid range is not invalid under VM, VS1 (if it still exists), DOS/VS (or whatever it is called now), TPF, etc.
>
Linux, also, has no bar exclusion.
Does CMS support use of storage above the bar?
I understand that on z/OS Java has a special dispensation to use
storage within the bar.
-- gil
John P. Baker
It seems that you are saying that the Extended Addressability Guide is
incorrect, in that it shows the first user private area beginning at 2G and
extending to 2T. What you are saying is that the storage area beginning at
2G and extending to 4G is reserved, and the first user private area begins
at 4G. Is this correct?
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Bill Fairchild
Sent: Thursday, December 09, 2010 7:34 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: z/OS IARV64
Gunter Hochreiter
Gunter Hochreiter
System Software Analyst
Total System Services
Work Phone 706 644 0534
Fax 706 644 6327
Email ghoch...@tsys.com
-- gil
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you
Tom Marchant
>I understand that on z/OS Java has a special dispensation to use
>storage within the bar.
I wish you wouldn't write "within the bar". It suggests that
the bar has thickness, which it does not. Addresses up to and
including 7FFFFFFF are below the bar. Addresses from 80000000
and up are above the bar. "Special dispensation" is not needed.
Prior to that, it is true that that IARV64 would never create a
memory object in the range from 2GB to 4GB. That was an arbitrary
decision intended to avoid confusion. As I understand it, there
was some concern that a user might see an address with bits 0-31
all zero and bit 32 on and be confused. Is it a 31-bit address
with the high order bit on to signify AMODE(31) or is it a 64-bit
address? It seems to me that it hes led to considerable other
confusion.
As to Java, this was discussed on IBM-MAIN. See, for example,
this post from Jim Mulder:
http://www.mail-archive.com/ibm-...@bama.ua.edu/msg108339.html
where he writes,
>>The range from 2GB to 32GB is set aside for a particular
>>intended user, which is the JVM.
The way that the area is used is described in SHARE presentation
2160 from Seattle last year, titled, "Java SDK5, SDK6 and Beyond:
A Performance Update"
--
Tom Marchant
Rob van der Heij
> On Thu, 9 Dec 2010 06:23:45 -0700, Paul Gilmartin wrote:
>
>>I understand that on z/OS Java has a special dispensation to use
>>storage within the bar.
>
> I wish you wouldn't write "within the bar". It suggests that
Yes, programming in the bar is frowned upon... In fact, some people
already get upset when they just hear assembler instructions being
discussed in the bar...
Couldn't help thinking of the "A Virus Walks Into a Bar..." series by
Brian Malow :-)
Edward Jaffe
> It was my understanding that addresses with bit 31 "on" (xxxxxxxx
> xxxxxxxx 1xxxxxxx xxxxxxxx) are considered invalid. This was imposed due
> to the convention of using the high-bit of a (32 bit) register as a
> flag. So, we can use storage below the 2 GB line or above the 4 GB line,
> but not between them.
>
> Secondly, if using IARV64, you will never receive storage that includes
> this 'invalid' area.
Not unless you code USE2GTO32G=YES.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Walt Farrell
wrote:
>Prior to that, it is true that that IARV64 would never create a
>memory object in the range from 2GB to 4GB. That was an arbitrary
>decision intended to avoid confusion. As I understand it, there
>was some concern that a user might see an address with bits 0-31
>all zero and bit 32 on and be confused. Is it a 31-bit address
>with the high order bit on to signify AMODE(31) or is it a 64-bit
>address? It seems to me that it hes led to considerable other
>confusion.
>
>As to Java, this was discussed on IBM-MAIN. See, for example,
>this post from Jim Mulder:
>http://www.mail-archive.com/ibm-...@bama.ua.edu/msg108339.html
>
>where he writes,
>>>The range from 2GB to 32GB is set aside for a particular
>>>intended user, which is the JVM.
>
>The way that the area is used is described in SHARE presentation
>2160 from Seattle last year, titled, "Java SDK5, SDK6 and Beyond:
>A Performance Update"
>
Additionally, in z/OS R12 the area from 32G to 288G is now reserved for
system callers who ask for its use via the LOCALSYSAREA=YES parameter on
IARV64 REQUEST=GETSTOR.
(And isn't this entire discussion more appropriate for IBM-MAIN?)
--
Walt Farrell
IBM STSM, z/OS Security Design
Walt Farrell
<edj...@phoenixsoftware.com> wrote:
>On 12/9/2010 4:19 AM, Tony Thigpen wrote:
>> It was my understanding that addresses with bit 31 "on" (xxxxxxxx
>> xxxxxxxx 1xxxxxxx xxxxxxxx) are considered invalid. This was imposed due
>> to the convention of using the high-bit of a (32 bit) register as a
>> flag. So, we can use storage below the 2 GB line or above the 4 GB line,
>> but not between them.
>>
>> Secondly, if using IARV64, you will never receive storage that includes
>> this 'invalid' area.
>
>Not unless you code USE2GTO32G=YES.
But note that (as far as I know) USE2GTO32G is an undocumented parameter
that is not part of the intended programming interface.
Gunter Hochreiter
In 1989 in South Africa I converted the last VS1system in the world (
according to IBM) to XA for a company called CNA . Subsequently I
heard that there still was one in Spain
Gunter Hochreiter
System Software Analyst
Total System Services
Work Phone 706 644 0534
Fax 706 644 6327
Email ghoch...@tsys.com
From: Paul Gilmartin <PaulGB...@aim.com>
To: ASSEMBL...@LISTSERV.UGA.EDU
Date: 12/09/2010 08:31 AM
Subject: Re: z/OS IARV64
Sent by: IBM Mainframe Assembler List
<ASSEMBL...@LISTSERV.UGA.EDU>
-- gil
-----------------------------------------
Bill Fairchild
Bill Fairchild
Watkins, Douglas
1_00000000 and up are above the bar? I thought that was the original
reason for the "bar" designation, "thickness" being an intentional
attribute.
How many "lines," then, do we need? 16MB, 2GB, 4GB, 32GB, 288GB . . .
Doug Watkins
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant
Sent: Thursday, December 09, 2010 10:37 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: z/OS IARV64
Alex Kodat
> Prior to that, it is true that that IARV64 would never create a
> memory object in the range from 2GB to 4GB. That was an arbitrary
> decision intended to avoid confusion. As I understand it, there
> was some concern that a user might see an address with bits 0-31
> all zero and bit 32 on and be confused. Is it a 31-bit address
> with the high order bit on to signify AMODE(31) or is it a 64-bit
> address? It seems to me that it hes led to considerable other
> confusion.
It was more than to avoid "confusion". It was to prevent code that used the
high order bit of 32-bit registers as a flag bit (yes, usually to indicate AMODE,
but not always) and was changed to run in 64-bit mode from accidentally "working",
where "working" means clobbering storage between the 2G and 4G area or, at the
very least, picking up the wrong data from that area.
The z/OS folks made a wise decision to burn a teeny bit of storage (for the
extra page table entries) in the interest of reliability. This is also the
reasoning behind the IARV64 guard bands and I encourage people to use these
generously. I can attest that making the addresses from 2G to 4G unaddressable
along with guard band support has been very effective in catching bugs in the
64-bitting of code. If possible, it's also a good idea to put junk into the
high order 32 bits of registers at strategic points to try to ensure that
code is using proper hygiene in loading addresses into registers (using LLGF/LGF
rather than L). Unfortunately, it's all too easy for code to accidentally work in
64-bit mode because someone happened to clear the high order 32 bits of some
register shortly before the accidentally working code. And, as we all know, code
that works by accident today, might not work tomorrow.
--
Cheers,
Alex Kodat
Sirius Software
Edward Jaffe
Fully documented:
[USE2GTO32G=NO|YES]
is an optional keyword input that specifies
whether this is an explicit allocation request for
64-bit virtual storage in the 2G-32G area.
DEFAULT: NO
USE2GTO32G=NO
The request will not be satisfied from the
2G-32G area.
USE2GTO32G=YES
The request is to be satisfied from the 2G-32G
area.
Martin Trübner
>> In fact, some people already get upset when they just hear assembler instructions being
discussed in the bar...
reminds me of a conversation I had in a sauna with Roland S.
about how to hack the mainframe of a major city ...
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
Martin Trübner
>> (And isn't this entire discussion more appropriate for IBM-MAIN?)
(Not realy- z/VSE will get IARV64 - and it is very likely that it will
be with the same functionality as in the flagship-version.)
BTW- the OP is a VSE person.
Walt Farrell
<edj...@phoenixsoftware.com> wrote:
>On 12/9/2010 8:08 AM, Walt Farrell wrote:
>> On Thu, 9 Dec 2010 07:55:36 -0800, Edward Jaffe
>> <edj...@phoenixsoftware.com> wrote:
>>> Not unless you code USE2GTO32G=YES.
>> But note that (as far as I know) USE2GTO32G is an undocumented parameter
>> that is not part of the intended programming interface.
>
>Fully documented:
>
>[USE2GTO32G=NO|YES]
> is an optional keyword input that specifies
> whether this is an explicit allocation request for
> 64-bit virtual storage in the 2G-32G area.
> DEFAULT: NO
>
>
In which book, Ed? I couldn't find it.
Edward Jaffe
> In which book, Ed? I couldn't find it.
Books?! Who uses them? The best documentation for any modern z/OS macro is in
the macro prolog.
Tony Thigpen
Tony Thigpen
Walt Farrell
<edj...@phoenixsoftware.com> wrote:
>On 12/9/2010 8:35 AM, Walt Farrell wrote:
>> In which book, Ed? I couldn't find it.
>
>Books?! Who uses them? The best documentation for any modern z/OS macro is in
>the macro prolog.
While I'll agree they prologs are interesting to look at, I'm not sure we
view them as official documentation, and they certainly describe many things
that are not officially programming interfaces, with all that implies for
you (and potentially your program or system) if you try to use them.
So anyone using the prologs -should- (in my opinion) be making sure that
what they're using is also described in the books or they're taking some risks.
Though in this case I see that the prolog does indicate that USE2GTO32G is
not a programming interface, so one could get that info from a careful
prolog reading, too, as long as one read -all- of the prolog and not just
the keyword descriptions.
Thanks!
John P. Baker
It seems that it has gotten a lot more complicated.
As best I can determine, the rules now appear to be --
2G thru 32G-1 is available for private memory objects, but only if
USE2GTO32G=YES is coded (not documented, not supported for non-IBM use).
32G thru 288G-1 is available for private memory objects, but only if
LOCALSYSAREA=YES is coded (new for z/OS V1R12); question: is this storage
unconditionally available for private memory objects on releases prior to
z/OS V1R12?
288G thru 2T-1 is available for private memory objects.
2T thru 512T-1 is available for shared memory objects.
512T thru 16E-1 is available for private memory objects.
Paul Gilmartin
> On Thu, 9 Dec 2010 06:23:45 -0700, Paul Gilmartin wrote:
>
>> I understand that on z/OS Java has a special dispensation to use
>> storage within the bar.
>
> I wish you wouldn't write "within the bar". It suggests that
> the bar has thickness, which it does not. Addresses up to and
> including 7FFFFFFF are below the bar. Addresses from 80000000
> and up are above the bar. "Special dispensation" is not needed.
> ...
> As to Java, this was discussed on IBM-MAIN. See, for example,
> this post from Jim Mulder:
> http://www.mail-archive.com/ibm-...@bama.ua.edu/msg108339.html
>
Wherein he quotes ??? quoting Ed Jaffe's reference to the "the
previously 'thick' bar", so my usage, however deprecated, may
be no worse than being outdated.
Doublewords are somewhat magical in storage management. A
32-bit word can refer to 4Gi doublewords, which is 32GiB,
which may motivate a boundary at that point.
-- gil
Gunter Hochreiter
user , I forgot why but can read it up.
Gunter Hochreiter
From: "John P. Baker" <jbak...@comporium.net>
To: ASSEMBL...@LISTSERV.UGA.EDU
Date: 12/09/2010 12:28 PM
Subject: Re: z/OS IARV64
Sent by: IBM Mainframe Assembler List
<ASSEMBL...@LISTSERV.UGA.EDU>
Bill,
John P. Baker
Bill Fairchild
-----------------------------------------
Walt Farrell
wrote:
>32G thru 288G-1 is available for private memory objects, but only if
>LOCALSYSAREA=YES is coded (new for z/OS V1R12); question: is this storage
>unconditionally available for private memory objects on releases prior to
>z/OS V1R12?
As far as I know, yes. New functions in z/OS R12 required reserving some
space for system functions, and the VSM designers chose that previously
unreserved 256GB chunk of storage addresses for that purpose.
Edward Jaffe
> While I'll agree they prologs are interesting to look at, I'm not sure we
> view them as official documentation, and they certainly describe many things
> that are not officially programming interfaces, with all that implies for
> you (and potentially your program or system) if you try to use them.
Too often the books are incomplete or just plain wrong. Having time to file an
RCF to get them fixed is a luxury. Sometimes I have time; sometimes I don't. In
my experience, the macro prologues are the best place to find the accurate and
most up-to-date interface and usage details. Even the return/reason codes are
enumerated there and contain the latest information. The doc is often woefully
out of date.
Here's a recent true story: For a programming task started last month involving
Health Checker, the book was so inadequate that the programmer couldn't figure
out how to use the HZSQUERY interface to do what he knew should be possible. I
spent a good deal of time looking at it myself and finally asked, "Did you look
at the macro prolog?" Of course, what was needed was fully described there and
the programming task proceeded to the next phase. The new functionality is now
tested and working fine awaiting delivery to customers in the next release.
> So anyone using the prologs -should- (in my opinion) be making sure that
> what they're using is also described in the books or they're taking some risks.
If we weren't supposed to read the macro prologues, the z/OS programmers would
not create them in the first place or maintain them so painstakingly with each
change.
> Though in this case I see that the prolog does indicate that USE2GTO32G is
> not a programming interface, so one could get that info from a careful
> prolog reading, too, as long as one read -all- of the prolog and not just
> the keyword descriptions.
Exactly! IARV64 provides an on-point example of how the documentation in a
modern macro prolog is often _far_ more complete than the books.
The macros are carefully maintained by the highly-qualified z/OS programmers
writing the code in the U.S. or Europe or wherever they may be located whereas
the books are maintained by some non-programmer "ID" folks in a far-away land
called China.
The documentation the z/OS programmers provide is obviously intended to, and
absolutely succeeds in, helping us (the exploiters) be more self-sufficient. I'd
much rather read that information than waste everyone's time with days of
experimentation or a call/email to my friends in POK asking how an interface
actually works.
What would make us even more self-sufficient would be access to the source code
or compiler listing of the code behind the interface as is done in Linux--the
most popular emerging operating system in the world. Where listings still exist
for non-OCO z/OS modules, there are rarely any questions. In fact, experienced
programmers can often fully diagnose abends in IBM code as I did recently for
still-open PMR 06143,227,000 which resulted in still-open APAR OA34895. But, I
digress...//
Gunter Hochreiter
area. Then the user areas What is the System area used for ? Any
ideas ?
Gunter Hochreiter
From: Walt Farrell <wfar...@US.IBM.COM>
To: ASSEMBL...@LISTSERV.UGA.EDU
Date: 12/09/2010 01:26 PM
Subject: Re: z/OS IARV64
Sent by: IBM Mainframe Assembler List
<ASSEMBL...@LISTSERV.UGA.EDU>
-----------------------------------------
John P. Baker
There seems to be some belief here that 2G thru 4G-1 is unavailable for some
reason other than that specifically addressed by the undocumented
USE2GTO32G={NO|YES} operand.
I do not believe that to be case. Am I correct?
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Walt Farrell
Sent: Thursday, December 09, 2010 1:24 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: z/OS IARV64
Gunter Hochreiter
problems with it. They wrote a fix as far as I can remember.
Gunter Hochreiter
m
From: "John P. Baker" <jbak...@comporium.net>
To: ASSEMBL...@LISTSERV.UGA.EDU
Date: 12/09/2010 01:36 PM
Subject: Re: z/OS IARV64
Sent by: IBM Mainframe Assembler List
<ASSEMBL...@LISTSERV.UGA.EDU>
Walt,
John P. Baker
-----------------------------------------
Walt Farrell
wrote:
>The 1st 32gig are reserved for JVM then comes 288G-32G for a System
>area. Then the user areas What is the System area used for ? Any
>ideas ?
The system area is used for whatever system functions need it. Nothing we
know of had needed it before z/OS R12, though some of the z/OS designers had
foreseen a possible need for it someday.
As it turned out, both the Restart phase of Checkpoint/Restart processing
and the child-side part of UNIX Fork processing examine storage and fail if
there is any allocated 64-bit storage when they run, since they can't
properly restore the original storage contents. RACF changes in z/OS R12
ended up allocating 64-bit storage early in the life of a job (before the
Restart and fork-child processing), and so z/OS needed something like the
local system area in order to avoid Restart and Fork failures.
Checkpoint/Restart and Fork simply ignore that area, and everything
continues to work as it used to.
Walt Farrell
wrote:
>There seems to be some belief here that 2G thru 4G-1 is unavailable for
some reason other than that specifically addressed by the undocumented
>USE2GTO32G={NO|YES} operand.
>
>I do not believe that to be case. Am I correct?
USE2GTO32G is very recent, John; perhaps z/OS R10 or R11. And it's much
larger than the the gap in storage allocation from 2G to 4G, which has
existed since the inception of 64-bit z/OS storage.
As far as I know, the reasoning expressed in this thread is correct: we have
the 2G to 4G gap to avoid potential problems with AMODE(64) programs that
have a 31-bit address with the high-order bit on, perhaps because it signals
an addressing mode or (perhaps more likely) because it's an end-of-plist
indicator for a 31-bit parameter list.
Tom Marchant
>So, Tom, is it a common misconception that only addresses from
>1_00000000 and up are above the bar? I thought that was the original
>reason for the "bar" designation, "thickness" being an intentional
>attribute.
It is a misconception. I can't say how common it is.
An address is above the bar if it can only addressed with the
processor running in 64-bit mode. That is, bits 31 and 32 of the
PSW are both 1. AFAIK, the reason for calling it a bar is to
distinguish it from the line that is at 16M. Addresses above 16M
cannot be referenced when running in 24-bit mode. They could have
designated the old "line" as the "16M line" and designated the bar
as the "2G line". That would have required that everyone change
the way that they think about "above the line".
--
Tom Marchant
john gilmore
I have found this now lengthy thread a little puzzling.
Vanilla use of IARV64 obviates all difficulties, and it is perhaps worth repeating that we are talking here about virtual storage: none of these reservations deprives anyone of any real storage; and even with these reservations the size of the AMODE(64) address space is ample to our needs in the foreseeable, even indeed the conjecturable future.
John Gilmore Ashland, MA 01721-1817 USA
Mark Boonie
> z/OS is the only operating system produced by IBM that I know of
> that enforces this rule. The invalid range is not invalid under VM,
> VS1 (if it still exists), DOS/VS (or whatever it is called now), TPF,
etc.
In z/TPF, virtual addresses from 2GB to 4GB-1 are invalid.
- mb
Mark Boonie
z/TPF Development
Peter Relson
>the bar has thickness, which it does not. Addresses up to and
>including 7FFFFFFF are below the bar. Addresses from 80000000
>and up are above the bar. "Special dispensation" is not needed.
Actually, as it was designed, there is "thickness". The bar is from
80000000 through FFFFFFFF.
Everything from 1_00000000 on up is above the bar.
The bar has been blurred because of the special compensation for Java to
use an area that includes the bar.
Peter Relson
z/OS Core Technology Design
Peter Relson
bearing on whether it is a documented progarmming interface. Officially,
only the books are the arbiter of programming interfaces.
Further, the prolog shows that this Use2Gto32G is not a programming
interface:
*01* EXTERNAL CLASSIFICATION:
*
*02* GUPI: BASE
*
*02* NONE: FIELDS
* DOAUTHCHECKS
* USE2GTO32G
*
*01* END OF EXTERNAL CLASSIFICATION:
I readily grant that the books are too often wrong. But that does not
lessen their official-ness. Help us to get them right.
Paul Gilmartin
OK. Thanks. Henceforth I will try to accommodate Tom's
preference by eschewing "within the bar" in favor of "an
area that includes the bar". (If I remember.) Should I
also use "compensation" rather than "dispensation"?
Everybody happy?
gil
Paul Gilmartin
>
> Vanilla use of IARV64 obviates all difficulties, and it is perhaps worth repeating that we are talking here about virtual storage: none of these reservations deprives anyone of any real storage; ...
>
They do, however, entail the overhead of segment or page table entries.
-- gil
Tom Marchant
I defer to Peter's knowledge of the original intent, since the bar is a z/OS
construct and not a hardware one. For my purposes, data "above the bar" is
data that requires me to be in 64-bit mode. It makes little difference
whether that means above 2 GB or above 4 GB, since I will never allocate
storage within that range. However, if I need to examine Java stack in that
range, the distinction becomes blurred.
--
Tom Marchant
Abend-AID development
Compuware
Tony Thigpen
SA22-7614-07 "MVS Programming: Extended Addressability Guide". That doc
says that "above the bar" starts at 2 GB instead of 4 GB.
Tony Thigpen
Mark Boonie
Why wouldn't the region-third-table entry simply be marked invalid? (I'm
not saying you're wrong -- I have no idea how z/OS does it.)
Chris Craddock
> I readily grant that the books are too often wrong. But that does not
> lessen their official-ness. Help us to get them right.
I am all in favor of following the documented interfaces where ever possible, however the books are not just "often wrong". They are almost always out of date. In days of old the functionality included in a new release would usually show up in the books for the new release, or in a TNL. Now it is pretty common for great hunks of function not to show up in the books for a release or two. And while I sympathize with the plea to help "get them right", I can tell you from first hand experience over (mumble) years, sending in an RCF is about as useful as yelling down a well. IBM is not investing in keeping the platform information up to date.
CC
McKown, John
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * 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 Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Chris Craddock
> Sent: Friday, December 10, 2010 10:39 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: z/OS IARV64
>
Edward Jaffe
> I defer to Peter's knowledge of the original intent, since the bar is a z/OS
> construct and not a hardware one. For my purposes, data "above the bar" is
> data that requires me to be in 64-bit mode. It makes little difference
> whether that means above 2 GB or above 4 GB, since I will never allocate
> storage within that range. However, if I need to examine Java stack in that
> range, the distinction becomes blurred.
Either way you'll need to be in 64-bit addressing mode since there is no 32-bit
addressing mode. That's where I draw the line. 24-bit, 31-bit, 64-bit. Who cares
where the system actually allocates the virtual addresses?
Actually, it does matter for performance minded folks. Java got a substantial
performance boost by using so-called "compressed" pointers which is really just
a fancy way of saying that they stored addresses in four bytes instead of eight
to minimize memory and cache line usage.
After seeing that, we tried something similar in some performance-sensitive
64-bit code. We didn't want to code USE2GTO32G because it wasn't supported on
all of the back z/OS releases we needed to support. So, instead we changed from
using pure 64-bit addresses to using 32-bit offsets within the 64-bit memory
object. Incredibly, we saw some measurable performance improvement even though
we *added* AGF instructions to the code path (carefully so as to avoid AGI as
much as possible).
Edward Jaffe
> ... I can tell you from first hand experience over (mumble) years, sending in an RCF is about as useful as yelling down a well.
In all fairness, I've had pretty good luck with RCFs. The problem for me was
often the amount of my time it took to fully explain what was wrong/missing and
sometimes go back and forth about it. I had enough trouble convincing myself to
open PMRs.
Rob Scott
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Edward Jaffe
Sent: 10 December 2010 17:00
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: z/OS IARV64
Chris Craddock
>
> Rob Scott
that would certainly help salvage and preserve the community knowledge about the platform. (IMO) One of the main reasons that people are not building sophisticated software for the platform is that almost none of the relevant information is actually written down anywhere. It exists only in the heads of folks who have the scars to prove it and when they're gone, that knowledge will be too.
So yeah, I'm in.
CC
Sam Siegel
> Maybe we need the z/OS manuals in a "wiki" somewhere so that we can all
> chip in :-)
>
> that is a great idea give the depth of experience of IBM-MAIN and the
relatively narrow audience.
Tony Harminc
> The fact that you can see information in the prolog of a macro has no
> bearing on whether it is a documented progarmming interface. Officially,
> only the books are the arbiter of programming interfaces.
>
> Further, the prolog shows that this Use2Gto32G is not a programming
> interface:
>
> *01* EXTERNAL CLASSIFICATION:
> *
> *02* GUPI: BASE
> *
> *02* NONE: FIELDS
> * DOAUTHCHECKS
> * USE2GTO32G
> *
> *01* END OF EXTERNAL CLASSIFICATION:
So the macro prolog has no bearing on the PI status, but you are
showing us some prolog text to demonstrate that a feature is not
PI...? Should I take it from this that a prospective user of any
service needs to check both the macro and the book and use the most
restrictive interpretation?
And while I'm here - what's the difference between "NONE" and "NOTPI"?
I would've thought "NONE" would mean that no one has pronounced upon
it, and that "NOTPI" would be the definitive statement of non support.
> I readily grant that the books are too often wrong. But that does not
> lessen their official-ness. Help us to get them right.
RCFs concerning typos or minor formatting issues often produce
corrections in the next release. Those concerning substantive issues
that would require the tech writer to consult with development have
rarely done so, in my experience. I have had pleasant conversations
with concerned tech writers over the years, but as for actual changed
publications...
Tony H.
Pires, Antonio
some things up being a mainframe newbie, and boy do I agree with this
statement:
"[this information] exists only in the heads of folks who have the scars
to prove it[...]"
If you guys get around to putting something like that together, let us
all know! :)
Even the MVS manuals that I inherited from a co-worker seem like they
were written for people that already know what's going on...
Regards,
Antonio
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Chris Craddock
Sent: Friday, December 10, 2010 11:17 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: z/OS IARV64
Dougie Lawson
> Should I take it from this that a prospective user of any
> service needs to check both the macro and the book and use the most
> restrictive interpretation?
>
The book will have a clear definition of what part of the interface is
GUPI vs what part is PSPI.
GUPI == general usage programming interface
PSPI == product specific programming interface
PSPI code is normally reserved for IBM internal and/or OEM vendors
rather than end users.
If you use a PSPI when it breaks because IBM have changed something
you'll get to keep both pieces. If you don't have the right Q&A
support contracts in place with IBM you could get a bill from your
local software support centre when IBM have spent more than a couple
of hours debugging your bug in your code.
--
http://twitter.com/DougieLawson
http://facebook.com/DougietheIMSman
Tony Harminc
> On 10 December 2010 19:03, Tony Harminc <to...@harminc.com> wrote:
>> Should I take it from this that a prospective user of any
>> service needs to check both the macro and the book and use the most
>> restrictive interpretation?
>
> The book will have a clear definition of what part of the interface is GUPI vs what part is PSPI.
Well, actually, no - the books often enough do no such thing. The Data
Areas books often (but not always) have a section in front of a data
area that says "Programming Interface Information", but as often as
not it's empty. For example, here's the entire such information for
the very first data area in the book, the Abdump Exit Parameter List
(ABEP):
2.0 ABEP Programming Interface Information
------------------ Programming Interface Information -------------------
ABEP
|--------------- End of Programming Interface Information ---------------|
So how do I interpret that? "There is no programming interface
whatsoever that involves this data area?" Or perhaps "Sorry - we
neglected to copy the PI data onto this page from the macro"?
Now one might notice that the description of the IEAVTABX exit in the
MVS Installation Exits book says that the address of an ABEP is
provided to the exit, and one might therefore *assume* that the
content of the ABEP is a PI. But there is no shortage of examples of
IBM providing a pointer to a control block in which only some fields
are PI, and in some cases only a single field out of many is a PI. (I
think the OCVT (BPXZOCVT) takes this to the limit, in that one lonely
bit of the entire structure is PI.) So what ABEP fields are PI? Who
can tell?
> GUPI == general usage programming interface
> PSPI == product specific programming interface
Yeah - I'm well familiar with those terms, though plain PI seems to be
replacing them. And some macros classify some fields as "DMTI". I've
never taken the time to try to look that one up.
> PSPI code is normally reserved for IBM internal and/or OEM vendors
> rather than end users.
>
> If you use a PSPI when it breaks because IBM have changed something
> you'll get to keep both pieces.
Of course this is the world many ISVs live in. Many things cannot be
accomplished without using such interfaces, and it is our job to keep
on top of them. That's fair enough, but it would be nice if there was
consistent labelling.
> If you don't have the right Q&A
> support contracts in place with IBM you could get a bill from your
> local software support centre when IBM have spent more than a couple
> of hours debugging your bug in your code.
I've heard this one for around 30 years now, but I've never
encountered anyone who actually got that bill and paid it. Neither
have I heard of anyone getting paid by IBM when an IBM bug consumed
hours of the customer's time. Not to say neither has happened...
Tony H.
Martin Trübner
Tony realy made it:
>> I've heard this one for around 30 years now, but I've never
encountered anyone who actually got that bill and paid it.
I know of a few cases here in Germany - and it is not (as Dougie
phrased it)
>> ...bill from your local software support centre when IBM have spent more than a couple
of hours debugging your bug in your code.
Customers not having a "Comfort line contract" are forced (before
anyone looks at the case) to sign a paper stating "....if not covered by
other contracts you pay 3000 Euros plus up to 10 hours (with 280
Euros)" ....
And these bills do come in - sometimes even for cases
where it was clearly an IBM problem (where/because someone forgot to
mark the right box when closing the case).
Tony continued:
>> ....Neither have I heard of anyone getting paid by IBM when an IBM bug consumed
hours of the customer's time.
Ages ago I have been actively involved in such a case (including the
part of getting a refund).
It was settled in a different way ;-)
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
Dougie Lawson
> On 10 December 2010 14:22, Dougie Lawson <dl1...@gmail.com> wrote:
>> On 10 December 2010 19:03, Tony Harminc <to...@harminc.com> wrote:
>>> Should I take it from this that a prospective user of any
>>> service needs to check both the macro and the book and use the most
>>> restrictive interpretation?
>>
>> The book will have a clear definition of what part of the interface is GUPI vs what part is PSPI.
>
> Well, actually, no - the books often enough do no such thing.
In that case send reader's comments. Every online book has a CONTACT
link at the bottom of the page.
Every PDF book has an email address or URL for comments.
That process works well with IMS and DB2 books. I've been sending
reader's comments for best part of 30 years.
john gilmore
| Well, actually, no - the books often enough do no such thing.
Dougie Lawson wrote:
<begin snippet>
In that case send reader's comments. Every online book has a CONTACT link at the bottom of the page. Every PDF book has an email address or URL for comments.
That process works well with IMS and DB2 books. I've been sending reader's comments for best part of 30 years.
</end snippet>
I am a great admirer of Mr Lawson's work in his own bailiwicks. Who is not? That said, this party-line response is unhelpful.
I have been sending comments about IBM books to the places nominated to receive them for rather more than 40 years, and the results have been various.
In some cases, e.g., with the PrOp and the HLASM manuals, responses have been prompt and, in the lawyer's sense of this word, responsive: errors have been fixed, examples have been added, even what I perceived to be infelicities have been addressed.
In many other cases, however, this has not been the case. Responses have been pro forma, even perfunctory, and not at all responsive in the lawyer's sense of this word; and nothing much has been done to remedy what I took to be these other books' deficiencies.
Differences of this sort are to be expected in a very large, geographically dispersed organization; but I have a suspicion, which has been voiced here before, that IBM's internal use of PL/X instead of assembly language has led to significant deterioration in the currency of the assembly-language documentation that the rest of us, outside IBM, must still use.
My use of the word suspicion here is indeed a form of politesse. It is clear that this has happened, that it is a problem, and that not enough has been done within IBM to address it.
Reader's comments are desirable; I plan to continue mine; but they alone will remedy these problems only in that long run in which, as Keynes reminded us, we shall all be dead.
Peter Relson
for the duplication for those who follow both>>
>So the macro prolog has no bearing on the PI status, but you are
>showing us some prolog text to demonstrate that a feature is not
>PI...? Should I take it from this that a prospective user of any
>service needs to check both the macro and the book and use the most
>restrictive interpretation?
The information was placed into the prolog to help answer questions just
like Ed's. I contend that it does.
Also, for data areas, the book is generated automatically from the macro
(including prolog).
The one thing that is missing in the prolog is the explicit statement on
Use2Gto32G that this keyword is intended for IBM use only.
Perhaps that will be added when we get around to it.
GUPI and PSPI: now PI.
DMTI (Diagnostic, Modification, Tuning information): now notPI
Our intent is to provide migration and change information if anything GUPI
/ PSPI / PI changes incompatibly.
We fail to meet that intent every now and then (maybe too many now's and
too many then's) but we're trying to improve.
Walt Farrell
>Well, actually, no - the books often enough do no such thing. The Data
>Areas books often (but not always) have a section in front of a data
>area that says "Programming Interface Information", but as often as
>not it's empty. For example, here's the entire such information for
>the very first data area in the book, the Abdump Exit Parameter List
>(ABEP):
>
>
>2.0 ABEP Programming Interface Information
>------------------ Programming Interface Information -------------------
>
> ABEP
>
> |--------------- End of Programming Interface Information ---------------|
>
>
>So how do I interpret that? "There is no programming interface
>whatsoever that involves this data area?" Or perhaps "Sorry - we
>neglected to copy the PI data onto this page from the macro"?
>
You interpret it just as the information at the front of the book tells you
to, Tony. For that book it's one page earlier than the example you showed,
at
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/mvs12da1/FRONT_1?SHELF=EZ2ZBK0K&DT=20100920145502
for z/OS R12, in the section titled "Programming Interface Information".
<quote>
Unless otherwise specified, for data areas classified as programming
interfaces, the MACRO ID and DSECT NAME(S) in the header are part of the
programming interface. ALL other header information is included for
diagnostic purposes ONLY.
Since a data area name that is designated as part of the programming
interface is one of the following:
* MACRO ID
* DSECT NAME
* commonly-used name
before including the data area name in a program, refer to the data area
header for the applicable MACRO ID.
If only certain fields in a data area are intended or not intended for use
as a programming interface, the specific field name(s) are differentiated
within the data area.
</quote>
Interpretation: For ABEP, everything is part of the programming interface.
--
Walt Farrell
IBM STSM, z/OS Security Design
John Ehrman
<... but I have a suspicion, which has been voiced here before, that IBM's
internal use of PL/X instead of assembly language has led to significant
deterioration in the currency of the assembly-language documentation that
the rest of us, outside IBM, must still use.>
Because many customers and IBM-internal sites rely heavily on the
assembler, we try to keep its documentation correct and up to date. If you
have suggestions about specific areas for improvements, please let me know.
Regards... John
---------------
555 Bailey Ave, San Jose CA 95141 +1-408-463-3543
Internet: ehr...@us.ibm.com, ehr...@vnet.ibm.com, EHRMAN at STLVM27
408-463-3543, TIE 543-3543 (fax -3873)
john gilmore
It is the documentation of other operating-systems facilities that outsiders must use in assembly language rather than PL/X that is sometimes laggard and/or deficient.
John Gilmore Ashland, MA 01721-1817 USA
> Date: Mon, 13 Dec 2010 11:14:29 -0800
> From: ehr...@us.ibm.com
> Subject: IBM Documentation (Was z/OS IARV64)
> To: ASSEMBL...@LISTSERV.UGA.EDU
Paul Gilmartin
>
> <... but I have a suspicion, which has been voiced here before, that IBM's
> internal use of PL/X instead of assembly language has led to significant
> deterioration in the currency of the assembly-language documentation that
> the rest of us, outside IBM, must still use.>
>
> Because many customers and IBM-internal sites rely heavily on the
> assembler, we try to keep its documentation correct and up to date. If you
> have suggestions about specific areas for improvements, please let me know.
>
because many customers and IBM-internal sites rely heavily on the
assembler, test before shipping! We got hit by:
APAR Identifier ...... OA34037 Last Changed ........ 10/10/01
MACRO IFAENF37 HAS A SLIGHT ERROR IN IT, WHICH CAUSES AN
ASSEMBLER ERROR
PTF List:
Release 770 : UA56527 available 10/09/08 (F009 )
This was opened mere days after the GA of 1.12. It could never
have assembled without error ('*' in column 1 missing from a
comment). Well, maybe if the test driver bypassed it with an
AGO.
In fact, it has been mentioned on IBM-MAIN that data area macros
(as this is) are generated automatically from the PL/X source.
That something like this could escape indicates an error in the
filter.
-- gil
john gilmore
o the HLASM proper, its quality and the quality of its documentation, from
o those of other operating-system facilities that are implemented in assembly language.
The HLASM is, of course, imperfect; but it is the best, indeed the only vehicle we have for implementing performance-critical routines and accessing many system resources.
Moreover, compared to other assemblers, which often seem to have been implemented in a fashion deliberately intended to discourage their significant use, it is a marvel.
Legitimate and important criticisms of facilities implemented in assembly language are too easily diverted into---or systematically misunderstood to be---criticisms of the assembler proper. This distinction therefore needs to be made systematically in posts here and on IBM-MAIN.