GNV behavior and the DECC incantations

[Bill Pedersen]

I am currently trying to get a porting project off square one and have been having issues with GNV. With all the different incantation from DECC feature logicals it gets a bit difficult to figure out the right mix.

An issue I am having currently is it appears that for the command line to function reasonably - things like "man ln" not breaking - I need to enable DECC$EFS_CASE_SPECIAL.

But, this does not provide any help for some issues with symbolic links and correct operation of mkdir. To get mkdir to function reasonably - in this case create a unix style directory name of aaa.dir which translated to aaa^.dir.DIR;1 I need DECC$POSIX_COMPLIANT_PATHNAMES defined a "2" or at least that is what I am using.

But DECC$POSIX_COMPLIANT_PATHNAMES disables DECC$EFS_CASE_SPECIAL. It also hides the "/dev/null/" special file, which then makes the configure script I am trying to get to run successfully as a "start" think that bash is "too old" since it can not find "/dev/null".

Any suggestions on the appropriate set of incantations?

This is on OpenVMS I64 V8.4 with V0400 update, TCPIP 5.7 ECO 2 and GNV 2.1.3.

Thanks,

Bill.

[H.Becker]

To me it looks like you are using the GNV tools from DCL. That's not intended. To start the bash and to execute commands within bash you do not need to define any of the DECC feature logicals.

[Bill Pedersen]

No, Hans, I am using bash, invoked from DCL to enter the "GNV environment" so the commands are presented to bash/GNV.

GNV, like any other "C" program is dependent on the CRTL which is controlled by the DECC feature logicals. Its behavior is thus changed by the particular incantation of the DECC logicals.

[H.Becker]

>>>
GNV, like any other "C" program is dependent on the CRTL which is controlled by the DECC feature logicals. Its behavior is thus changed by the particular incantation of the DECC logicals.
<<<

Right, but all the utilities and tools within GNV do not need to have DECC features enable by the user, aka defining logicals. That's all done with image initialization code. With GNV you have the sources, or? So you can have a look at the code, how this is done.

[Hoff]

I've posted up a reply to this question in the DECUServe PORTING_TO_VMS conference.

There's a third thread in c.o.v..

[Bill Pedersen]

Hans, with no logicials defined, other than those created during installs of products, GNV utilities such as man do not properly handle input such as "man ln" which should display the man page for ln.

If I define DECC$EFS_CASE_SPECIAL this utility works. From my observation this is necessary.

Without DECC$POSIX_COMPLIANT_FILENAMES set to "2" a command inside of GNV such as:

mkdir aa.dir

Does not create aa.dir but creates aa with directory properties and if fact creates aa.DIR on the disk. So that behavior is incorrect as you would expect on Unix or Linux to see a directory file "aa.dir".

So I do not understand you saying the utilities do not need the logicals. They call the CRTL. They depend on its functionality/features and they behave differently - sometimes in correctly without the various logicals. And of course the logicals are not necessarily compatible.

So, I am looking for some guidance here on the correct combination.

Hoff, yes, I realize that I have posted here, and COV and the SIG list. Not everyone looks everyplace. Some of us do.

I will review what folks have sent me.

Thanks,

Bill.

[Steven Schweda]

I don't use GNV much, which may explain why I
seem to have only "DEC AXPVMS GNV V1.6-2"
installed on my (VMS V8.3) Alpha system, but
I don't have any of the exotic DECC$ feature
logical names defined, and "man ln" works
just fine for me.

alp $ sho log decc$*

(LNM$PROCESS_TABLE)

"DECC$FD_LOCKING" = "TRUE"

(LNM$JOB_82A17A40)

(LNM$GROUP_000050)

(LNM$SYSTEM_TABLE)

"DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR_EV56"
"DECC$SHR" = "SYS$SHARE:DECC$SHR_EV56"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
alp $ bash
alp$ man ln
LN(1) FSF LN(1)

NAME
ln - make links between files

SYNOPSIS
[...]


I guess that I should get my GNV updated. I
hate missing out on all the fun.

[Bill Pedersen]

Well, join the fun...

LEEDS$ sho log decc*

(LNM$PROCESS_TABLE)

"DECC$FD_LOCKING" = "TRUE"

(LNM$JOB_896ACC80)

"DECC$ARGV_PARSE_STYLE" = "ENABLE"

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

"DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR"
"DECC$SHR_AV" = "DECC$SHR"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
LEEDS$ bash
bash$ man ln
No manual entry for ln

[Hein van den Heuvel]

>> bash$ man ln
>> No manual entry for ln

Bill, you seem to be implying that this 'man ln' failing is because issues with command line or file spec parsing. But maybe it is just imply trying to tell you there is no man page on your system for 'ln'.

I do not know gnv (yet) but maybe the manpages are an installation option?

