topic Re: GNV behavior and the DECC incantations in Operating System - OpenVMS

GNV behavior and the DECC incantations

Bill Pedersen — Fri, 18 Feb 2011 14:39:04 GMT

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.

Re: GNV behavior and the DECC incantations

H.Becker — Fri, 18 Feb 2011 15:43:59 GMT

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.

Re: GNV behavior and the DECC incantations

Bill Pedersen — Fri, 18 Feb 2011 15:50:24 GMT

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.

Re: GNV behavior and the DECC incantations

H.Becker — Fri, 18 Feb 2011 16:20:25 GMT

>>>
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.

Re: GNV behavior and the DECC incantations

Hoff — Fri, 18 Feb 2011 16:31:14 GMT

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..

Re: GNV behavior and the DECC incantations

Bill Pedersen — Fri, 18 Feb 2011 17:27:24 GMT

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.

Re: GNV behavior and the DECC incantations

Steven Schweda — Fri, 18 Feb 2011 18:35:04 GMT

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.

Re: GNV behavior and the DECC incantations

Bill Pedersen — Fri, 18 Feb 2011 19:41:03 GMT

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

Re: GNV behavior and the DECC incantations

Hein van den Heuvel — Fri, 18 Feb 2011 20:33:00 GMT

>> 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

Re: GNV behavior and the DECC incantations

Bill Pedersen — Fri, 18 Feb 2011 21:08:57 GMT

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.

Re: GNV behavior and the DECC incantations

Steven Schweda — Fri, 18 Feb 2011 22:05:21 GMT

> "/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

Re: GNV behavior and the DECC incantations

Bill Pedersen — Fri, 18 Feb 2011 22:22:55 GMT

No, it is an ODS-5 disk.

Re: GNV behavior and the DECC incantations

Steven Schweda — Fri, 18 Feb 2011 22:29:57 GMT

> 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.

Re: GNV behavior and the DECC incantations

Bill Pedersen — Fri, 18 Feb 2011 22:49:54 GMT

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.

Re: GNV behavior and the DECC incantations

Bill Pedersen — Sat, 19 Feb 2011 00:06:14 GMT

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.

Re: GNV behavior and the DECC incantations

Steven Schweda — Sat, 19 Feb 2011 02:10:55 GMT

> 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.

Re: GNV behavior and the DECC incantations

Steven Schweda — Sat, 19 Feb 2011 02:14:13 GMT

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.

Re: GNV behavior and the DECC incantations

Craig A Berry — Sat, 19 Feb 2011 04:39:21 GMT

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.

Re: GNV behavior and the DECC incantations

H.Becker — Sat, 19 Feb 2011 11:24:30 GMT

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 :-)

Re: GNV behavior and the DECC incantations

P Muralidhar Kini — Mon, 21 Feb 2011 08:16:08 GMT

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