There is an old technology, one that is ordinarily used statically, that can
also be used somewhat dynamically to circumvent the security-orient[at]ed
restrictions that have been imposed upon the
use of IDENTIFY proper.
It employs a preassembled n-element transfer vector, each element of which
is an eight-byte unsigned integer in the sequence
0, 1, 2, . . . , n - 1,
i.e., a zero-origin array of n elements having its subscripts as the values
of these elements, that is bound as a single-RSECT program object, call it
RANKS000, and brought into storage in the usual way.
A management program elsewhere keeps track of the number
0 <= u <= n
of elements of this array that are in use, have been assigned as the rank of
a virtual-storage address for which pseudo-VERIFY facilities are required.
A necessarily unique name for such an address, call it GUBBINS0, is chosen;
and a traditional IDENTIFY is used to create a CDE for GUBBINS within the
RANKS000 program object at the address
addr(RANKS000) + 8u,
after which u is incremented by 1. A STORAGE macro followed by a directed
LOAD for GUBBINS0 then yields the load address of GUBBINS0, which the
management program stores as the corresponding element of ANOTHER array,
this one a dynamic one that can be stored into. The rank found at the
address for which IDENTIFY has created a CDE for GUBBINS0 can then be used
to address this second address array to obtain the actual virtual-storage
location of GUBBINS0.
This management program uses a dedicated register, DXD, CXD, etc., i.e., the
HLASM analogues of PL/I controlled storage, to manage the dynamic storage it
uses efficiently.
Described in extenso this scheme sounds complicated. In fact it is nothing
but a very simple indirect-addressing one.
Its chief limitation is that n is fixed when RANKS000 is assembled. Its
chief merit is that busybodies will find it all but impossible to interdict
its use or that of schemes like it. (I have no objection, I indeed welcome,
legitimate security precautions; but this one was larger than life,
interdicted too much; and its circumvention is entirely appropriate.)
John Gilmore
Ashland, MA 01721
USA
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
----------------------------------------------------------------------
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
