Why are DCL.EXE and command tables opened twice?

[Jess Goodman]

Just noticed this issue on my VMS 7.3-2 and earlier systems. It's not causing a problem but I'm curious - is this a bug; some optimization for the more-common case; or what?

When a process logs in, if its command tables are not DCLTABLES (either via SYSUAF setting or via LOGIN's /TABLES=xtables qualifier), then the process will have two channels open for both SYS$SYSTEM:DCL.EXE and SYS$SHARE:xtables.EXE. When DCLTABLES.EXE is used there is only one channel each.

PLEASE SIGN ON--GOODMAN/NOCOMMAND/TABLES=DCLTABLES
Password:

$ ANALYZE/SYSTEM !from another process
SDA> SHOW PROCESS/CHANNEL GOODMAN
Process active channels

Channel CCB Window Status Device/file accessed
0010 7FF60000 00000000 AX38$DKA0:
0050 7FF60080 00000000 Busy LTA159:
0070 7FF600C0 00000000 LTA159:
00A0 7FF60120 822370C0 AX38$DKA0:[VMS$COMMON.SYSEXE]
DCL.EXE;1 (section file)
00B0 7FF60140 81DA6540 AX38$DKA0:[VMS$COMMON.SYSLIB]
DCLTABLES.EXE;178 (section file)

Total number of open channels : 5.
--------------------------------------------
$ SET DEFAULT SYS$COMMON:[SYSLIB]
$ COPY DCLTABLES.EXE NEWTABLES.EXE
$ INSTALL ADD SYS$SHARE:NEWTABLES/OPEN/HEAD/SHARE

PLEASE SIGN ON--GOODMAN/NOCOMMAND/TABLES=NEWTABLES
Password:

$ ANALYZE/SYSTEM !from another process
SDA> SHOW PROCESS/CHANNEL GOODMAN
Process active channels

Channel CCB Window Status Device/file accessed
0010 7FF60000 00000000 AX38$DKA0:
0050 7FF60080 00000000 Busy LTA161:
0070 7FF600C0 00000000 LTA161:
00A0 7FF60120 822370C0 AX38$DKA0:[VMS$COMMON.SYSEXE]
DCL.EXE;1 (section file)
00B0 7FF60140 822370C0 AX38$DKA0:[VMS$COMMON.SYSEXE]
DCL.EXE;1 (section file)
00C0 7FF60160 81B18580 AX38$DKA0:[VMS$COMMON.SYSLIB]
NEWTABLES.EXE;1 (section file)
00D0 7FF60180 81B18580 AX38$DKA0:[VMS$COMMON.SYSLIB]
NEWTABLES.EXE;1 (section file)

Total number of open channels : 7.

[John Gillings]

Jess,

The simple answer is "because" ;-)

Longer answer - I think it has to do with the way a process is started. You begin with DCLTABLES, then switch to the other tables, effectively by recursing into DCL.EXE with the new table. So, yes a kind of optimization for the common case.

Simple experiment - what do you get if you login and SET COMMAND/TABLE=NEWTABLES ?

If you want a complete explanation, you'll need to dig into the sources to see how login /TABLES is implemented (and be warned, it probably isn't very pretty, or easy to follow!)

Please ask yourself why you're using an alternate table. It's mostly just making work for yourself maintaining compatibility through upgrades. If you're doing it for "security" by deleting commands you don't want people to be able to execute... DON'T (or at least don't let anyone who knows what they're doing log into your "secured" accounts ;-)

[David Jones_21]

I imagine it's using the image activator to map the tables and VMS doesn't have a clean way to rundown just that image.