Sequoia PRO version 2.5 has been available for a number of months. In general, this release does not impact PicLan or PicLan-IP users. There are some issues however.
Unfortunately, this transition above 128 Megabytes did reveal a problem. The Pick virtual assembler includes an opcode called LOCK.FRM. This opcode will lock a virtual frame so that it will not be paged to disk. The interface to this opcode provided for the buffer number of the lock to be returned in a 16-bit process variable called T2. It is this 16-bit return value that fails on systems with more than 128 Megabytes of memory. A 16-bit signed number has a range of 0 to 32767. 128 Megabytes, organized as 4K pages is 32768 pages. Thus the lock-frame function will return an incorrect value on systems with large amounts of memory.
From talking with GA, the only area of Sequoia PRO that appears to be impacted by this are tape handling routines. These can cause all sorts of wierd problems including GFEs, system crashes, etc. GA is working on a fix for this problem and is planning on putting it into QA in the next several days.
PicLan also uses the lock-frame function during it's initial install process where the PicLan driver is loaded. PicLan-IP likewise uses this functions whenever the PLIP-INIT verb allocates additional TCP/IP connection and buffer areas. This can cause PicLan and PicLan-IP to incorrectly lock system memory and lead to system stability and crashing problems.
As it works out, PicLan is probably mostly safe because of the manner in which PicLan loads. Normally, PicLan is loaded onto the system very early during the system coldstart proceedure. In that Pick uses memory buffers from the bottom up, it is unlikely that the system will have even referenced more than 128 Megabytes of memory by the time the PicLan driver loads. And as long as the PicLan driver loads into the first 128 Megabytes of memory, there is no problem. Problems could occur if you have arranged your coldstart routine to perform operations prior to the PicLan load that manipulate large amounts of data. Operations such as a dummy file-save or other database scan prior to the PicLan load could easily cause the PicLan driver to lock memory above the 128 Megabyte boundary and lead to system stability problems.
If you have a Sequoia PRO system with 128 Megabytes or more of memory, Modular Software recommends that you load the pl-seq25-patch.zip file. The reason for recommending this for 128 Meg systems is that a with 128 Megabytes of memory, a couple of memory buffers will actually get allocated about the 128 Meg boundary (this is because of the 384K "hole" in memory between 640K and 1 Meg). Other than using the lock-frame function and not relying on the return value in T2, these assembler modes have identical source code to the previously shipped PicLan support code. The object code for this patch assembler file is slightly different because GA has slightly changed some of the assembler macro expansions. These changes only effect code size and not performance or functionality.
It is acceptable to load the patch onto Sequoia PRO 2.4 systems, although there is no known reason why you would want to do this.
You can execute this command on a DOS, Win 3.1, Win 95, or Win 98 system (the W_DISKS.EXE program is not compatible with Win NT). This W_DISKS.EXE program is included in any PicLan or PicLan-IP release download, so it is likely that you already have a copy of it. If you do not, you can download it from here.W_DISKS WQ1 A,1440,PL-SEQ00.DSK
After you have created the diskettes, you load the patch into PicLan by logging on to the PIC-LAN account, accessing TCL, and typing:
Once the patch is loaded, you must load the new Pick assembler modes into USER.ABS. You can do this by executing option 7 of the PIC-LAN account menu or by typing:SET-FLOPPY (HA T-ATT T-REW T-LOAD PL.BP,VIR.OBJ (O
SSELECT PL.BP,VIR.OBJ MLOAD PL.BP,VIR.OBJ To:USER.ABS