[log in to unmask] wrote:

> I said to Kevin yesterday:

> > I posted some information along these lines to Kriss Rant on a
> > related topic offline; I can forward that if you like (it is in
> > my mail folder at work, not here).  It outlined some of the
> > "missing pieces" that I referred to above.

> Please do!  I've worked on HP-UX in a limited amount about a year
> ago.  I helped setup a internal web site, but I'm afraid that I am
> *very* new at this MPE/iX to Posix shell stuff.

I've been bickering over this for going on two years now, so anyone
else so inclined is welcome to join the "customer demand".  Anyway,
here's the reply to Kriss.  Some of the included discussions involve
MPE 5.0 and I haven't verified that 5.5 doesn't address them, but can
confirm that the statements are still [AFAIK] true on 5.5.  Some last
minute clarifications (in [brackets]) added:

Kriss Rant wrote:

> Can you please share with me what ideas you have for fixing
> POSIX and the wall around it?  You mentioned that there are
> issues in POSIX that make it difficult to create a COBOL cgi-bin.

Here are a couple of issues.  First, why the freeware NCSA httpd is
stuck at version 1.3 [while the freeware unix one is several generations
later]; I spoke with Mike Belshe about this when he was still with CSY
and his comments were:

> The big "problem" with http on the 3K is that fork() is really slow.
    [Granted fork() has been addressed somewhat in 5.5 -- JK]
> So back in November of last year I tried to rewrite a version which
> would use multiple precreated servers and then pass the connection
> between them.  I got it to mostly work, but encountered some sockets
> bugs/limitations on MPE.
>
> Well, version 1.4 implemented a precreated server paradigm.  They
> used a slightly different mechanism than I did in my prototype- so
> I was optimistic that theirs might work.  It turns out they are using
> a little-known option of the recvmsg function call which supports
> passing file descriptors between processes on a UNIX system.  I
> checked the MPE BSD sockets manual to see if this option was
> supported.  The manual says that the system call accepts the "access
> rights" field (which is where the descriptors are passed) but
> doesn't explicitly state that the functionality works (neither does
> the UNIX man page!)...  Of course, it doesn't work- BSD sockets
> doesn't support it on MPE.  If anyone would like to file an SR for
> this, that would be great-we might be able to slide an SR in saying
> "the documentation says it is supported but it doesn't work".  It
> looks like it was completely forgotten in the MPE sockets
> implementation.
>
> It is probably possible to port V1.4 without the precreated server
> business, but I haven't really looked at it.  The coolest feature for
> the new server is the ability to have precreated servers, so I'm
> pretty disappointed that it doesn't work on MPE.

Now, more specifically to the cgi-bin issue.  COBOL cannot get any input
from cgi-bin METHOD=POST nor METHOD=GET actions.  The only language[s]
which can do this is c89/gcc.  In a 'C' program the cgi-bin program can
read the cgi input (a set of "name=value" pairs) from STDIN and write
output to STDOUT.  In the cgi-bin case, STDIN/STDOUT are mapped to the
open socket (the bsd socket between the web browser and the httpd
server).  Such is not the case with MPE-domain $STDIN[X]/$STDLIST.

There are two related problems:
(1) Posix and MPE don't allow all possible interchanges of file
descriptors and socket descriptors.  On unix, they are (almost) fully
interchangeable.  [In MPE terminology, cgi-bin works by redirecting
$stdin/$stdlist to the network socket; piece of cake on unix, limited
on Posix, broken on MPE].  Quoting again from Mike Belshe answering my
question about this problem when it first arose:

