Re: Rexx vs. execve

[Paul Gilmartin <pg...@sweng.stortek.com>]

In a recent note, Bill Schoen said:

> Date:         Tue, 21 Dec 1999 08:47:14 -0500
> Sender: MVS OpenEdition <MV...@VM.MARIST.EDU>
> From: Bill Schoen <wj...@US.IBM.COM>
>
> By convention, argv[0] should be the name of the program you are exec()ing.
> For the REXX support, this is actually required since the front-end to the
> interpreter (BPXWREXC) is what is really exec()ed and the only hint it has
> to find the script is argv[0] and the environment variables.  With exec()
> everything else gets blown away.  Since you are passing the argv given to
> your program, it probably locates your C program and figures out it is not
> a REXX exec.
>
Ummm.  So if I put a fully qualified path in "path" and the name of
a totally different Rexx Exec in argv[0], execve() will first examine
the magic number of the first to determine that it's Rexx, then
call the interpreter to execute the second, right?

Very ugly; actually incredible and unconscionable.  I'm surprised
I didn't stumble on it sooner.

I encountered this in real life testing a colleague's work porting
a popular application to OS/390.  This application provides a form
of user exits.  These may be written in C, Bourne Shell, Perl, etc.
I thought it was reasonable to try writing one in Rexx.  Exits
reside in a directory that the user identifies in a configuration
file.  On other platforms and for languages other than Rexx, the
user is accustomed to not need to put the exits directory in
the PATH environment variable.

The application takes the name of the exit the user supplies,
prefixes the directory name, and calls execve with the fully
qualified name as "path" and the basename as "argv[0]" leading
to the BPXW0000I.

I'll ask the senior developers whether it's preferable to
add "#ifdef __MVS__" and pass the fully qualified path as arg[0],
or to require users to add the exits directory to PATH if it's
desirable to code exits in Rexx.

Drat!  This application actually contains code to examine magic
numbers and invoke interpreters for platforms lacking the "#!"
facility.  Alas, this works by detecting and recovering from
the ENOEXEC error.  But in the case of Rexx-OS/390, execve()
has already replaced the process space with the interpreter
before the error is reported.

OS/390 has too many wrong ways of invoking interpreters.  A
case in point is OW31644, which has already broken for Korn
Shell.  It would be preferable to pass the full pathname as
argv[0], which is what other UNIX implementations appear to
do, rather than introducing the peculiar breakages of OW31644
and execve()-Rexx.  Yet another case is in PMR 41861,033,000;
clearly broken, but no APAR yet (six months and counting).

-- gil
--
StorageTek
INFORMATION made POWERFUL