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

[Stephen Hoffman]

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.
>> 
>> 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.

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.

> 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.

> 
> 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.

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

For an overview of what a key-value store is, see associative arrays 
<http://en.wikipedia.org/wiki/Associative_array>.  At its core, this 
also gets back to the hackery that is the "array support" in DCL.  The 
easiest way to implement that (in DCL) being something like an indexed 
file, or using ampersand substitution.  DCL is good at chaining 
together invocations, but far from effective as a generic 
text-processing tool, and it's not good at storing and retrieving data 
through a means other than logical names or symbols, both of which have 
limits.  Python, Perl and Lua can do much better here.  bash — which 
lacks key-value support in most any version I've worked with — does 
better than DCL with its (limited) array support.  Compiled languages, 
too, can store data.  (Though that's also often a whole lot of work in 
the older versions and older languages found on VMS.)

Basically, logical names usually end in pain when applied at scale, or 
when subject to collisions, and for the sorts of corner-cases that can 
arise around tool upgrades and tool failures.



-- 
Pure Personal Opinion | HoffmanLabs LLC