8870 Adventures

© Joe Farr, 2011 – 2024

Home

Clear message 155 – System Recovery Is Necessary

There are two types of applications, those that can fail with no real adverse affects, and those that can’t.

If you are printing out a simple report odds are that as long as it doesn’t update anything if it fails, you can just fix the problem and run the print again. However, if you are running an accounts update that calculates figures, writes them away, deletes entries from a control file as its running, odds are that if this fails it’s not a simple task to just run it again, and in these cases, the software developer can indicate to the system that the program cannot fail and if it does, a system recovery, or 2nd Generation Recovery is required which simply means recovering the entire system from the last backup; and losing all your work since that backup was made.

What a program of this type fails you will get the dreaded “155 Recovery is necessary” message. (Irrespective of what the text actually says, it will always be message 155).

The reality is that on many occasions, trained software personnel could rectify the problem and cancel the recovery. Whilst working for the Nixdorf Software Support Centre in Manchester, I wrote many programs that could fix data due to a failed job thus negating the need for a full system recovery.

Whether you decide to do a recovery or not is ultimately down to the user, but the system isn’t going to let you do much until you either do the recovery or somebody clears it.

The actual process for clearing the recovery is quite simple. The flags indicating a recovery is required are stored in the file TF.PORT All that is required is to set the first 4 bytes of record 0 to “1000”.

Here I have two videos that show different ways you can clear the recovery flag and get your system working again.

This first method makes use of a utility program JU-READWRITE that is often available on the system disk. In the UK the equivalent was called HE-READWRITE

This second method shows how to write a simple BASIC program to clear the recovery flag for you. Don’t forget to save it as it may come in handy again.

2 responses to “Clear message 155 – System Recovery Is Necessary”

  1. Pam avatar
    Pam

    As far as I can remember, this was a TAMOS security message. You could always run the program from inside the Basic interpreter, but not from the TAMOS menu if the flag was on. A normal user, using TAMOS, only could do a restore from a full backup to be sure that the data will be consistent in the future. If a user always worked from TAMOS menu he could be sure that everything was fine. This was very progressive for that time. The procedure for restore was time-consuming but we didn’t have much possibilities to do it otherwise. It was end 19-seventies.
    We had to program our COMET Master 5 in 14KB chunks. Yep that is right, a whopping 14KB. Room for redo-files etc was not there. It was always looking for space to get an extra statement. Dropping the comments (we had programs to do that and to restore for listing purposes), using the same variables for more purposes (aargh, I hear you scream) etc. We got very inventive creating space. A few bytes here , a few bytes there and you could put in an extra statement. Later on we got an extra KB, so we had 15 KB: party time!
    During development (testing) we used indeed HE.READWRITE of HE. WRITEFILE to put the field in TF.PORT on 1000 if we tested it from TAMOS menu. Most of time you just give the command RUN in the basic program.

    BTW Just to compare: I wrote last just a simple “Hello World” program in C on a Linux-box to see what it takes. Compiled, it took 6KB on disk with debuginfo stripped off!

    1. joe.farr@gmail.com avatar
      joe.farr@gmail.com

      The message was triggered when a program with a certain run mode (specified in the associated TAMOS menu selector entry) terminated via TA.ABO instead of TA.END or TA.NCO. It was designed to indicate that a program had crashed during some type of update / batch job and that data integrity of the files had been lost. A failure or program crash whilst processing General Ledger transaction files would cause this. Sometimes the recovery could be cancelled (if you knew what damage had occurred and how to fix it).

      I can remember the maximum partition size being 16Kb for a while, and then the world opening up when it was increased to 32Kb. The good old days of real programming with limited system resources.
      I think 32Kb partitions were introduced with NIROS 5.0.

      I do remember in NIROS 3.3 if you were entering a line in BASIC with a syntax error, it used to beep at you and throw the line away so you had to start again. They fixed that in NIROS 4.1 and introduced the EDIT command.

Leave a Reply