No real issues – only an additional web
All seems well, on all systems. There are a few minor tweaks to take care of, but these are of class “somewhat annoying” and I can live well with them: it looks like the spam-list isn’t updated (I got a few messages slip through the mazes of PMAS that were discarded by SMTP, show up in the operator log but are missing in the list…)
The progress on the webpage program is more important at the moment.
The big thing, simply required to get on with the program, is running it as the main “page” – without reference to it’s actual location. No problem to map it, I thought, so I created a new service in WASD, to be usable from the local network only, and located on a separate port, so it wouldn’t interfere with all the other webs. I will run the program directly from the location that the building procedure will locate it on, but give it another name using a logical:
$ DEFINE/SYSTEM TSTEXE $1$DISK:[USER.DEV.EXE]
and map it all in HTTPD$MAP.CONF
map / /txtexe/wg_webpagedev map=once
exec /tstexe/* /tstexe/*
path /* /*testexe/*
like I have setup my mainpage (that uses “/cgi-bin/” under the hood)
It didn’t work: mapping was allright but once the ‘script’ was to be accessed, /tstexe/ was mentioned to be a bad name.
Finally, I took a look at the directory the home-exe runs under: cgi_bin. This proved to be a searchlist, to start with, but, like the blogs, both links are actully concealed devices!
After I defined TSTEXE as concealed device (there is no need (yet) for a searchlist) :
$ DEFINE/SYSTEM TSTEXE $1$DISK:[USER.DEV.EXE.]/TRANS=(CONCEALED)
and now it worked. I didn’t get the expected results (actually, I got the nasty “Not a valid CGI-response” error due to program errors not yet handled) but that was solved by creating and modifying the configuration file.
Expanding the code
The code has been expanded to show what’s read from the system (the symbols set up by tyhe webserver) and from the configuration, but just limited to the basic data. I added some more things to be displayed and it turned out that it wasn’t doing what it should: some data wasn’t accessed in the right place, or not at all. Some addition was made to the configuration and therefore the code, to get all data in place.
Once that proved to be right, the next phase is to load the report definitions, using the printLibrary routines (made years ago on VAX, and only recently ported to Alpha). Originally, the OpenReport function would do this, and prepare output as well. However, this is not feasable in this situation where output isn’t to be opened at all – yet – so I had to add another routine in the (FORTRAN) code of the print library routines: InitReport – actually the same as OpenReport but without accessing output. Another advantage is that here I can now specify the library – where OpenReport relies on logical PRINTLIB (this hasn’t changed). This new routine is now called to initialize the pages. So far, it looks good, in both html-output as plain ASCII.
It also meant I had to review the environment code I created before to access these routines. Some required attributes were still missing, and arguments that change, needed to be specified to be VAR.
Now I can start getting data, but first I should determine WAHT to get if no arguments are specified. It means another addition to the configuration file and structures (and code). It’s just more of the same and no problem at all.