Can yo (brute force 'find' or ls ) the files?
I dunno, maybe:
$ ls /usr/share/man/*/ln*
/usr/share/man/man1/ln.1.gz

Do any man pages work? apropos?
Are you using 'man' failing as an example of many failures or it this the only problem?

google will happily find only man pages, so if all you need is an explanation for the mann command then just http://linux.die.net/man/1/ln or comparable other place.

Is there something 'real' broken as well, and can you articulate that?

Cheers,
Hein

[Bill Pedersen]

Hein, the only thing I need to do is define DECC$EFS_CASE_SPECIAL then I get the man page. So, yes, the man page exists and is in the expected location.

Note, without the above logical if I do "man LN" it will eventually find the .gz file and ask it I want to display it:

LEEDS$ bash
bash$ man ln
No manual entry for ln
bash$ man LN
"/usr/share/man/cat1/LN.1.GZ" may be a binary file. See it anyway?

So man is running around trying to find the files based on its rules and directories it just does not like the situation where at present "case_special" is not defined, at least in "my case".

Bill.

[Steven Schweda]

> "/usr/share/man/cat1/LN.1.GZ" [...]

"LN.1.GZ"? Really? Around here (older
version):

alp$ ls -l /usr/share/man/cat1/*ln*
-rwxr-xr-x 1 SYSTEM 1 1016 Oct 10 2005 /usr/share/man/cat1/ln.1.gz

Looks to me as if something awful happened
when your GNV was installed. You didn't put
it onto an ODS2 disk, did you?

show proc /parse

[Bill Pedersen]

No, it is an ODS-5 disk.

[Steven Schweda]

> No, it is an ODS-5 disk.

So, how did you get the wrong-case file
name(s)? Around here, for example:

alp $ dire /date ALP$DKA100:[VMS$COMMON.GNV.usr.share.man...]*ln*

Directory ALP$DKA100:[VMS$COMMON.GNV.usr.share.man.cat1]

ln^.1.gz;1 11-JUN-2003 08:53:22.00

Total of 1 file.

Directory ALP$DKA100:[VMS$COMMON.GNV.usr.share.man.man1]

ln.1;1 11-JUN-2003 08:53:23.00

Total of 1 file.

Grand total of 2 directories, 2 files.


I realize that many things are possible, but
it's hard to believe that there's a GNV kit
out there with wrong-case file names in it.

[Bill Pedersen]

Well, at least at a start it appears that my file names are no lower case as yours appear to be:

LEEDS$ dire /date DKA100:[VMS$COMMON.GNV.usr.share.man...]*ln*

Directory DKA100:[VMS$COMMON.GNV.USR.SHARE.MAN.CAT1]

LN^.1.GZ;1 11-JUN-2003 08:53:22.00

Total of 1 file.

Directory DKA100:[VMS$COMMON.GNV.USR.SHARE.MAN.MAN1]

LN.1;1 11-JUN-2003 08:53:23.00

Total of 1 file.

Grand total of 2 directories, 2 files.
LEEDS$

Which I downloaded from the HP site:

ftp://ftp.hp.com/pub/openvms/opensource/

Here is the information from the PCSI file.

HP-I64VMS-GNV-V0201-003-1.PCSI$COMPRESSED;1
5-NOV-2009 05:27:55.00

So, it this initial item is an issue of incorrect install, I guess I could remove and re-install. As a start. It still does not answer the other issue of getting mkdir to work properly and /dev/null being visible, assuming I still need decc$posix_compatible_pathnames.

Bill.

[Bill Pedersen]

A side note. The HP OpenVMS Open Source porting environment behaves in a similar fashion to my environment as far as the man ln vs man LN and the use of DECC$EFS_CASE_SPECIAL.

So, if there is a CORRECT way for GNV to be installed we need to understand what that is so we can correct it on my system as well HP OpenVMS Engineering's system.

Bill.

[Steven Schweda]

> I realize that many things are possible, but
> it's hard to believe that there's a GNV kit
> out there with wrong-case file names in it.

Well, it is until you try it.

By searching the whole destination disk, I
did manage to find GNV$STARTUP.COM.

ALP $ @ ALP$DKA100:[VMS$COMMON.SYS$STARTUP]GNV$STARTUP.COM
%DCL-I-SUPERSEDE, previous value of GNV_PCSI_DESTINATION has been superseded
%DCL-E-OPENIN, error opening SYS$SYSROOT:[SYS$STARTUP]PSX$UP_STARTUP.COM; as input
-RMS-E-FNF, file not found

GNV$STARTUP problem: %RMS-E-FNF, file not found

%DCL-W-VALREQ, missing qualifier or keyword value - supply all required values


To a casual observer, this stuff appears to
be garbage. I think that I'll be trying to
put the old one back.

[Steven Schweda]

ALP $ prod remove gnv

The following product has been selected:
DEC AXPVMS GNV V2.1-3 Layered Product

Do you want to continue? [YES]

The following product will be removed from destination:
DEC AXPVMS GNV V2.1-3 DISK$UTIL5ALPX:[VMS$COMMON.]

Portion done: 0%
%DCL-E-OPENIN, error opening SYS$SYSROOT:[SYS$STARTUP]GNV$MNTROOT.COM; as input
-RMS-E-FNF, file not found
%PCSI-I-SPAWNEXE, error executing: @SYS$STARTUP:GNV$MNTROOT.COM,@PCSI$DESTINATIO
N:[GNV.lib]PCSI_REMOVE.COM

%PCSI-E-EXERMVFAIL, product supplied EXECUTE REMOVE procedure failed
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] n
[...]


At least it's free.

[Craig A Berry]

would give a serious think about how deep the need for symlinks is. Are they an integral part of the functioning of the package, or just a convenience used during the configuration and build process? So far the implementation of symlinks on VMS is incomplete enough that you'll likely spend as much time working around the limitations as you would just reimplementing the underlying feature some other way.

On VMS, you can't symlink a directory (well you can, but it doesn't work when you try to query it); you can't symlink to absolute pathnames that are not on one of those POSIX root GNV mount point thingies; you can't create a symlink on a volume that has write behind caching enabled because readlink() won't find it until the cache is flushed.

Those are the bugs I can think of off the top of my head that I've stumbled on without looking for them and haven't had time to write up and report. I've reported a couple of others that have been fixed, but since you can't rely on folks having access to patches anymore, it's dicey distributing software that depends on them.

[H.Becker]

A bash command "mkdir aaa.dir" should create a VMS directory aaa^.dir.DIR;1, no matter what feature logical was in place when you started bash from DCL. If it doesn't, then there is (or always was) a bug.

In a Posix/GNV environment all pathnames should be Posix style (equivalent to CRTL feature DECC$POSIX_COMPLIANT_PATHNAMES == 1). If GNV does not enforce this, this is (or always was) a bug. All VMS filename semantics should be translated to Posix style. That may require having a Posix root and mounting VMS disks/directories into the Posix filesystem tree. For what do you need DECC$POSIX_COMPLIANT_PATHNAMES different from 1 - especially if you port from Linux/Unix?

Whether /dev/null (as well as /bin and /tmp) is handled in a special way by the CRTL or by a special device driver should not be your - a GNV user's - concern. These files have to be there or you should be able to create them from within the Posix environment.

Although porting looks so easy, just "tar && ./configure && make && make install", mixing environments makes it complex.

Also, GNV seems at least neglected - in the real world, however it seems to perform very well on powerpoint slides :-)

[P Muralidhar Kini]

Hi Craig,

>> So far the implementation of symlinks on VMS is incomplete
The SYMLINK feature was added in OpenVMS V83 version.
But with V84, the SYMLINK feature has been redesigned.
Are you referring to your experiences with V84 itself ?

>> On VMS, you can't symlink a directory (well you can, but it doesn't work when
>> you try to query it);
Whats the directory specification in this case ?

>> On VMS, you can't symlink a directory (well you can, but it doesn't work when
>> you try to query it); you can't symlink to absolute pathnames that are not on
>> one of those POSIX root GNV mount point thingies; you can't create a
>> symlink on a volume that has write behind caching enabled because
>> readlink() won't find it until the cache is flushed.
If you can provide me, with steps to reproduce the problems, I can make a note
and log a internal problem report for it.

Regards,
Murali

[H.Becker]

>>> The SYMLINK feature was added in OpenVMS V83 version.
<<<
The SYMLINK feature was added in OpenVMS V7.2-6C2. However, there was no DCL interface. It was redesigned for V8.3, now with DCL support. It was rewritten to fix bugs and improve performance for V8.4. Unfortunately all the changes are incompatible: you can't use previous symbolic links in current versions. With all the changes and bug fixes it is recommended to avoid symlinks on older versions than V8.4.

>>> On VMS, you can't symlink a directory (well you can, but it doesn't work when you try to query it)
<<<
Symlinks for directories kind of work, but you have to be careful (on an ODS5 disk with Parse Style: Traditional and Case Lookup: Blind):
$ cre/dir [.sub]
$ cre [.sub]foo
[ Exit ]
$ cre/symlink=sub lnsub
$ dir [.lnsub]

Directory USER01:[BECKER_H.SYMLINKS.LNSUB]

FOO.;1

Total of 1 file.
$ create sub.
huhu
Exit
$ type lnsub.
huhu
$

>>> you can't symlink to absolute pathnames that are not on one of those POSIX root GNV mount point thingies
<<<
Not really true on V8.4.
$ def the_sub USER01:[BECKER_H.SYMLINKS.SUB]
$ cre/symlink="/the_sub" there
$ dir /date

Directory USER01:[BECKER_H.SYMLINKS]

LNSUB.;1 -> SUB 21-FEB-2011 20:19:44.93
SUB.;1 21-FEB-2011 20:25:19.02
SUB.DIR;1 21-FEB-2011 20:18:44.42
THERE.;1 -> /the_sub
21-FEB-2011 20:37:38.95

Total of 4 files.
$ dir [.there]

Directory USER01:[BECKER_H.SYMLINKS.THERE]

FOO.;1

Total of 1 file.
$

>>> symlink on a volume that has write behind caching enabled because readlink() won't find it until the cache is flushed.
<<<
And vice versa. It's a bug.
$! same command, error is expected:
$ cre/symlink="/the_sub" there
%CREATE-E-SYMLINKERR, error creating symbolic link THERE
-RMS-E-FEX, file already exists, not superseded
$ del there.;*
$ cre/symlink="/the_sub" there
%CREATE-E-SYMLINKERR, error creating symbolic link THERE
-RMS-E-FEX, file already exists, not superseded
$! unexpected error, what else should I delete?
$! after waiting a while ...
$ cre/symlink="/the_sub" there
$

And yes, symlinks are for GNV:
$ bash
bash$ ls there/
FOO
bash$

[Craig A Berry]

Murali. Thanks for the offer. Here goes.


Hans wrote:

>Symlinks for directories kind of work

Thanks for the working example. I was working from a C example that I thought I had reproduced using pretty much what you do here in DCL, but I might've fumbled something and I don't have the details handy.

>>> you can't symlink to absolute pathnames that are not on one of those POSIX root GNV mount point thingies
<<<
>Not really true on V8.4.

Good to know. On v8.3-1H1 it's not there yet:

$ create/symlink="/sys$manager/operator.log" op.lnk
$ type/tail op.lnk
%TYPE-W-OPENIN, error opening DISK8:[BERRYC.TEST]op.lnk;1 as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

>>> symlink on a volume that has write behind caching enabled because readlink() won't find it until the cache is flushed.
<<<
And vice versa. It's a bug.

And here is a reproducer in C. (And it's really unlink(), not readlink() that is unable to deal with cached file headers):

$ type symlink_nowritethru.c
#include
#include
#include
#include

main() {
char fn[]="regularfile.tmp";
char sl[]="symlink.tmp";
char buf[30];
ssize_t buflen;
int saved_errno = 0;
FILE *f;

if ((f = fopen(fn, "w+")) == NULL)
perror("fopen() error");
else {
fprintf(f, "I am not a symlink!");
fclose(f);

if (symlink(fn, sl) != 0)
perror("symlink error");
else {

if ((buflen = readlink(sl, buf, sizeof(buf))) != -1) {
buf[buflen] = '\0';
printf("# readlink() succeeded, '%s' points to '%s'\n",
sl, buf);
}
}
}

/* clean up */
if (unlink(sl) != 0)
perror("Couldn't unlink symlink");
if (unlink(fn) != 0)
perror("Couldn't unlink regular file");

}

