XX:GTDOM.DOC.5, 9-Sep-88 01:46:07, Edit by SRA This file contains information you might want to know before attempting to install the MIT GTDOM% code in your monitor. See GTDOM.MAN for the standard JSYS documentation page. THINGS YOU SHOULD KNOW ABOUT GTDOM.MAC GTDOM% should assemble correctly for TOPS-20 releases 5.4, 6.1, and 7.0. In 6.1 and 7.0 GTDOM runs in extended swappable code, in 5.4 it's in normal swappable code. In all cases there's about a dozen words of resident code (scheduler tests). There is no saved state between GTDOM% calls, and the only global storage is one word for the resolver's slot in the special PID table. Stack usage is minimal. One page of JSB free space is used as a buffer for IPCF messages. As currently written, GTDOM% is just a user interface to the resolver. GTDOM% does not have any access to the domain database except through the resolver. Long range plans for GTDOM% include a monitor cache of query/answer pairs so that repeated questions can be answered without having to invoke the resolver; if implemented this will require some storage for the cache, probably about thirty non-resident pages. This will, however, be purely a performance tweak; GTDOM% still won't have any special access to the domain database, it will just have its own cache so that it needn't incur the overhead of asking the resolver the same question 200 times in a row. You can use the resolver without GTDOM% if you prefer. You can also also assemble GTDOM.MAC as a user context library and link it into programs. The advantages of the JSYS version are: scheduler tests to time out queries when the resolver is losing and to allow the resolver to "do nothing" in an efficient manner, compatibility with older programs that used GTHST%, access to the shared monitor cache if/when it is implemented (which could be done in user context via a mapped file if you really wanted it that way), and access to the monitor's IP routing tables. GTDOM% uses paged IPCF from monitor context to communicate with the resolver. DEC didn't support this until release 6 of TOPS-20, so to run GTDOM% under release 5 you have to make a few patches to IPCF.MAC. As of release 6 DEC still doesn't support paged IPCF into monitor context, so this must be added in both releases. There are also two accessor routines that must be added to IPCF.MAC in all releases; these provide a clean way for GTDOM% to use a more complicated scheduler test that allows it to time out if the resolver is taking an inordinately long time to answer a request (this same code is also used by the resolver to dismiss itself when idle). Fortunately, both of these routines are quite short and consist almost entirely of calls to existing utility routines, so it should be possible to patch all this into a monitor built at a non-source site if absolutely necessary. GTDOM% also needs to access a few existing routines from IPIPIP.MAC, in order to check the resolver's Internet Queue Handle for validity and do some address prioritizing. This requires making a few local addresses global, which is trivial even in a non-source monitor. Sites that run subnetting or in other respects have non-standard IP code might want to supply their own prioritizing routines, using the default routines in GTDOM.MAC as a model. Presumably any site that is running non-standard IP code is a source site. We have worked out the support needed for GTDOM% in the field test version of TOPS-20 7.0, and DEC has told us that they intend to put the required patches onto an autopatch tape (it won't be in time to be shipped with the intial release of 7.0, unfortunately), so in the long run it should be practical for non-source sites to run GTDOM%. Interested parties should contact BUG-CHIVES to find out what the current state of affairs is. FILES YOU NEED FROM THE CHIVES DISTRIBUTION You need two files to build the GTDOM module, besides the normal monitor files: GTDOM.MAC and DOMSYM.UNV. GTDOM.MAC is, of course, the source code. DOMSYM.UNV is generated from the concatenation of several files which contain definitions of constants from the domain RFCs and definitions specifying the message protocol used between GTDOM% and the resolver. Generate DOMSYM.UNV by doing @COMPILE @DOMSYM.CMD DOMSYM.CMD has all the right files in the right order. Copy the resultant DOMSYM.UNV to your monitor directory, along with GTDOM.MAC. You don't want to just append all the files together to make a single source file for DOMSYM: this defeats the purpose of having all the definitions in a single place (USRDEF.D and RFCDEF.D); using the method described here allows the EXEC to check the file dates and correctly determine when DOMSYM needs to be recompiled. Obviously, if you recompile DOMSYM you should also force a recompilation of GTDOM. EXISTING MONITOR MODULES YOU NEED TO CHANGE STG.MAC: SPIDTB needs to grow by one word, INTQSP needs to become resident. See STG.ADD. MONSYM.MAC: GTDOM% JSYS, function codes, flags, error codes. Need to assign a new special PID symbol, .SPRSV (resolver). See MONSYM.ADD. IPCF.MAC: Rel 5 paged mode support (if needed), accessor routines as described above. See IPCF.ADD. IPIPIP.MAC: CHKIQ routine needs to be made global, some minor hooks for prioritizing IP addresses need to be added. See IPIPIP.ADD. Once you have all the above taken care of, you should be able to compile GTDOM and link it into the monitor in the usual way. The resultant monitor doesn't need any special files to boot. When in the normal course of events a resolver signs itself on (by stuffing its PID into SPIDTB[.SPRSV]), GTDOM% should start returning results; if there isn't a resolver available, GTDOM% will give an error return as soon as it is able to detect that fact. No special action is needed if a resolver crashes, just reboot the resolver fork and things should work again. In other words, GTDOM% should be relatively painless to install, should require no special care and feeding, shouldn't be able to hurt you at all if you don't use it, and doesn't do anything complicated enough to hurt you severely if you do use it. If correctly installed, the worst thing that should happen is that GTDOM% won't be of any particular use until somebody fixes whatever is keeping GTDOM% and the resolver from functioning properly.