[Info-vax] Looking into C-include files on VMS

[John E. Malmberg]

Joerg Schilling wrote:
> Hi,
> 
> I am currently trying to make compiling cdrtools a bit more automated.

http://encompasserve.org/anon/htnotes/conf?f1=PORTING_TO_VMS

Read access does not require an account.  Accounts are free.

As long as you are doing an update:

mkiosf is assuming that the host system has the "." and ".." special 
directories and exits with an error if they are not present.

The ISO 9660 specification does not require the existence of these 
directories, and as far as I know, neither does the X/Open group Unix 
standard.

> 
> OpenVMS XXX 0 V7.2 VAX_7000-720 VAX

<snipping and skipping answered questions>

> The machine I have access to has a GNV installation from March 2005 which is 
> obviously not the latest version.

GNV on VAX has been abandoned at the moment.  I do not know if work wil 
resume on it.  GNV on Encompasserve.org is up to date, and is properly 
installed, something that the existing GNV install kits will not do.

> There are several problems:
> 
> -	The filesystem only supports one dot "." in filenames which would
> 	require modifications in "configure"

Correct.  The work around used by other projects is to put wrappers 
around the C library calls to open files and then encode the names.  I 
have seen 4 popular methods for this.

     1. Replace all illegal characters with underscore (not reverseable)
     2. Old Pathworks(Advanced Server) where illegal characters are
        replaced by _XX where _XX is the HEX encoding for the character,
        and the first period is not encoded.
     3. New Pathworks, where the last period in a filename is not encoded
        because it makes files more readable on the host.
     4. Using a $ character to indicate a case shift, which in addition
        to violating VMS naming conventions, causes problems with
        accessing files from some of those utilities.

As has been pointed out later in the thread using Alpha / Itanium will 
support ODS5 disks.

On encompasserve.org, an ods5 volume is usr_ods5:[xxxx] where [xxxx] is 
your login username.

But that is far from the only problem with configure.  Configure is not 
properly checking for things as it is not using the header files for its 
initial checks.

On platforms that maintain backwards binary compatibility with older 
versions, the default entry point for a C library function or syscall 
can have bugs in it that can not be fixed because they will break 
existing programs.  But newer programs that use the standard header 
files will get redirected to the fixed routine.

This is not just a VMS specific issue, but it shows up in VMS more than 
  in Unix because VMS does not implement the alternate APIs that Unix has.

So unless you hand inspect the output of configure on each different 
platform, you may not be getting optimal results.

And lately about 1/3 of the time it takes to run configure is wasted on 
checks that configure already knows the answer to.

It is first checking to see if a header file is working, and then 
regardless of the outcome is then doing an almost identical test to see 
if the header file exists.  Why?  If it is working, it obviously exists, 
and if it is not working, then it does not matter if it exists.

> -	cc always exits with exit code 0 even in case of errors. This
> 	causes many configure tests to fail

You need to define _POSIX_EXIT to be 1, and you need to make sure that 
main() calls exit() instead of returning unless you have V7 compiler 
that supports /MAIN=POSIX_EXIT

And the module must include <stdlib.h>, or the _POSIX_EXIT definition 
will be ignored.

See the encompasserve.org conference link for how to fool configure to 
get the right answers with out modifying the Unix source.

> -	cc -E t.c | grep something hangs infinitely
> 	This causes most of the other configure tests to fail

That is a known bug in GNV bash.  It uses the CRTL pipes which are 
implemented as VMS mailboxes.  VMS mailboxes are too small.  The updates 
at ftp://encompasserve.org/gnv have the fixed source to use virtual 
memory pipes.  The current GNV kit should have that fix.

> -	OpenVMS 7.0 should support a POSIX compliant struct stat.st_ino
> 	but I cannot make this work.

Sorry, you have to get VMS 8.2 or later of VMS for a standard stat and 
need to request it by _USE_STD_STAT macro.  Current GNV kits will do 
this automatically.

Older versions of the CRTL have incomplete stat.st_ino values.

The st_ino on VMS is 48 bits.  Some programs truncate it to 32 bits and 
hope that it is good enough.  I would have to look at the stat.h file to 
find the variants.  I think that there are about 7 different possible 
stat_t structures that can be returned depending on the macros passed to 
stat.h.

But you need VMS 8.2 and _USE_STD_STAT to get one that is standard 
compliant.

> 	**********************
> -	I cannot see the ful content of the system include files.
> 	Could someone help me with hints on how to do this?
  	**********************

As pointed out before, those are in text libraries.  There is a command 
procedure that a privileged user can extract them into a reference 
directory, but I do not have time to look it up now.

> 
> I am currntly trying to compile "smake" and use a static hand made 
> configuration that was created by Mr. Heuser but I need to find a way to
> run commands via bash. What is the best way to do this? THere seems to be no
> fork() but vfork(). Will vfork()/exec() work?

There are dragons there.  You may want to see if you can find something 
useful in the GNV bash updates at the ftp://encompasserve.org/gnv directory.

1. vfork() does not create a new process, but returns twice, but both 
times until you successfully exec(), you are still in the parent process.

There are bugs in the vfork/exec() code that can not be fixed because 
existing programs depend on them.

Steven Schweda wrote:

 >    I've been trying for (what seems like) a (very) long time,
 > with limited success, to get him to adopt some VMS-specific
 > changes in various cdrtools programs related to process
 > priorities (where VMS and POSIX differ), scanning every device
 > on every SCSI adapter looking for optical-writing drives, and
 > (my absolute favorite) "fwrite(buf, 1, len, f)" versus
 > "fwrite(buf, len, 1, f)" (where one creates "len" one-byte
 > records on VMS, while the other creates one "len"-byte record,
 > and it doesn't matter on UNIX),

Joerg, it is absolutely necessary to have that change that Steven 
mentions in order to make the program usable on VMS.

VMS is designed as a record oriented file system, and has mapped the C 
file calls to this.  Doing a bunch of single byte writes on VMS will 
totally kill the performance of a system as compared to doing a single 
write of a record.

It may also be possible that other platforms can suffer if you do single 
byte writes to files that are disk.

-John
wb8tyw at qsl.network
Personal Opinion Only