From: CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 21-JAN-1989 07:43 To: MRGATE::"ARISIA::EVERHART" Subj: Re: Problem with $SETUAI, help needed Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Wed, 4 JAN 89 20:57:02 PDT Received: from gold.bacs.indiana.edu by KL.SRI.COM with TCP; Wed, 4 Jan 89 20:41:37 PST Date: 4 Jan 89 23:14:00 EST From: "IVAX::IJAH400" Subject: Re: Problem with $SETUAI, help needed To: "info-vax" [] Hans Sundstroem , writes: >Hi, > >I have a problem that I cant solve. I'm trying to use SYS$SETUAI (from fortran) >with the itemlist > > itemlist(10).bufflen=9 > itemlist(10).itemcode=UAI$_account > itemlist(10).address=%LOC(account) > itemlist(10).retlen=%LOC(acc_len) > itemlist(n).endlist=0 > >and the call is STATUS = SYS$SETUAI ( ,,USERNAME,ITEMLIST,,,). > >I'll have other items at the same time, if i remove itemcode UAI$_ACCOUNT >status is 1 = success. But with above lines i always get STATUS to SS$_BADPARAM >=20 , it dosn't matter if i the only item in itemlist is UAI$_ACCOUNT. > >Im using VMS 5.0-2. > The $SETUAI documentation is incorrect. The UAI$_ACCOUNT item is an 8 character blank-filled string (the documentation is correct about that). The documentation then goes on to mention a byte sized prefix (contradicting itself), and thus that a buffer length of 9 bytes is required. This is not true. $SETUAI always will write 8 bytes, blank filled, and will return SS$_BADPARAM for any buffer length greater than 8. The V5.0 documentation is still incorrect, but I have only demonstrated this problem under V4.7 (we aren't running V5.0 yet but this sounds like your problem). Other $SETUAI documentation errata that VMS wizards may wish to know: o The V4.7 $SETUAI documentation leaves out a null argument in the argument list description. There are three null arguments after the itmlst argument, not two (just like $GETUAI). The documentation has been corrected for V5.0. o There is a UAI$_USERNAME argument mentioned in the V4.7 documentation Just for laughs I tried setting this under V4.7; it fails. Not suprising, since the username is the primary index of the UAF! What would it mean to "set" the username? ("delete" the record and re-insert it with a different primary index??) o The documentation on the UAI$_PWD_LIFETIME (for both $SETUAI and $GETUAI) describes it as a quadword absolute time value. It may actually be (and is usually more usefully used as) a quadword deltatime value. o The item UAI$_PWD_DATE (date password was last set) cannot actually be set, at least in V4.7. Pre-expired passwords have this set to quadword -1 (this is an exception as this is always an absolute time value, so -1 can mean pre-expired). Since you can't set this, you can't pre-expire the password with $SETUAI (AUTHORIZE can of course, but it doesn't bother with the documented interface, $SETUAI, at least in V4.7). o Some (quota) items really take 0 as meaning "infinite" (the ones usually described as taking a value "1 to 65535"). I guess I shouldn't complain too much; it doesn't appear that $SETUAI is finished yet. If DEC's goal is to provide a documented interface to the UAF, it still needs: o A way to add new UAF records. o A way to set passwords. Setting the hashed password is useless if there is no interface to the hashing routine, currently there isn't. This would be required to implement the previous item also. Then we could complain about not being able to pre-expire them :-)). o A way to delete UAF records. o A way to find unused UIC member and group numbers. You can currently do this without knowing anything about the layout of the file using RMS, as it can be coaxed into telling you whether a particular value of a secondary index (the UIC is a secondary index for the UAF) is in use or not. So maybe this workaround isn't "cheating" (as grubbing around in the fiche to find the layout of the UAF record isn't required). >BTW. I found an error in the docmentation for UAI$FLAGS the described login >flag UAI$V_FORCE_EXP_PWD_CHANGE on page SYS-435 (system service reference >manual) should be UAI$V_DISFORCE_PWD_CHANGE. For many large systems, DEC's usual "System manager sits down and runs AUTHORIZE" approach is simply out of the question. If DEC's not going to give us anything better than AUTHORIZE, then it would be nice if they finished $SETUAI/$GETUAI so we could write something that wouldn't break if the format of the UAF changes... Currently, we are still cheating (but at least I don't have to spend days running AUTHORIZE ;-) - Jim Harvey, IUPUI Computing Services (Indiana University) Internet: IJAH400%IVAX.DECNET@GOLD.BACS.INDIANA.EDU BITNET: IJAH400@INDYVAX