[Info-vax] Some questions on software for VMS 7.3 VAX

[David Froble]

lists at openmailbox.org wrote:
> On Thu, 21 Jan 2016 17:36:10 +0100
> hb via Info-vax <info-vax at rbnsn.com> wrote:
> 
>> On 01/21/2016 04:58 PM, lists at openmailbox.org wrote:
>>
>>> %DCL-W-ACTIMAGE, error activating image BLD_ROOT:[LOCAL.BIN]EMACS-21_2
>>> -CLI-E-IMGNAME, image file DUA0:[REDACTED.][LOCAL.BIN]EMACS-21_2.EXE;
>>> -RMS-E-DNF, directory not found
>>> -SYSTEM-W-NOSUCHFILE, no such file
>> I apologize, my fault. I should have checked GNU_STARTUP.COM for
>> BLD_ROOT and what it is set to.
>>
>>> I guess one thing at a time. What should I do now? Thanks a lot for
>>> helping with this. Sorry it took me awhile to get to this. Usually
>>> whenever I have something interesting to try on my home systems I get
>>> to work overtime that day. I will never know how they know...
>>>
>> (Re)-Define BLD_ROOT, the rooted logical. Assumed your current directory
>> when restoring the saveset was DUA1:[USER] then
>>
>> $ define BLD_ROOT /trans=(conc,term) DUA1:[USER.]
>>
>> It seems, when BLD_ROOT is defined before GNU_STARTUP runs, the command
>> procedure will not change it.
>>
>> Or change GNU_STARTUP.COM. It seems in line 278 BLD_ROOT is defined.
> 
> What I did was to copy the gnu_startup.com to my own version and modify
> that to try a few things. I did global changes on your filespec disk and
> user directory to mine and then I changed [LOCAL. to [EMACS. to match my
> setup after following your instructions about how to expand the backup
> saveset to my desired directory. Thanks for your clear emails, they really
> help. This gets me past having to set BLD_ROOT each time.
> 
> This got me further and Emacs did start (well, it started to start). But
> then I got additional messages that various files couldn't be found. They
> were still using the LOCAL directory. Apparently this is baked-in fairly
> deeply. I don't know if it's just scripts that could be tracked-down or
> whether it's also in code.
> 
> I guess I could keep trying to track down the scripts and rename them or I
> could just live with the local directory name. The former seems like the
> better solution since the directories are nested to max depth for VMS as I
> understand it, which would mean I could never have a directory named local
> wherever I decide to root this whole thing if I ever get it working and
> can't hide it in a higher-level directory.
> 
> Falling back to using the baked-in directory name it gets further
> 
> [Spawning a new Kept EMACS]
> 
> but I get a message for various emulated terminals that they aren't
> supported. For example coming in through Putty's telnet I get:
> 
> emacs: Terminal type vt102-132 is not defined.
> If that is not the actual type of terminal you have,
> use the Bourne shell command `TERM=... export TERM' (C-shell:
> `setenv TERM ...') to specify the correct type. It may be necessary
> to do `unset TERMCAP' (C-Shell: `unsetenv TERMCAP') as well.
> 
> Using xterm and telnet I get a similar message:
> 
> emacs: Terminal type vt100-132 is not defined.
> 
> So I used the default xterm size and it also failed similarly:
> 
> emacs: Terminal type vt400-80 is not defined.
> 
> Do you know how to resolve the terminal issue? Looks like it's fairly close
> but there would still be the issue of how to make it globally available
> since the directory structure and names are baked-in...
> 
> Thanks a lot for the help.
> 

Well, you could just use EDT,

$ EDT :== EDIT/EDT

and then have your login do a

$ SET TERM/INQ

and it just works ....

or, you can keep smashing your finger with the hammer ...