Subject: | |
From: | |
Reply To: | |
Date: | Wed, 22 May 2002 18:00:36 -0600 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Paul writes:
> This information has also been educational for me. While I finally got a
> better understanding of Local Attributes and in some ways share the
> concerns mentioned by Tracy, it also pointed out another problem with this
> 'hiding' feature.
>
> Supposing that you had an application and you adjusted its Local attribute
> 'bit mask' to indicate the temporary unavailability of a certain subsystem
> (easier to do it there than changing the attributes of the user base that
> had access to the subsystem). Then suppose that you need to move the
> application to another machine and decide to use 'BULDACCT.PUB.SYS'. The
> user local attribute that will be stored in the 'BULDJOB1' file will be the
> 'new logical AND' of the user attribute and the changed account attributes.
> When the job is executed on the new machine an 'incorrect' user attribute
> value will be applied and thus cause all kinds of confusion when the
> subsystem is re-enabled.
>
> Regards
> Paul Christidis
>
> Question to Bill Cadier:
> Is there a command that will show the 'hidden' value of the user's
> local attribute value?
>
I could not find one.
I found a system on 5.5 that had a copy of MPEX and it did not display the
unfiltered local attribute. Maybe newer copies do? Or maybe I don't know how to
run MPEX properly? Didn't the old MPE V/E "LISTDIR5" program do this?
I seem to recall but it's been years since I've been near one of those systems :)
The only method I could locate that would show the raw local attribute is using the
AIFACCTGET intrinsic with item 6008. I cobbled up a test and that does work.
I also checked our support database for any references to this and I could find
only 1 service request filed back in 1994 that discussed the same scenario with
BULDACCT and using local attributes that did not get copied correctly to a new
system. The SR number is 5003-229096 and it has no duplicates. It did give a work-
around of setting the account local attribute to $ffffffff (all bits on) prior to running
BULDACCT. That sounds a bit cumbersome except in the simplest of cases. The
enhancement was also not implemented and I can't say why except that it was routed
to BULDACCT and maybe should not have been.
I would have expected that adding ;PASS to the LISTUSER command would cause
it to display the raw local attribute. I was surprised it didn't. Perhaps this is an enhancement
request if anyone would like to ask their friendly Response Center to file it on their behalf?
Bill
HP/CSY
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
|
|