Archive Anecdotes of a WARP Connect User

From OS2World.Com Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

By Bill Kredentser

I believe deeply in the WARP Desktop Archive feature. More than once it has saved my bacon. I have gotten in the habit of always booting from an archive immediately after taking it. This has uncovered a number of anomalous conditions. I believe if I tell you about my problems, your life may be easier.

First anecdote

I installed Watchcat on my system at work some time in the spring of 1995. That system was a WARP non-Connect (red spine). I never had any unusual archive-related experiences with it. In the summer of 1995 I acquired my first home computer. My software was (and continues to be) WARP Connect (blue). After installing Watchcat and using it across a couple of reboots, I took my first Desktop Archive with Watchcat installed and then tried to boot from that archive. My 3:00 A.M. weary eyes and mind were not prepared to deal with the hard trap I got just at the moment it appeared that "Restoring KEY files" was done. I simply powered the system off and went to bed.

Next day - well, later that day - I powered the system on and tried to boot from that archive again, just to see if the symptoms were reproducible. To my amazed joy, everything booted up fine. I shut down and rebooted from the archive and got the trap. Another reboot from the archive went fine. This was too goofy. Goofy always makes me think. What's different between when it works and when it fails? After encountering the trap, the next bootup sees that the previous execution of OS/2 was not shut down cleanly, so it automatically does a CHKDSK on my boot partition.

That got me to thinking even more. When do you most need to boot from an archive? When your Desktop is completely screwed up, and you need to drop back to one you know is operable. It's probably a smart thing to do to run CHKDSK on all your hard drive partitions in such a situation. Even though I came to this procedure from Watchcat, which is made obsolete by the recent Fix Pack 17, I think the procedure is useful independent of Watchcat. Here it is in recipe form. My hard drive is partitioned into a FAT C drive and HPFS D and E drives.

1. When it's time to archive your Desktop, modify your CONFIG.SYS as follows:

IFS=D:\OS2\HPFS.IFS  /AUTOCHECK:+D+E
DISKCACHE=,AC:+C

The + signs force OS/2 to perform CHKDSK on the indicated disk partitions, even if they don't need it.

2. Bring up the Desktop Settings notebook, turn to the Archive page, and activate "Create archive at each system restart." Then close the notebook.

3. Close all active applications and Shut Down.

4. Reboot. I recommend you display the Recovery Choices screen at every boot-up. I mean, there's not much point in having archives if you don't give yourself a chance to use them, is there? At this point in the procedure, press Esc to use your current CONFIG.SYS.

5. Wait patiently while your normal boot process is lengthened by the time it takes to run CHKDSK on all your partitions. On my 486DX50 with a 420Meg hard drive, it takes maybe a minute to do all 3 partitions.

6. After the Desktop comes up, inspect the OS2\BOOT\ALTF1MID.SCR file on your OS/2 boot partition. This file contains the archive messages displayed on the Recovery Choices screen. (For full details, refer to the Archive topic in the Master Help Index in the Information folder on your Desktop.) Pay particular attention to the date/time stamps in this file. It has been my experience on two different WARP Connect systems, one red, one blue, that another shutdown & reboot is necessary at this point to get the system to TAKE an archive.

7. Once you are sure your system has created a new Desktop Archive, open the Desktop Settings notebook again and deselect the choice you selected in step 2 above. Close the notebook.

8. Shut down again. When the Recovery Choices screen appears, press the 1 key. This causes the system to boot from your archive. The most recent archive is always number 1, the next older one is 2, and the oldest user-requested archive supported by OS/2 is 3. I hope you agree with me that it is no good discovering an archive is unusable when you are in a bind and need to use it. Better to verify it's good as soon as you take it. Since the CONFIG.SYS saved in step 5 above is the one with the + signs in it, booting from the archive also runs CHKDSK on all your hard drive partitions.

9. Once the system boots from the archive, change your CONFIG.SYS back, so it looks like this:

IFS=D:\OS2\HPFS.IFS  /AUTOCHECK:DE
DISKCACHE=,AC:C

10. Shutdown and reboot one last time. Press Esc this time when you reach the Recovery Choices menu.

I have been using Watchcat without any problems on two WARP Connect systems, one each at home and work, for months now without any further archive problems.

Second Anecdote

My blue system at home has MPTS and TCP/IP 3.0 installed, and I connect to my Internet provider over a modem. When I first installed my Internet support, I went through the laborious Archive Exercise I've just described and again hit a hard trap just as the KEY files were done being restored. (Months later, I had the same experience at work on my red system, so I believe I have not experienced some idiosyncratic weirdness unique only to me. But there were additional problems there; stay tuned for my third story.)

