| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 629.1 | | BMT::MISRAHI | at the tone, please leave your ... | Mon Dec 14 1987 10:32 | 1 |
| Hopefully using GETUAI calls .
|
| 629.2 | Clarification | ENOUGH::HEAFEY | | Mon Dec 14 1987 11:15 | 5 |
| I should have specified in the topic note that I'm writing
this procedure in DCL. Sorry for the lack of info.
Dave H.
|
| 629.3 | | STAR::PIPER | Derrell Piper - VAX/VMS Development | Mon Dec 14 1987 14:28 | 19 |
| The UAF has four keys of which only 2 are currently used. The first
key is the 32 character space filled username. The second key is the
longword binary UIC. For example, the UIC [11,636] would be stored as
%X0009019E (remember that UICs are in octal).
But what does this have to do with opening the UAF shared?
If you want to open the UAF from DCL, you can do something like this:
$ SET PROC/PRIV=SYSPRV
$ OPEN/SHARE=WRITE/READ/WRITE UAF SYS$SYSTEM:SYSUAF.DAT
$ READ/KEY="PIPER"/INDEX=0 UAF RECORD
But you can't access the UIC from DCL because DCL can't deal with
binary keys.
Your best bet is to use $GETUAI/$SETUAI in an image. It'll be faster
and it won't break if we reformat the UAF in the future.
|
| 629.4 | read/index=1 sysuaf | FROST::W_PIPER | bill piper | Mon Dec 14 1987 15:35 | 19 |
| re: .3
>>> But you can't access the UIC from DCL because DCL can't deal with
>>> binary keys.
Sure it can. Like so (assuming Username = Identifier)
$ uic = f$identifier (f$getjpi(0,"Username"), "Name_to_Number")
$ key[0,32] = uic
$
$ Open /Read /Share=Write uaf Sys$System:SysUAF.dat
$ Read /err=99 uaf record /key=&key /index=1
$ User = f$edit (f$extract(4,32,record), "Trim")
$ Show Symbol User
$ 99:
$ close uaf
$ exit
-piper
|
| 629.5 | | STAR::PIPER | Derrell Piper - VAX/VMS Development | Tue Dec 15 1987 07:14 | 1 |
| Neat! Finally a real use for the "&" operator...
|
| 629.6 | "&" is buggy! | USHS01::BLANDO | Reality, what a concept! | Wed Dec 16 1987 20:16 | 7 |
| Actually, there would be many uses for the "&". I found one not
too long ago, but found a "glitch/feature" in that the CALL statement
and the "@" procedure invocation ignore it. I submited an SPR,
and was told to use the "'". Which did not help since I needed
the delaid translation of the "&" after "'".
FJBlando
|