My legacy Cobol code is using canned xl calls to vplus. We put these
together about 12 years ago and they are tried and true. What I have done
is to put my new code into these calls so that when I flip a switch in the
calling code, the calls are reading from stdin and writing to stdlist.

My Perl based server builds temp files on the fly and then invokes the
Cobol program as follows:

run cobcode;stdlist=atmpfile;stdin=atempfile

My cgi script on my Linux box gets the user input, invokes the perl server
that passes the requests off to the Cobol code and gets the answer back
from what's written from the Cobol code to the perl server which passes it
back to the cgi script on the Linux box.

The test stuff is working well but I am running into one little glitch (
at least I think that it is a glitch - just in mind at the present) In the
view calls, the form is shown and then waits for user input. In my bypass
code, I am not sure of just how it is going to wait for the input to come
back from the client. I have only a simple test that takes from client and
runs Cobol code. I will be testing today on this possible problem.

Thanks again - as always any and all input from fellow programmers is
something of great value.

#Joseph Norris (Perl - what else is there?/HP3000/Linux/CGI/Msql)
print @c=map chr $_+100,(6,17,15,16,-68,-3,10,11,16,4,1,14,-68,12,1,14,8,
-68,4,-3,-1,7,1,14,-68,-26,11,15,1,12,4,-68,-22,11,14,14,5,15,-90);


On Wed, 16 Jun 1999, Tony Summers wrote:

Our solution is to have two entry points into the program - one for normal view access and one for batch access which simply feeds the main processing sections with "pre-filled" screens.

The multiple entry points can be acheived in a variety of ways - we tend to use run time switches (parm=nn).

The program has to recognise when it is in batch mode access and skip round the relevant View intrinsics.