> Jeff Kell ([log in to unmask]) wrote:
> : I don't know which "standards" define exactly what behavior, but the
> : following code snippet is from the FreeBSD distribution whois.c
> : which does the "questionable" fdopen().
> :
> :         if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) {
> :                 perror("whois: connect");
> :                 exit(1);
> :         }
> :         sfi = fdopen(s, "r");
> :         sfo = fdopen(s, "w");
> :         if (sfi == NULL || sfo == NULL) {
> :                 perror("whois: fdopen");
> :                 (void)close(s);
> :                 exit(1);
> :         }
> :         while (argc-- > 1)
> :                 (void)fprintf(sfo, "%s ", *argv++);
> :         (void)fprintf(sfo, "%s\r\n", *argv);
> :         (void)fflush(sfo);
> :         while ((ch = getc(sfi)) != EOF)
> :                 putchar(ch);
> :         exit(0);
> :
> : In other words, they get to use file I/O on the sockets.  In
> : contrast, the FreeBSD "finger" does an fdopen() then uses read()
> : and write(), and as you mentioned, this works fine.

> Looks like you are right.  I wrote a little program with the
> following:
>
>    int sock;    /* socket descriptor */
>    FILE *fp;    /* file pointer to use with socket */
>
>    [...]
>
>    fp = fdopen(sock, "rw");
>
>    write(sock,"write works\n",12);
>    send(fileno(fp),"send to fileno(fp) works\n",25, 0);
>    send(sock,"send to sock works\n",19, 0);
>    fprintf(fp,"if this works I will be amazed\n");
>    fwrite("fwrite works\n",  sizeof(char), 13, fp);
>
> Output:
> hpcsyn22-ttyp2(/users/mbelshe) % telnet romeo 8000
> Trying...
> Connected to romeo.cup.hp.com.
> Escape character is '^]'.
> write works
> send to fileno(fp) works
> send to sock works
> Connection closed by foreign host.
>
> So I'd guess you are right.  The sockets calls are not accessible via
> the buffered IO calls (fwrite, fprintf, etc).
>
> File an SR!
>
> Mike Belshe
> [log in to unmask]
> HP CSY Networking Lab

(2) This incompatibility across file descriptors/socket descriptors is
aggravated by [when the files are] $STDIN/$STDLIST.

You can workaround this with a C wrapper which writes the info to a temp
file, then invoke the cobol program with $stdin redirected to the file,
but it shouldn't be required.

[If the above makes no sense, here's a more practical example of a
 perfectly reasonable expectation I had with inetd/telnet server on
 5.5 which didn't come about]

For the very same reasons, you cannot "attach" an MPE program to a TCP
port number -- it would be VERY desirable to us to be able to add a few
lines to /etc/inetd.conf so that specific tcp port numbers could be
associated with an application.  I would like to have something like
this in /etc/inetd.conf:

chargen      dgram  udp nowait MANAGER.SYS internal
telnet       stream tcp nowait MANAGER.SYS internal
#bootps       dgram  udp wait   MANAGER.SYS /SYS/NET/BOOTPD bootpd
tftp         dgram  udp wait   USER.TFTP /SYS/NET/TFTPD tftpd
myapp        stream tcp nowait USER.ACCOUNT /ACCOUNT/PUB/MYCOBOL mycobol

and define "myapp" in /etc/services:

whois        43/tcp  nicname
domain       53/tcp  nameserver     # Domain Name Service
domain       53/udp  nameserver     #
tftp         69/udp                 # Trivial File Transfer Protocol
gopher       70/tcp
finger       79/tcp
myapp      7000/tcp                 # My cobol application

The intended result would be to have users telnet to the machine using
port number 7000, and the "mycobol" application appears on the screen
running as USER.ACCOUNT with no login required.  Access to the
application can be controlled by /usr/adm/inetd.sec specifications.
This allows more "granular" and secure access than open telnet access
granting them a login prompt.  We use this on our unix servers but it
doesn't work on MPE.

You can do something "similar" with serial ports and :STARTSESS, but
there is no [network connection] equivalent currently in MPE.  I was
hoping this would be addressed by Telnet server/iX but alas, it was
implemented as an inetd internal service (instead of a more general
pty/vty solution).

Does that clarify my concerns/requests?

Jeff Kell <[log in to unmask]>

PS - Almost forgot; COBOL/iX cannot access the cgi-bin environment
variables either (i.e., c89 "getenv()" values).