HLPWWW (Version 8.7) JESS copyright (C) 1985-2019 Licensee : Webmaster, Murdoch University, Australia Welcome. Wednesday, 24-Apr-24 19:06 The following deals with the normal recovery procedure following premature termination of program UPDJTH. It is assumed that you have a copy of the database exactly as it was prior to the accident. First, check that the file UPDJTH.JNL exists in the directory which contains the database on which you were working when premature termination occured. Rename it as UPDJTH.VDU and then edit it to ensure that it contains a reasonably complete record of the UPDJTH session which was interupted. (If it does not, you are in rather more difficulty than is the case otherwise - consult the index using the type of database (JTH) and the terms "emergency" and "recover" to obtain details on how to proceed.) Look especially at the last few lines of the UPDJTH.VDU file; it is sometimes sensible to delete a few of these so that the recovery ends in a convenient way, i.e. not in the middle of some insertion. Secondly, rename the existing *.IND files to, say, *.BAD You should not need these files again but it is best to keep them initially in case something goes wrong with this procedure (for example, if your copy is not exactly as it was prior to the accident). Thirdly, re-instate the *.IND files from your copy of them. It is best to "copy your copy" not rename it, again to guard against the unexpected. Fourthly, XQT UPDJTH and then enter "||||UPDJTH" (without quotes) in response to the first prompt (for the database name). You should find that all the entries you made during the interrupted session of UPDJTH are then repeated. You end up at the point where the last entry in the UPDJTH.VDU file has been implemented. It is then best to QUIT in the normal way, make a copy of the updated database and inspect it using XQT VEWJTH to check that everything seems OK.
The following deals with the normal recovery procedure following premature termination of program GETJTH. It is assumed that you have a copy of the database exactly as it was prior to the accident. Simply re-instate the database exactly as it was prior to the accident and again XQT GETJTH. This should work without a problem since the sequential files for data to be inserted into the database are opened as read-only. Thus, there is no possibility that the premature termination of GETJTH can corrupt its input.
The following deals with the emergency recovery procedure following premature termination of program UPDJTH. It is assumed that you do NOT have a copy of the database exactly as it was prior to the accident. 1. XQT FIXJTH This will reset the flag which currently prevents access to the database by any other JTH program. It may then be possible to use the database normally. This would, however, generally be exceedingly unwise. This is because the internal links in the database may well have been broken or misaligned. When a program modifying the database is terminated prematurely (such as occurs under VMS after CTRL-Y, under Unix or DOS after CTRL-C or, under whatever operating system, when you have had a power failure!) there is subsequently no way that one can be sure of the integrity of the database. Both JESS and the operating system maintain data buffers so that, if these are not flushed (as happens on normal exit) the records in the database might well get out of sync. Sometimes you see the effects of this immediately (as evidenced by SYSERR crashes whenever you work in the vicinity of the database corruption). However, the effects can be more subtle. They may only manifest themselves later, and in ways that can be very difficult to address. The bottom line is that it is highly advisable, following premature termination of UPDJTH and other programs that write to the database, to take precautions against future trouble. These precautions are embodied in the steps of the procedure being described here. Unfortunately, the means of recovering from the position you are in are fairly complicated. So if you haven't entered a lot of data it is best simply to re-create the database and re-enter it. Alternatively, if this entails an unacceptable loss of time and effort proceed as follows. 2. XQT VEWJTH Browse around the database to establish (a) the date and time of the first entry/modification made - this being shown at the head of the data listed under "View Data"; (b) whether you have modified existing data or only just inserted new items; and (c) whether data in the vicinity of the reactions you were working on when the crash occurred have been corrupted. 3. XQT NUMJTH Select the options which allow you to specify the date and time established in 2(a) above. Thus obtain a file (as best as you can if crashes are occurring) with the reaction numbers of all those entered by you. This can of course be done manually if that is easier but make sure you identify ALL of the required reactions. On the other hand, you should omit those reaction numbers (if any) which cause VEWJTH to crash when an attempt is made to display the data for that reaction. These data are unrecoverable and will have to be entered again. 4. XQT SUBJTH Enter the name of your corrupted database (e.g. TST) and the name for a sub-database which you are about to create. Name the sub-database something like BIT, for example. The BIT sub-database will contain all the reactions which have been modified by you since the date/time established under 2(a) above. Then enter the relevant reaction numbers. If the latter are in a file (e.g. NUM.WRK) you can make the program read them in the usual way by entering ||||NUM.WRK at the reaction number prompt. Note that the lines are soliduses (straight up-and-down line symbols). Enter E (for END) to terminate entry of the reaction numbers. 5. XQT BLDJTH Build database BIT. 7. XQT PUTJTH Create a set of BIT*.WRK files containing all your new information. 8. Delete (or perhaps safer, rename) the original TST*.IND files 9. Re-create the TST database exactly as you did in the first place. Usually this means copying the files you have saved. For those who must learn about all this the hard way there may be no alternative but to XQT DOSUB again. 10. XQT GETJTH Insert all the information from BIT*.WRK into the newly-created TST database. In other words, at this stage the database is called TST and the sub-database is called BIT. 11. Make a copy of your recovered work; which should now have all appeared (in TST*.IND). Check everything thoroughly; if all is well you should delete the copy of the corrupted database, made by renaming the files in step 8 above.
The following deals with the normal recovery procedure following premature termination of program UPDJLR. It is assumed that you have a copy of the database exactly as it was prior to the accident. First, check that the file UPDJLR.JNL exists in the directory which contains the database on which you were working when premature termination occured. Rename it as UPDJLR.VDU and then edit it to ensure that it contains a reasonably complete record of the UPDJTH session which was interupted. (If it does not, you are in rather more difficulty than is the case otherwise - consult the index using the type of database (JLR) and the terms "emergency" and "recover" to obtain details on how to proceed.) Look especially at the last few lines of the UPDJLR.VDU file; it is sometimes sensible to delete a few of these so that the recovery ends in a convenient way, i.e. not in the middle of some insertion. Secondly, rename the existing *.KEY files to, say, *.BAD You should not need these files again but it is best to keep them initially in case something goes wrong with this procedure (for example, if your copy is not exactly as it was prior to the accident). Thirdly, re-instate the *.KEY files from your copy of them. It is best to "copy your copy" not rename it, again to guard against the unexpected. Fourthly, XQT UPDJLR and then enter "||||UPDJLR" (without quotes) in response to the first prompt (for the UPDJLR command). You should find that all the entries you made during the interrupted session of UPDJLR are then repeated. You end up at the point where the last entry in the UPDJLR.VDU file has been implemented. It is then best to QUIT in the normal way, make a copy of the updated database and inspect it using XQT VEWJLR to check that everything seems OK.
The following deals with the normal recovery procedure following premature termination of program GETJLR. It is assumed that you have a copy of the database exactly as it was prior to the accident. Simply re-instate the database exactly as it was prior to the accident and again XQT GETJLR. This should work without a problem since the sequential files for data to be inserted into the database are opened as read-only. Thus, there is no possibility that the premature termination of GETJLR can corrupt its input.
The following deals with the emergency recovery procedure following premature termination of program UPDJLR. It is assumed that you do NOT have a copy of the database exactly as it was prior to the accident.