
CONVERGENT TECHNOLOGIES

RELEASE NOTICE FOR
1.0 CTOSII Operating System (SAA2000)

Revised July 7, 1986


SECTION   TITLE	PAGE
	1.0	Description of Programs	 3
	2.0	Changes from Prior Version	 6
		2.1  Changes from CTOS 9.73.2	 6
		2.2  SPRs Closed in This Release	 12
	3.0	Contents of Distribution Diskettes	 14
	4.0	Installation Procedures	 16
		4.1  Installing Custom Configurations 
		     of CTOSII locally	16
		4.2  Installing Custom Configurations 
		     of CTOSII on Workstation Masters	17
		4.3  Installing Custom Configurations 
		     of CTOSII on SRP Masters	18
		4.4  Installing the CTOSII Build Environ
		     ment	19
	5.0	Building an Operating System	19
	6.0	Required Files	22
		6.1  Workstation bootable disks	22
		6.2  SRP bootable disks	22
		6.3  SRP bootable tapes	23
	7.0	System Software Compatibility	24
		7.1  General	24
		7.2  Workstation Environment	25
		7.3  SRP Environment	26
	8.0	Hardware Information	29
		8.1  Hardware Configurations Supported	29
		8.2  Bitmap video compatibility	31
		8.3  Software Applications  Supported	32
	9.0	Resource RequirementsUtilization	33
		9.1  Memory RequirementsUtilization	33
		9.2  Disk RequirementsUtilization	34
{	10.0	Restrictions	35
		10.1  Cluster Configurations	35}
	11.0	Documentation	36
		11.1  Guide to current documentation	36
		11.2  Documentation updates	37
		11.3  Documentation eratta	38
	12.0	Error Codes	38
	13.0	Known Errors and Omissions	38
	14.0	Miscellaneous	40

NOTE
This Release Notice is for the CTOSII Operating System ONLY.
Previous Release Notices for the CTOS Operating System have included information about Standard Software.  Standard Software II information is contained in a separate Release Notice for Standard Software II.
Read the Standard Software II Release Notice before reading this one.


