On 06/13/2017 09:06 PM, John McKown wrote:
On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills <charl...@mcn.org> 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).
<SNIP>

Me thinks you are missing something.

However, data set names and/or code paths are an interesting thing to hold in your storage that is anchored out of the User's Anchor Table.

When I started working with this many years ago, I immediately started thinking about how to use that anchor point to allow cross product communications, should ACS ever acquire another company that had a product.

So as Charles Mills said, one really needs to think about how to use this (and now I will add to what he said) before one paints themselves into a corner and this anchor point becomes a problem.

That "Think about how your customer will recover without an IPL if the tables become corrupted." is a very interesting statement.

So, running a chain to get to your anchor is not that big of a deal, AND, if your product is starting up, it can, from any address space, find out if it had been running, or if any of its compatriots are running and change its start up code paths accordingly.

Regards,
Steve Thompson

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to