Posted on

24-Apr-2008

First page shows
By adding log lines in the OpenReport routine showed the mistake causing the access violation. The routine should be called with the same context – actually the address where the initiated report is stored. Next problem turned out to be a wrong name: “PAGETITLE” was not found in the report. No wonder, I specified the wrong one. In changing the configuration file to contain the right report – behold: The pages shows up!
It’s only that no data is shown, but that seems to be rather normal if the datafile is empty. It’s also possible that getting the index record fails as well.
So next is to add data into these files – using a DCL procedure, to begin with. Perhaps I’ll write a tiny, Q’nD image that is as straight forward as possible. Just a simple input routine, and simple storage. Well, the routines do exist and can be used. In that case, I can (should) use Stephen’s recommendations.

On second thought: that might be the right way to go.

MySQL once more
Any time when an update comes along after some time (MySQL has been running for 2 weeks with just a few updates), the big one yesterday was stored – and MySQL_SERVER thought it time to crash again. I’m getting rather tired of this problem, and will update some time soon – there is not too many room at the moment.

SQLite
Someones is porting SQLite to VMS – something I abandoned a few months ago. Would I have looked deeper into the issue, I might have foun there is an os_vms.c file already available. Old, but very usable. It seems the big locking problem has been solved by the latest CRTL library routines – flck seems to be available on OpenVMS 8.3, and working. Jean-Francois Pieronne – Mr MySQL/Python/MoinMoin – did some re-code for some routines and theer shouldn’t be any problem now. How to integrate this with WordPress is probably not that easy – there will, no doubt, be a PHP extension but I don’t know if it can easily be ported. A Python one exists, and works.
But I can use it in my program. It’s FAST. It’s TINY. Just what I need on my small box.

Django
This is a Python framework for creating, well, articles and newspapers. Blogs, in other words. Google seems to use it as well as the framework for their applications.
Worth to try!

As usually, there is too much to be done in too little time 🙁

Posted on

23-Apr-2008

Creating a page: reading files
I found some time to get on with the web-page program. I remembered everything compiled, and I kind of recalled that there was something wrong in file specification in the [[HOME]] section, but that was about it.
Again, WATCH is the ultimate tool.
Accessing the data didn’t work, I got non-conformance messages all the time and watching the server work, it immediately can out what was wrong: The currently active version was built /DEBUG. The remedy is easy: rebuild the image withiout debug, and don’t forget to copy the result to CGI_BIN: ! (It took some attempts to remember that…)
Having that setup, where do the logfiles go? Although I had set the proper logical, and deleted the old files, no new logfiels were created. Returning memory fragments lead me to other places and have protection set so the server could indeed WRITE to the proper directory – a requirement to create files. It had worked before but when I installed the new webserver version, protections were reset. This one as well, so NO write access anymore…)

After an hour, I was at the point I could start finding out whether it works. Of course, id didn’t.

One of the things to be done before actually reading the data files, some converion needs to be done with date: A standard VMS-formatted datetime, like “23-apr-2008 21:25:22.012”, is not usable for a descending key – you’ll need this date converted to a sting like “20080423212522012”. Of course, I have a (FORTRAN) library routine, but there were some problems in there that needed to be solved. Finding out why that conversion failed took some time. The first was a miscalculation, which was simply solved, The other turned out to be testing for errors on an internal WRITE (integer*4 datum into a character*11 string ) returned a IOSTAT of 1 – non-zero so error – so the error branch was taken – but the converted data was indeed correct. The short cut is simply forget about status and use it reguardless the outcome. For now, that is. A final solution must be found later, but “1” seems to be valid in this case, though not zero. (ERRSNS gave some RMS error codes and none seems feasable – there is no RMS involved)

Once that was settled, opening the files failed: %RMS-F-DEV, error in device name or inappropriate device type for operation. The reason is quite obvious: using the right logicals is crucial. The program runs in the server’s scripting account and therefore the logicals should be defined in either /GROUP (for that user) or /SYSTEM. The latter is the easy one 😉
Still, the files were not opened, although the right name was specified. The debug log didn’t show why, and examioning the code revealed the one simple reason: the routine to initiate data access used fixed specifications in stead of the data stored in memory. It means an adjustment to the interface, passing the names of index and data files. These additional argumnets, used in OPEN statements, meant the files are accessable and can now be read. No errors found here, but it remains to be seen if data is actually passed.
I was anticipating that the read data could be seen once the data was stored in the report and outputted – these routines are used with the image cureently creating the homepage, but here I ran into another problem: an Access violation. There will be something wrong in the interface. The curent program is a FORTRAN one, and the new program is Pascal, and there may be an error in the PASCAL definition of the routine.

Now time is up – so solving that will have to wait. Just a short time, I hope