OC.HANLEY@CU20B.COLUMBIA.EDU (John Hanley) (11/14/86)
Is there anyone on DECnet reasonably close to Columbia that could send me
the DECUS C compiler or any other public domain CC? Is it huge, should I
send a magtape instead? We just got the DECUS spring and fall '85
distributions and were terribly disappointed that CC wasn't updated and
redistributed in '85. A copy of PME (performance monitor) would be
appreciated, too.
Regarding that problem of dynamically mapping 12 character usernames to
10 characters for net dealings with an IBM and then back again, I suggest
the following:
Consult your Internals book (what? You don't have a copy?! Obtain one
immediately from Digital Press: "VAX/VMS Internals and Data Structures,"
(c) 1984 by DEC) and look at the PCB docs on pages 445 and 751.
All kinds of UAF parameters set by LOGINOUT.EXE can be changed on the fly
by an image installed with CMKRNL that modifies the Process Control Block.
I have personally used this technique to change UIC from within an image
rather than doing a DCL $ SET UIC, so I assume it should work on username
as well. I have also successfully used CMKRNL to elevate WSEXTENT (in the
process header) above UAF-authorized values for running particular images
with huge physical memory requirements (ie, Lisp). Your kernel mode
routine could blank out the last 2 characters of a 10 character username
(I think) with something like
MOVL @#SCH$GL_CURPCB, R0
MOVW #^X2020, PCB$T_LNAME+10(R0)
Later, when you finish talking to the IBM, do a $GETUAI and another
kernel mode MOVW to restore those two characters. If this does what
I think it will, any $GETJPI's, such as done by a $ SHOW USERS, will
return the current 10 character username until it is restored. I have
not tested this out because I CAUTION YOU that while debugging kernel
mode routines it is TRIVIALLY EASY to crash the system. You suddenly
find yourself yearning for ACCVIO stack dumps because a kernel mode
access violation generally shows up not as a symbolic stack dump but as
a crash message on OPA0. You should therefore test all this black magic
late at night with few or no users on, and preferrably with all but one
disk dismounted so it doesn't take forever to rebuild them when the system
comes up again. I will vouch for the effectiveness of this technique if
the parameter to be changed on the fly is the UIC [use
MOVL @#SCH$GL_CURPCB, R0
MOVL new_uic, PCB$L_UIC(R0) ]
because I HAVE tested that one and actually accessed files with unpriv'd
accounts that would ordinarily be protected.
As mentioned above, I have also used kernel mode to increase working sets
temporarily by changing PHD$L_WSEXTENT beyond what it's supposed to be,
running a particularly large image, and then making sure that at image
exit or ^Y a $ SET WORKING_SET/EXTENT=10000 is done to set WSEXTENT back
to the largest authorized value. This leads naturally into a flame on
VAX/VMS image activations. Rather than coping with exceptional cases by
activating an installed image to do the above kludgery, then run the
program of interest, then use a third image activation (SET) to restore
things, it would be nice if suitably privileged users could grant WS
parameters (DEFAULT, QUOTA, and EXTENT) to frequently used programs whose
paging behaviour was well understood. The image activator would then
stuff these values into the PCB and restore on image exit, at almost no
cost of extra overhead. The benefit would be WS parameters tailored to
particular images rather than the "one size fits all and if you page a lot
you'll eventually get more memory" approach used now. Any V5.x implementors
listening?
John Hanley, system programmer
Manhattan College Computer Center
Box 902, Manhattan College
Riverdale, NY 10471
(212)920-0424
oc.hanley@cu20b
-------