VMS83A_UPDATE V8.0 breaks GNV bash DCL capability

[Eric W. Robertson]

The version of Bash in GNV supplies the capability of executing DCL commands from within the Bash command line by preceeding the command with "DCL". For example:

bash>DCL show time

However, I noticed today that after installing the VMS83A_UPDATE V8.0 Patch this feature no longer works correctly. From within bash, attempting to execute any DCL command this way generates the following error:

%DCL-W-ACTIMAGE, error activating image SYS$COMMON:[SYSEXE]DCL.EXE
-CLI-E-IMGNAME, image file SRVR1$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DCL.EXE
-SYSTEM-F-ACCVIO, access violation, reason mask=28, virtual
address=000000007FFD1160, PC=000000000000001A, PS=7FF9DEA5

I know for certain it is this patch because after seeing this problem the first time, I restored my system from backups to its state prior to the installation of this patch and verified that this feature of GNV Bash worked once again. Then I applied the patch, rebooted OpenVMS and verified that this feature of GNV Bash no longer worked with the above symptom.

I have not yet had time to poor over the release notes for this patch to see what changes it contains and why it might cause this feature of GNV Bash to break. It could be that there is a latent problem in the way GNV implements this feature which was exposed by the changes contained in the patch. But I thought I would post this information here just in case anybody from HP that monitors this forum might have some additional wisdom.

As always any wisdom is appreciated.


Eric

[Hoff · Accepted solution]

Something smashed the stack, by the look of that ACCVIO.

Smashed stack inside privileged components are usually bad news, too. And DCL is privileged.

SSL (system service logging) might be able to spot the sequence of calls inside GNV (and the source to at least some versions of GNV is available; see <>), but I'd guess this command is probably doing a lib$spawn of the command, and specifying the image as DCL.

Since it's HP pieces that broke HP pieces, it's probably fastest to contact HP directly.

[David Jones_21]

It looks like something the patch did is making the process bash spawned activate sys$system:dcl.exe instead of gnu:[bin]dcl.

[x2084]

As already noted, the GNV dcl wrapper is not in SYS$SYSTEM. It is in GNU:[bin] or PSX$ROOT:[bin], which should be the same directory.

You are invoking the VMS DCL.EXE, because the dcl wrapper was not found in your path and as a last resort, GNV tries to lookup the wrapper in SYS$SYSTEM.

So this looks more or less like a etup problem.

bash$ echo $PATH
/bin:/gnu/bin:/GNU/BIN:/usr/bin:/usr/local/bin:.
bash$ which dcl
/bin/dcl
bash$

Check the path, check the related logicals, especially
"BIN" = "PSX$ROOT:[bin]" (LNM$SYSTEM_TABLE)
( and check the Posix root
$ SHOW ROOT)
and
"GNU" = "$8$DKA100:[000000.]" (LNM$JOB_88631980)

I have no idea what the ECO changes, but there is no obvious relation to GNV.

[Eric W. Robertson]

Everybody,

Thanks for the info. I will look into the PATH environment variable settings and the GNU and PSX$ROOT logicals. But, I would be very surprised if these got changed as a result of the patch installation. All of these settings are node specific and NO patch should be changing these items. I can't do the test now because because if it turns out that these node specific items are not changed, then I will have to go to the trouble of restoring my system disk from backup tape (again). I just can't do that right now. Later on tonight I will install the patch again and check these items and report back my findings.

Eric

[Larry Bohan]

afaict, this GNV DCL wrapper, can be found on (my) path.

also, the same problem occurs on Itaninum
(post-update v7, there, iirc). the accvio looked similar.

(gnv-bash)$ echo $PATH
/bin:/gnu/bin:/GNU/BIN:/usr/bin:/usr/local/bin:.
(gnv-bash)$ which dcl
/gnu/bin/dcl
(gnv-bash)$ dcl sh time
%DCL-W-ACTIMAGE, error activating image SYS$COMMON:[SYSEXE]DCL.EXE
-CLI-E-IMGNAME, image file $1$DKA0:[SYS0.SYSCOMMON.][SYSEXE]DCL.EXE
-SYSTEM-F-ACCVIO, access violation, reason mask=28, virtual address=000000007FFD1160, PC=000000000000001A, PS=7FF9DEA5
(gnv-bash)$ exit

[x2084]

