|
HP OpenVMS Systemsask the wizard |
|
The Question is: Thanks for the answer to my question no. 3365 about tracking use of global sections. Your answer to question 2889 mentions (an undocumented) system service $SIGPRC. Can I use this service to solve the problem? All the processes involved already keep a table in local memory of the different named global sections that they map. Can I use this service to make them dump the table? How? Or can you point to info. or an exa mple? I have so far had no luck with either Compaqs website or Goldenbergs books. Another way I thought of is to have all processes also record the information in a single global section that then could be examined. The drawback concerns cleanup. I know of no way to ensure cleanup. The DCL command STOP (=$DELPRC) does not result in inv ocation of an already declared exit handler. $FORCEX does. But you cannot always be sure that that is the way these (detached) processes are deleted (by a user or another detached non-interactive process). Yet another way might be to somehow use locks ($ENQ/$DEQ) - maybe by encoding the id of process and global section in the ressource name. The advantage is cleanup for free by OpenVMS. The drawback is a solution that is misusing ressources. Common event flags is not an option. There is not enough of them. I could open up a hole in each process using a mailbox via which the process could dump the table. But I would like a less involved solution if possible. I also checked SDA. It does not provide this info - at least not readily available. Thanks. The Answer is :
If you know which global sections are mapped, then you can quite
clearly and quite certainly determine which global sections are
mapped to the process. (That much is axiomatic.)
If each process knows which global sections are mapped to the
local process, then -- by sharing that information -- other processes
can learn which sections are mapped to the target process.
If each process that maps global sections stores the information on
which global sections are mapped into a global section (rather than
in temporary local storage), then any other process that is interested
in this can map to that information, and then map itself (if required)
to the particular global section(s) required, and then dump the contents.
The name of the global section that contains the information on the
various global sections associated with the process can be built
from a known prefix and (for instance) the PID. This permits other
processes to quickly determine the name of the section, and it
avoids namespace collisions. (In general, just some basic header and
data structure version information, and a list of the names of the
mapped section should be stored in the section. With the normal
(and prefered) position-independent mapping, the virtual address
range that each section is mapped into is only of interest within
(and only within) each particular process.)
If you wish to implement some form of cleanup, then two of the usual
approaches are via records written to a disk file or via interprocess
coordination using the OpenVMS lock manager and an application-specific
cleanup process. In this particular environment, two other obvious
options exist: the (permanent) global section associated with each
process can use file-based backing storage in a known (and shared)
directory area, and a periodic (eg: hourly) scan of the files (and
the particular file names) in the directory and a match against the
currently-active processes that can easily detect obsolete files, and
that can thus delete the (permanent) global section and the backing
storage file -- this is effectively a variation of the shared section
discussed in your question. Alternatively and far more easily, simply
use the (default) temporary attribute for these global sections, as
temporary sections are cleaned up automatically when the last process
associated with (mapped to) the global section exits.
Discussions of "bridging" a data structure from a single (fixed-size)
global section into multiple global sections -- when many sections are
mapped to the process -- is left as an exercise to the reader.
Reliance on internal or undocumented features is generally not
recommended, particularly if there is an approach available that
relies on documented features. If you do decide to use internal
or undocumented features, then a supremely useful resource -- in
addition to the OpenVMS Internals and Data Structures manual -- is
the OpenVMS source listings.
QB-MT1AB-E8 OpenVMS Alpha Source Listings CD-ROM
QT-MT1AB-Q8 OpenVMS Alpha Source Listings CD-ROM Updates
QB-001AB-E8 OpenVMS VAX Source Listings CD-ROM
QT-001AB-Q8 OpenVMS VAX Source Listings CD-ROM Updates
If you require general application design assistance, please consider
contacting (and potentially contracting with) Compaq Services.
|