Adam Dorritie wrote:
 
>The problem seems to have stemmed from the fact that the old V'ers
>don't like an SL bigger than 32k.  The program would copy the SL and
>set the FLIMIT to the EOF on the copy, so when it comes time to delete
>and add segments if you have a big SL (lots of HP products), you might
>not see the problem, if, like us, your SL is relatively puny...watch
>out!
 
Actually, the code seemed to be doing the equivalent of a COPYSL 100
_after_ having deleted the segments it was going to subsequently
replace.  This re-builds the file with an FLIMIT 100% bigger than the
EOF.  We started with an SL that looked like:
 
FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                  SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
SL      * SL      128W  FB       16xxx      65535   1    ....
 
but after the deletes and COPYSL, the temporary copy looked something
like:
 
FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                  SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
TEMPSL  * SL      128W  FB        8xxx      16xxx   1    ....
 
At this point, the update program started adding segments back to a
_much_ smalled SL.
 
>As far as restoring @[log in to unmask], my experience was that the COLDLOAD
>sufficed.
 
As a new copy (X.40.A1) of SPOOK5 was already loaded at that time, we
felt that the restore was called for.  BTW, the new SPOOK5 has some
incompatibilities with the older G.12.00 version.  Specifically, a
COPY #Onn followed by a PURGE #Onn now fails, as the COPY performs an
implicit TEXT, marking the spoofle as LOCKED.  The older versions
figured out that, even though the file was locked, it was locked by
the current SPOOK process and could be deleted.  Now, you get an error
stating that the file isn't in the READY state.  (RC has been called,
no SR yet.)  PURGE * still works, however.
 
--
------------
Randy Medd
Telamon, Inc.