[Info-vax] Removing /identifier from rights list

[Hein RMS van den Heuvel]

On Thursday, September 25, 2014 1:19:22 PM UTC-4, Craig A. Berry wrote:
> On 9/24/14, 10:08 AM, RGB wrote: 
> > Hi Steve,
> > Oddly, an analy/rms/check returned no errors with my rightslist.dat file.

Why is that odd? Rightslist file, rms indexed files in general rarely get corrupted. And if they do you'd typically get a hard message on access.

> >  The value of the identifier is okay i.e, %X8... but the name which should be associated with the value is all screwed up in some instances.
> > ........>....................... %X8001013C
> > This is a direct copy and past from a specific user account.  

So this is 'bottom line' output for MCR AUTHORIZE SHOW <user>/RIGHTS ? right?

Now let's use: 

MCR AUTHORIZE SHOW /iden/value=id=%X0001013C

And let's look with DCL:

$ open/read/write/share=write r rightslist
$ k="1234"
$ k[0,32]=%X8001013C
$ read/key=&k r record
$ show symb record

btw... You can also delete the record like so:

$ read/key=&k/delete r record

Only one gotcha. Can anyone guess?

Allthough we tell DCL to postpone value interpretation/interpolation with the "&" it still looks into the bytes.  If the is a double-quote valued byte in there ( 0x22 = 34. ), you have to double it up! Nasty.

Finally DUMP a few records. Trial and error, 
Pick a start number towards the end of the file. If there are 500 entries, pick 450?

$ dump /reco=(start=50,count=5) rightslist/wid=80

Show us the one for 8001013C ?


Craig> Did you by any chance (accidentally) sort the file? You could easily
> scramble the association of an identifier name (key 2) with the
> identifier value (key 0) or holder (key 1). 

I don't think that's correct. When you sort entire records get sorted the columns travel together. After a sort, they'd supposedly converted... and be back in normal primary key order: the ID.

Craig> Only the first record in a series contains the name, so if that record got moved to the middle or end of a section, the preceding records would be unlikely to display the correct name.

Again, I don't think that's correct. 
What makes you think it works that way?
If one were to DUMP the SIDR bucket for key #2 = "NAME" then yeah, you'd sort of see that thanks to repeating leading byte compression in RMS.
Programs will never see that though.


Cheers,
hein