  Tracking Global Section Accessors? (take II) 
 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.
 
 