In this situation, I followed the failed boot from archive with several more and encountered the hard trap at the same spot each time. But just from knowing the rhythm of my system, it felt to me like all the KEY files had in fact been restored. So on a hunch, I booted from the Esc option on the Recovery Choices screen, and it did successfully boot up.

Many device drivers loaded by DEVICE statements in CONFIG.SYS generate messages on the monitor. The "Restoring KEY files" message appears after the last of these. From explanations in the online OS/2 documentation of the order of processing of CONFIG.SYS statements, this means that the next step executed after restoring the KEY files should be execution of RUN and CALL statements. The most recent preceding time I had successfully booted from an archive, I had not yet installed MPTS and TCP/IP. So I inspected my CONFIG.SYS for changes wrought by the installation of these new features. Sure enough, I found the following statement (among others) had been added:

CALL=D:\OS2\CMD.EXE /Q /C D:\MPTN\BIN\MPTSTART.CMD

Again, from knowing the rhythm of my system during a normal boot, it seemed that the trap occurred during the boot from archive just at the point where this CALL statement was about to be executed. It even seemed to me that the command may have just begun when the trap occurred. I thought perhaps I could avoid the problem by delaying the execution of this line. So I simply commented it out in CONFIG.SYS and added it to STARTUP.CMD. As soon as I did that, I was able to boot from the archive again.

Third Anecdote

Months after that experience with my blue system at home, I upgraded from WARP (red) to WARP Connect (red) at work. When I installed MPTS and TCP/IP 3.0 there, I moved that CALL statement out of CONFIG.SYS to STARTUP.CMD before I even used TCP/IP. But I unexpectedly got a trap during boot from archive just as the restore of the KEY files seemed complete. Why wasn't this just like at home?

At home, I use a modem to connect to the Internet. At work, I have a network card connecting my system to my employer's LAN and from there, over a leased line to our corporate Internet provider. In addition, I installed the OS/2 Peer support, something else I don't have at home. The following lines appeared in my CONFIG.SYS at work, some of which I had never seen at home. I have shown the new lines in all upper case. The lines in all lower case appear in both systems:

RUN=D:\OS2\EPW.EXE
call=d:\ibmcom\protocol\netbind.exe
run=d:\ibmcom\lanmsgex.exe
device=d:\mptn\protocol\sockets.sys
device=d:\mptn\protocol\afos2.sys
device=d:\mptn\protocol\afinet.sys
device=d:\mptn\protocol\ifndis.sys
device=d:\mptn\protocol\afnb.sys
run=d:\mptn\bin\afnbini.exe
run=d:\mptn\bin\cntrl.exe
call=d:\os2\cmd.exe /q /c d:\mptn\bin\mptstart.cmd
RUN=D:\IBMCOM\PROTOCOL\NBTCP.EXE
RUN=D:\IBMLAN\NETPROG\LSDAEMON.EXE
RUN=D:\IBMLAN\NETPROG\VNRMINIT.EXE
device=d:\ibmcom\protocol\netbeui.os2
DEVICE=D:\IBMCOM\PROTOCOL\TCPBEUI.OS2
DEVICE=D:\IBMLAN\NETPROG\RDRHELP.200
IFS=D:\IBMLAN\NETPROG\NETWKSTA.200 /I:D:\IBMLAN /N
device=d:\ibmcom\protocol\netbios.os2
DEVICE=D:\IBMLAN\NETPROG\VNETAPI.OS2
device=d:\tcpip\bin\vdostcp.vdd
device=d:\tcpip\bin\vdostcp.sys
run=d:\tcpip\bin\vdosctl.exe

Based on my experience at home, I believed that some part of this new section of my CONFIG.SYS, added by installing some of the networking features, was executing too early, before the restore of all the KEY files was complete. Some of it had to move from CONFIG.SYS to STARTUP.CMD. DEVICE and IFS statements can appear only in CONFIG.SYS so I was not considering them. Only RUN and CALL statements were under suspision. VDOSCTL.EXE is something for the benefit of DOS and WIN-OS/2 sessions so I didn't worry about that one, especially since I left it in my CONFIG.SYS at home.

The problem is that RUN is also a statement that can appear only in CONFIG.SYS. Moreover, it is not entirely clear from the Online Command Reference in what order RUN and CALL statements are processed. Are all CALLs done before all RUNs? RUNs before CALLs? Interleaved? I started experimenting by reinstating the CALL MPTSTART statement in CONFIG.SYS and moving it around. I started by inserting it immediately after the RUN EPW statement. This generated errors. I moved it after each RUN and CALL statement in the above CONFIG.SYS fragment and it got errors at every location above the point at which the installation procedure had automatically generated it. In additon, when I moved it from CONFIG.SYS to STARTUP.CMD, there were error messages from the 3 RUN statements after MPTSTART in CONFIG.SYS, and the NET START REQ statement in STARTUP.CMD also generated errors. So it seems that RUN and CALL statements are executed in order, interleaved. And the programs executed by these statements can condition the environment for the subsequent programs.