1.0	DESCRIPTION OF PROGRAMS
This Release Notice describes the CTOSII Operating System, version 1.0.  This section and the sections that follow provide a description of the product, contents of the Distribution Diskettes, installation procedures, and other information pertinent to this release of the CTOSII Operating System.
This CTOSII release includes prebuilt operating systems for the NGEN CP001, CP002, and CWS based workstations and for the Megaframe Shared Resource Processor (SRP).  You are also given the files necessary to construct a custom version of CTOSII.  In addition, the customizable Native Language Support (NLS) table file Nls.asm is included.
The table below indicates the most current version of CTOS or of CTOSII that supports each workstation type.
CTOS 9.1	IWS
CTOS 9.11	AWS
CTOSII 1.0	CWS, NGEN T1, NGEN T2, 	SRP
{CTOSII 1.0 includes support for NGEN modules CP002 and CP002287 in real  mode with a maximum of 1 megabyte of memory.  System services can run in protected mode with their code residing in the upper 3 megabytes of memory, if the Protected Mode Operating System Server (PMOS) is installed.}
Naming Conventions for CTOSII Configurations
The following naming conventions are used for naming CTOSII configurations:
Family Type
n	NGEN CP001, CWS and NGEN CP002 and CP002287 (real mode) workstation
srp	Shared Resource Processor
Hardware Type
Clstr	Cluster workstation
ClstrLfs	Cluster workstation with local file system
Cp	Cluster Processor
Sp	Storage Processor
Dp	Data Processor (combination of Storage Processor (SP) and storage controller (SC) boards).
Fp	File Processor
Mstr	Master workstation
Stnd	Standalone workstation
Tp	Terminal Processor
Xp	CpTp (for bootable tape OS's)
{OS Type (SRP only)
Deb	SRP OS that contains the debugger.  (Workstation CTOS contains the debugger by default).
Qic	Bootable Qic
Tape	Bootable halfinch tape}
Names of run files, link files, and SysGen configuration files are a concatenation of the above mnemonics in the order:
FamilyType  HardwareType [OS Type]
For example, nClstrLfs, stands for NGEN Cluster Local File System and SrpCp stands for Cluster Processor of an SRP (without debugger).
Executable file names have a suffix of .run, link files  have a suffix of .link, and SysGen prefix files have a suffix of .asm.  Note that when CTOS run files are actually used they are copied to the [Sys]<Sys> directory under the names specified in section 4.0 of this document and given the .sys suffix.
2.0	CHANGES FROM PRIOR VERSIONS
2.1	Changes from CTOS 9.7  SRP CTOS 3.2 
A.	This release includes operating systems derived from a common source base which run on the both the SRP and NGEN workstations. 
B.	File system requests to SRP masters are no longer single threaded through the master FP or DP.  They are instead immediately routed to the appropriate FP or DP.  As a result, delays (particularly due to disk allocation) in multiple FP or DP systems are reduced.
C.	The mechanism for using loadable requests is simplified so that all loadable requests are in one file, [Sys]<Sys>Request.sys, usable both by SRPs and workstations.  Two new utilities plus a submit file, invoked via three new commands, List Request Set, Make Request Set, and Install New Requests, are provided for creation and manipulation of loadable request files.  See the CTOS II Systems Administrator's Guide for further information on request files.
D.	The Video Access Method (VAM) has been removed from the operating system.  (This is not applicable to SRP OS's).  VAM is now loaded at boot time from a separate file.   There are now two versions of VAM, one for character mapped workstations and one which supports bit map based workstations.  A workstation with  the GC003 graphics module attached requires the bit mapped version of VAM.  All other workstations require the character mapped version.  CTOSII automatically selects the proper VAM file to be loaded based on the hardware configuration.  A number of new VAM calls which improve both functionality and performance have been added.  In particular, there are new procedures, especially useful in window or menu oriented environments, which make it possible to move blocks of text or video attributes to and from, or about, the screen rapidly, without directly manipulating the contents of the character or bit map.
E.	The 10.0 CommNub has been put into the CP and TP SRP OS's.  This requires less space and provides improved performance over the compatibility modules from Ctos.lib which were formerly required to be included with SRP communications applications.
F.	8251 chip support has been added to Communications Bytestreams in order to allow accessing port C of the CP board and ports E through J of the TP in the same manner as other  RS232 communications ports.
G.	The SRP's Programmable Interrupt Timer (PIT) now has the same resolution as the NGen PIT  50 microseconds.  Note that this introduces an incompatibiltiy with certain previously released software.  See section 7.3.
H.	All 1.0 Standard Software II run files (with minor exceptions) execute on workstations and SRP processor boards.  SRP versions of CTOSII now support the version 6 run file format introduced in Standard Software 10.0.  There is also only a single version of Ctos.lib which supports both workstations and SRPs.  See the 1.0 Standard Software Release Notice for further information.
I.	Support for the Virtual Code Segment Management Facility  has been added to SRP versions of CTOSII, allowing overlayed run files to execute on every board of the SRP.
J.	Only one temporary directory, <$000>, is needed.  Files accessed in the <$> directory have five digits of user number followed by a > character automatically inserted by CTOSII before the user specified name.  Thus, access to the file <$>foo by user number 5 would be translated into access to the file <$000>00005>foo.  See the Release Notice for 1.0 Standard Software II for further information.
K.	National Language Support (NLS) tables are (optionally) loaded from the file [Sys]<Sys>NLS.sys at boot time.  These  include keyboard translation tables, collating sequence information, date and time name tables, and keycap name tables.  See the CTOSII Reference Manual for information on routines to access the information in the NLS tables.  For information on modification of the NLS tables, see the documentation contained in NLS.asm, distributed with the CTOSII Build diskettes.  Note that the nationalization information in the tables in NLS.sys is in addition to that found in the message files read by many standard software utilities.  See the CTOS II Systems Administrator's Guide for further information on message files.
L.	Support is added for SRP boards which have 768k resident memory.  These boards neither require nor allow further memory expansion via memory expansion boards (ME's).
M.	Support is added for the hardware Math Server, a component of Standard SoftwareII 1.0 which allows multiple simultaneous use of the 80287 math coprocessor on the CP002287.  If MathServer.run is present in [Sys]<Sys>, it is automatically executed upon boot.  The Math Server is required if it is desired to have multiple system services andor applications use real number operations in the C, PLM, Pascal, Basic, or Fortran languages.
N.	Virtual partition memory management (VP) is supported on workstation versions of CTOSII only. The Virtual partition facility is an extension of the Multipartiton facility (MP) of CTOSI and is designed to simplify partition management,  provide compatibility with Distrix and provide compatibility with a (future) protected mode implementation of CTOSII.  The main visible feature of VP is that partitions no longer need be configured statically as was done before in CmConfig.sys.  The notion of partitionuser number is confined to resource allocation (e.g. file handles, short and long lived memory) and is unrelated to a particular size or place in memory.   Each time a program is loaded the size and location of the partition is newly chosen in order to optimize system memory usage.
{Following is a summary of the differences between VP and MP:
	MP		VP

1. Fixed partitions		Partitions vary in size 
		and 	memory location 
		when a Chain occurs

2. Partitions can only	 	Partitions can be 
   be created by the		created at any time, 
   program in the		without forced exiting
   primary partition 
   which is then forced
   to exit

3. Swapping done by CM		Swapping built into CTOS

4. Swapping only upon		Swapping upon demand and 
   demand		optionally by timer

5. Debugger doesn't		Swapping transparent to
   work in the presence		Debugger
   of swapping

6. Programs must be		Small model movable
   swapped in the same		programs supported but
   place as originally			normally only used by
   loaded		Distrix

7. Code segments swapped		Code only has to be 
   in and out even though			swapped out once 
   they never change		

8. Code is never shared		Code is automatically
		shared if in variable
		partition, version 6 
		run file, with separate 
		code  data, and no data 
			selectors embedded in
		code

9. Distrix Fork 		Distrix Fork operation
   operation unsupported		supported}
{O. 	The Cluster service has been rewritten for increased efficiency and improved statistics keeping.  Polling and response to polling occur at interrupt level, minimizing the overhead due to process switching, especially at the master workstation.  Cluster errors seen by workstations and formerly unreported, are now reported by the enhanced version of the Cluster Status program.  Termination requests are sent as a single transaction to the master workstation, instead of many separate transactions.  Cluster workstations may exchange IFrames (data packets) with the master rather than waiting for another poll.}
P.	There is an indirect cluster boot feature.  It is no longer necessary to have multiple identical copies of the operating system in files such as ws240>Sysimage.sys and ws250>Sysimage.sys.  If, at cluster workstation boot time, the master workstation finds that the contents of the boot image file is a text string instead of a valid run file, the text is interpreted as the file name of the correct boot image to use.  For example, if the [Sys]<Sys>ws240>Sysimage.sys contained not a run file but instead, the text  string [Sys]<Sys>ws250>Sysimage.sys followed by a carriage return, the contents of the later file would be used whenever a workstation of type 240 attempted to boot.  It is necessary that a complete file specification including volume and directory be specified as the text string.  The file containing the text string will not work correctly with the BootStrap command.
Q.	The CTOS configuration options file [Sys]<Sys>Config.sys has been expanded to include many new options, including the specification of a memory resident debugger and  swap file names and sizes.  The possible options (and their default values) are:
:ClusterLineSpeed:1.8Mbps
:ResidentDebugger:No
:SwapFile:[Sys]<Sys>CrashDump.sys
:SwapFileSize:3000
:VDMFile:[Sys]<Sys>InstallVdm.run
:LfsToMaster:No
:WakeUpInterval:0
:Fork:No
:OldMaster:No
:XBusModuleID:
:XBusWindowSize:
In addition, you can specify multiple Config.sys files, each for the use of a different workstation type by prefixing WSnnn> to the file name, in the same manner as SysInit.jcl files and CTOS boot image files.  See the CTOS II Systems Administrator's Guide for more information.
{R.	A new optional feature of the file system causes read mode Open's to [Sys]<Sys> which fail at a cluster workstation with local storage to be retried at the master workstation.  Thus, files, especially .run files, may be redistributed between cluster workstations and the master workstation without need to change programs or configuration files.  The presence of this feature is controlled by the Config.sys option :LfsToMaster:yes.}
S.	An alternate request procedural interface is available which allows the issuance of requests with other than the default user number through the procedural interface, eliminating the requirement to manually construct request blocks in this case.  This feature is invoked by prefixing the name of an operation with Alt and supplying the desired user number as the first parameter to the procedure.  For example, to issue a CloseFile request with user number 5 and file handle fh, the calling sequence would be AltCloseFile(5, fh).
T.	The file system supports a new mode, modePeek, which allows read access to a file without preventing subsequent modification by a different user.  A file opened with modePeek is treated identically to a file opened with modeRead until a subsequent open occurs with modeModify.  Then, existing modePeek handles to the file are put into a state where subsequent operations return erc 235, and the modeModify open is allowed to succeed.  This feature is useful with a file such as the Executive message file which it is  desirable to update but which is constantly open.  A program opening a file using modePeek must be prepared to deal with an erc 235 return from any Read operation by attempting to reopen the file.
2.2	SPR's Closed in This Release
A1281		Debugger could not be removed from workstation versions of CTOS.
A1343		When multiple requests are queued to the Cluster Agent (in large XBlocks) the requests can overwrite active XBlocks.  
A1422		The Net Agent does not set the proper routing bits in the handle returned by a nonfilesystem request which specifies a routing of OpenFh.
A1786		When you action finish a swapped out context, the CTOS looses track of messages on the swapping exchange.
A1961		VacateRemove of a system service crashes the workstation.
A3378		The default node name is not cleared by logging out and signing on again.
A3485		System hangs at boot time when installing multiple servers from a JCL file.  Problem due to a deadlock involving the termination process and the file system.  (Also A3466, A3403. A3336, A3239)
A0559		Too many video attributes error (erc 505, an AWS only error) is incorrectly reported on NGEN workstations.
01786		The Ctos request ExpandAreaSL is not implemented on the SRP.  
10016		When a file specification has the node {local} on it, the request is routed to the Net Agent (or cluster agent, if Net not installed) rather than file system. The reason is that the kernel's check for node {local} fails when checking the length of the node spec on the file (or UCB, when applicable).  
{10017		When a user is booted from a local disk, and sets his path to node {master} all subsequent requests routed by file spec will be routed to the master, even if the file spec in the request begins with a volume spec.  The worst result of this is that the master becomes the effective sys volume because even exit run file specs.}
10025		Excessive temporary (<$>) directories are required.
3.0	CONTENTS OF DISTRIBUTION DISKETTES
The CTOSII Operating System Distribution Diskette set is your master copy and has been shipped writeprotected.  It should not be writeenabled, nor should it be used as a working copy.
The contents of the CTOSII Build diskettes are described below.  The CTOSII Build diskettes are required only if you are building a custom configuration of CTOSII.
The Build diskettes consist of a 3diskette set containing files required to build version 1.0 CTOSII.
{1.0 CTOSII Build Diskettes
Disk 1 of 3, <Sys> directory
   HdInstall.sub
   LinkCtos.sub
   LinkCtosCmd.sub}
Disk 2 of 3, <Gen> directory
   Clstr.lib
   Dbg.lib
   Init.lib
   nls.asm
   nls.mdf
   RqLabl.obj
   RqLablAlt.obj
   SourceDbgNub.lib
Disk 3 of 3, <Gen> directory
   OS.lib
Disk 3 of 3, <ReleaseNote> directory
   ReleaseNotice
{Disk 1 of 3, <Gen> directory
   kbd.asm	Kbd.mdf
   Kbd.obj	nClstr.asm
   nClstr.link	nClstr.obj	
   nClstrLfs.asm	nClstrLfs.link
   nClstrLfs.obj	nMstr.asm
   nMstr.link	nMstr.obj
   nStnd.asm	nStnd.link
   nStnd.obj	Request.asm
   Request.mdf	Request.obj
   Request_MF.asm	Request_MF.mdf
   Request_MF.obj	SrpCp.asm
   SrpCp.link	SrpCp.obj
   SrpCpDeb.asm	SrpCpDeb.link
   SrpCpDeb.obj	SrpDp.asm
   SrpDp.link	SrpDp.obj
   SrpDpDeb.asm	SrpDpDeb.link
   SrpDpDeb.obj	SrpDpTape.link
   SrpFp.asm	SrpFp.link
   SrpFp.obj	SrpFpDeb.asm
   SrpFpDeb.link	SrpFpDeb.obj
   SrpFpQic.link	SrpSp.asm
   SrpSp.link	SrpSp.obj
   SrpSpDeb.asm	SrpSpDeb.link
   SrpSpDeb.obj	SrpTp.asm
   SrpTp.link	SrpTp.obj
   SrpTpDeb.asm	SrpTpDeb.link
   SrpTpDeb.obj	SrpXp.asm
   srpXp.link	SrpXp.obj
   sysgen.asm	sysgen.mdf}
4.0	INSTALLATION PROCEDURES
Install Standard Software II Utilities before installing a new CTOSII configuration.  See the Release Notice for 1.0 Standard Software II for details.
Also install the Standard Software II Development Utilities if you plan to build a custom CTOSII configuration.
Standard Software II installation installs a cluster local file system configuration of CTOS.  Hence, you need install CTOS only if you require a different configuration or version.  See the Release Notice for 1.0 Standard Software II for information on the use of the the prebuilt OS kits.
Use the installation procedure described below to install custom configurations of CTOSII not provided with the prebuilt OS kits or for installation of the files required to build a custom configuration of CTOSII.
Characters that you must type are shown in boldface.  Keys you must press, such as RETURN and GO, are shown in UPPER CASE.
4.1	Installing Custom Configurations of CTOS II locally
A.	Check to see that the currently executing CTOS configuration is memory resident.  Look at the CTOS configuration name displayed in the Executive status frame at the top of the screen.  If the name has the Swp suffix, CTOS is NOT memory resident.
	If the OS is not memory resident, insert the Standard Software II Initialization diskette in floppy drive [f0] and type
	Command  Bootstrap  RETURN
Bootstrap
  File name  [f0]<Sys>SysImage.sys  GO
B.	Copy your custom configuration of CTOSII to [Sys]<Sys>SysImage.sys.
	If the copy fails with error 219 (access denied), first check the following.
1.	Have you supplied the correct password?
2.	Did you use a wildcard (* or ?) in the file name?  Wildcards are not permitted.
3.	Is the size of SysImage.sys less than the size of your CTOSII configuration?  Use the Files command of the Executive (answering yes to [Details?] to check.  If so, you must reinitialize your hard disk and specify a larger size for SysImage.sys.
4.2	Installing Custom Configurations of CTOSII on the Workstation Master
Use this procedure when you plan to bootstrap from the master.
A.	At the master, copy your custom configuration of CTOSII to
	    [Sys]<Sys>wsNNN>SysImage.sys
	where NNN is the workstation type, from 000 to 255.
	To enable cluster workstation BOOTROMs to bootstrap the correct default CTOS configuration, select NNN based on the following table.  Note that the 240242 series of system image files normally contain the same contents as the 250252 files and thus the new indirect boot feature may be used to conserve disk space.  See item P in section 2.0.
NNN	Hardware Configuration
000015	IWS (CTOS I only)
240	NGEN t2 with a hard disk
241	NGEN t2 with floppy drives only
242	NGEN t2 with no local file system
250	NGEN t1 with a hard disk
251	NGEN t1 with floppy drives only
252	NGEN t1 with no local file system
252	CWS
253	AWS with a hard disk (CTOS I only)
254	AWS with floppy only (CTOS I only)
255	AWS with no local disks (CTOS I only)
4.3	Installing Custom Configurations of CTOSII on SRP Masters
The SRP contains multiple boards, each board executing a copy of CTOSII appropriate to its hardware type.  Thus updating an SRP configuration with customized versions of CTOSII may involve updating several files, each containing the version of CTOSII for a specific board.  Note that all boards must run either CTOSI or CTOSII.  Mixing the two versions is not allowed.  Use the following procedure to update your SRP:
A.	Determine the name or names of the files to which the custom configurations of CTOS II will be copied.  For the master FP or DP in the first cabinet this file name is always [Sys]<Sys>Sysimage.sys.  The names of the operating system files loaded into all other boards are contained in the [Sys]<Sys>Master.cnf file (or varients, see below).  These operating system names can be found in text lines of the form:
	Xp	[Sys]<Sys>SrpXp.sys
	where XP is the board type (one of Fp, Dp, Sp, Cp, or Tp).  Note that files with names ending in .run are created in the <Gen> directory by the Link Ctos command but the standard names for bootable SRP versions of CTOS II end in .sys.  Thus <Gen>SrpCp.run is usually copied to [Sys]<Sys>SrpCp.sys.
	It is possible to have multiple Master.cnf files, each corresponding to a different position of the front panel key switch.  Master.cnf.r corresponds to the REMOTE key switch position, Master.cnf.n corresponds to the NORMAL position and Master.cnf.m corresponds to the MANUAL position.  These additional Master.cnf files may all specify different file names.
B.	Copy the custom configurations of CTOSII to the corresponding names determined in step A. 
C.	Note the current SRP keyswitch setting.  Turn the keyswtich to STOP and then back to the original setting.  This reboots the SRP. 
4.4	Installing the CTOSII Build Environment on Hard Disk Systems
A.	Sign on to your workstation.  Fill in the SignOn form with the a valid user name and password (if required).  Press GO.
B.	Insert diskette 1 of 3 of the CTOS Build Diskettes.  Type
	Command  Install  GO
	The submit file prompts you for a volume name and password and creates a <Gen> directory on your disk.
	The submit file then copies files to the <Gen> directory.
	Insert diskettes 2 and 3 when prompted and press GO to continue.
5.0	BUILDING AN OPERATING SYSTEM
This section describes how to build a version of CTOSII from the files supplied on the CTOSII Build distribution diskettes.
All the files needed to do a system generation (SysGen) are contained in the <Gen> directories of the CTOSII Build diskette set.  The installation procedure creates the <Gen> directory  on your hard disk.  The <Gen> directory contains the libraries and files needed to build any configuration of the operating system.

NOTE
The procedures for building SRP versions of CTOS have changed substantially from prior releases.  SRP and workstation versions of CTOS are now built using the same procedures and the same libraries.


{Building a CTOSII Configuration
You may edit the SysGen prefix files to change system generation parameters or edit the link files to add or remove functionality.  If you do not want to change parameters, proceed directly to the step of linking CTOSII using the Link Ctos command (see below).}
Each configuration of CTOSII has an assembly language prefix file that contains system build parameters such as type of workstation, number of partitions, and so on.  The files are named xxx.Asm, where xxx is the CTOSII configuration name, such as nStnd.asm and SrpFPDeb.asm.
You may modify the build parameters contained in the prefix files or in the file SysGen.Asm, which is included by the prefix files.  Comments in SysGen.Asm describe the changes that may be made to the prefix files.  Notice that the SysGen prefix files use the $Include statement to incorporate the contents of the files SysGen.mdf and SysGen.asm.
Sysgen.asm and Sysgen.mdf are used for building both workstation and SRP operating systems.  Request.asm and Request.mdf are used for building workstation operating systems, whereas Request_MF.asm and Request_MF.mdf are used for building the SRP operating systems.  Note that it is not necessary to link custom versions of CTOSII to add new requests.  It is preferable to use the loadable request mechanism.
Assemble a prefix file using the Assemble command.
	Command  Assemble  RETURN
	Assemble
	  File name       nClstr.asm   RETURN
	  [Errors only?]  yes            GO
Link CTOSII using the Link Ctos command.
	Command  Link Ctos  RETURN
	  OS type  nClstr   RETURN
	  Version  II1.0   GO
{Removing Optional Services
You may remove optional services from CTOSII by editing the .Link file for the operating system version and replacing the modules that implement the service with dummy modules.  These files are named vvv.Link, where vvv is the CTOSII configuration name, such as nClstrLfs.link and SrpTP.link.}
Optional services are the Debugger and the Programmable Interval Timer (PIT).
After editing, link the operating system as described above.
Removing the Debugger
To remove the Debugger, replace the Debugger resident modules:

    DBG.LIB( ... ) and
	SourceDbgNub.lib( ... )
with
    DBG.LIB(dbgNul)
Remove the Debugger initialization modules:

    DBG.LIB(t1DLow  ... ) and
	SourceDbgNub.lib(SourceDbgOnc)

Note that the non Deb SRP OS's have these steps done already.
Removing the PIT
To remove the Programmable Interval Timer (PIT), replace the timer module
    OS.LIB(lowmem ... timer ...)
with 
    OS.LIB(lowmem ... timdum ...)

Do not remove the PIT from SrpCp or any OS that will host the QuarterInch tape server.
{6.0	REQUIRED FILES
6.1	Workstation bootable disks
The following files are required to be present in the <Sys> directory of a floppy or hard disk in order that the disk be bootable on an NGEN workstation:
Sysimage.sys    (any NGEN version of CTOSII)
Sys.cmds
t1Sys.font                 *
Exec.run
ExecMsg.bin
Signon.run
.user
InstallVdm.run
Vdm_CH.run                 *
Vdm_BM.run                 ***
1024x768_80sys.font        ***
720x348_80sys.font         ***}
THE ***'ed files may be omitted if the disk will never be booted on a GC003 based system.  The *'ed files may be omitted if the disk will never be booted except on a GC003 based system.  All of the above files are obtained by installing Standard Software II 1.0.
{6.2	SRP bootable disks
The following files are required to be present in the <Sys> directory of a Syquest removable cartrige, FP attached nonremovable disk or DP attached SMD disk for the disk to be bootable on an SRP:
Sysimage.sys (SrpFp.run if Syquest or FP or SrpDp.run if DP (SPSC pair))}
Master.cnf    (Customized to configuaration)
SRPCp.sys     (If any CPs)
SRPDp.sys     (If additional DPs)
SRPFp.sys     (If additional FPs)
SRPSp.sys     (If any SPs)
SRPTp.sys     (If any TPs)
CLI.run
CP00.cnf      (If any CPs)   *
DP00.cnf      (If any DPs)   *
FP00.cnf      (IF any FPs)   *
Additional *'ed files with names of the form XPnn.cnf where XP is the board type and nn = 00, 01, 02 are required if there are multiple boards of the same types.  In addition, the directory <$000> must exist.  If Mcommands are to be executed from workstations, the [Sys]<Sys>MfAdminAgent.run file must be present and installed and the files [Sys]<Sys>WsAdminAgent.run and [Sys]<Cmd>WsAdminAgent.txt must be present.  See the CTOS II Systems Administrator's Guide for more information.  
6.3	SRP boottable tapes
The following files are required in sequence, separated by tape marks in order for the tape (QIC or 12 inch) to be bootable on an SRP:
SrpFpQic.run (Qic tape) or SrpDpTape.sys (12inch tape)
Table of contents file as constructed by MakeBootTape
SrpXp.run
Menu.run
A bootable QIC tape is included with Standard Software II 1.0.  Bootable 12 tapes are not distributed and must be constructed using the MakeBootTape program.
The SrpFpQic.run, SrpDpTape.run and SrpXp.run files are produced using the procedures in section 5.0 of this document (Building an Operating System). Note that for a bootable tape to be useful, more than the minimum files specified above need to be included.  In particular, a program such as TapeRestorei.run along with a file containing a backup constructed by TapeBackup.run or TapeSelectiveBackup.run is usually included subsequent to the Menu.run program.  The i or interactive versions of TapeBackup, TapeRestore and MIvolume (as indicated by an i appended to the file name) must be used on bootable SRP tapes.  The Menu.run program and interactive versions of the standard utilities may be found on the QIC and Syquest media distributed with Standard Software II 1.0.  See the CTOS II Systems Administrator's Guide for more information.  
7.0	SYSTEM SOFTWARE COMPATIBILITY
7.1	General
A.	All operating system calls supported by previous releases of CTOS are supported by CTOSII version 1.0.
B.	Mixed clusters containing machines running CTOS I and CTOSII are supported but all versions of CTOS must be workstation version 9.1 or SRP version 3.2 or later.
C.	In prior versions of CTOS, the ConvertToSys operation caused the user number of the issuer to be changed.  A special class of request, ChangeUserNumber requests, were automatically issued at the time the user number changed to notify other servers.  CTOSII 1.0 does not change the user number of a program issuing ConvertToSys and, as a result, no ChangeUserNumber requests are issued.  However,  servers which are to continue working with CTOS I or in a cluster environment containing systems executing CTOS I must continue to serve and process such requests.
D.	Prior versions of CTOS associated the user number of 1 with the primary partition.  CTOSII 1.0 distinguishes between system and application partitions but not between primary and secondary partitions except that system services may be installed only when a single nonsystem partition (formerly the primary partition) exists.  As a consequence of this, and of item C above, user number 1 is not associated with any particular partition.  In fact, to avoid confusion, user number 1 is never associated with any partition and is now equivalent to user number 0 in that the presence in a request block of either a 0 or a 1 causes substitution of the issuer's user number.  In order that programs which based actions on whether or not they were in the primary partition continue to execute, the GetUserNumber operation has been modified to falsely return the number 1 under the following circumstance.  If there is only a single application partition, GetUserNumber calls from that partition will return 1.  In all other circumstances, GetUserNumber will return the proper user number.  
E.	Virtual partition memory management causes movement of partitions about memory across Chain or Exit operations.  As a result, the contents of longlived memory also move.  The pointers in the Applications System Control Block (ASCB) to long lived memory (the pVlpb and the pMsgRet) are automatically updated at this time.  However, if parts of longlived memory itself contain 32 bit pointers to other parts of longlived memory, these pointers may become invalid after Chain or Exit operations.  The standard use of longlived memory is for parameter passing between two programs via CTOS Parameter Management calls.  These calls do not use 32 bit pointers and thus do not have any pointer invalidation problem.  Among Convergent supplied programs there is a single known use of 32 bit pointers in longlived memory, namely the BGPArt Designer programatic interface.  In this interface, a 32 bit pointer to data to be displayed graphically masquerades as a text string and is passed via standard Parameter Management calls.  CTOSII 1.0 recognizes this case and adjusts the pointer accordingly.  It is recommended that future applications use only 16 bit pointers, relative to the base of longlived memory, to address objects within longlived memory.
7.2	Workstation Environment
CTOSII 1.0 on workstations requires Context Manager II version 1.0 or later.  Previous versions of the Context Manager will not execute on CTOSII 1.0.  In addition, Context Manager II 1.0 will not execute on versions of CTOS prior to CTOSII 1.0.
In order to execute system services in protected mode  on CP002s in the memory above 1 megabyte, CTOSII 1.0 requires Protected Mode Operating System Server (PMOS) version 1.1 or later.  PMOS version 1.0 will not execute on CTOSII 1.0.  PMOS version 1.1 is backwards compatible with CTOS version 9.7.
CTOSII 1.0 requires System Performance Accelerator (SPA) version 1.1 or greater in order to use the Ramdisk feature of caching files in memory above 1 megabyte.  However, the Mover.run from SPA version 1.0 is usable with CTOSII 1.0 for the purpose of using memory above 1 megabyte as a swap file.  The Ramdisk.run and Cacher.run provided with SPA version 1.0 will not execute properly on CTOSII 1.0.
7.3	Shared Resource Processor Environment
CTIX will not execute on CTOSII 1.0.  This will be rectified in a future version of CTOSII.
The SRP and workstation operating systems are now revision compatible under CTOSII with the exception of a few areas.  See the CTOSII Reference Manual for a description of which operations execute only on the SRP or workstations.  Following is a list of the general areas of incompatibility.
A.	On the SRP, the SetTrapHandler operation does not create trap handlers which are part of a partition's context (and are thus switched when processes in a different context are running).  Instead, the handlers are global to the board on which SetTrapHandler is executed.
B.	The Virtual Partition (VP) facility and its associated operations are not available on the SRP.  Partitions are statically configured in a manner similar to workstation CTOS version 9.1. 
C.	Only a few GetPStructure structcodes are available on the SRP.  The available codes are 0, 3, 4, 5, 11, and 17.  See the CTOSII Reference Manual for information on the meanings of structcodes.
D.	Operations oriented around interboard communication  or SRP hardware, such as ReadRemote or GetSlotInfo are not available on workstations.  Operations concerning the XBUS, such as MapXbusWindow, are not available on the SRP.
E.	Terminal mangement operations, such as OpenTerminal and ReadTerminal are not available on workstations.
F.	Only a subset of VAM operations are supported on the SRP and within that subset operations are restricted to provide only the functionality of a dumb terminal.  PosFrameCursor, ScrollFrame, PutFrameAttrs and ResetFrame are supported but do not cause any operation to take place.  PutFrameChars causes characters to be output but ignores the specifed screen coordinates.  VDM operations such as InitVidFrame are not supported on the SRP.
G.	The GetUserStatus, GetWsUserName and GetWsNum operations are not supported on SRP's or on workstations attached to SRP masters.  These operations are obsolete and should not be used in new programs.  Similar information to that returned by these operations can be obtained through the GetClusterStatus operation. 
H.	Only the encoded versions of keyboard operations are available on the SRP.  In addition, the SetSysinMode call, which is required by the Submit facility, is not supported.
Because the resolution of the Programmable Interval Timer (PIT) on the SRP is now that same as on workstations, customer applications which used the PIT on the SRP require may change in order to run under CTOSII 1.0.
{In prior releases of CTOS for the SRP, use of the call ConvertToSys in system services was discouraged.  In CTOSII, the operating system restraints were removed, allowing free use of ConvertToSys on the SRP as well as the workstation product lines.  The following choices are available:
A.	New or existing servers can be writtenmodified to call ConvertToSys.  This will allow the server to execute on either workstation or SRP without the need for hardware checks (most servers had code in them to check on which kind of hardware they were executing, and called ConvertToSys accordingly.)}
B.	Existing servers can be left as is.  The method of creating a partition and then loading the server into it using MInstallServer or LoadPrimaryTask will continue to be supported.
C.	Make the calling of ConvertToSys be a command line parameter.  For workstations, this would always be yes.  For SRP's, there is a memory consideration:  After all the partitions are created,  CTOSII still needs enough room to load the exit run file (CLI.run.)  If the creation of the last partition leaves less than about 60K in the primary partition, CTOSII will not be able to load CLI.run and the board will crash with erc 400.  By allowing the last server installed on the board to run in the primary partition (in otherwords by NOT calling ConvertToSys), this problem is alleviated.
{8.0	HARDWARE INFORMATION
CTOSII version 1.0 requires a minimum of 512K bytes of memory on workstations and 256K on the SRP.  It is suggested however, that SRP boards have either 768K of memory on the base board or be accompanied by a memory expansion board (ME).
8.1	Hardware Configurations Supported
CTOSII version 1.0 supports the following hardware configurations.  The revision levels listed are the minimum required.}
NGEN Modules
CP0018	8 Mhz 80186 processor
CP0019	8 Mhz 80186 processor
CP002	8 Mhz 80286 processor
CP002287	8 Mhz 80286 processor with 80287 
	numerical processor
VM001	12 monochrome monitor
VM002	14 monochrome monitor
VM003	14 monochrome bitmap monitor
VC001	15 color monitor
GC001	graphics controller
GC003	graphics controller
KM001	keyboard
TM001	voice processor (with modem)
VP001	voice processor (without modem)
XC002	RS232 port expander
XE001	Ethernet module
PC001	PC compatibility module
HB001	quarterinch tape module
FD001	dual floppy disk
FD0A1	dual floppy disk
HD002	10 Mb floppyhard disk
HD003	20 Mb floppyhard disk
HD006	20 Mb hard disk upgrade
HD011	32 Mb hard disk upgrade
HD020	85 MB hard disk upgrade
HD0A1	20 Mb floppyhard disk
HX002	10 Mb hard disk expansion
HX003	20 Mb hard disk expansion
HX011	32 Mb hard disk expansion
HX020	85 Mb hard disk expansion
{CWS Workstations
CM002	512 Kb
CM003	1024 Kb}
{Shared Resource Processor
CP	Rev Y (Shipping Y, Z and AA)
FP	Rev Z (Shipping AA through AG)
SC	Rev E (Shipping N)
SP	Rev J (P if more than
	       4 SMD drives are
	       to be online
	       concurrently.
	       Shipping S)
TP	Rev T (Shipping X)
SC2        Rev C (Shipping F, H, J)
SP2	Rev C (Shipping J, K)
ME050	Rev T (Shipping W, X, Y)}
Qic Controller          Rev B
Syquest Module          ECL 7
BackPlane               Rev B
Main Power Supply115V  Rev C1 or E (National)
Main Power Supply230V  Rev M
Bus Repeater            Rev E (Shipping F)

NOTE
The CP002 and CP002287 processor modules require the following revisions for floppy and floppyhard disk modules:
   FD001:  revision B or greater
   HD002:  revision C or greater


{8.2	Bitmap video compatibility
The GC003 graphics controller supports both a new high resolution monitor VM003 and the current medium resolution monitor VM001.  The GC003 does not have a hardware character map like the standard NGEN system.  Therefore characters and attributes are created in software.  The VM003 has sufficient resolution to emulate the standard character attributes.  The VM001, on the other hand, does not have sufficient resolution to have the same quality of emulation for the half bright attribute.  Half bright is emulated for consistency across all machines, but it is recommended that applications in the future refrain from using half bright on the VM001.  Executive II, for example, does not use half bright on the VM001.  Note that when a GC003 is used, with either monitor, characters with the blinking attribute are surrounded by an outlined box since actual blinking is not possible.}
Programs which do not use the VAM interface but which instead obtain pointers to the character map from the Video Control Block (VCB) or via the GetPStructure call will not work on GC003 equipped systems.  Such programs should be modified to replace the use of pointers to the character map by VAM calls.  VAM now provides operations which render obsolete most reasons for direct character map access.  Some versions of Convergent supplied programs make use of pointers in this manner and thus will not function on GC003 equipped systems.  The list of such programs follows:
Word Processor 10.3
Document Designer 1.0
Forms Editor 9.0
Art Designer 1.0
Multiplan 8.3
Extended Multiplan 2.0
Editor 10.2
Business Graphics 10.0
Vector Font Designer 1.1
PC Emulator 1.0
Graphics Library 11.0
{8.3	Software Applications Supported
Applications which are supported on CTOS IIGC003
  Application               CTOS II      GC003
 ArtChart Designer 1.0	YES	NO
*ArtChart Designer 1.1	YES	YES
 Business Graphics 10.0	YES	NO
 Context Manager II 1.0	YES	YES
 CTDBMS 10.1	YES	YES
 CTMail 4.2	YES	YES
 CTNet 3.1	YES	YES	**
 CTNet Async 1.0	YES	YES
 CTNet HDLC 3.0	YES	YES
 CTNet Ethernet 1.0	YES	YES
 Dictionaries 1.0	YES	YES
 Distrix 2.1	YES	
 Document Designer 1.0	YES	NO
*Document Designer 2.0	YES	YES
*Enhanced 3270 2.1	YES	YES
 Extended Multiplan 2.1	YES	YES
 Forms 9.0	YES	NO
*Forms 9.1	YES	YES
 Generic Print System 1.0	NO	NO
 Generic Print System 1.1	YES	YES
 Graphics Library 11.0	YES	NO
 Graphics Library 11.1	YES 	YES
 IconRaster Editor 1.0	YES	NO
*IconRaster Editor 2.0	YES	YES
 ISAM 11.0	YES	YES
 Mouse Services 1.0	YES	NO
 Mouse Services 2.0	YES	YES
*MTE 1.0	YES	
 Operator 1.1	YES	YES
 Pascal 9.0	YES	NO
*Pascal 9.1	YES	YES
 PC Emulator 1.0	YES	NO
 PLM86 2.3	YES	YES
 PMOS 1.0	NO	NO
*PMOS 1.1	YES	YES
*SNA Network Gateway 11.1	YES	NO
*SNA 3270 11.0	YES	NO
*SNA RJE 2.5	YES	NO
 SPA 1.0	NO	NO
*SPA 1.1	YES	YES
 TelexTWX Manager 1.1	YES	YES
 Terminal Mail Manager 2.0	YES	YES
 Vector Font Designer 1.1	YES	NO
*Windows 1.0	YES	YES
 Word Processor 10.3	YES	NO}

Languages:

 Basic 9.0	YES 	NO
*Basic 9.1	YES	YES
 C Compiler 2.1	YES	YES
 High Cobol 1.0	YES
 Fortran MS	NO	NO
 Fortran86 8.0	YES	NO
*Fortran86 9.0	YES	YES

*   To be released soon.
**  Does not wok on a GC003VM001 but does on 
                      GC003VM003
{9.0	RESOURCE REQUIREMENTSUTILIZATION
9.1	Memory RequirementsUtilization
The table below gives the memory requirements of all configurations of CTOSII and of loadable VAM.  Except when either the Protected Mode Operating System (PMOS) or the System Performance Accellerator (SPA) are installed on CP002 based workstations, CTOSII 1.0 is capable of utilizing a maximum of 1 megabyte of memory.}
The sizes are larger than the sizes of earlier versions of CTOS.  This difference results from the addition of code from the Context Manager, new Memory Management calls, Nationalization, and dynamic partitions.  However, overhead for each installed system services is less than in previous versions and VAM is not included:
Name	Size (bytes)

nClstr	 131,072

nClstrLfs		179,200

nStnd		163,840

nMstr		212,992

SrpCp		124,928

SrpDp		130,048

SrpFp		124,928

SrpSp		 86,416

SrpTp		106,496

BM (bitmap)	  58,368

CH (character)	   8,192
CTOSII 1.0, when used in conjunction with the Mover.run of SPA version 1.0 or later or PMOS version 1.1 or later, can utililize the memory above 1 megabyte on CP002 based systems for a swap file.  If Mover.run or PMOS is installed at the time a swap is first required and enough upper memory is available to meet the default or user specified (in [Sys]<Sys>Config.sys) swap file size, then upper memory is used in lieu of disk for swapping.  See the Release Notice for 1.1 Protected Mode Operating System (PMOS) Server or the Release Notice for the 1.0 System Performance Accelerator.
9.2	Disk RequirementsUtilization
It is recomended that CTOSII 1.0  Standard Software II 1.0 be installed only on systemsclusters with at least 20Mb of hard disk capacity. 
Swap files for each workstation using the Context Manager are recomended to be each at least 3000 sectors long (approximately 1.5 megabytes).  If using in conjunction with the Mover.run of SPA or PMOS, the swap file may use no disk space since the swap file will be in upper memory.  Diskless workstations may use their memory above 1 megabyte, if available, for swapping.  If high memory is not available, diskless workstations have their swap files located at the master workstation.  The Context Manager will operate on a system without a swap file (swap file size of 0 must be specified), but all contexts must then fit in memory and the variable size partition feature may not be used (See Section 2.0, item N).  The swap file size is now specified in [Sys]<Sys>Config.sys (See Section 2.0), not in the Context Manager configuration file.  If no size is specified, 3000 sectors is used.  If no file name is specified, [Sys]<Sys>Crashdump.sys is used if it is of the required size, otherwise successive file names of the form [Sys]<Sys>SwapAreaNN.sys (where NN = 00, 01, ...) are opened andor created.  
Workstations using the Debugger require a swap file large enough to hold the contents of memory, minus the size of the operating system (approximately 1700 sectors for a 1 megabyte RAM system).  The debugger will fail to operate if such a file does not exist or cannot be created.
All configurations of the CTOSII system image can be contained in 512 sectors.
Installation of the CTOSII Build diskettes requires 3400 sectors (approximately 1.7M bytes).  
Each CTOSII configuration you build requires approximately 650 sectors.
Building all the standard configurations requires  approximately 15000 sectors (approximately 7.5M bytes), in addition to the space required for CTOSII 1.0 Standard software and development tools.
{10.0	RESTRICTIONS
10.1  Cluster Configurations
Clusters can consist of combinations of IWS, AWS, NGEN, and CWS workstations and may involve SRP masters.  NGENCWSonly clusters can operate at 1.8 megabits per second, whereas mixed clusters of IWS, AWS, NGEN, and CWS workstations are restricted to 307 kilobits per second.  Note that appropriate cabling and terminators must be used for the cluster to operate at 1.8 megabits.}
{	
NOTE
For clusters with NGEN masters, an NGENCWS cluster operates at 1.8 megabits only if [Sys]<Sys>Config.sys (at the master) contains the entry
  :ClusterLineSpeed: 1.8 Mbps

The absence of this file or this entry in the file results in cluster speeds of 307K bits per second.
	
}
{11.0	DOCUMENTATION
11.1			Guide to current documentation 
The CTOSII operation system manuals are now organized as follows:
The CTOS II Systems Administrator's Guide, Engineering Update, describes how to configure clusters, establish backup schedules, and other administrative tasks.}
{The CTOSII Concepts Manual describes the features and concepts of each subsystem in CTOSII.  (Manual to be available Q486).}
{The CTOSII Reference Manual, consisting of two volumes, contains a description of each CTOSII procedure and is arranged alphabetically for quick reference.}
{The CTOS Programmer's Guide, Preliminary Edition, serves as a first reference for the programmer, covering practical rather than theoretical topics.}
{The Status Codes Manual contains complete listings of all status codes, bootstrap ROM error codes, and CTOS initialization errors.}
{11.2		Documentation Updates
SetMsgRet
Description
The SetMsgRet procedure is used to cause a message to be displayed after an application exits or a server uses the ConvertToSys operation.  
In the case of a ordinary application, SetMsgRet may be called at any time.  If the application is subsequently terminated, either normally or abnormally, the specified message will be displayed by the Exit Run File (usually the Executive).
In a system service, SetMsgRet is called prior to a ConvertToSys operation.  Then, immediately following the ConvertToSys, the Exit or ErrorExit operation is invoked, causing the Exit Run File to be loaded and the message displayed.   SetMsgRet must be used in lieu of ErrorExitString for this function because it is illegal to access or allocate longlived memory following a ConvertToSys operation.  SetMsgRet, like ErorrExitString allocates longlived memory but, unlike ErrorExitString, may be used before the ConvertToSys.}
{Procedural Interface
SetMsgRet (pbText, cbText): ErcType
where
pbText	

cbText	describe a text string which is to be displayed by the Executive. 

SetMsgRet is an object module procedure}

Stack Requirements
The requirement for stack size previously documented as 128 bytes for VAM calls has now been increased to 512 bytes.  This situation is more apparent on GC003 systems.
{11.3		Documentation Errata
1.	(CTOSII Reference Manual) The Video Control Block (VCB) fields iColLeftOff and iLineLeftOff are set to 255 after a ResetFrame operation, not 0 as documented under the description of ResetFrame.} 
2.	(Status Codes Manual) Erc 903 is documented as being returned only from the MarkNextQueueEntry operation.  It is in fact returned as a generic, no entries available error.
12.0	ERROR CODES
1.0 CTOSII adds the following error codes:
257	Swap file is full
258	Need to swap but no swap file is present
259	Swap file is too fragmented
260	Swap file is inconsistent
261	Cannot readwrite existing swap file
508	Invalid Video Access Method (VAM) parameters.
509	VAM is not installed.
13.0	KNOWN ERRORS AND OMISSIONS
CTOSII version 1.0 contains the following known errors and omissions.
A.	The date and time as kept in the system datetime structure on the TP board of the SRP are incorrect.
{B.	The Chain operation closes all open files and then checks for the existence of the specified run file.  If the run file is not accessible then an appropriate error is returned to the caller of Chain but the files belonging to the caller are left in a  closed state.	}
C.	Due to the changed semantics of user numbers across ConvertToSys operations (see Section 14.0) system services which check for user number 1 in a deinstallation request block may fail to deinstall under CTOSII.  The list of such servers follows:

       SNA Network Gateway
       Enhanced 3270
D.	Crash status messages are not printed on GC003 based systems until the system is rebooted.
E.	SRP versions of CTOSII 1.0 contain uninterruptable sections of code which may result in character overruns while running synchronous communications packages at 9600 baud.
F.	The KillProcess operation results in system crashes or hangs if used on processes which have executed SetTrapHandler or on processes which are not on the run queue.
{G.	Context Manager II 1.0 has a feature for locking programs permanently in memory.  To do so,  must be specified after the application name in the CmConfig.sys file and the program must be started using the autostart mechanism.  This feature interacts with the Debugger and can cause the system to hang if the resident Debugger option is not used and the Debugger is entered prior to installing the Context Manager.}
{H.	The file system of CTOSII 1.0 does not serve a swapping request.  In workstations attached to multiple FPDP SRP systems this could haved resulted in spurious erc 813s being displayed by the Context Manager when swapping from one application to another.  As a partial fix, a longer timout before erc 813 is issued has been implemented.  This can result in, in situations unrelated to the above SRP configuaration, a delay before a legitimate erc 813 is issued (as in the case of a server which has a bug in it and does not serve or respond to swapping requests).}
I.	On versions of the SRP with a Syquest removable disk, CTOSII occasionly fails to automatically recognize a cartridge upon insertion.  This problem usually occurs the first time that a cartridge is inserted following reboot and can be rectified by removing and reinserting the cartridge.
J. 	Pressing ACTIONFINISH while in the Debugger sometimes does either nothing  or causes a system crash.  If the Debugger is permanently resident (:ResidentDebugger:Yes in [Sys]<Sys>Config.sys), this condition does not occur.
14.0	MISCELLANEOUS
A.	The ServeRq and GetRequestInfo operations now return erc 31 (no such request code) if presented with a request associated with a dummy local service code.  Requests with dummy local service codes are used in loadable request files to fill unused request code slots.  Formerly, unused request codes below the maximum allocated were treated as if they were in fact in use, and erc 33 (server not installed) was returned by the above operations.
{B.	If CTOSII is unable to automatically create a swap file, a record is written to [Sys]<Sys>Log.sys and may be examined with the Plog program.}
{C.	CTOSII 1.0 supports two types of partitions, fixed and variable.  Fixed size partitions are created by the Context Manager when the :MemorySize: parameter in the CmConfig.sys file simply specified a number (e.g. :MemorySize:300).  Variable partitions are created when :MemorySize: specifies a range of sizes (e.g. :MemorySize:<350).  Use of variable partitions is preferable in that only the amount of memory specifed at the time a run file was linked with the Bind command (a version 6 run file) is used, thus making better use of memory and reducing swapping.  Run files linked with the Link command (version 4 run files) do not specify an amount of memory to be used.  In this case, the maximum amount of memory is used (i.e. if the CmConfig.sys entry for program Foo specifies <350 and Foo.run is a version 4 run file, 350K of memory will be used to run foo).}
D.	If you do not want to use a swap file, specify 0 in the :SwapFileSize: entry in [Sys]<Sys>Config.sys.  However, variable partitions (see C above) should not be specified in the Context Manager configuration file in this case.
E.	The CTOSII 1.0 parallel printer driver requires that the NOPAPER signal be connected (and not asserted) before data is printed on the parallel printer.  This was also the case in CTOS 9.7 but was not the case in prior versions.  If a parallel printer interface cable does not properly connect this signal, the printer will not operate.  For information on the construction of parallelprinter cables see any of the NGEN Processor manuals (e.g. Processor Model CP001 Volume2).
F.	Under certain circumstances, when the swap file is fragmented, swapping may fail with an Erc 2 (EOM).  To resolve this, enlarge your swap file or logout and log in again.  