> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Neil Duffee
>
> At 2009.12.03 07:57 concerning "Re: question on STORAGE function -
> TCB may become non-dispatchable?", John Chase <[email protected]>
>
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List [On Behalf Of Neil Duffee
> >> [snip]
> >>> The original request was for experiences / advice on using 64-bit
> >>> storage "directly" in CICS, but CICS doesn't support that (yet).
> [snip]
> > You apparently missed "directly" above.
> >
> > Please cite the syntax for an application program to obtain storage
> > above the bar. E C GETMAIN doesn't do it.
>
> Nope. I saw the "directly" and admit that nothing the the API manual
> for E C GetMain mentions it specifically. In fact, FLENGTH =
> fullword implies 32-bits, no? In addition, the "ptr-ref" definition
> as a "register" is sufficiently vague about 31 vs 64 bit addresses.
Early in the CICS APRM, SET(ptr-ref) is described as always (and only)
referring to a fullword for all API, SPI and XPI commands that offer
SET(ptr-ref) as an option.
> I'm relying on what both Release Guides mention (some snippets
> below). Documentation mis-matches? Perhaps. Anyway, my point was
> that the assumption might not (still) be invalid. I suspect the best
> resource (outside of an ETR) for detailed discussion is Cics-L 'cause
> I'm nowhere near a Cics SysProg by a lonnng shot.
CICS itself exploits (some) above-the-bar addressing: "Containers" are
stored there, but for application access to that data CICS copies it to
24- or 31-bit storage. Applications themselves cannot directly access
the data in 64-bit storage (Assembler excepted, of course; but "you're
on your own" in that case).
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
