[mod.computers.vax] VMS: deassigning logical names from the /job table

GROPP-BILL@YALE.ARPA (03/21/86)

I have a program which uses the /job table to communicate startup information
to various processes.  However, the names entered into this table can
not be deleted by the user.  If you do a SHO LOG/JOB/ALL, they show up,
but if you try to do a DEASSIGN/JOB name, you get "no logical name match".
From a program, you can translate the name correctly, but not delete it
(no such logical name).  DEASSIGN/JOB/ALL does get rid of them (and lots
more besides).  We are running VMS 4.3.  Does anyone have any ideas on
what I'm doing wrong, or if this is a known problem with a work-around?
                                            Bill Gropp
-------

LEICHTER-JERRY@YALE.ARPA (03/22/86)

    I have a program which uses the /job table....  However, the names
    entered into this table can not be deleted by the user.  If you do a
    SHO LOG/JOB/ALL, they show up, but if you try to do a DEASSIGN/JOB name,
    you get "no logical name match".  From a program, you can translate the
    name correctly, but not delete it (no such logical name)....

                                                Bill Gropp
In VMS V4 (unlike earlier versions of VMS), ALL logical name tables have four
levels of names in them, corresponding to the 4 access modes of the VAX pro-
cessor.  User programs, normally running in user mode, create user-mode logi-
cal names.  DCL, running in supervisor mode, normally manipulates only super-
visor mode names.  DEASSIGN, for example, deassigns such names only; you can
specify /USER on the DEASSIGN to have it affect user-mode names instead.
SHOW LOGICAL displays names at ALL access modes unless you specify otherwise
(/ACCESS_MODE qualifier).  Similarly, the $CRELNM and $DELLNM system services
each have an optional argument (acmode) which specifies the access mode to
operate on.  (For a user-mode program, there is no point in specifying this
argument - you can only get to a LESS privileged mode through it, not a MORE
privileged mode.)

User-mode programs can manipulate supervisor-mode logicals by calling back to
DCL.  It does not appear that this is what you are doing.

The interaction of user-mode logical names with user-mode image rundown is
commonly misunderstood.  A user-mode image rundown deletes all user-mode
logicals in PROCESS-PRIVATE tables.  (Previous to V4, this amounted to all
possible tables.)  User-mode logicals in SHARED tables - such as the JOB table
- are not affected.

The /FULL qualifier on SHOW LOGICAL will display the access mode associated
with a logical.  Take a look at the logicals you've created and make sure
your various attempts to create and delete them all occur at the same level.

							-- Jerry
-------