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.