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

David Froble davef at tsoft-inc.com
Sun Feb 10 00:56:32 EST 2013


AEF wrote:
> 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? Also, I am not familiar with the DECC$ disaster.
> 
> 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?

You can use logical names for all kinds of things.  But a database isn't 
one of them.

Doing a SHOW LOG /SYS I wonder about the many TCPIP* logicals ...

>> Both the stuff I mentioned above, and the stuff I mentioned below:
>>
>>>> Upgrades can be fun, where these are added or removed; there's no
>>>> "attachment" back to the application.
>>>> No namespaces, for that matter.
>>>> There are other issues.
>> 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.
> 
> OK, I won't run TO.COM when doing an upgrade, if I ever do one again,
> that is.
> 
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
> 
> AEF



More information about the Info-vax mailing list