This used to be broken. Strange things would happen under certain conditions, like only the directory being changed or the directory being hidden in sys$disk. It appears to be fixed on EISNER. Is there documentation of this fix somewhere? I've been searching on the web, only to come up empty. TIA! (^_^(

Den 2021-10-22 kl. 08:45, skrev alanfe...@gmail.com:
> This used to be broken. Strange things would happen under certain conditions, like only the directory being changed or the directory being hidden in sys$disk. It appears to be fixed on EISNER. Is there documentation of this fix somewhere? I've been searching on the web, only to come up empty. TIA! (^_^(
>

What used to be brooken and what fix?
Care to post an example?

On Friday, October 22, 2021 at 5:58:22 AM UTC-4, Jan-Erik Söderholm wrote:
> Den 2021-10-22 kl. 08:45, skrev ala...@ g.com:
> > This used to be broken. Strange things would happen under certain conditions, like only the directory being changed or the directory being hidden in sys$disk. It appears to be fixed on EISNER. Is there documentation of this fix somewhere? I've been searching on the web, only to come up empty. TIA! (^_^(
> >
> What used to be brooken and what fix?
> Care to post an example?

I can't post an example, as I don't have access to a system where it was broken. But I have the following notes:

The DCL program SET DEFAULT has two problems with nested logical
names:

1.) If the first translation has a trailing colon and there is no
explicit directory-spec in the second translation, SYS$DISK is changed
to the 1st translation and the directory portion is not changed. The
"actual" current directory remains hidden in SYS$DISK.

2.) If the 1st translation has no trailing colon, then only the
directory portion of the default is changed! This can leave SYS$DISK
incorrect thereby leaving the default incorrect.

Additionally, in certain circumstances, SET DEFAULT returns an error
but still changes your process to a bad default.

I'd like to know what version of VMS this was fixed in and the ECO release notes if anyone can find them. There's an excellent post in cov from way, way back describing this, perhaps in a better way, but I can't find it.

I found the post! Here's an example with some context. I can post or reference the entire post if it's okay to do so. (Yeah, I'm a bit paranoid.)

Anyway, the details:

"As we all know", the default directory information is stored in two
pieces. The default device (stored as the equivalence name for the
logical name SYS$DISK:) and the default directory string (stored in
process P1 space named by PIO$GT_DDSTRING). Thus, changing the default
directory potentially involves changing two pieces of information.

The SET DEFAULT command looks at its given argument to determine
which pieces of data need to be changed. The problem is that it is
"stupid". If the given specification OR ITS FIRST TRANSLATION (if
a logical name) contains a colon, then SYS$DISK will be modified.
If no colon is found, ONLY THE DIRECTORY PATH will be changed.

So, let's look at the problem again.

$ SET DEFAULT HOME ! No colons here...

translation of HOME yeilds "SYS$LOGIN". no colons there either...

well, there's gotta be SOMETHING to do. Lets figure out
what directory path to store....

no directory path in SYS$LOGIN. translate it again.

"device:[directory]"

Ah ha! A directory path. Extract it and change the default
path to "[directory]"

All done!

So, there we have it. Isn't this brilliant? :) I run into this "gotcha"
every now and then when I don't remember to place a trailing colon on a
logical name, too. As far as I know, this behaviour isn't documented.
Apparently the VMS developers never make this "error", so never see the
problem. :)

On Friday, October 22, 2021 at 11:45:15 PM UTC+13, alanfe...@gmail.com wrote:
>
[intricacies of semantics of SET DEFAULT]
> So, there we have it. Isn't this brilliant? :) I run into this "gotcha"
> every now and then when I don't remember to place a trailing colon on a
> logical name, too. As far as I know, this behaviour isn't documented.
> Apparently the VMS developers never make this "error", so never see the
> problem. :)

Could be worse. Imagine, for the sake of argument, that somebody designed an OS where you could only use a single letter to name each disk device.

