[Info-vax] Long uptime cut short by Hurricane Sandy

[Richard B. Gilbert]

On 2/10/2013 4:58 PM, AEF wrote:
> On Feb 10, 9:57 am, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
> wrote:
>> On 2013-02-10 04:11:28 +0000, AEF said:
>>> On Feb 8, 9:15 pm, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
>>> wrote:
>>>> On 2013-02-06 01:00:46 +0000, AEF said:
>>
>>>>> On Feb 5, 10:48 am, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
>>>>> wrote:
>>>>>> So you are seeking a key-value data store, something that logical names
>>>>>> classically excel at stinking at.
>>
>>>>> I'm not familiar with the term key-value data store.
>>
>>>> In RMS terms, think "indexed file".  You have a Key.  And you have a
>>>> Value associated with it.
>>
>>>>> And I take it
>>>>> you're saying that for this purpose, logical names stink well.
>>
>>>> Ayup, logical names commonly used for this, and I've used them for this
>>>> myself, and I've learned to completely despise this approach.
>
> So LNM's are good at stinking. And interesting way to put it.
>
>>>> Logical names are a disaster for this usage; for storing information
>>>> and for storing and retrieving preferences data, or application data.
>>
>>>>>> Logical names got us the morass that is the DEC C feature logical
>>>>>> names, after all.
>>
>>>>>> Sure, it works.
>>
>>>>>> At least until you trip into some other user; a collision.
>>
>>>>>> Or you need to scan all keys, as both VMS and environment variables
>>>>>> lack wildcards.
>>
>>>>> In TO.COM you can set it so that all its logical names start with
>>>>> TO_ . This should avoid a collision. Instead of TO_0, TO_1, TO_2,
>>>>> etc., I prefer HERE, LAST, 2BACK, 3BACK, . . . . They're much easier
>>>>> and faster to type, and that has never cause me a problem. If it does
>>>>> cause a problem you can instead use the TO_ versions. So where's the
>>>>> problem?
>>
>>>> The problem is you have a crap-ton of random logical names, with no
>>>> connections, with the possibility collisions, with no clean-up
>>>> mechanisms, and usually then with the general disaster that the DECC$
>>>> mechanisms have garnered themselves.
>>
>>> Well, the ones that start with TO_ are not random. Sorry, connections
>>> to what?
>>
>> To each other.  You have a crap-ton of logical names.  Inherently
>> isolated from each other, save by unenforced and unenforceable program
>> conventions, and easily subject to collisions, removal or otherwise
>> messed with.  Your logical names are further not prefixed, which was
>> the convention for avoiding collisions.  By "isolated", I mean there's
>> no way you can remove all entries, or scan entries, save through the
>> conventions.
>
> So by collisions you mean the same LNM may be used by different
> programs?
>
> Yes, these LNM's can be messed with, but they are in my own process
> table, and I know what's going on in it.
>
> They _are_ prefixed. Well, you have a choice: Use the ones prefixed by
> TO_, or use the easier ones HERE, LAST, 2BACK, . . . . I know that the
> latter won't conflict with anything I use, so that's what I use, as I
> find it easier to type 2BACK than TO_2. Other users can stick to the
> set prefixed by TO_ , in which case _all_ LNM's in TO.COM are prefixed
> by TO_ . This is the default.
>
> I believe this prefix method is in your DCL book, which I read and
> learned much from. (Although not for LNMs? [my copy is at work, so I
> can't verify right now].) Thanks!
>
>> By "connections", compare logical names with how the records in an
>> indexed file or the cards in a deck of punched cards can be scanned in
>> order, without regard to what's present and what's not in the settings,
>> and a file or a card deck can be (barring clumsy operators) kept
>> together as a unit for processing.  Can you do this with logical names?
>>   Not really.  You get to do your own housekeeping of all the logical
>> names.
>>
>> Feasible?  Sure.  Pain in the rump?  Can be.  Hard to deal with
>> collisions and missing logical names, because somebody hit a ^Y at the
>> wrong moment, procedure crashed out, somebody else defined a logical
>> name in your namespace, because somebody installed a new version of
>> TO.COM that works somewhat differently?  Definitely.
>
> I took care of the ^Y problem. I worked very hard on that. I was able
> to put out a warning when the logical names might not all be up to
> date.
>
> TO.COM crash? I put in error handling that should take care of that,
> at least by giving a warning that the LNM's may not be up to date.
>
> No one else can mess with my logical names. They are process-private.
> A program I run can, but I know what I'm running.
>
> You can use CLEAR-TO-LNMS.COM, which is part of the TO.COM package, to
> delete all LNM's created by TO.COM.
>
> Upgrades? I'd have to look at my previous manuals to see if any
> upgrades caused a problem with the LNM's. I don't think so. It might
> have happened once for something, in which case I did mention it in
> the manual or release notes. And if you don't read them, well, too
> bad. If I ever do write a new version, I'll be sure to keep this in
> mind.
>
>>> Also, I am not familiar with the DECC$ disaster
>>
>> Yeah; read my various previous dissertations on that topic.
>> /non-modular DEC C feature logical name morass/ or some permutation
>> should get you fairly close.
>> In simplest terms, it's the storing-key-value-data-in-logical-names
>> design, but yet more problematic due to how the settings can hang
>> around and derail subsequent (and potentially unrelated) image
>> activations.
>
> But this doesn't happen only with LNM's:
>
> This also happens with the Filter setting in the "Export with
> QuickTime" function in iMovie '09 and '11! By default iMovie applies
> the last used settings. But one of them is a full-blown one-shot deal.
> It is the "Filter" function, which can be used to add filter effects,
> such as blur, color adjustments, or “aging” and such. Any filters you
> apply affect the entire movie.
>
> So, you wouldn't want to set this to "aging" for one movie, then
> export another, forgetting that the filter is still set for "aging"!
>
> Sorry, I digress. But that happens in this NG from time to time! (O_O)
>
> Yes, this could be a problem!
>
>>
>>
>>> I used logical names because I want to use them in generalized file-
>>> specs, so to speak. Used it for years and it never caused a problem.
>>> You'll say I was lucky. Perhaps.
>>
>>> So what _can_ we use logical names for?
>>
>> Logical names work pretty well for their intended purpose, which itself
>> was a bit of a kludge meant to help how OpenVMS referenced its files
>> and directories; how the physical device specifications were inherently
>> visible within the design, and how that caused problems when the device
>> names changed.  Logical names helped avoid that.  An elegant kludge, as
>> it was.
>
> So this is like the /NOBACKUP in BACKUP which in a vanilla VMS system
> disk is set for page, swap, and dump files. I remember we tried to use
> SET FILE/NOBACKUP in our physics group (we had no professional sysmgr)
> to avoid backing up files certain large, but "not needed in a restore"
> files. Boy were we surprised by the results of a restore operation!
> (O_O) So I surmise that /NOBACKUP was added to avoid needless copying
> of data in these three files that get ignored in the boot process.
>
> I vaguely recall someone in this NG telling me that this qualifier was
> actually motivated by something else.
>
>>
>> As I stated before:
>>
>>
>>
>>>> Logical names get abused far too often, largely because DCL lacks any
>>>> sort of a generic preferences storage and retrieval mechanism, or an
>>>> integrated key-value mechanism short of using (for instance) an RMS
>>>> indexed file.
>>
>>>> This design inevitiably reminds me of using punch cards to store this
>>>> data.  Sure, that works.  It's even superior to using logical names in
>>>> a way.  But it's really ugly, it's a whole lot of work for what you
>>>> get, and it's quite easy to make mistakes, and upgrades and cleanups
>>>> can be a problem.  Unlike a deck of punch cards, logical names don't
>>>> have a way to read the whole wad of keys and values — data — and see
>>>> what's there, too.
>>
>> Working with a key-value store — Python, perl, most any compiled
>> language — really shows the weaknesses of DCL and the available tools.
>> bash would be somewhat of a pain in the rump here, though awk
>
> though awk . . . ?
>
> BTW, does awk stand for "awkward"? (^_^)
>

No!  It stands for the authors, Aho, Weinberg, and Kernigan!  ISTR that 
a VMS version is, or was, a VMS version.