Make sure you're on a volume with write-back caching enabled via SET VOLUME/NOWRITETHROUGH and notice that it cannot unlink the symbolic link it's just created:

$ write sys$output f$getdvi("SYS$DISK:", "WRITETHRU_CACHE_ENABLED")
FALSE
$ r symlink_nowritethru
# readlink() succeeded, 'symlink.tmp' points to 'regularfile.tmp'
Couldn't unlink symlink: no such file or directory
$ dir symlink.tmp

Directory DISK8:[BERRYC.TEST]

symlink.tmp;1

Total of 1 file.

Run it on a volume without write-back caching and it removes the symlink just fine.

[Craig A Berry]

Regarding Bill's problem with upcased man page filenames that the man utility can't locate, the source files do appear to be in lower case:

http://gnv.cvs.sourceforge.net/viewvc/gnv/gnv213/man/man_pages/man1/

So that one appears to be a GNV kitting problem. Someone probably got the memo that PCSI has trouble with lower case filenames (which was true at one point) and studiously upcased everything, which is clearly not appropriate for GNV.

[P Muralidhar Kini]

Hi Bill,

Please dont mind the deviation in the original topic caused due to my
discussion on symlinks.
I have now created a new thread for discussion on symlink problems
http://h30499.www3.hp.com/t5/General/Any-known-problems-with-SYMLINKS/m-p/4756917#M19408

Thanks Craig and Becker for providing the data. i will reply to these data in
the new thread created for discussing symlinks.

Regards,
Murali

[Bill Pedersen]

Murali:

No offense taken. The issue of symlinks is really where this started but as I was working on getting other things working I ignored them.

I will add a comment on the other thread as well...