Brad wrote (a while ago):

>I ran into a couple of very annoying problems.
>
>1. Transact opens all referenced databases and files when the program
>starts. Therefore, the filename in the system statement is a fixed
>entity. Yes, you can use file equations but that doesn't help when you
>are using uniquely named message files as communication pipes back to a
>web browser.

One potential approach might be to have Transact open the file and then
use the Posix rename "/bin/mv" or the respective library call (rename?)
to change the name of the already open file (eg to something including
the HPPIN).

But there would still be the need to "single thread" the initialization
phase from process creation (and std file opening) to after the rename().

>2. I cannot call a Transact program from *any* process in a CGI
>context under the Apache web server. I tried HPCICOMMAND, TL-CALL-TRANSACT
>and CREATEPROCESS but with each I get the same result -- tombstone. I CAN
>call a Transact process from the POSIX shell in a POSIX directory. Only
>fails in the CGI context.

Hmmm. I am launching Transact programs in CGI context from a small shell
script wrapper. The script carefully redirects input and output of the
Transact programs to /dev/null or a permament file (name constructed to
be unique).

>In fact, because Transact is so good at Image processing, I created a
>COBOL program to run under a job whose sole purpose is to spawn a Transact
>process on the browser's behalf. Message files are used to communicate
>between the browser and the spawned Transact program.

This approach sounds quite good also from the resource efficiency point
of view. At least if the spawned Transact "database server" can be used
from more than one CGI i.e. stays alive for future requests.

>Now if I could just get around the CGI problem, I would do all my web
>stuff with Transact.

This is why I even played with CREATEPROCESS from Java. Might be nice
to use Java for the networking, web, client-server etc. stuff and let
Transact child processes do the TurboIMAGE retrievals/updates (where
the prefix "turbo" might make good sense ;-)

Lars.