I concluded that the installation program had generated these statements in the order in which they must be executed. But leaving them all in CONFIG.SYS left me with an archive that wouldn't boot. CALL statements are acceptable in STARTUP.CMD but RUN statements are not. So I tried executing, for example, simply EPW.EXE on a line by itself in STARTUP.CMD. That had some very weird side-effects. Try it some time. I found it quite educational. So I tried using the START command. That simply moved the weird side-effects from one place to another. I ended up with the following in my STARTUP.CMD file:

DETACH D:\OS2\EPW.EXE
CALL=D:\IBMCOM\PROTOCOL\NETBIND.EXE
DETACH D:\IBMCOM\LANMSGEX.EXE
DETACH D:\MPTN\BIN\AFNBINI.EXE
DETACH D:\MPTN\BIN\CNTRL.EXE
CALL=D:\OS2\CMD.EXE /Q /C D:\MPTN\BIN\MPTSTART.CMD
DETACH D:\IBMCOM\PROTOCOL\NBTCP.EXE
DETACH D:\IBMLAN\NETPROG\LSDAEMON.EXE
DETACH D:\IBMLAN\NETPROG\VNRMINIT.EXE
NET START REQ

This works. No more archive anomalies.

Fourth Anecdote

(Added 4/24/96)

After I posted that collection of Archive Anecdotes, some more things caught my eye. I paid special attention to the date/time stamps of the items in the \OS2\ARCHIVES\CURRENT directory. That directory is not written when you shut down, neither with nor without the Take an Archive setting turned on. It is also not written when you boot up from the Esc choice on the Recovery Choices menu. However, it is written when you boot from an Archive. By careful observation & experimentation, I have concluded that it contains the environment in effect before the chosen Archive is restored. The order of events seems to be this:

1. Boot using the CONFIG.^ where ^ is 1, 2, or 3 depending on the Archive you've chosen to boot from. This file is in \OS2\BOOT on the boot drive.

2. Copy the KEY files to the \OS2\ARCHIVES\CURRENT directory and subdirectories. This is CONFIG.SYS, STARTUP.CMD, & AUTOEXEC.BAT from the root directory on the boot drive; OS2.INI & OS2SYS.INI from the OS2 directory on the boot drive; and the entire directory named DESKTOP from the boot drive.

3. Restore the aforementioned KEY files from the identified \OS2\ARCHIVES directory. Note that even though you've booted from a particular CONFIG.SYS, it appears that it is not copied from the Archive to the root directory until this later time. And it is copied from the Archive, even though the boot appears to be done from the file in \OS2\BOOT.

I was recently presented with a popup, after a boot from an Archive had restored KEY files & my STARTUP.CMD had completed, telling me my Desktop had not been found in OS2.INI. I thought I was simply caught between a rock & a hard place, so I just rebooted and selected the next older Archive. I follow my own advice so all I lost was the Desktop object for the one application I was installing. But if I ever see that frightening vision again, I'm going to try doing a manual reconstruction of my Desktop from the CURRENT directory. Even if it doesn't work, it will be educational. And I'll always be able to drop back to that older Archive.

I am not entirely certain of this next claim, but I believe CURRENT is also written when you experience a Desktop Recovery. Next time I have one of those, which I hope is no time soon, I'll try to verify this & I'll put up a revision to this note.

Fifth Anecdote

(Added 4/25/96)

The Recovery Choices screen gives you choices numbered 1, 2, & 3 for Desktop Archives you save. On the Archives page of the Desktop Settings Notebook, you can set the name of the directory in which OS/2 keeps your Desktop Archives. Assuming you left the original default setting alone, look on your boot drive in the directory OS2\ARCHIVES. You'll notice directories named OS2\ARCHIVES\01, OS2\ARCHIVES\02, & OS2\ARCHIVES\03. It's obvious to any idiot that of course when you select Archive 1 on the recovery choices screen, that OS/2 finds that archive in OS2\ARCHIVES\01, Archive 2 is in OS2\ARCHIVES\02, and Archive 3 is in OS2\ARCHIVES\03. It stands to reason. It's a no-brainer. It's obvious that's how it works.

Wrong.

At my age, I really should have learned what a mistake it is to apply logic to most situations. By careful inspection of date/time stamps, you can discover that Archive 1 is in OS2\ARCHIVES\03. Sure. Anybody would expect that. Archive 3 is in OS2\ARCHIVES\01. I'm sure the residence of Archive 2 in OS2\ARCHIVES\02 was an oversight. They originally intended to support 4 user Archives, but somebody's finger slipped & the mistake wasn't noticed until it was too late for a correction.

WW

Team OS/2 & PROUD OF IT!