Posted on

28-Feb-2008

Repairs
One issue was found on the management display: the list that contains the mail rejected by SMTP – the ones that slipped the spam filter. These were shown in OPERATOR.LOG but they didn’t show up in this list.
It turned out that spam.log – version ;2 – is correctly backed up to spam.txt – version ;2. However, version 3 existed as well, which didn’t hold the latest updates. Accessing over the web – without a version – caused this highest version to be shown. It was solved as simple as finding the issue: delete these versions above the one required….Now the right file shows up, including updates.

Another thing to be updated however didn’t work properly: Moinmoin, a type of wiki, on the web. Local, to start with, configuring following the documentation:
pass /wiki/* /moin_root/share/moin/htdocs/* ods=5
script+ /* /moin_wiki_root/vms/moincgiplus/* \
map=once ods=5 script=syntax=unix script=query=none \
script=as=moinmoin_usr throttle=1,,,30
This did’t work – even worse, the main page (index.html) didn’t show up. WATCH – the tremendous utility of WASD – showed the reason: /* – anything under the documentroot – is now mapped to the CGI-script, and the output showed “Function disabled”.
Of course, changing the mapping of the CGI-procedure to /wiki* as source made the index.html file show up again, but the wiki didn’t show up either, with the same message. What could it mean – I wasn’t aware of any WASD parameter that could disable teh CGI-Plus script. But since the site I used is a restricted one – requiring login under SSL – it could be that script=as=moinmoin_usr caused the script to fail. So this line was commented out and the mapping reloaded. Now, the result was that “illegal deirectory” – because moin_wiki_root wasn’t defined. Using moin_root instead didn’t crash immediately. It took some time, something IS wrong but at least, there was a page!
I needed to changes some things – it is uncertain if all post-install activities were done: the installation (actually: mount two LD devices) was done quite some time ago, and new versions are available. The new containers have been downloaded, and an Python RunTimeEnvironment, so I’ll retry after installation (inclusive a complete post-installation).

Another problem is that accessing index.html under the wiki did not work either, although the file does exists accessing this file still gives a 404 error: Document not found. The address however has been changed to a CGI procedure – on the same spot. That file does, indeed, not exist. But what causes this behaviour? Well, index.html does:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta http-equiv="refresh" content="0;URL=moin.cgi/">
</meta></head>

<body bgcolor="#FFFFFF" text="#000000">
Click <a href="moin.cgi">here</a> to get to the FrontPage.
</body>
</html>

(Using the real < and > caused problems displaying this entry!! Had to changed them using PHPmYaDMIN…)

So in the end, it works – if that CGI-procedure would exist.

Reason to update the container files!

Posted on

24-Feb-2008

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.

Posted on

21-feb-2008

Coding
Bit by bit, the program for dynamic content continues. Small steps at a time since it’s just a few hours on some days, and none on others.
It required slight updates for already present library routines, though the vast majority just does what it should do. I only found a slight mistake in one of the routines interfacing to Mark Daniel’s CGILIB, and that caused a problem getting data from the server. This has now been solved, and at this moment, the retrieval of required server symbols works, as well as the basis configuration for both home and blog-definitions.
Next will be the initialisation of all reports. The basics are alrteady in use in the current homepage, actually a derivate of the testprogram for all reporting routines, where the texts are hardcoded. But all of the html code is saved as a report in the text library. There is no HTML-generating code in this program!
And that’s what I want it to be like.

Some thoughts are still maturing – not at all fit for implematation, but to give an idea:

  • Specify the order of the blocks to be used in generating the page
  • Write pages to memory and server from there (kind of cache). Most feasable for index pages, but it can also be used for normal pages. Perhaps multiple caches: one for indexes and and for pages
  • Make it a threaded application
  • Multiple handlers – which will require a global section where all data is kept: initialisation data, reports, caches…
  • make it a RunTimeEnvironment

    • Not necessaraly in that order. Give it time, it may, or may not, appear in a future release.

    (I noticed I have to adjust the specification of LIST items here – but that can only be done on the server itself, I have no access to the files via the web – for obvious reasons of security. In the mean time, I did some <font> specification, to make at least the text more readable)

    Posted on

    20-Feb-2008

    No T4 – but why – and since when
    This morning, it was observerd that all T4 programs are missing. I’ll dig into this tonight. Not that T4 is crucial (Diana’s processes will run without them) but for complete coverage of performance, it’s a pity some data is missing.
    When accessing SYSTEM mail, it turned that out yesterdays processing has finished, so it’s just starting collecting data for today failed. No further information at the moment (11:00 am)
    UPDATE
    T4 does run, only on different PIDs as expected. Up to today, the T4 processes showed up at the end of SHOW SYSTEM list. But at this moment, they show up more to the top. Using WASD’s SYSTEM report, this wasn’t that clear…