> IIRC, the only real issue is with some DCB exits e.g., EODAD
Au contraire, exactly where this thread started is with the issue of
buffers above the line and the possibility of ALLOC DA(*). As I
understand it, if you want buffers above the line ("exploit 31-bit
storage") you must EITHER
- explicitly or implicitly disallow terminal output (and input, but that
is not my problem today); or
- dual-path the code to put buffers below the line if you detect ALLOC
DA(*)
Either alternative, I think, qualifies as evidencing a lack of device
independence in the control program.
And further, it is apparently not documented correctly. I am having
success in testing, and no customer complaints, with something that the
manual says will not work (AMODE=31 PUT to terminal).
BTW, I think EODAD gets driven in the caller's AMODE and can be any
RMODE. IIRC the issue is with SYNAD, which always gets driven AMODE=24,
and thus must also start out RMODE=24.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Edward E. Jaffe
Sent: Tuesday, August 02, 2005 5:49 AM
To: [email protected]
Subject: Re: Device Independence (was: ... DCB coexistence ...)
Charles Mills wrote:
>- This issue affects every developer who wants to write a program that
>exploits 31-bit storage (what a concept in 2005!) and still supports
>terminal I/O.
>
>
IIRC, the only real issue is with some DCB exits e.g., EODAD. They can
be handled by creating a below-the-line "glue" routine for those cases.
I agree that 21st-century programmers shouldn't be burdened with such
things.
----------------------------------------------------------------------
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
