Passing shell arguments to OpenVMS Fortran 90 programs the Linux way

[Ph Vouters]

Dear HP Fortran for OpenVMS programmers,

Although HP Fortran for OpenVMS is stuck to 95 standard, it is somehow still possible to translate Fortran 2003 source code to HP Fortran 90/95 standard thanks to the HP Fortran community. The OpenVMS solution at http://vouters.dyndns.org/tima/OpenVMS-Fortran_90-getopt_long-Passing_shells_arguments_to_programs-The_Linux_way.html is a translation of the Linux Fortan 2003 solution at http://vouters.dyndns.org/tima/Linux-Fortran_2008-getopt_long-Passing_shells_arguments_to_programs-The_Linux_way.html

In the hope this method can give you ideas on defining a VMS foreign command for your Fortran programs and pass them arguments the C way. from DCL.

Yours truly,

Philippe

[Ph Vouters]

I must state that unlike for the C equivalent, the DCL arguments passed to the Fortran program using this method are case sensitive. For example:

$ fortran/source=free getopt_long.f90
$ link getopt_long,f2kcli,getopt
$ getopt_long :== $PHV:[PHV]getopt_long.EXE
$ getopt_long -Wf
You activated this program with --first_arg
$ cc getopt_long
$ link getopt_long,getopt
$ getopt_long -Wf
$1$DGA102:[PHV]getopt_long.EXE;73: unknown option -- w
?? getopt returned character code 077 ??
You activated this program with -f

$ getopt_long "-Wf"
You activated this program with --first_arg

$

Perhaps, the HP OpenVMS CRTL engineering could get inspiration from [.source.vms.f90]f2kcli.f90 so that uppercased DCL arguments passed to C programs no longer need to be quoted enclosed ! This would impact as well Java for OpenVMS which is based upon the CRTL. For HP engineering information, f2kcli.fs based upon lib$get_foreign for the DCL passed arguments. This would make porting Unix shell scripts activating Java or C programs much easier.

Philippe Vouters

[Jansen_8]

---

@Ph Vouters wrote:

I must state that unlike for the C equivalent, the DCL arguments passed to the Fortran program using this method are case sensitive. For example:

$ fortran/source=free getopt_long.f90
$ link getopt_long,f2kcli,getopt
$ getopt_long :== $PHV:[PHV]getopt_long.EXE
$ getopt_long -Wf
You activated this program with --first_arg
$ cc getopt_long
$ link getopt_long,getopt
$ getopt_long -Wf
$1$DGA102:[PHV]getopt_long.EXE;73: unknown option -- w
?? getopt returned character code 077 ??
You activated this program with -f

$ getopt_long "-Wf"
You activated this program with --first_arg

$

Perhaps, the HP OpenVMS CRTL engineering could get inspiration from [.source.vms.f90]f2kcli.f90 so that uppercased DCL arguments passed to C programs no longer need to be quoted enclosed ! This would impact as well Java for OpenVMS which is based upon the CRTL. For HP engineering information, f2kcli.fs based upon lib$get_foreign for the DCL passed arguments. This would make porting Unix shell scripts activating Java or C programs much easier.

Philippe Vouters

---

[Jansen_8]

Seems you cannot use CSWB on OpenVMS to post to these forums. All text I added in my previous post was dropped

What I wanted to say:

Case sensitivity of the arguments in C-programs depends on the settings of the parse style. To make it case sensitive do one of the following

$ set  proc/parse=extend

or

$ define DECC$ARGV_PARSE_STYLE enable

the way your fortran program is coded seemns not influenced by these parameters.

[Ph Vouters]

Re Jansen_8

Why is there such an inflation of DECC$* logicals when some or many of them could be avoided ? This causes VMS users  using VMS C programs to become CRTL experts. This includes as well VMS Java users.

My lietmotto is always : "Simple is beautiful" and this DECC$* logicals inflation make VMS uselessly complicated and very end-user unfriendly.

All the contrary of the spirit of the DEC's founder who initiated VAX/VMS and the Digital Command Language (DCL) which was later imposed to all DEC's operating systems including RT11/RSX11-M/RSTS.

Philippe Vouters (ex-DEC)

[Ph Vouters]

RE: Jansen_8

Your reply is not fully correct. I need both for a C program :

$ set process/parse=extended

AND

$ define DECC$ARGV_PARSE_STYLE enable

Here is my proof:

$ cc getopt_long
$ link getopt_long,getopt
$ getopt_long :== $PHV:[PHV]getopt_long.EXE
$ set process/parse=traditional
$ define DECC$ARGV_PARSE_STYLE enable
$ getopt_long -Wf
$1$DGA102:[PHV]getopt_long.EXE;74: unknown option -- w
?? getopt returned character code 077 ??
You activated this program with -f

$ set process/parse=extended  
$ getopt_long -Wf
You activated this program with --first_arg

$ deassign DECC$ARGV_PARSE_STYLE
$ getopt_long -Wf
$1$DGA102:[PHV]getopt_long.EXE;74: unknown option -- w
?? getopt returned character code 077 ??
You activated this program with -f

For the Fortran 90 equivalent:

$ sho logical DECC$*  

