Steve, This is exactly as Charles stated we want to do.
Scott On Tue, Jun 13, 2017 at 10:51 PM Steve Thompson <ste...@copper.net> wrote: > 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 > -- Scott Ford IDMWORKS z/OS Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