Crazy, I know. Nobody in their right mind would propose such a thing, would they? I mean, would you entrust mission-critical business functions to an OS that could only handle 26 drive letters?

In article <2a79c8d5-1812-4fcb-a031-b30815399b06n@googlegroups.com>, =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>On Friday, October 22, 2021 at 11:45:15 PM UTC+13, alanfe...@gmail.com wrote:
>>
>[intricacies of semantics of SET DEFAULT]
>> So, there we have it. Isn't this brilliant? :) I run into this "gotcha"
>> every now and then when I don't remember to place a trailing colon on a
>> logical name, too. As far as I know, this behaviour isn't documented.
>> Apparently the VMS developers never make this "error", so never see the
>> problem. :)
>
>Could be worse. Imagine, for the sake of argument, that somebody designed an OS where you could only use a single letter to name each disk device.
>
>Crazy, I know. Nobody in their right mind would propose such a thing, would they? I mean, would you entrust mission-critical business functions to an OS that could only handle 26 drive letters?

ROTFLMFAO!

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 10/23/2021 6:55 PM, Lawrence D’Oliveiro wrote:
> On Friday, October 22, 2021 at 11:45:15 PM UTC+13,
> alanfe...@gmail.com wrote: [intricacies of semantics of SET DEFAULT]
>> So, there we have it. Isn't this brilliant? :) I run into this
>> "gotcha" every now and then when I don't remember to place a
>> trailing colon on a logical name, too. As far as I know, this
>> behaviour isn't documented. Apparently the VMS developers never
>> make this "error", so never see the problem. :)
>
> Could be worse. Imagine, for the sake of argument, that somebody
> designed an OS where you could only use a single letter to name each
> disk device.
>
> Crazy, I know. Nobody in their right mind would propose such a thing,
> would they? I mean, would you entrust mission-critical business
> functions to an OS that could only handle 26 drive letters?

Probably nobody today.

Arne

In article <00B6ABCB.5D301AFD@SendSpamHere.ORG>, VAXman-
@SendSpamHere.ORG writes:

> > Could be worse. Imagine, for the sake of argument, that somebody
> > designed an OS where you could only use a single letter to name each
> > disk device.
> >
> > Crazy, I know. Nobody in their right mind would propose such a
> > thing, would they? I mean, would you entrust mission-critical business
> > functions to an OS that could only handle 26 drive letters?
>
> ROTFLMFAO!

I'm sure that when VAXman gets a chance to configure a Windows system,
he would try to use those nine letters for the drive names, but then
give up because two of them are repeated. :-)

Then just set up two drives: FO. :-D

In article <sl306k$4gp$1@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
>In article <00B6ABCB.5D301AFD@SendSpamHere.ORG>, VAXman-
>@SendSpamHere.ORG writes:
>
>> > Could be worse. Imagine, for the sake of argument, that somebody
>> > designed an OS where you could only use a single letter to name each
>> > disk device.
>> >
>> > Crazy, I know. Nobody in their right mind would propose such a
>> > thing, would they? I mean, would you entrust mission-critical business
>> > functions to an OS that could only handle 26 drive letters?
>>
>> ROTFLMFAO!
>
>I'm sure that when VAXman gets a chance to configure a Windows system,
>he would try to use those nine letters for the drive names, but then
>give up because two of them are repeated. :-)
>
>Then just set up two drives: FO. :-D

NOT that I would EVER configure a WEENDOZE box but if a were to, I'd use the
letters FJB.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 10/23/21 7:19 PM, VAXman-@SendSpamHere.ORG wrote:
> In article <2a79c8d5-1812-4fcb-a031-b30815399b06n@googlegroups.com>, =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> writes:
>> On Friday, October 22, 2021 at 11:45:15 PM UTC+13, alanfe...@gmail.com wrote:
>>>
>> [intricacies of semantics of SET DEFAULT]
>>> So, there we have it. Isn't this brilliant? :) I run into this "gotcha"
>>> every now and then when I don't remember to place a trailing colon on a
>>> logical name, too. As far as I know, this behaviour isn't documented.
>>> Apparently the VMS developers never make this "error", so never see the
>>> problem. :)
>>
>> Could be worse. Imagine, for the sake of argument, that somebody designed an OS where you could only use a single letter to name each disk device.
>>
>> Crazy, I know. Nobody in their right mind would propose such a thing, would they? I mean, would you entrust mission-critical business functions to an OS that could only handle 26 drive letters?
>
> ROTFLMFAO!
>

