We've been working quite a bit with OIPI at Sprezz Towers recently, and having not had a problem creating PDFs locally we were flummoxed when the same PDFs would not create on the client's workstations - rather, every time we called Set_Printer("TERM") we'd get the following...
Being a little overawed by the apparent complexity of the INIT call we checked and rechecked our code but could find nothing wrong with it. Finally we gave in and contacted Revelation Support in the US who asked simply "Do you have a SYSTEMP table?". Well as it happens, locally we do - but on client sites we tend to only install directories we need so - as we weren't using AREV32 - we hadn't installed the AREV_DIR subdirectory and a file called SYSTEMP that lives there.
So we created a SYSTEMP table and lo and behold our formerly recalcitrant program began creating PDFs like they were going out of fashion.
But this still begs the question - why a SYS1000 loading error? To understand this we have to understand how file IO works in OpenInsight - especially in relation to file handles. In OpenInsight a file handle is effectively the name of the various Modified Filing Systems (MFSs) attached to the file followed by the program responsible for implementing the various IO opcodes (the Base Filing System - BFS), followed by the name of the DOS file that the operation should be performed upon. So taking a simple example of an indexed file, the file handle might look like this :-
SI.MFS²RTP57²REV10101.LK
When the system encounters say a read opcode, it would take the first program in the list (SI.MFS) and call it passing in RTP57²REV10101.LK. SI.MFS would then do it's thing (which in this case is to call RTP57 passing it REV10101.LK, and on return update index transactions) and then exit.
How does this help us?
Well look at the call stack - we've gone from our program to SET_PRINTER1, to RTP36, to RTP27. To explain this simply, our program has called SET_PRINTER1 with a TERM request. SET_PRINTER1 has tried to place a lock on a table (RTP36), but RTP27 - the program loader - has complained that it has been asked to call a null program. Why would RTP36 try to load a null program? Referring back to our logic, IO opcodes strip the first program from the file handle and call it. They don't check to see if there is anything IN the file handle as why would a programmer ever ask the system to use a null file handle?
From this we're able to conclude that the file handle for SYSTEMP (fingered as the culprit by RevSoft earlier) must have been null. From this we can extrapolate that somewhere in the code for SET_PRINTER1 there is an
Open "SYSTEMP" to vSystemp Else vSystemp = ""
Rev assure us that this has been fixed in 9.3 but it's worth bearing in mind that when faced with a SYS1000 error you might be looking at a blank file handle.
Being a little overawed by the apparent complexity of the INIT call we checked and rechecked our code but could find nothing wrong with it. Finally we gave in and contacted Revelation Support in the US who asked simply "Do you have a SYSTEMP table?". Well as it happens, locally we do - but on client sites we tend to only install directories we need so - as we weren't using AREV32 - we hadn't installed the AREV_DIR subdirectory and a file called SYSTEMP that lives there.
So we created a SYSTEMP table and lo and behold our formerly recalcitrant program began creating PDFs like they were going out of fashion.
But this still begs the question - why a SYS1000 loading error? To understand this we have to understand how file IO works in OpenInsight - especially in relation to file handles. In OpenInsight a file handle is effectively the name of the various Modified Filing Systems (MFSs) attached to the file followed by the program responsible for implementing the various IO opcodes (the Base Filing System - BFS), followed by the name of the DOS file that the operation should be performed upon. So taking a simple example of an indexed file, the file handle might look like this :-
SI.MFS²RTP57²REV10101.LK
When the system encounters say a read opcode, it would take the first program in the list (SI.MFS) and call it passing in RTP57²REV10101.LK. SI.MFS would then do it's thing (which in this case is to call RTP57 passing it REV10101.LK, and on return update index transactions) and then exit.
How does this help us?
Well look at the call stack - we've gone from our program to SET_PRINTER1, to RTP36, to RTP27. To explain this simply, our program has called SET_PRINTER1 with a TERM request. SET_PRINTER1 has tried to place a lock on a table (RTP36), but RTP27 - the program loader - has complained that it has been asked to call a null program. Why would RTP36 try to load a null program? Referring back to our logic, IO opcodes strip the first program from the file handle and call it. They don't check to see if there is anything IN the file handle as why would a programmer ever ask the system to use a null file handle?
From this we're able to conclude that the file handle for SYSTEMP (fingered as the culprit by RevSoft earlier) must have been null. From this we can extrapolate that somewhere in the code for SET_PRINTER1 there is an
Open "SYSTEMP" to vSystemp Else vSystemp = ""
Rev assure us that this has been fixed in 9.3 but it's worth bearing in mind that when faced with a SYS1000 error you might be looking at a blank file handle.
| Making Databases Happen |
USA +1 267 238 3814
|