(LNM$PROCESS_TABLE)

  "DECC$EFS_CASE_PRESERVE" = "ENABLE"
  "DECC$FD_LOCKING" = "TRUE"

(LNM$JOB_890F66C0)

(LNM$GROUP_022000)

(LNM$SYSTEM_TABLE)

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

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)

$ deassign DECC$EFS_CASE_PRESERVE
$ deassign DECC$FD_LOCKING      
$ fortran/source=free getopt_long.f90
$ link getopt_long,f2kcli,getopt
$ set process/parse=traditional
$ getopt_long -Wf
$1$DGA102:[PHV]getopt_long.EXE;75: unknown option -- F
?? getopt returned character code : octal( 77 )
$ set process/parse=extended  
$ getopt_long -Wf
You activated this program with --first_arg
$ set process/parse=traditional
$ getopt_long "-Wf"
You activated this program with --first_arg
$

So your DECC$ARGV_PARSE_STYLE logical makes things uselessly complicated and very end-user unfriendly..

Yours sincerely,

Philippe

[x2084]

>>>

$ set  proc/parse=extend

or

$ define DECC$ARGV_PARSE_STYLE enable

<<<

You have to have both, the DCL and the C RTL "feature".

>>>Why is there such an inflation of DECC$* logicals ...<<<

There IS an inflation of C RTL features to let the RTL behave more like on Unix/Posix systems. One way to enable such a feature is to use a logical. However, real programmers would enable the feature "with" the image. The way to do this is to enable it at image initialization time. Once this is done, no VMS user needs to define DECC$ logicals. But the user still has to enable the extended parsing. Then arguments to foreign commands (as well as file specifications) are case preserved.  I wonder whether extended parsing was enabled for the FORTRAN example or not.

[Ph Vouters]

Why not a simple DECC$UNIX_COMPATIBILITY enable instead of this inflation of DECC$ logicals ?

By the way, I know of two cases where DECC$SELECT_IGNORES_INVALID_FD enable proved useful :

With getdtablesize() C call as highlighted by http://vouters.dyndns.org/tima/OpenVMS-TCPIP-C-fd_set_getdtablesize_select_file_descriptors_limit.html and with select() or poll() C calls when sockets are in a FIN_WAIT_2 state

For getdtablesize() this logical can be avoided provided this CRTL routine takes the minimum of SYSGEN CHANNELCNT and the FILLM process quota.

For select() or poll() with sockets in FIN_WAIT_2 states, this logical can be avoided provided TCP/IP for OpenVMS enables to automatically close FIN_WAIT_2 state sockets with a zero FIN_WAIT_2 timeout like on any Unix/Linux operating systems, including HP-UX. For full information on the minimum FIN_WAIT_2 timeout on OpenVMS systems, refer to http://vouters.dyndns.org/tima/OpenVMS-TCPIP-FIN_WAIT_2_state_sockets.html

[Willem Grooters]

The DECC stuff is nasty, but hardly avoidable to have Unix-based stuff (and JAVA in particular) run on OpenVMS - because it's background. The big flaw is the fact that Unix - and hence Linux,  JAVA and other Unix-base software - is case sensitive. Up to date I've never heard a valid argument for it's reason....

Most VMS programs don't care since VMS adheres to uppercase only - by default. That's the way VMS is built. Mixing case breaks things. Especially if it's done 'under the hood' - where you wouldn't expect it. It happens: When any program in the chain finds out it runs, or expects itself to run in an ODS-5 environment,  and changes PARSE_STYLE (which is a process environment setting!) where other programs cannot handle mixed case, you run into trouble.

I ran into a similar issue years ago, where a program using 3rd party libraries, was run by a webserver from it's CGI-procedure, since SET PARSE_STYLE to EXTENDED influences the way that the commandline is passed to the program.

PARSE_STYLE=TRADITIONAL didn't just turned all filenames, diretories et al to uppercase. Data passed to a program was uppercased as wel. PARSE_STYLE = EXTENDED kept it all as it was typed - INCLUDING the parameters passed to the program. Things get funny if you compare passed parameters to VMS way: UPPERCASE only.  When the CGI procedure was set to do SET PARSE_STYLE to EXTENDED, the program didn't work properly, because the passed (and compared) parameters were no longer converetd to uppercase\, and "IF param="A"" (TRUE) became "IF param = "a"" (FALSE).

How ugly these DECC logicals may be, they offer a greater deal of fine-tuning, a requirement where co-existance, and co-operation between programs is key issue - that is: in most cases. Best solution: Avoid case sensitivity. :smileyhappy:

[Ph Vouters]

Dear Willem,

Thank you for your response. VMS is so traditionnally uppercased that under the VMS debugger you can't

DBG> set image DECC$SHR

then back

DBG> set image <mixed or lower case>

I came across this issue while debugging the Java to C translated program available at:http://vouters.dyndns.org/tima/OpenVMS-CRTL-Java-C-Illegal_seek-lucene-Problem_with_running_any_lucene_based_Java_code.html.

This tradionally uppercased VMS makes it port of Opensource code terribly complicated without the fact that the C RTL partly implemetns the set of C Unix calls.

Philippe