Problem with AXPVMS-VMS732_DCL-V0500

[Duncan Morris]

I have discovered a problem with the lexical function F$ENVIRONMENT following the installation of the latest DCL patch for Alpha V7.3-2.

Since installation a call such as

BASEDIR = F$ENVIRONMENT ("PROCEDURE")

returns a corrupt file spec. The version number is returned as a non-numeric character
(see attachment). This then causes subsequent F$PARSE operations to fail.

After de-installing the patch, the correct behaviour returns.

Has anybody else seen this behaviour?

[Dr. Richard Glasow]

Yes !
If F$ENVIRONMENT("PROCEDURE") returns exactly 30 characters, the last digit of the version number gets corrupted.
In most cases the last digit is overwritten by a binary zero, which causes F$PARSE to return a truncated version number. But especially in nested command procedures, I observe arbitrary bit patterns, which let F$PARSE fail completely (i.e. return of zero length strings).

[Jan van den Ende]

Has this already been reported to and/or acknowledged by HP?

Proost.

Have one on me.

jpe

[Duncan Morris]

Jan, I am not currently in a position to escalate to HP via support.

I am working on a test routine to try to nail down the exact combination of circumstances. However, from my work already, it would appear it be related to the total length of the string returned - not just the 30 chars mentioned by Dr Glasow.
Currently running the test in different directories with different name/type lengths - but there certainly is a real problem!

[Duncan Morris]

After a few experiments, it would appear that we get a problem at specific lengths of the returned strings

Length String returned

23 $1$DGA1310:[0,0]AAA.Q;P
31 $1$DGA1310:[0,0]AAAAAAAAAAA.Q;P
39 $1$DGA1310:[0,0]AAAAAAAAAAAAAAAAAAA.Q;P
47 $1$DGA1310:[0,0]AAAAAAAAAAAAAAAAAAAAAAAAAAA.Q;P

31 SYS$SYSROOT:[SYSMGR]AAAAAAA.Q;P
39 SYS$SYSROOT:[SYSMGR]AAAAAAAAAAAAAAA.Q;P
47 SYS$SYSROOT:[SYSMGR]AAAAAAAAAAAAAAAAAAAAAAA.Q;P
55 SYS$SYSROOT:[SYSMGR]AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.Q;P

looks like a problem with lengths (n * 8)-1

[Jan van den Ende]

Duncan,

least of we owe you many thanks!
We planned on a rolling install of patches next week, but we will definitely leave THIS ONE out!

Thanks again.

Proost.

Have one on me.

jpe

[Ian Miller.]

I have emailed Mr.DCL

[Duncan Morris]

Many thanks Ian

[Guy Peleg · Accepted solution]

Thank you for reporting the problem and
for providing a reproducer. I'll make
sure the kit will be put on hold first
thing Monday morning.

Guy

[Guy Peleg]

The V5 kit fixed a problem related to
memory management within DCL. The fix
is in the area of memory allocation making
sure that the amount of memory being allocated is the same amount being freed.
Sounds trivial..? yes...but it's a little
harder than it sounds....;-)

Anyway, we fixed the problem and expect to
ship a new kit VMS732_DCL-V0600 later this
week. In the meanwhile the V5 kit will be
put on hold.

Sorry for any inconvenience

Guy

[Duncan Morris]

Guy, many thanks for a rapid response and resolution.

[Ian Miller.]

the updated patch has been announced
http://www.openvms.org/stories.php?story=06/02/01/1650225

but I can't see it on the ftp site yet
ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2