LinkRight

LATE BREAKING NEWS AND INFORMATION The last few weeks before release of LinkRight 1.1 was spent fixing major bugs and finding and documenting minor bugs. There are lots of minor bugs and we're sure that more will be found after release. With any luck, no major bugs will be discovered. Doing files transfer thru the parallel port can cause OS/2 to crash (Trap 0008), but there are workarounds. First the symptoms. You transfer a 5 meg, 10 meg, 50 meg and hundreds of files, but then OS/2 crashes. This is probably caused by a bug in COM.SYS. One workaround is to REM out the statement in your config.sys that installs COM.SYS and VCOM.SYS. Another workaround is to add the ignore spurious interupt switch to the com driver: DEVICE=C:\OS2\COM.SYS (1, 03F8, 4, I) (2, 02F8, 3, I) Or you can apply OS/2 fix XR0F037. It goes on top of OS/2 2.11. Contact IBM for this fix. Reference APAR PJ09132. If this bug still occurs, set LinkRight to the lowest packet size, transfer and verify, and turbo mode off. This may help. This problem occurs most when you connect a fast system to a relatively slower system. Although it makes no sense for the COM driver to cause crashes during parallel port transfers, that seems to be what is happening. If you get the crash, write down all the register info, and call IBM, they will tell you to apply fix XR0F037. The results for our testing indicate much higher reliability with this fix, slightly less reliability with no COM driver installed, and and less reliability with just spurious ints disabled. We'll keep looking at this problem for the best solution, since not everyone can get IBM fixes. A significant bug that is leftover from version 1.0 is that LinkRight CANNOT BE RUN FROM THE ROOT DIRECTORY. It must be run from a subdirectory. The reason for this is that LR builds some temp files and uses a basepath onto which it appends filenames. If the basepath is the root directory, LinkRight FAILS MISERABLY. Most people who have run LinkRight from the root did so to try to correct another percieved problem. If they tried to change to the parent directory (equivalent to doing "cd .." at an OS/2 command prompt) and failed, they figured they could navigate to where they wanted to go by starting LR in the root directory. This scheme won't work, don't try. If you want to change to the parent directory, double click on the line with ".." (double dots) on it. The Event Log can grow to be rather large. If you select to View a large (> 50K) Event Log, it may not display properly and may take a long time to display. We suggest using EPM.EXE or E.EXE to view a large log. We've had a report from a beta tester that after he deletes the Event Log or Error Log, in the same session he can not View the log. Although we can't duplicate this problem, we thought we should warn you about it. Caution should be taken when clearing logs. Make sure the Local machine is Idle (not transferring files) when clearing a log. Some machines with 16550 UARTs boot with the setting of "buffer=auto". LinkRight does not change this setting, but should. The proper setting is "buffer=on". To check this setting for COM1, type "mode COM1" at an OS/2 prompt. To change this setting, enter "mode COM1 buffer=on". Other COMs can be checked and changed in the same way. As a last resort if you're having problems, shutdown and reboot the OS/2 system. In one case during testing, a LinkRight session was killed and ended abnormally. We started LinkRight to run more tests, but could not establish a connection using par ports. But after rebooting the system, everything was fine. Evidently the LRPAR.SYS driver did not close properly on an abnormal exit. This only happened once, and no matter what we tried we could not duplicate this problem. Obviously, this suggestion won't help if you've never been able to sucessfully establish a connection, but if LinkRight has been working well and then all of a sudden quits working, you might try this. As a first resort if you're having problems on a DOS machine, reboot it. When attempting to clone a system, do not mix and match OS/2 2.1 and OS/2 2.11 executables ON THE SAME COMPUTER. In other words, if your modified bootable floppies were created from original 2.1 diskettes, make sure that EAUTIL.EXE and CMD.EXE on the target system are from OS/2 2.1. Also, make sure the path is set so that it will use EAUTIL and CMD in C:\TEMP, rather than any EAUTIL.EXE or CMD.EXE that has been transferred to the target system during cloning. Symptoms of this problem include an error msg saying "Wrong Operating System Version" or EAUTIL failed. In some ways, it is easier and less trouble prone to use 2.1 bootable floppies no matter what is on the Source system. In other ways, it is easiest to use bootable floppies of the version of OS/2 that is being cloned. Use your own judgement on this one. BOOT21.ZIP, which can be found on Compuserve and most good OS/2 BBSs, can be used to create a single bootable diskette. Good Luck and Happy Computing. Jeff Tremble President, Rightware