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

[AEF]

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"? (^_^)

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

Thanks again for your insights.

>
> --
> Pure Personal Opinion | HoffmanLabs LLC

AEF