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
You could use an RMS ascending or descending key for the storage of a binary date value within your storage field; see the XAB$C_BN8 and XAB$C_DBN8 ascending and descending key types for the quadword format. A call to sys$asctim or sys$bintim to convert, and you’re home.
As you are writing this application fresh, I’d suggest dispensing with the OpenVMS classic native dates (in the internal storage) and use the “newer” dates available in OpenVMS, either in the form of the UTC system services, by using the DTSS calls in V7.3 or later, or by always converting the traditional quadword date to UTC when storing it and converting to local time on the way back out. By always attaching UTC or a TDF-capable format in the storage.
These approaches will far more easily get you the timezones, if and when you get to that. This should you decide to add “local time” support for viewers, or should you wish to avoid the usual slew of TDF “fun”.
Binary dates used as keys are most stable when the date values are always-increasing values, and the traditional OpenVMS time formats don’t do that if you follow daylight saving time conversions.
For long-running applications, there are system service event notifications for time changes and TDF changes, too.
I have thought about using the date as a binary value and use $ASCTIM and $BINTIM, and converting date to UTC as a base – and taking eventual DST into account (My system is set to UTC without DST, which makes life easier – internally.
The reason I didn’t follow the idea is twofold.
To start with, the program to output text has a higher priority than pushing the data into the files. This format allows me to use DCL to push data into the files (I didn’t find a proper way to transfer the date (in whatever format) to a 64-bit integer in DCL). If I have created a program to add data into the database (the basic routines already exist) it will be a simple transition. Moving to SQLite, MySQL or RdB is an option as well.
Secondly, I tried binary time as a key, but had trouble to get things right in the FDL files and accessing them from a Pascal source. I don’t remember the details but IIRC, there are constraints in Pascal using 64-bit binary keys. Unless I would write my own open- and access routines.
Since time is a constraint – I want to have the program running as soon as I can – I’d rather keep it simple and keep the original idea in the back of the head, so transition to the original idea would not be too hard. .
Moving to a database (mySQL, RdB) or database-like (SQLite) would be a good moment for that:
I’ll need a program for this access anyway.