Why? This was at the same time when your only had 640K of
memory. And who would ever need more? Heck, why would
anyone ever need a computer in their house?

Hindsight is always 20/20.

bill

On 2021-10-22 06:45:02 +0000, alanfeldman48@gmail.com said:

> This used to be broken. Strange things would happen under certain
> conditions, like only the directory being changed or the directory
> being hidden in sys$disk. It appears to be fixed on EISNER. Is there
> documentation of this fix somewhere? I've been searching on the web,
> only to come up empty. TIA! (^_^(

*You rang?*

Logical names are volatile key-value store design and straight out of
~1984, and long since and widely used and misused.

For device redirection, they're adequate.

Logical names have had "surprising" edge cases ~forever, too.

The whole of the default directory stuff cited is just utterly
hilarious, but that design is just too entrenched to ever be fixed and
the existing stuff deprecated and removed.

Search lists too are surprisingly fragile, particularly with missing
directories potentially in the mix.

I'd wager that most existing apps don't specify the filenames as would
be preferable, and many OpenVMS developers aren't aware of the
"preferred" filename defaulting and translation sequence. Or aren't
interested in using that ordering.

And then there's what I'd consider the misuse of logicals as a volatile
and out-of-band and poorly implemented management UI. q.v. CRTL.

Alas, VSI is unlikely to be interested in adding additional checks as
those sorts of changes have a history of breaking existing and ~working
configurations, too. q.v. Hyrum's Law.

Best case, app preferences support become available within OpenVMS,
preferably non-volatile, and existing app-specific file and device
accesses can then all be redirected from within the app-associated
preferences, as permitted by local security policies.

But this current logical name design? I'm not sure it's even
particularly salvageable short of the V3-to-V4-scale rework of the
whole logical names design, if it's even worth salvaging, and that
salvaging necessarily preserving most of the edge cases for existing
consumers. The original logical names were a great idea within the
limits of the PDP-11 / RSX-11M era. The V4 stuff was far more flexible
and with better APIs, but whether it really improved this whole area?
Nowadays, past isolated device or isolated file redirection—where apps
have been created to allow that—the whole of the design is really
limited and showing its age.

--
Pure Personal Opinion | HoffmanLabs LLC

On Sunday, October 24, 2021 at 12:22:44 PM UTC-4, Stephen Hoffman wrote:
> On 2021-10-22 06:45:02 +0000, alanfe...@gmail.com said:
>
> > This used to be broken. Strange things would happen under certain
> > conditions, like only the directory being changed or the directory
> > being hidden in sys$disk. It appears to be fixed on EISNER. Is there
> > documentation of this fix somewhere? I've been searching on the web,
> > only to come up empty. TIA! (^_^(
> *You rang?*

Yep! That was the best part of the show, no? When Lurch would suddenly turn into the scene seemingly out of nowhere and say, "You rang?"
[...]
>
> Logical names are volatile key-value store design and straight out of
> ~1984, and long since and widely used and misused.
>
> For device redirection, they're adequate.
>
> Logical names have had "surprising" edge cases ~forever, too.
>
> The whole of the default directory stuff cited is just utterly
> hilarious, but that design is just too entrenched to ever be fixed and
> the existing stuff deprecated and removed.

But Hoff, it _was_ fixed! Looks like no one knows when or what version of VMS it was fixed in.

Here's a bonus question. When was EDT updated to allow more than 22 lines? IDK, but it's made me happy!

Bonus No. 2: In what version of VMS was "Proactive Reclamation of Memory from Idle Processes" introduced? This one I found on my own. Turns out it was v5.4-3. Made a big difference in my main system at the time!
>
[...]
> --
> Pure Personal Opinion | HoffmanLabs LLC
AEF

Den 2021-10-25 kl. 06:28, skrev alanfe...@gmail.com:
> On Sunday, October 24, 2021 at 12:22:44 PM UTC-4, Stephen Hoffman wrote:
>> On 2021-10-22 06:45:02 +0000, alanfe...@gmail.com said:
>>
>>> This used to be broken. Strange things would happen under certain
>>> conditions, like only the directory being changed or the directory
>>> being hidden in sys$disk. It appears to be fixed on EISNER. Is there
>>> documentation of this fix somewhere? I've been searching on the web,
>>> only to come up empty. TIA! (^_^(
>> *You rang?*
>
> Yep! That was the best part of the show, no? When Lurch would suddenly turn into the scene seemingly out of nowhere and say, "You rang?"
> [...]
>>
>> Logical names are volatile key-value store design and straight out of
>> ~1984, and long since and widely used and misused.
>>
>> For device redirection, they're adequate.
>>
>> Logical names have had "surprising" edge cases ~forever, too.
>>
>> The whole of the default directory stuff cited is just utterly
>> hilarious, but that design is just too entrenched to ever be fixed and
>> the existing stuff deprecated and removed.
>
> But Hoff, it _was_ fixed! Looks like no one knows when or what version of VMS it was fixed in.
>
> Here's a bonus question. When was EDT updated to allow more than 22 lines? IDK, but it's made me happy!

There as an EDT patch just a year ago or so from VSI.
Had something with numnber of lines to do, I think...

>
> Bonus No. 2: In what version of VMS was "Proactive Reclamation of Memory from Idle Processes" introduced? This one I found on my own. Turns out it was v5.4-3. Made a big difference in my main system at the time!
>>
> [...]
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
> AEF
>

On 2021-10-25, alanfe...@gmail.com <alanfeldman48@gmail.com> wrote:
>
> Here's a bonus question. When was EDT updated to allow more than 22 lines? IDK, but it's made me happy!
>

$ set response/mode=good_natured

It was a procrastination project by someone at VSI. :-)

(IOW, a project you work on when you are stuck on what you are _really_
supposed to be working on.)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-10-25 04:28:45 +0000, alanfeldman48@gmail.com said:

> But Hoff, it _was_ fixed! Looks like no one knows when or what version
> of VMS it was fixed in.

If this purported logical name colon-oscopy makes you happy and if
logical names do what you need, by all means enjoy and use logical
names. They are what is available, of course.

For my usage, logical names are a weak and volatile system-integrated
key-value store design straight from the 1980s, and largely intended
for app customization, and competitively woefully inadequate for app
needs past device and file redirection, and I'm increasingly skeptical
there.

Logical names provide one facet of app customization semi-adequately,
and that is not an issue I tend to have encounter or create in newer
app designs, while poorly providing for other app customization
requirements, and the whole of logical-name-based settings maintenance
is just utterly and stupidly disconnected from the apps themselves.

The whole realm of logical names and app customization needs an
overhaul of a scale well past the VAX/VMS V4.0 overhaul.

> Here's a bonus question. When was EDT updated to allow more than 22
> lines? IDK, but it's made me happy!

EDT was long ago considered deprecated and ~immutable, and now it's
apparently not. That's a decision that VSI gets to make, of course.
Whether its apparent commutation was a wise decision remains to be
seen. But then I tend to use EDT only when that's the last editor
available this side of PATCH. For those that do still prefer to use
EDT, yay, it's not dead yet. Maybe some of the 🤬 in the EDT help gets
fixed too, as VSI develops their strategy for text editor support.

BTW: LSEDIT permits the EDT keypad, and has supported far larger
displays, and with app development features massively better than EDT.

--
Pure Personal Opinion | HoffmanLabs LLC

On Monday, October 25, 2021 at 12:31:01 PM UTC-4, Stephen Hoffman wrote:
> On 2021-10-25 04:28:45 +0000, alanfe said:
>
> > But Hoff, it _was_ fixed! Looks like no one knows when or what version
> > of VMS it was fixed in.
> If this purported logical name colon-oscopy makes you happy and if
> logical names do what you need, by all means enjoy and use logical
> names. They are what is available, of course.
>
> For my usage, logical names are a weak and volatile system-integrated
> key-value store design straight from the 1980s, and largely intended
> for app customization, and competitively woefully inadequate for app
> needs past device and file redirection, and I'm increasingly skeptical
> there.
>
> Logical names provide one facet of app customization semi-adequately,
> and that is not an issue I tend to have encounter or create in newer
> app designs, while poorly providing for other app customization
> requirements, and the whole of logical-name-based settings maintenance
> is just utterly and stupidly disconnected from the apps themselves.
>
> The whole realm of logical names and app customization needs an
> overhaul of a scale well past the VAX/VMS V4.0 overhaul.
> > Here's a bonus question. When was EDT updated to allow more than 22
> > lines? IDK, but it's made me happy!
> EDT was long ago considered deprecated and ~immutable, and now it's
> apparently not. That's a decision that VSI gets to make, of course.
> Whether its apparent commutation was a wise decision remains to be
> seen. But then I tend to use EDT only when that's the last editor
> available this side of PATCH. For those that do still prefer to use
> EDT, yay, it's not dead yet. Maybe some of the 🤬 in the EDT help gets
> fixed too, as VSI develops their strategy for text editor support.
>
> BTW: LSEDIT permits the EDT keypad, and has supported far larger
> displays, and with app development features massively better than EDT.
> --
> Pure Personal Opinion | HoffmanLabs LLC

"Logical name colonoscopy?" I was talking about SET DEFAULT and my program (DCL command procedure) TO.COM. Yes, TO.COM does stuff with logical names. But it does a lot more than that. SET DEFAULT had 2 or 3 silly bugs that I figured wouldn't take long to fix. But year after year they didn't fix it. This is one of the reasons I wrote TO.COM. Hey, at least one person has used it, as he wrote to me about it! I figured if anyone would ever use it I better give it lots of features and make it as bulletproof as possible.

I get the impression you don't think highly of logical names! I can't imagine removing them from VMS though. Sounds like a lot of work, as they are so ubiquitous. And there are all the 3rd-party apps that use them!

Anyway, I am curious about when, what version, and want to get a copy of the release notes for it. I found them for EDT now having more than 22 lines! (You also don't seem to think much of EDT!)

[The following is a tad long, but you've now and in the past told me there are better editing tools than EDT, so I'd like to tell you why I didn't use them much.]

Speaking of EDT, I have to say it has served me well. When I was at a remote place to do an experiment in the late 1980s, I tried EVE/TPU/whatever. Didn't work. Something with terminal settings -- maybe is was the Eightbit thing. I don't recall for sure. OTOH, I found that EDT worked everywhere under any circumstances without any fuss! "It just worked." But its 22-line limit became really annoying when bigger screens became available. And it was finally extended last year! Another project that probably took very little time to implement. But no. We were stuck with the 22-line limit and the silly SET DEFAULT bugs year after year after year for no good reason.

[Stay with me here. I get to the editors shortly.] At one job c. 1999, I was working on exporting data from a database -- using DCL, no less! As a former mere physicist, I was excited that I figured out a way to do it. And I only had DCL to work with. Sure, tell me all the better ways I could and should have done it. (Actually, maybe not.) All I had was DCL. Oh, and I had to export ALLIN1 Word Perfect documents, too! A third party vendor was going to charge us something like $11,000 plus expenses _just_ for the database export! I saved my company at least that much money. Now, I mention this because I was very frustrated that EVE didn't have EDT's SET NOTRUNCATE feature. I sorely needed that for a particular task but EDT didn't support long-enough lines. So I just had to struggle. (There was no native support in that database for exporting data that anyone could find, including the third party we hired to put the exported data into their newfangled database.)

I didn't use VMS from 2010 until 2015 when (as you have probably already guessed, the migrate-off-of-VMS part), I was to help export the file trading system to a Unix system with Autosys for the scheduling. VMS was pretty soon a very minor part of the process until we finally found the contact for two very important files they sent us every workday. Maybe it was late 2016 or early 2017. In 2018 I left the company. None of this was app development, unless you count the export work c. 1999, where EDT and EVE each had their respective annoying shortcoming.

Out of curiosity I recently looked at the freeware page at VSI and saw an old version of TO.COM (v4.3.1) and that the link to download it was broken. I did the "Contact Us" routine and was told it could be fixed and would I like to submit an updated version. "Sure!" I said.

So I was really glad to see EDT now has unlimited lines. Better late than never! Actually, it's kind of mind-blowing to see EDT on my screen with roughly 50 lines and sometimes a little more!

As for EVE and LSE, I never had any luck with those programs. EVE didn't work at remote labs without a lot of fuss. Locally I tried to customize EVE and at one point it kept saying "Compilation aborted at line 1." But EDT always worked and worked everywhere. Once I learned the nokeypad commands, I customized it to my liking. I even fiddled with it a little now. I already know it. I don't already know the others. Modifying a key definition was super easy. You could see them all at once, and just edit the one you needed to modify, and close the file! Oh, and I forgot what the problem with LSEDIT was. EVE and LSE were too-powerful tools for my needs. Like using a blow torch to light a cigarette.

As for LSEDIT supporting larger displays, I don't seem to need that. As for app-development features, I don't need them either. I'm pretty much only working on TO.COM. Maybe I'll spruce up a couple of others. If I ever get an OpenVMS job again, maybe I'll check them out again.

To end on a positive note, I was very happy when "Proactive Reclamation of Memory from Idle Processes" came on the scene. And it was v5.4-3. Boy that made things run better! At my last job, before my app died, we had it running on a fleet of as many as 40 MicroVAXes at one point. One of them in London had only 8 MB of RAM, while the others running the same app had 40 MB. Memory was very tight, but it still ran like a champ!

Hey, a second positive note! My favorite feature of EVE is the box editing. I think I can probably make use of it to improve my help page, which has two columns in it. And I did occasionally make use of it in the past.

Thanks for your reply.

On 10/25/2021 12:30 PM, Stephen Hoffman wrote:
> On 2021-10-25 04:28:45 +0000, alanfeldman48@gmail.com said:
>
>> But Hoff, it _was_ fixed! Looks like no one knows when or what
>> version of VMS it was fixed in.
>
> If this purported logical name colon-oscopy makes you happy and if
> logical names do what you need, by all means enjoy and use logical
> names. They are what is available, of course.

I do use them, to some extent. I don't go in for some of the quirky
things, such as rooted logicals. I don't like things to be hidden.

I'm quite happy with the way I use logicals.
I am not guilty of how others may use them.

> For my usage, logical names are a weak and volatile system-integrated
> key-value store design straight from the 1980s, and largely intended
> for app customization, and competitively woefully inadequate for app
> needs past device and file redirection, and I'm increasingly
> skeptical there.

WHOA!!!

Where did that "app customization" thing come from?

Device and file redirection (your terminology) is a good thing, and
logicals used in a good manner do that quite well.

> Logical names provide one facet of app customization semi-adequately,
> and that is not an issue I tend to have encounter or create in newer
> app designs, while poorly providing for other app customization
> requirements, and the whole of logical-name-based settings
> maintenance is just utterly and stupidly disconnected from the apps
> themselves.

Got to agree, since logicals have no place in the apps.

> The whole realm of logical names and app customization needs an
> overhaul of a scale well past the VAX/VMS V4.0 overhaul.

The concept needs to die ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/25/2021 2:28 PM, alanfe...@gmail.com wrote:

> But it does a lot more than that. SET DEFAULT had 2 or 3 silly bugs that I figured wouldn't take long to fix.

What bugs? I've never seen any.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <sl6m42$4v0$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes:

> For my usage, logical names are a weak and volatile system-integrated
> key-value store design straight from the 1980s, and largely intended
> for app customization, and competitively woefully inadequate for app
> needs past device and file redirection, and I'm increasingly skeptical
> there.

Cluster-wide logical names, especially those visible only to a certain
group (but cluster-wide) are very nice. Does linux have something
similar (and I don't mean turd files).

> EDT was long ago considered deprecated and ~immutable, and now it's
> apparently not.

Much faster than TPU: no cursor slow motion, doesn't read the whole 1-GB
file if it just needs to change the top few lines. Probably easier to
script and run in batch.

> BTW: LSEDIT permits the EDT keypad, and has supported far larger
> displays, and with app development features massively better than EDT.

TPU supports the EDT keypad. So does emacs, for that matter. But there
is much more to EDT than the keypad. It's a way of life. :-)

On 10/25/2021 3:54 PM, Phillip Helbig (undress to reply) wrote:
> In article <sl6m42$4v0$1@dont-email.me>, Stephen Hoffman
> <seaohveh@hoffmanlabs.invalid> writes:
>> EDT was long ago considered deprecated and ~immutable, and now it's
>> apparently not.
>
> Much faster than TPU: no cursor slow motion, doesn't read the whole 1-GB
> file if it just needs to change the top few lines. Probably easier to
> script and run in batch.

EVE/TPU is actually very powerful for scripting.

Arne

On 2021-10-25 19:54:43 +0000, Phillip Helbig (undress to reply said:

> In article <sl6m42$4v0$1@dont-email.me>, Stephen Hoffman
> <seaohveh@hoffmanlabs.invalid> writes:
>
>> For my usage, logical names are a weak and volatile system-integrated
>> key-value store design straight from the 1980s, and largely intended
>> for app customization, and competitively woefully inadequate for app
>> needs past device and file redirection, and I'm increasingly skeptical
>> there.
>
> Cluster-wide logical names, especially those visible only to a certain
> group (but cluster-wide) are very nice. Does linux have something
> similar (and I don't mean turd files).

Yes; there are more flexible and more capable alternatives, as has been
discussed on each of the previous times you've asked this question.

The OpenVMS APIs available for apps to access a distributed directory
and to access and maintain settings are less well developed than those
on other platforms, which is the crux of my comments.

>> EDT was long ago considered deprecated and ~immutable, and now it's
>> apparently not.
>
> Much faster than TPU: no cursor slow motion, doesn't read the whole
> 1-GB file if it just needs to change the top few lines. Probably
> easier to script and run in batch.

Main memory on an Alpha runs at a fraction of the speed of main storage
on recent-generation client hardware, and recent-generation client main
memory surpasses Alpha processor cache speeds.

(Alpha EV7 L1 cache bandwidth: 7.77 GBps, versus recent-gen 204 GBps to
main memory. Alpha local main memory bandwidth 4.6 GBps, versus
recent-gen 7.4 GBps SSD read bandwidth. Etc.)

On OpenVMS, Eve and particularly TPU were built to script.

Most editors now are scriptable, of course. Just ask an emacs user. Or
a teco user.

And dedicated and portable scripting languages widely available, not
the least of which are Perl, Python, and Lua.

>> BTW: LSEDIT permits the EDT keypad, and has supported far larger
>> displays, and with app development features massively better than EDT.
>
> TPU supports the EDT keypad. So does emacs, for that matter. But
> there is much more to EDT than the keypad. It's a way of life. :-)

Until and unless your preferred 1980s-era tooling ceases to work for
you and your needs, I would expect nothing less.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-10-25 19:32:15 +0000, Dave Froble said:

> On 10/25/2021 12:30 PM, Stephen Hoffman wrote:
>
>> For my usage, logical names are a weak and volatile system-integrated
>> key-value store design straight from the 1980s, and largely intended
>> for app customization, and competitively woefully inadequate for app
>> needs past device and file redirection, and I'm increasingly skeptical
>> there.
>
> WHOA!!!
>
> Where did that "app customization" thing come from?
>
> Device and file redirection (your terminology) is a good thing, and
> logicals used in a good manner do that quite well.

Logical names are a central part of the available app-customization API
available within OpenVMS.

The whole point of logical names is to customize the default behaviors
of and the file and device references of apps, and of OpenVMS itself.

Logical names work decently well for file and device redirections, and
particularly when the developers know about and use FNA/DNA/RLF.

Logical names tend to get messy with other app-specific customization
settings; when not re-directing file or device references.

A whole lot of the "magic" of logical names is tied to the proper
filename specification on the file opens too, and that usage is far
from ubiquitous among developers.

A volatile key-value store is both limited and limiting too, as app
customization APIs go.

And as I've mentioned up-thread, I'm finding it rather less common to
be redirecting individual files within apps. OpenVMS itself and its
archaic clustering "management interface", yes. But App file
references, not so much.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/25/21 3:54 PM, Phillip Helbig (undress to reply) wrote:
> In article <sl6m42$4v0$1@dont-email.me>, Stephen Hoffman
> <seaohveh@hoffmanlabs.invalid> writes:
>
>> For my usage, logical names are a weak and volatile system-integrated
>> key-value store design straight from the 1980s, and largely intended
>> for app customization, and competitively woefully inadequate for app
>> needs past device and file redirection, and I'm increasingly skeptical
>> there.
>
> Cluster-wide logical names, especially those visible only to a certain
> group (but cluster-wide) are very nice. Does linux have something
> similar (and I don't mean turd files).
>
>> EDT was long ago considered deprecated and ~immutable, and now it's
>> apparently not.
>
> Much faster than TPU: no cursor slow motion, doesn't read the whole 1-GB
> file if it just needs to change the top few lines. Probably easier to
> script and run in batch.
>
>> BTW: LSEDIT permits the EDT keypad, and has supported far larger
>> displays, and with app development features massively better than EDT.
>
> TPU supports the EDT keypad. So does emacs, for that matter. But there
> is much more to EDT than the keypad. It's a way of life. :-)
>

So is EMACS... :-)

bill

On Monday, October 25, 2021 at 3:47:23 PM UTC-4, Dave Froble wrote:
> On 10/25/2021 2:28 PM, alanfe...@gmail.com wrote:
>
> > But it does a lot more than that. SET DEFAULT had 2 or 3 silly bugs that I figured wouldn't take long to fix.
> What bugs? I've never seen any.

I posted on earlier in the thread. I think it's even mentioned in the docs once, but I don't recall where and doubt I can find it.

Here is my summary of them:

The DCL program SET DEFAULT has two problems with nested logical
names:

1.) If the first translation has a trailing colon and there is no
explicit directory-spec in the second translation, SYS$DISK is changed
to the 1st translation and the directory portion is not changed. The
"actual" current directory remains hidden in SYS$DISK.

[ I assume this mean if you specify <LNM>:[directory] ]

2.) If the 1st translation has no trailing colon, then only the
directory portion of the default is changed! This can leave SYS$DISK
incorrect thereby leaving the default incorrect.

[This is the example posted by someone long ago which I put in one of my first posts in this thread.]

Additionally, in certain circumstances, SET DEFAULT returns an error
but still changes your process to a bad default.

[Unfortunately, I don't recall any examples of this.]

> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

AEF

On Monday, October 25, 2021 at 5:28:47 PM UTC+13, alanfe...@gmail.com wrote:
> When was EDT updated to allow more than 22 lines? IDK, but it's made me happy!

“EDT” and “happy” were never words I considered using in the same sentence ...