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). -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
