[Indigo]<Spruce>13>Changes.bravo!2

Each pressfile received by the spooler is saved as a subfile in the file Spruce.Spool (SpoolFile). Information about this subfile is contained in several structures - primarily DocG. Currently, a queue of DocG structs (SproullerQ) is saved in the Checkpoint file. Due to the small size of the checkpoint file, there is a limit on the number of entries in the SproullerQ. To eliminate this constraint, a new scheme must be adopted. The new scheme requires an additional T80 file, Spruce.Queue.

When a new subfile is created in the SpoolFile, a page in the QueueFile is allocated to hold information relevant to the new subfile (e.g. DocG, SPruceFile, map, and history info). When a SpoolFile subfile is forgotten, the page in the QueueFile is marked invalid, but is still available for historical queries. There is a detail in the ’forget’ operation which should be noted: When a new file is spooled into the SpoolFile freeFile, any number of files may be overwritten. Consequently, a number of QueueFile entries (pages) may need to be marked invalid. Consecutive pages in the QueueFile describe consecutive subfiles in the SpoolFile. Eventually, the QueueFile will wrap around, and the oldest entry (first page) will be overwritten.

Since each page in the active region of the QueueFile contains a complete description of a subfile, the in-core queue need not contain the DocG, map, and SPruceFile structures. Likewise, it is no longer necessary to save these structures in the checkpoint file. A much more compact representation of the queue can be used (requiring less space in core). A vector of unique IDs (described below) would suffice. Sorting the queue into print-priority order would require more information (waitTime, totalPages, etc) to be extracted from each DocG struct (referenced by the unique ID). Various parts of the user interface will need to be modified to access/update the entries now stored in the QueueFile. Queue inspection should start with the most recent entry (examining the entries in core) and continue to the oldest entry (examining the entries saved in the QueueFile).

The fileCode field of the SPruceFile struct is used to hold a subfile ID (currently between #1000 and #1777). Currently, the subfile-ID is only useful inside Spruce, and it isn’t very compatible with the proposed QueueFile modifications. An alternative scheme would be much more flexible: Assign some unique ID to each spooled file (same for net or local disk). Given the ID, information about the file (i.e. DocG fields), or pages of the file itself should be easily referenced. A sender should be able to refer to a spooled file with the unique ID (for status requests, reprint commands, etc...). Using the page numbers of the entries in the QueueFile for IDs would allow easy access to a subfile. (via info stored in the QueueFile). When the QueueFile wraps around (to page one), the Unique IDs assigned to the overwritten pages will become invalid. Unique IDs might be in the range: 0 -> QueueFile>>SPruceFile.numPages

Files spooled from the local disk are a problem. To construct the necessary SPruceFile structures, routines trashed after initializtion must be called. Saving and/or never discarding these routines would allow creation of new SPruceFiles anytime. If new SPruceFiles could be created after initialization, the user interface could be modified to allow printing an arbitrary file on the local disk. Space limitations make this seem difficult. Alternativly, the existing scheme could be modified to save SPruceFile descriptions in the QueueFile. At initialization time, entries for files ’*.press’ are extracted from SysDir. The map & SPruceFile structures for these files are created, and saved in the QueueFile until requested from the user interface. A vector of QueueFile page numbers (LocalDocsVec) allows quick access to the QueueFile pages which describe local disk files (scanning the QueueFile page by page could be slow). If a number of PressFiles exist on the local disk, constructing the many SPruceFile structures could become time consuming. To speed up restarts and initialization, ’old’ checkpointed SPruceFiles which still appear valid need not be recreated (compare old info in QueueFile to the PressFiles’ leader page on disk). To actually queue a file, sort the appropriate QueueFile page number into the in-core ’queue vector’ (SpoolVec).

Consider the operation of adding new fonts to the system. Is it really desirable to flush the Queue? probably not. What should be preserved and what should be reinitialized? What does not get reinitialized when the system is simply restarted? Having various flavors of ’restart’ might be good - ranging from complete reinitialization to simple restoration of state.

The existing ’installation’ procedure should probably be flushed in favor of a simpler scheme. Installation could be done automatically by checking for existance of both (Spruce & Sprint) version statics in the CheckPoint file. Storing the default installation parameters in User.CM would reclaim space wasted by menus, tables, existing installation code, etc. Spruce could create SPruceFile and map structures for User.CM, and save them in the CheckPoint file. For a ’cold-start’, installation parameters would be read from User.Cm; for a ’warm-start’ installation parameters could be restored from the CheckPoint file, and possibly modified by the (ideal) menu-driven user interface (saving a trip into Bravo to edit User.CM). Since the default installation values would no longer be stored within Spruce, it would be necessary to associate the static names, with the respective addresses. This could be accomplished by parsing the .Syms files (SPruceFile and map structures for the .Syms files could be CheckPointed). Code for parsing the .Syms files exists in StorageStats.Bcpl