Using the SYS$GETUAI and SYS$SETUAI I am maintaining employee information in
the SYSUAF file (uai$_user_data area).

The application I wrote up works for almost every account (1500 or so) however
does not work on a handful (12 or less).  The application READS (getuai) the
uai$_user_data then changes the value and then WRITES (setuai).

I was racking my brains out on this and decided to delete the problem account
and re-add it.  Subsequently, the update to uai$_user_data worked.

Has anyone experienced this?


J*o*h*n B*r*a*n*d*o*n
VMS Systems Administrator
firstname.lastname.spam.me.not@dalsemi.com

In article <04071214573260@dscis6-0.dalsemi.com>, brandon@dalsemi.com (John Brandon) writes:
:...maintaining employee information in the SYSUAF file (uai$_user_data area).
...
:The application I wrote up works for almost every account (1500 or so) however
:does not work on a handful (12 or less).  The application READS (getuai) the
:uai$_user_data then changes the value and then WRITES (setuai).
:
:I was racking my brains out on this and decided to delete the problem account
:and re-add it.  Subsequently, the update to uai$_user_data worked.
:
:Has anyone experienced this?


  FWIW, I don't generally recommend using the UAF for the storage of user
  data, the existence of the itemcode aside.   This for various reasons,
  not the least of which is a complete lack of coordination across any
  potential users of UAI$_USER_DATA.

  Check that there is not already somebody else using the SYSUAF record
  in other words, or something else odd about the particular UAF record
  itself.

  It is much safer -- and just as supported -- to use a private file for
  this and other data.  I use tools which regularly synchronize with the
  current records stored in the SYSUAF, keeping the side database file
  current with the status of the records in the main SYSUAF ile.


 ---------------------------- #include <rtfaq.h> -----------------------------
    For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
 --------------------------- pure personal opinion ---------------------------
        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com

In article <04071214573260@dscis6-0.dalsemi.com>, brandon@dalsemi.com (John Brandon) writes:
> Using the SYS$GETUAI and SYS$SETUAI I am maintaining employee information in
> the SYSUAF file (uai$_user_data area).
> 
> The application I wrote up works for almost every account (1500 or so) however
> does not work on a handful (12 or less).  The application READS (getuai) the
> uai$_user_data then changes the value and then WRITES (setuai).
> 
> I was racking my brains out on this and decided to delete the problem account
> and re-add it.  Subsequently, the update to uai$_user_data worked.

Are you certain you are using the first byte of the field as a count ?

In article <IXDIc.5711$_u.867@news.cpqcorp.net>, hoff@hp.nospam (Hoff Hoffman) writes:
> In article <04071214573260@dscis6-0.dalsemi.com>, brandon@dalsemi.com (John Brandon) writes:
> :...maintaining employee information in the SYSUAF file (uai$_user_data area).
> ..
> :The application I wrote up works for almost every account (1500 or so) however
> :does not work on a handful (12 or less).  The application READS (getuai) the
> :uai$_user_data then changes the value and then WRITES (setuai).
> :
> :I was racking my brains out on this and decided to delete the problem account
> :and re-add it.  Subsequently, the update to uai$_user_data worked.
> :
> :Has anyone experienced this?
> 
> 
>   FWIW, I don't generally recommend using the UAF for the storage of user
>   data, the existence of the itemcode aside.   This for various reasons,
>   not the least of which is a complete lack of coordination across any
>   potential users of UAI$_USER_DATA.
> 
>   Check that there is not already somebody else using the SYSUAF record
>   in other words, or something else odd about the particular UAF record
>   itself.
> 
>   It is much safer -- and just as supported -- to use a private file for
>   this and other data.  I use tools which regularly synchronize with the
>   current records stored in the SYSUAF, keeping the side database file
>   current with the status of the records in the main SYSUAF ile.
> 

	That field is a good place to stuff information that normal
	prying eyes won't see.  Additionally, the owner field is not a good
	place as finger will show that.  Yes, go around and disable finger.

	But in the age of Identity Management - it is necessary to *know*
	who you are disusering/removing.  As the employee count sky
	- rockets , there are many opportunities for error short
	of having identifiable information at the ready.  Create separate
	tools, methods?  Why?  setuai/getuai and the uai$_user_data
	field is there and numerous Googles don't even reveal a hint
	of "unsafeness."  Separate tools/methods?  One more thing to
	support and sell to management?  I don't think so.  Creative
	solutions when looked at years later are often very very painful
	to support (unless of course Hoff or equivalent are writing/documenting
	).  

	And oh... when that side database gets stomped on or corrupted.
	A flat file?  How does it scale?  Insertions, deletions.  An index 
	file?  And who does that bit of programming?

	Any hints as to why things aren't safe with setuai/getuai?

				Rob

Kilgallen@SpamCop.net writes:

> > Using the SYS$GETUAI and SYS$SETUAI I am maintaining employee information in
> > the SYSUAF file (uai$_user_data area).
> > 
> > The application I wrote up works for almost every account (1500 or so)
> however
> > does not work on a handful (12 or less).  The application READS (getuai) the
> > uai$_user_data then changes the value and then WRITES (setuai).
> > 
> > I was racking my brains out on this and decided to delete the problem account
> > and re-add it.  Subsequently, the update to uai$_user_data worked.
> 
> Are you certain you are using the first byte of the field as a count ?

I am not aware of this.  Will look into. 


J*o*h*n B*r*a*n*d*o*n
VMS Systems Administrator
firstname.lastname.spam.me.not@dalsemi.com

In article <IXDIc.5711$_u.867@news.cpqcorp.net>, hoff@hp.nospam (Hoff Hoffman) writes:
> In article <04071214573260@dscis6-0.dalsemi.com>, brandon@dalsemi.com (John Brandon) writes:
> :...maintaining employee information in the SYSUAF file (uai$_user_data area).
> ..
> :The application I wrote up works for almost every account (1500 or so) however
> :does not work on a handful (12 or less).  The application READS (getuai) the
> :uai$_user_data then changes the value and then WRITES (setuai).
> :
> :I was racking my brains out on this and decided to delete the problem account
> :and re-add it.  Subsequently, the update to uai$_user_data worked.
> :
> :Has anyone experienced this?
> 
> 
>   FWIW, I don't generally recommend using the UAF for the storage of user
>   data, the existence of the itemcode aside.   This for various reasons,
>   not the least of which is a complete lack of coordination across any
>   potential users of UAI$_USER_DATA.
> 
>   Check that there is not already somebody else using the SYSUAF record
>   in other words, or something else odd about the particular UAF record
>   itself.
> 
>   It is much safer -- and just as supported -- to use a private file for
>   this and other data.  I use tools which regularly synchronize with the
>   current records stored in the SYSUAF, keeping the side database file
>   current with the status of the records in the main SYSUAF ile.

I second that emotion.  When I was working as a third-party VMS
product developer I inherited a product that did UAF stuff.  It
would use the user data area for some of its "special" stuff. 
All was well until a customer had their own homegrown user data
munger that creamed the special stuff.  I updated the product
after that to use its own rms index file to handle the special
stuff.  Less tears and tearing of hair that way.