NAME/TOKEN would be a lot more flexible and would not require IBM's involvement
but I have to think the code path for the anchor is a heck of a lot shorter, at
least not counting any validation of version, length, etc.
L 15,16 Load CVT from PSA
L 15,X'8C'(,15) Load ECVT from CVT
L 15,X'CC'(,15) Customer Anchor Table from ECVT
ICM 15,B'1111',nnn(15) Ptr f/Cust Anch
JZ NotThere Not running
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of John McKown
Sent: Tuesday, June 13, 2017 6:06 PM
To: [email protected]
Subject: Re: IBM customer anchor
On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills <[email protected]> wrote:
> As a user of the word, you really, really want to think about upward
> compatibility. Don't store the address of your product's anchor table
> there. Assume you will someday have multiple products. You would want
> to store the address of a vector of anchor table addresses. Think
> about upward compatibility for the layout. Include a length and a
> version number in your vector. Clear everything unused to zero. Think
> about how your products will cooperate if product A starts up first; or if
> product B starts up first.
>
> Think about how your customer will recover without an IPL if the
> tables become corrupted.
>
> Charles
>
Hum, I'm likely missing something, but my thought is to just use a global
NAME/TOKEN pair. Of course, I don't know the relative CPU efficiency of using
that versus "chain chasing" from the CVT. If necessary, the NAME portion could
be an initialization parameter just in case some other "product" used the same
one. It could be set via a configuration CSECT, which is compiled into the
execution library & LOADed. Or specified in the PARM= on the EXEC. Or even in a
DSN specified using a DD. For the truly weird, make the "configuration
repository" a "hard coded" UNIX file name such as /etc/<product>.conf where
<product> depends on what you call your product (e.g. /etc/sdsf.conf for the
SDSF parameters).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