For what it is worth: you need the dcl wrapper if you want to issue a VMS DCL command, which matches a program in the path or builtin command of bash. For example 'sh' as an abbreviation for the SHOW command.

bash$ show time
25-MAR-2009 05:52:40
bash$ sh time
time: time: no such file or directory
bash$ dcl sh time
25-MAR-2009 05:53:07
bash$

Also, the dcl wrapper is transparently used if any redirection for a DCL command is requested.

The fallback to DCL can be disabled. Then you have to use the dcl wrapper if you still want to use a DCL command.

bash$ export GNV_DISABLE_DCL_FALLBACK=
bash$ show time
bash.exe.1: show: command not found
bash$ dcl show time
25-MAR-2009 06:07:33
bash$

The dcl wrapper, as any other bash external command, is executed with the execve() function, which expect a full pathname, which is constructed out of the first found matching file in the given PATH.

bash$ echo $PATH
/bin:/gnu/bin:/GNU/BIN:/usr/bin:/usr/local/bin:.
bash$ which -a dcl
/bin/dcl
/gnu/bin/dcl
/GNU/BIN/dcl
bash$ /bin/dcl sh time
25-MAR-2009 06:30:30
bash$

First I would check if the dcl wrapper can be invoked with an absolute path as found with 'which'.


In Unix speak, VMS has a file system with multiple roots: each disk is a root. For Posix and GNV a Posix root was invented, which can be seen as a concealed device. However it should be set with the SET ROOT command.

$ show root
_$8$DKA100:[4,4,0]
$ sh log PSX$ROOT/full
"PSX$ROOT" [exec] = "_$8$DKA100:[4,4,0.]" [concealed] (LNM$SYSTEM_TABLE)

So the above absolute Posix paths are or start here: PSX$ROOT:[bin], PSX$ROOT:[gnu], PSX$ROOT:[GNU], PSX$ROOT:[usr]

Next I would check if I can access these directories, if they contain dcl. or dcl.exe and if I can run the dcl wrapper like

$ mc PSX$ROOT:[bin]dcl. sh time
25-MAR-2009 06:51:45
$

Traditionally, the CRTL uses logical names as rooted directories. That is a VMS directory pointed to by the logical 'bin' is the rooted /bin.

Therefore I would check the related logicals for the path, here bin, gnu and usr and would check if I can access the pointed to directories and if there is a dcl wrapper and if it can be invoked like

$ mc BIN:dcl. sh time
25-MAR-2009 06:53:39

I do not know the order here. That is if a PSX$ROOT:[bin] overrides a BIN logical or vice versa. That's a feature of the CRTL. In any case, there should be only one bin directory.

Maybe I would check if the DECC$SHR image was supplied and what is said in its release notes and if there are related DECC$
feature logicals defined.

And as a workaround, you can copy the dcl wrapper to a different directory and change your PATH to have that directory searched, first

[Eric W. Robertson]

Everybody,

I am turning a very dark shade of crimson as I type this in. The problem was not the patch! As more than a few people have pointed out, the path, GNU and PSX$ROOT logicals must be setup correctly in order for GNV bash to function properly. In particular the GNV and PSX$ROOT logicals are setup in SYS$STARTUP:GNV$STARTUP.COM which is one of the commands in my SYS$MANAGER:SYSTARTUP_VMS.COM. However, before rebooting I had removed an older version of Python for VMS (Python V2.52) and replaced it with a new version of python for VMS (Python V2.54). However, this Python upgrade required a change of the startup command in SYS$MANAGER:SYSTARTUP_VMS.COM from @SYS$STARTUP:PYTHON252_STARTUP.COM to @SYS$STARTUP:PYTHON254_STARTUP.COM. My blunder was ommitting this necessary change before rebooting. So, when I rebooted, SYSTARTUP_VMS.COM promptly exited when it could not find the startup file for the old version of Python referenced in SYSTARTUP_VMS.COM (I don't have a SET NOON in SYSTARTUP_VMS.COM). Having thus exited prematurely, it never got to execute the GNV$STARTUP.COM. Thus not configuring the necessary logicals for GNV bash and ultimately leading to the observed access violation when attempting to execute a DCL command from within GNV bash.

UGH!

My abject apologies for this errant post!

Eric

[Mike Kier]

Eric,

Don't apologize! I learned several new things from reading this thread and I'm sure others will as well.

Glad it was resolved!