
CONVERGENT TECHNOLOGIES

RELEASE NOTICE FOR
2.4 CTOSVM Operating System (SAA3401)

Revised 17 November 1989



	Table of Contents	Page
	1.0	Description of Programs 	 5
	2.0	Changes from Prior Versions 			 8
	2.1		Changes from CTOSVM 2.3 		 8
			A. 25 Mhz 386i support	 	 8
			B. Unisys datacomm support	 	 8
			C. Unisys B28EXP and B28LCW	 	 9
			D. New user number requests	 	 9
			E. SCSI MassIO enhancement	 	10
			F. Kernel primitive request	 	10
			G. Date modified	 	10
			H. GetSerialNumber	 	10
			I.	 VAM 3.1 support and packaging 	10
			J.	 Sysgen changes 	11
	2.2		Changes from CTOSVM 2.0 		12
			A. Kernel primitive Request	 	12
			B. SCSI Device Names	 	12
			C. Extended Video .		12
			D. New Hardware support	 	13
			E. Installable System Common	 	13
			F. Parallel Port Management	 	13
			G. Debugger	 	14
			H. Overlapped Seeks	 	14
			I. Cluster Protocol Enhancements	 	15
			J. OEM Options in Sysgen	 	 16
			K. Access to OEM Common Data Area	 	 16
			L. Encrypted passwords	 	 16
			M. Syntax in Config.sys	 	 17
			N. Real Mode Programmable Interval Timer 
			   support 		 17
			O. Nonfatal NonMaskable Interrupt Handling	 	 17
			P. Enhanced IBus support	 	 17
			Q. Keyboard Enhancements	 	 18
			R. Series 286i386i Non Volatile RAM support	 	 19
			S. Series 386i and HSD Seven Segment Display	 	 19
			T. Create Directory Protection Option	 	 19
			U. LoadRunFile and DeallocRunFile requests	 	 19
			V. File Structure verify option	 	 20
			W. Disk Retry and Log option	 	 20
			X. Cluster Workstation Timeout Option	 	 20
			Y. Dummy Video Option	 	 21
{	2.3		SPRs Closed in this release 		 22
	2.3.1			Problems closed in 2.4 	 22
	2.3.2			Problems closed in 2.3 	 22
	2.3.3			Problems closed in 2.2 	 24}
	3.0	Contents of Distribution Diskettes 			 26
	3.1		OS Build diskettes 		 26
	3.2		OS Kit diskettes 		 27
	4.0	Installation Procedures 			 29
	4.1		Installing prebuilt OS's 		 29
	4.2		Installing Custom Configurations of CTOSVM 
			locally 		 32
	4.3		Installing Custom Configurations of CTOSVM on	
				Workstation Masters 	 34
	4.4		Installing the CTOSVM Build Environment 		 35
	5.0	Building an Operating System 			 36
	6.0	Required Files 			 39
	6.1		Workstation Bootable diskettes 		 39
	7.0	Software Compatibility 			 40
	7.1		Operating System Features 		 40
	7.2		Real Mode (RMOS) Compatibility 		 40
	7.3		PMOS Compatibility 		 40
	7.4		System Services Compatibility 		 41
	7.5		Application Software Compatibility 		 45
	8.0	Hardware Information 			 46
	8.1		Hardware Configurations Supported 		 46
	8.2		Bit Map Video Compatibility 		 48
	8.3		Series 386i Memory Configurations 		 49
	8.4		GC102 character map on XBUS 		 53
	9.0	Resource RequirementsUtilization 			 54
	9.1		Memory RequirementsUtilization 		 54
	9.2		386i Expansion Memory Utilization 		 55
	9.3		Disk RequirementsUtilization 		 56
	10.0	Restrictions 			 57
	10.1		Cluster Configurations 		 57
	10.2		Memory Requirements for 80386 Features 		 57
	10.3		132 Column VC002 with EV processors 		 58
	11.0	Documentation Updates 			 59
	11.1		Guide to Current Documentation 		 59
	11.2		Nonvolatile ram support 		 60
	11.3		LoadRunFile and DeallocRunFile procedures 		 61
	11.4		SetResetIBusHandler procedures 		 63
	11.5		User Number procedures 		 66
	11.6		Get Serial Number 	procedures 	 67
	12.0	Status Codes 			 70
	13.0	Known Errors and Omissions 			 71

NOTE
This Release Notice is for the 2.4CTOSVM Operating System ONLY.  Information detailing 2.0CTOSVM is contained in a separate Release Notice for 2.0CTOSVM Operating System.
Standard Software  information is contained in a separate Release Notice for 11.5Standard Software Update.  Read the 11.5 Standard Software Update Release Notice before reading this one.
Video information is contained in a separate Release Notice for VAM 3.1
Install VAM 3.1 and 11.5 Standard Software before installing CTOSVM 2.4.  Install VAM 3.1 before installing 11.5 Standard Software Update.




NOTE
The bootable (.img) files of 2.4 CTOSVM are larger than 512 disk sectors.  You will probably have to IVolume your disk to increase the size of the SysImage.Sys file on your system disk drive.  See Sections 4 and 9 of this document for details and specific requirements.

1.0  DESCRIPTION OF PROGRAMS
This Release Notice describes the CTOSVM Operating System, version 2.4.  This release, in addition to being a maintenance release of 2.3 CTOSVM, supports Unisys intelligent datacomm modules and Unisys datacomm software.  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 CTOSVM Operating System.
This CTOSVM release includes a prebuilt operating system for the Series 286, 286i, 386, and 386i workstations.  You are also given the files necessary to construct a custom version of CTOSVM.
The table below indicates the most current version of CTOS or CTOSVM that supports each workstation type.  Although each version of CTOS contains different features, they are compatible and work together via the Convergent Cluster Network.
CTOS 9.1	IWS
CTOS 9.11	AWS
CTOS 9.10	Series 186, 286, 386
CTOSSRP 1.4	SRP
CTOSVM 2.4	Series 286, 286i, 386 and 386i,
	B28EXP, B28LCW
Naming Conventions for CTOSVM Configurations
The following naming conventions are used for naming CTOSVM configurations:
OS Family Type
p	Protected mode operating system.
OS Configuration Type
Clstr	Cluster workstation.
ClstrLfs	Cluster workstation with local file system.
Mstr	Master workstation.
Stnd	Standalone workstation.
{OS File Type
.img	Bootable system image, output of the PMake utility.  The Debug File utility cannot symbolically display or modify a .img file due to the absence of a version 6 run file header and the use of data compression.}
{.run	Run file, output of the Linker and input to the PMake utility.  A run file is an intermediate file used in the creation of a bootable system image.  The Debug File utility can symbolically display or modify a .run file.}
{.sym	Symbol file, output of the Linker.}
{.map	Linker report, output of the Linker.}
{.gdt	System image report, output of the PMake utility.}
{.fls	Object list file, input to the Linker.}
{.asm	System generation configuration (prefix) file, input to the Assembler.}
{Names of system files are a concatenation of the above mnemonics in the following order:
FamilyType ConfigType FileType
For example, pClstrLfs.img, names a protected mode Cluster Local File System bootable image.}
Unisys Naming Conventions
CTOSVM 2.4 will host Unisys datacomm applications (see section 2.1 for details).  Many Unisys naming conventions differ from those used by Convergent.  The table below is offered to help Convergent customers correlate Unisys names with Convergent names when installing Unisys software.
{	Operating System Names
	Unisys Name	Convergent Name
	BTOS	CTOS
	BTOS II	CTOSVM}
{	Processor Names
	Unisys Name	Convergent Name
	B24	no equivalent
	B25	generic name for Ngen workstations
	B26	186 CPU
	B27	no equivalent
	B28	286 CPU
	B28EXP	no equivalent
	B28LCW	no equivalent
	B38	386 CPU
	no equivalent	286i
	B39	386i
	XE520	SRP}
2.0  CHANGES FROM PRIOR VERSIONS
2.1  Changes from CTOSVM 2.3
The Release Notice for 2.0CTOSVM Operating System details new features for CTOSVM2.0.  In addition to those changes, the following have been changed or added starting with CTOSVM2.4.  
A.	25 Mhz 386i support
	CTOSVM 2.4 runs on the 25 Mhz 386i workstation.  This added support includes a 64K cache for the 25 Mhz 386i.
B.	Unisys datacomm support
	One of the primary motivations for producing CTOSVM 2.4 was to support Unisys datacomm hardware and software.
	Unisys high speed data communications hardware is now available to Convergent customers.  The following Unisys datacomm modules are now supported.  Each of the intelligent modules contains an 80186 CPU, 512K of local RAM, and communications hardware.  The Unisys IDMSS (Intelligent Datacomm Module Systems Software) is required for operation of the intelligent modules.
B25 ID2 (Intelligent Datacomm Module)  This intelligent module contains 2 RS232 channels which can drive synchronous lines up to 64K bps.  In addition it supports X.21 and Unisys TDI protocol.
B25 EN3 (Ethernet LAN Module)  This intelligent module replaces the Convergent XE001 module.  The EN3 can host either the lower 4 layers of the Unisys OSI products or TCPIP.
B25 TR2 (Token Ring LAN Module)  This new intelligent module can host either the lower 4 layers of the  Unisys OSI products or the Unisys SNA Transport Service.
	The following Unisys datacomm software products are now supported.  Except for LAN specific products (which must be installed on one of the LAN modules), these products can drive the RS232 channels of the CPU, be installed on the ID2, or drive the channels of the Convergent XC002.
BNetII 1.0.2
OSI Session 1.1.1
OSI Transport WAN 1.1.1
OSI Transport LAN 2.0
OSI Monitor 1.0
MHS Mail Manager 1.1
MHS Mail Server 1.1
X.25 9.0
X.21 CSS 1.0
TCPIP 1.0
IDMSS 4.0.0603
OFIS Bridge 1.2
RAF 2.0.07
SNA Transport 1.0
SNA RJE 3.2
SNA LUIS 2.2
SNA 3270 Emulator 7.0
SNA 3270 ClusterShare 1.0
SNA LU6.2 4.0
SNA PDF 1.0
BSC RJE 6.1
BSC 3270 Emulator 7.0
	CommLine has been changed to support Unisys datacomm appliciations running on channel A and B of the CPU.  This change should be transparent to Convergent and OEM applications.  In addition, a modification has been put into place to prevent mixed mode DMA operation on the 386i.  On the 386i, either both comm channels must operate in DMA mode or both in nonDMA mode.  If mixed mode is requested, erc 60 (invalid comm line spec) is returned.
C.	Unisys B28EXP and B28LCW support
	CTOSVM 2.4 supports the Unisys B28EXP and B28LCW CPU modules.  The B28EXP is a higher integrated version of the Convergent 286 CPU.  The B28EXP features expansion to 8 MB of RAM and an internal XBus expansion slot.  The B28LCW is a lower cost, cluster only version of the 286 CPU.
D.	New user number requests
	CTOSVM 2.4 has two new requests for the allocation and deallocation of blocks of user numbers.  The requests are described in section 11.5.
E.	SCSI MassIO enhancement
	The SCSI hard disk driver has been modified so that if the target is busy, the IOB is left on the queue to be tried later.
F.	Kernel primitive Request
	Because of incompatibilities with certain user application programs, the feature described in paragraph A in section 2.2 below, has been deimplemented.  The Request primitive now behaves as it did prior to CTOSVM 2.3.
{G.	Date modified
}	SetFileStatus has been modified so that if a user sets the date modified field of the file, that date will stay in effect when the file is closed.
H.	GetSerialNumber
	There is a new request and an object module procedure that return the bootROM's serial ID.  See section 11.6 for further details.
I.	VAM 3.1 support and packaging
	CTOSVM 2.4 does not include the packaging of VAM as has past releases.  While CTOSVM 2.4 will function with older versions of VAM, VAM 3.1 is required for the new GCx04 module and for the Unisys terminal emulators and status monitors.  If you wish to use VAM 3.1, please install it prior to installing the 11.5 Standard Software Update and CTOSVM 2.4.  Please consult the VAM 3.1 release notice for information regarding video.
	Note:  if VAM 3.1 is installed after 11.5 Standard Software Update, Display Configuration will not be able to identify any of the XBus modules.  It will display single modules with ? above them instead.  To correct this problem, reinstall the 11.5 Standard Software Update.
J.	Sysgen Changes
	A new parameter, called 'MaxXBlocksPerUser', has been added to pMstr.asm.  This parameter specifies the maximum number of request blocks a single program can have outstanding across the cluster.  In past releases this was hard coded at 4.  In CTOSVM 2.4, the default value is 4, but the value can be changed by building a custom configuration of the OS.  
	Another new paramter, called 'nUnBlocks', has been added to pMstr.asm.  This parameter specifies the number of user number blocks (where each block contains 8 user numbers) that can be allocated.  User numbers can be allocated and deallocated using the new user number requests.
	See section 5 for information on how to build a custom version of CTOSVM 2.4
	The parameter TimeOutTicks has been deimplemented.  TimeOutTicks is now set in the OS to an optimal value according to the cluster speed.
{2.2  Changes from CTOSVM 2.0
}The Release Notice for 2.0CTOSVM Operating System details new features for CTOSVM2.0.  In addition to those changes, the following have been changed or added starting with CTOSVM2.2 or CTOSVM 2.3.  These features are all also include in CTOSVM 2.4.
A.	Kernel primitive Request
	Starting in CTOS VM 2.3, if a request is not served, the kernel primitive Request returns erc 0 to the caller and puts erc 33 (service not available) in the ercRet field of the request block and responds to the request.  In previous releases Request returned erc 33 to the caller.  The change was made to insure consistent error handling regardless of where in the network the server is installed and to provide consistent aliasing and dealiasing of request block pointers.  (This feature has been removed from CTOSVM 2.4).
{B.	SCSI Device Names
}	In CTOSVM 2.2, nondisk SCSI device names were denoted as sn (e.g., s0).  Starting in CTOSVM 2.3, nondisk SCSI device names have been changed to zn (e.g., z0) due to device name inconsistency between CTOSVM workstation operating systems and 1.4 CTOSSRP SMD disk devices.
C.	Extended Video
	Processors that support Extended Video (i.e., Series 286EV, Series 386EV, and GC102) now have a cursor that is two pixels thick, rather than a single underline.  Processors that support Extended Video did not display underline in 34 line mode.
	In correcting the underline problem, it was necessary to increase the thickness of the cursor so that the cursor is visible when on an underline character.
	When in 29 line mode (default) the underline now rests on the bottom of the displayed character(s) and the cursor blinks below the underline.  When in 34 line mode the underline rests 1 pixel below displayed character(s) and the cursor blinks above the underline.
D.	New hardware support
	New hardware supported includes the Series 386i processor, the Series CP0A20A3 processors, the HSD040, HSD1940, HSD320, HSX140 and HSX320 SCSI hard disk modules and the GC102 and GC103 video cards.
{E.	Installable System Common
}	A generalized installable system common interface is included in CTOSVM2.2 with loadable definition options in the file [sys]<sys>Config.sys, install and query primitives, and reserved ranges similar to those for requests.
	The ranges of 32768 possible system common procedures are as follows:
0000h  3FFFh  Convergent use only
4000h  5FFFh  OEM Use (CT allocation)
6000h  7FFFh  OEM Use (no CT allocation)
	See the CTOSVM Reference Manual for details about the following calls for installable system common:
SystemCommonConnect
SystemCommonCheck
SystemCommonInstall
SystemCommonQuery
F.	Parallel Port Management
	Software support for the Series 286i386i and the CP0A20A3 parallel port input capability is provided.  The CTOSVM line printer driver has been enhanced to handle parallel port input and system termination requests.  LPT bytestreams now supports OpenByteStream operations with ModeModify as well as ReadBsRecord and ReadByte calls.
	The standard parallel printer driver provided within the CTOSVM 2.2 Kernel can be dynamically replaced.  This is done by creating FlushBufferLp, CheckpointBsLp, OpenByteStreamLp, and ReleaseByteStreamLp procedures that are installable (via System Common Install) and therefore take over the function of the procedures provided within CTOSVM.  Furthermore, the procedures InputPlm, OutputPlm, InPlm, OutPlm, and SetUpLpIsr have been made system common procedures.  These procedures, in combination with the SetLpIsr request, provide all that is necessary to replace the standard parallel device driver with a custom one.
G.	Debugger
	The Debugger is now a client of the installable video server, and no longer implements its own video.  This requires the Debugger, Video and Operating System to have a common 2.2 revision level for this release. 
	The debugger was changed to use the NLS keyboard encoding table for CodeI, and DebugFile.Run was changed to support CodeL to a disk file.
	A special OEM request has been added to CTOSVM to be used by the debugger, allowing debugging of a master workstation using the keyboard and monitor of a cluster workstation.  The request is GoDebugger and is defined in the CTOSVM Reference Manual.
	Other new debugger features such as usage of the 'Help' key, wildcards for symbols, and Virtual 8086 mode support are documented in the Debugger Manual Supplement 090145801.
	The Bitmapped video (Vdm_Bm.Run) reserves 128K memory for saving the user screen during debugging sessions.  If the debugger is not going to be installed on the workstation add the line:

   :SuppressDebugger:Yes

to [Sys]<Sys>Config.Sys and video will not reserve the additional 128K of memory.
H.	Overlapped Seeks
	The MassIO process has been enhanced to perform overlapped seeks on XBUS disk drives.  This is done through scheduling of seeks using the PIT timer.  This feature is enabled whenever two or more hard disks are on a system.  Note that this only applies to hard disk modules of the HDxxx and HXxxx variety.  SCSI capable modules (HSDxxx, HSXxxx and PHDxxx) support overlapped seeks as a feature of the SCSI protocol.
I.	Cluster Protocol Enhancements
	The standard CT cluster protocol has been extended so that workstations can provide a workstation identifier that uniquely identifies that workstation.
	The workstation identifier is obtained from either proprietary hardware or from a file on the cluster workstation (if the cluster workstation has a local disk) and placed in byte 6 of the XID protocol frame.  The master workstation cluster agent will save this number and make it available to applications on the master via the GetDaiNumber call.
	If the cluster workstation has no identification hardware attached, but has a local file system, then each hard disk volume on the workstation is searched (left to right) for the file DAI.sys in the <sys> directory.  The DAI number in this file appears as a text record of the form :DAInumber:xx.  If no identification hardware and no local file system exist on the cluster workstation (or the DAI.sys file is not present or does not contain the correct text record on the local file system), then the value zero is used which means that there is no identification number associated with this workstation.  See the CTOSVM Reference Manual for a description of the GetDAINumber call. 
{	The format of the XID frame is:
	   Offset   Value   Description
	0	n	Station ID
	1	XID	XID frame Type
	2	0
	3	91h
	4	n	line speed factor
	5	2
	6	DAI+1	DAI workstation identifier + 1 (0 means 
			no number is available)}
{	The cluster protocol also includes a modification to the SNRM frame.  A sixteen bit number is appended to the SNRM frame sent by the master workstation.  This number represents the cluster line speed in K bits per second (K = 1000).  The format of the frame is:
	   Offset	   Value	   Description
	0	n	Station ID
	1	93h	SNRM frame Type
	2	n	line speed (MSB)
	3	n	line speed (LSB)

Since the total length of the SNRM frame has not changed (bytes 2 and 3 were previously undefined), this frame is recognized by old workstation software.  The new line speed information will be used by future operating system and network software.}
J.	OEM Options in Sysgen
	Additional entries have been provided for OEM initialization needs before SysInit.run is invoked.  The procedure used to install video, keyboard, and math servers in the file Sysgen.asm is extended to allow the installation of the runfiles [sys]<sys>OEMt.run, where t can be 1, 2, 3, or 4.  Each of these runfiles, if it exists, is invoked sequentially before SysInit.run.
{K.	Access to OEM Common Data Area
	A single 32byte data segment has been reserved for OEM use.  This data segment has its own selector.  Exceeding the 32byte limit will cause a segment violation.  The location of the data area can be retrieved via a call to GetpStructure with a structure code of 37.  The selector for this data area is GDT based, therefore the data area is accessible by all CTOSVM protected mode programs.}
L.	Encrypted passwords
	CTOSVM supports encrypted passwords.  See the CTOSVM Concepts Manual for important information about encrypted passwords.
{M.	Syntax in Config.sys
	Comments can be used in Config.sys.  The ';' character is used to start a comment on a line.  Also the '' character may be used in place of the ':' character as a token delimiter.}
{N.	Real Mode Programmable Interval Timer support
	Real mode programs can now use the Programmable Interval Timer.}
{O.	Nonfatal Nonmaskable Interrupt Handling
	User level application programs that cause nonmaskable interrupts will no longer cause CTOSVM to crash.  The user level application will be terminated with error code 22.  Note that system level programs such as servers that cause nonmaskable interrupts are considered fatal and will still cause the system to crash.}
{P.	Enhanced IBus support
	An interface for implementing IBus access methods is provided in CTOSVM 2.2.  Requests are provided to allow setting and resetting of an IBus device handler for a specific device. These requests are SetIBusHandler and ResetIBusHandler.  This device handler is called from the keyboard interrupt process when data from the specific device is received.  The device handler then processes the input data and returns event codes and character codes to CTOS.  CTOS will queue the event and character codes to the current keyboard owner's event queue.  An application may retrieve the IBus information or data using the ReadInputEvent procedure call.  There may be up to eight IBus device handlers installed.  Also provided is a system common procedure WriteIBusDevice to allow output of a byte string to an IBus device.}
	{CTOSVM also now properly identifies IBus devices (assuming they follow the CT IBus protocol) and will place the IBus device identification bytes into the IBus table.  An application can then access this information by using the GetModuleID call.}
{	The SetIBusHandler and ResetIBusHandler procedural interfaces are detailed in the CTOSVM Reference Manual and section 11.4 of this document.}
{Q.	Keyboard Enhancements
	CTOSVM 2.2 now supports three different methods of keyboard encoding.
	1.Standard encoding, utilizing a 3byte by 128entry encoding table defined in NLS.sys.}
	2.Enhanced encoding, utilizing a 4byte by 128entry encoding table defined in NLS.sys.
{	3.Semicoded mode encoding.  This is a keyboard mode which provides much of the functionality of Convergent's standard unencoded mode, but requires less programming support and is easier to nationalize.  This mode functions like encoded mode but additionally returns information that indicates which other keys (shift, code, etc) were depressed to obtain the key code.  One request is provided to implement this option, ReadKbdDataDirect.  This request returns the encoded key character as well as coded information indicating which other keys were pressed to arrive at the final encoded character.  ReadKbdDataDirect is described in the CTOSVM Reference Manual.}
	Another new feature supports multiple character sequences such as '00' and '000' when a single key stroke is entered.  These character sequence keys are defined in the MultiByteEscapeKeys table in NLS.sys.  The table defines keyboard keys which when depressed result in multiple keystrokes being returned to keyboard clients.  All entries in the table are unencoded keystrokes. Any key on the keyboard may be defined as a MultiByteEscapeKey. Also, different results may be defined depending on the shift and code key state. See the CTOS Reference manual Appendix C1 for unencoded value of keyboard keys.  The resulting key sequences must include downstrokes as well as upstrokes as well as any shift state required to produce the keyboard characters desired. An upstroke is the key value OR'ed with 80h.
{R.	Series 286i and 386i NVRAM support
	A call is provided to allow applications to store and retrieve bytes from the nonvolatile ram memory in the Series 286i and 386i workstations.  The AccessNVRAM call is described in the CTOSVM Reference Manual and section 11.2 of this document.}
{S.	Series 386i and HSDxxx Seven Segment Display
	The Series 386i processor and the HSDxxx SCSI disk module each have a single seven segment display that can be used by applications for various signalling purposes.  The system call WriteLED provides access to this facility.  }
{T.	Create Directory protection option
	If the CreateDirectoryProtection:Yes option is selected in Config.sys, the volume password (if any) must be supplied when a directory is created.  This provides compatability with CTOS 9.9 and earlier versions.}
{U.	New LoadRunFileDeallocRunFile requests
	New requests are provided to allow the equivalent of a LoadTask and an UnloadTask operation.  The are called LoadRunFile and DeallocRunFile.  This will allow data andor procedures to be loaded in memory and removed from memory.  See section the CTOSVM Reference Manual or 11.3 of this document for details. }
{V.	File Structure verify option
	If the FileStructureVerify:Yes option is elected in Config.sys, the CTOSVM file system will verify all file system structures written to disk.  All file headers, directory entries and volume home blocks will be read immediately after they are written and verified for data correctness.  This option can be used to diagnose file system andor hardware problems that result in corrupt disks.  Enabling this option can result in a decrease of file system performance of up to fifty percent.  Normally this option is disabled (default state).}
{W.	Disk Retry and Log option
	Two Config.sys options are provided to allow the setting of disk error retry parameters.  DiskRetryCount:xx allows the user to define the number of times that CTOS will retry a disk operation before aborting it with an IO error.  If this option is not used, the default is as it was in previous CTOS versions (defined in SysGen.mdf).
	DiskLogThreshold:xx allows the user to specify a specific number of disk retrys below which if an operation is successful, no error is logged.  The default is one so that all retry attempts (successful or not) are logged.}
X.	Cluster Workstation Timeout option
	A Config.sys option is now available to allow the user to specify the length of time in seconds that a cluster workstation will wait before declaring that the master workstation is down.  In previous versions of CTOS, this timeout was fixed at approximately thirty seconds.  The :ClusterTimeout:xx Config.sys option allows this timeout to be specified.  If this option is not used, the default time will be set to thirty seconds.  This option is ignored on master and standalone workstations.
{Y.	Dummy Video Option
	A Config.sys option is now available to allow the user to configure a master workstation in a server configuration with no video or keyboard.  Set the option :VdmFile: [vol]<dir>Vdm_Dmy.run in config.sys if you want a dummy video system service.}
2.3  Problems Closed in this release
2.3.1  Problems closed in 2.4
InternalPC Emulator is now allowed to use the IO permission bitmap.
InternalThe idle loop has been modified so that ES is not loaded with an incorrect selector value.
InternalAn application which has defined soft vectors is now able to convert to sys.
InternalShortlived segments allocated by ReservePartitionMemory are now initialized to zeros when a context terminates.
InternalA cluster timing problem involving clusters running at 307Kbps with 25 Mhz 386i masters and 386 diskless cluster stations has been corrected.
SPR 15690  Keyboard race condition.
2.3.2  Problems closed in 2.3
Internal  During a debugging session, the debugger sometimes faulted when clearing break points or when terminating a program with break points set.
Internal  The master operating system could be built with more than 255 exchanges.  The number of exchanges is now calculated and will not exceed 255.
Internal  When a request block contained user number 1 to access the primary partition the kernel substituted the caller's user number rather than substituting the primary partition's user number.
Internal  If a partition was partially swapped when an error occurred trying to access the swapfile, the partition was sometimes not swapped back into memory properly.
Internal  Terminating a program with  shared code, which was sharing code with another program that was swapping, would sometimes cause the swapped program to fault when swapped back into memory.
Internal  If the config.sys token :EnterDebuggerOnFault: was set to No and the application encountered a system trap (e.g., divide by zero), it was terminated with the wrong erc.
Internal  Erc 33 was reported when booting diskless workstations from a Shared Resource Processor.
Internal  On Series 386i processors, if a scanner was attached to the parallel port, the system would not boot from floppy disk.
{SPR 14143  Clearing the keyboard typeahead buffer by issuing the calls
	SetKbdUnencodedMode (TRUE)
	SetKbdUnencodedMode (FALSE)
does not work under CTOSVM 2.2.}
SPR 14161  The keyboard enqueues repeat keys for users who don't own the keyboard.
SPR 14349  Erc 606 is sometimes returned if the keyboard buffer is full.
SPR 14466  Requests with :NetRouting: defined as CloseFh would try to do file specification expansion on pointers in the request block.
SPR 14623  Pressing ACTIONFINISH, from a diskless workstation, during a restore from the master's floppy can cause a crash 80.
SPR 14692  On Series 386i, the system will crash with Erc 80 if ACTIONFINISH is pressed during a LoadFontRam call.
SPR 14725  IO errors encountered by a ClstrLfs OS booted from the master are not logged to the master's log file.
SPR 14768  Installing more than two batch queues is not possible.
SPR 14803  On Series 386i processors, if a modem is attached to communication channel A and the modem is turned on and off, the system will hang.
SPR 14823  Pointers are not dealiased correctly if the ErcRet for a Request primitive is nonzero.
2.3.3  Problems Closed in 2.2 CTOSVM
For a complete list of the SPRs closed in this release of CTOSVM, refer to the Release Notice for 2.0CTOSVM Operating System.
SPR 12159  npTiming for pClstrLfs should be larger for preSysgened OS.
SPR 12230  Release notice doesn't mention need to configure or link the filesystem.
SPR 12292  Incorrect CS:IPs in CodeS of debugger.
SPR 12339  Cannot replace existing interrupt handler.
SPR 12393  GP fault in mediated hardware interrupt handler.
SPR 12394  Default interrupt handlers are not restored after a partition terminates.
SPR 12423  Cluster performance when running at 307K is degraded.
SPR 12446  GP fault after DeInstallMailServer.  Problem with SetpStructure.
SPR 12455  GetpStructure returns 0 for sbBootDevName pointer.
SPR 12462  Bit mapped video attributes.
SPR 12475  UserNumber after ConvertToSys is different from CTOS 9.7
SPR 12600  Erc 500 in Forms Editor.
SPR 12653  Certain GP faults cause a system crash when they shouldn't.
SPR 12715  RMOS partitions on a 286i are smaller than they should be.
SPR 12716  Xbif.run GP fault when booting from floppy.
SPR 12724  Volume password not required to create or remove directory.
SPR 12727  LowDataGDTProtected problem.
SPR 12784  PLog prints garbage for signon user name.
SPR 12808  NMI on reboot after crash dump on certain CP002 processors.
SPR 12811  Incorrect logging of disk errors with multiple hard disks.
SPR 12901  LPT prints garbage if set offline then online.
SPR 12913  SetDirectoryProtection returns ercOK for protection level 9999.
SPR 13094  Memory parity error on some CP002 processors.
SPR 13179  GP fault in the kernel when a bad node name is used.
SPR 13368  Any configuration of cluster workstations always use WS252>Sysinit.JCL.
{3.0  CONTENTS OF DISTRIBUTION DISKETTES
The CTOSVM Operating System OS and Build Kit  Diskette sets are your master copies and have been shipped writeprotected.  They should not be writeenabled, nor should they be used as working copies.}
{The contents of the CTOSVM Build and CTOSVM OS Kit diskettes are described below.  The CTOSVM Build diskettes are required only if you are building a custom configuration of CTOSVM.  The CTOSVM OS Kit diskette is required to update old versions of the operating systems.}
{The Build diskettes consist of a 3diskette set containing files required to build version 2.4 CTOSVM.  The OS Kit consists of a 4diskette set containing the four different types of operating systems.  The OS Kit diskettes also contain the files needed for installable video and debugging facilities.  These facilities are released together with the OS since they share enhancements which make them dependent upon identical revision levels.}
{3.1  CTOSVM Build Diskettes
Disk 1 of 3, <Sys> directory
HdInstall.sub	LinkCTOS.sub
LinkCTOSVM.sub	LinkFileSystem.sub}
{Disk 1 of 3, <CT> directory
FileSystem_n.obj	FS_n.asm
FS_n.fls	KBD.asm
KBD.mdf	KBD.obj
pClstr.asm	pClstr.fls
pClstr.obj	pClstrLfs.asm
pClstrLfs.fls	pClstrLfs.obj
pMstr.asm	pMstr.fls
pMstr.obj	pStnd.asm
pStnd.fls	pStnd.obj
RealNub.sys	Request.asm
Request.mdf	Request.obj
SysGen.asm	SysGen.mdf}
{Disk 2 of 3, <Sys> directory
All.sub	HdInstall.sub
OS Build Diskette 2 of 3}
{Disk 2 of 3, <CT> directory
Clstr.lib	Dbg.lib
FileSys.lib	Init.lib}
{Disk 3 of 3, <Sys> directory
All.sub	HdInstall.sub
OS Build Diskette 3 of 3}
{Disk 3 of 3, <CT> directory
OS.lib}
{3.2  CTOSVM OS Kit Diskettes
Disk 1 of 4, <Sys> directory
Cleanup.fls	Clstr.sub
Debug.sub	Delete.fls
HdInstall.sub	InstallConfig.sys
Local.sub	Master.sub
Request.VM.txt	SRP.sub
StandAlone.sub	Submit.fls
Workstation OS Kit Diskette 1 of 4}
Disk 1 of 4, <RelNote> directory
ReleaseNotice
Disk 2 of 4, <Sys> directory
Cleanup.fls	Clstr.sub
Debug.sub	Delete.fls
HdInstall.sub	InstallConfig.sys
Local.sub	Master.sub
SRP.sub	StandAlone.sub
Submit.fls	
Workstation OS Kit Diskette 2 of 4
{Disk 2 of 4, <CT> directory
pMstr.img}
{Disk 3 of 4, <Sys> directory
Cleanup.fls	Clstr.sub
Debug.sub	Delete.fls
HdInstall.sub	InstallConfig.sys
Local.sub	Master.sub
SRP.sub	StandAlone.sub
Submit.fls	
Workstation OS Kit Diskette 3 of 4}
{Disk 3 of 4, <CT> directory
pClstr.img	pClstrLfs.img}
{Disk 4 of 4, <Sys> directory
Cleanup.fls	Clstr.sub
Debug.sub	Delete.fls
HdInstall.sub	InstallConfig.sys
Local.sub	Master.sub
SRP.sub	StandAlone.sub
Submit.fls	
Workstation OS Kit Diskette 4 of 4}
{Disk 4 of 4, <CT> directory
DebugFile.run	Debugger.help
DebuggerP.sys	pStnd.img}
4.0  INSTALLATION PROCEDURES
Install 3.1 VAM before installing the 11.5 Standard Software and before installing a new CTOSVM configuration.  See the Release Notice for 3.1 VAM for details.
Install 11.5 Standard Software Utilities before installing a new CTOSVM configuration.  See the Release Notice for 11.5 Standard Software for details.
Install the 11.4 Standard Software Development Utilities if you plan to build a custom CTOSVM configuration.
If you choose to initialize your System disk ([Sys]), 11.5 Standard Software installation copies a cluster local file system configuration of CTOS to [Sys]<Sys>SysImage.sys.  Hence, you need to install from the CTOS OS Kit diskettes only if you require a different configuration or version.
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 PreBuilt OS's

NOTE
	For the Standalone and Local options listed below, you must perform the installation at the workstation that you wish to update.  You can perform the Master and SRP options from any workstation.

A.	Insert diskette 1 of 4 of the CTOSVM PreBuilt OS Kit Diskettes.  Fill in the floppy drive if you are not installing from [f0]
	Command  Install
Install
  [Floppy (default = [f0])]  GO
	You will be asked to designate the type of operating system to be installed.  The choices are:
Local 	Choose Local to install an OS on a workstation that has a local hard disk and is attached to the cluster network.  The installation process copies the  clusterlocal file system (pClstrLfs) configuration to
	   [Sys]<Sys>SysImage.sys
	This OS is on the second diskette, so you may simply insert diskette 2 of 2, and type the command Install as directed above.
Standalone 	Choose Standalone to install an OS on a workstation that has a local hard disk and is not attached to a cluster network.  The installation process copies the  standalone (pStnd) configuration to
	   [Sys]<Sys>SysImage.sys.
Master 	Choose Master to install OSs on the master workstation.   The installation process copies the master (pMstr) configuration to
	   [Sys]<Sys>SysImage.sys,
	copies the clusterlocal file system (pClstrLfs) configuration to
	   [Sys]<Sys>ws220>SysImage.sys, 
   [Sys]<Sys>ws221>SysImage.sys, 
   [Sys]<Sys>ws230>SysImage.sys, 
   [Sys]<Sys>ws231>SysImage.sys,
   [Sys]<Sys>ws240>SysImage.sys, and 
   [Sys]<Sys>ws241>SysImage.sys,
	and copies the cluster (pClstr) configuration to
	   [Sys]<Sys>ws222>SysImage.sys,
   [Sys]<Sys>ws232>SysImage.sys,and
   [Sys]<Sys>ws242>SysImage.sys.
	The wsNNN>SysImage.sys files are copied so that workstations connected to the cluster network can bootstrap from the master.
	For CTOSVM, the ws220, ws221, ws230, ws231, ws240, and ws241 files contain the same contents.  The ws222, ws232, and ws242 files are also the same.  If the master is executing CTOSVM, you may use the indirect boot image file feature (descibed in the CTOSVM 2.0 release notice section 2.1) to conserve disk space by preventing duplication of identical files.
SRP 	Choose SRP to install OSs on an SRP master.   Choosing SRP is the same as choosing Master except that an OS is not copied to the SRP's SysImage.sys (since that file has to be an SRPtype OS).
	The installation process copies the clusterlocal file system (pClstrLfs) configuration to 
	   [Sys]<Sys>ws220>SysImage.sys, 
   [Sys]<Sys>ws221>SysImage.sys, 
   [Sys]<Sys>ws230>SysImage.sys, 
   [Sys]<Sys>ws231>SysImage.sys,
   [Sys]<Sys>ws240>SysImage.sys, and 
   [Sys]<Sys>ws241>SysImage.sys,
	and copies the cluster (pClstr) configuration to
	   [Sys]<Sys>ws222>SysImage.sys,
   [Sys]<Sys>ws232>SysImage.sys,and
   [Sys]<Sys>ws242>SysImage.sys.
	The wsNNN>SysImage.sys files are copied so that workstations connected to the cluster network can bootstrap from the SRP.
	For CTOSVM, the ws220, ws221, ws230, ws231, ws240, and ws241 files contain the same contents.  The ws222, ws232, and ws242 files are also the same.  If the SRP is executing CTOSSRP 1.2 or a later version, you may use the indirect boot image file feature (descibed in the CTOSVM 2.0 Release Notice section 2.1) to conserve disk space by preventing duplication of identical files.  
B.	After installing OSs, the installation process copies the Debugger (DebuggerP.sys) the Debug File utility (DebugFile.run) and the Debugger Help text file (Debugger.help) to the [Sys]<Sys> directory.
	To install these files, press GO when prompted.  To prevent installation, press ACTIONFINISH when prompted.
4.2  Installing Custom Configurations of CTOSVM locally
Use the installation procedure described below to install custom configurations of CTOSVM.  A custom configuration of the operating system is an OS that you have built which resides in the <VMGen> directory.  Typically, custom configurations are created to change system generation parameters.
Section 5.0 describes how to build a custom configuration of CTOSVM.
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 an Swp suffix, CTOS is NOT memory resident.
	If the OS is not memory resident, insert the 11.5 Standard Software Initialization CTOSVM diskette in floppy drive [f0] and type
{	Command  Bootstrap  RETURN
Bootstrap
  File name  [f0]<Sys>SysImage.sys  GO}
B.	Copy your custom configuration of CTOSVM 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 new CTOSVM 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.
	All CTOSVM configurations should be no larger than 600 sectors.  If the OS you are copying is considerably larger, make sure that you are copying an image file (.img) rather than a run file (.run).
{4.3  Installing Custom Configurations of CTOSVM on the 
 Workstation Master
Use this procedure to enable cluster workstations to bootstrap from the master.
A.	At the master, copy your custom configuration of ClstrLfsClstr 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.  
	For CTOSVM, the ws220, ws221, ws230, ws231, ws240, and ws241 files contain the same contents.  The ws222, ws232, and ws242 files are also the same.  You may use the indirect boot image file feature (descibed in the CTOSVM 2.0 Release Notice section 2.1) to conserve disk space by preventing duplication of identical files.  
{NNN	Hardware Configuration
	CTOSVM 2.4

220	Series 386i with hard disk
221	Series 386i with floppy disk only
222	Series 386i with no local disk
230	Series 286i with hard disk
231	Series 286i with floppy disk only
232	Series 286i with no local disk}
{	CTOSVM 2.4 or CTOS 9.10

240	Series 286386 with hard disk
241	Series 286386 with floppy disk
	only
242	Series 286386 with no local disk}
{	CTOS 9.10

250	Series 186 with hard disk 
251	Series 186 with floppy disk only
252	Series 186 with no local disk}
{	CTOS 9.1

000015	IWS}
{	CTOS 9.11

253	AWS with hard disk
254	AWS with floppy disk only
255	AWS with no local disk}
{4.4  Installing the CTOSVM 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.  Fill in the floppy drive if you are not installing from [f0]
	Command  Install
Install
[Floppy (default = [f0])]  GO
	The submit file prompts you for a volume name and password and creates a <VmGen> directory on your disk.
	The submit file then copies files to the <VmGen> 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 custom version of CTOSVM from the files supplied on the CTOSVM Build distribution diskettes.}
All the files needed to do a system generation (SysGen) are contained in the <CT> directories of the CTOSVM Build diskette set.  The installation procedure creates the <VmGen> directory  on your hard disk.  The <VmGen> directory contains the libraries and files needed to build any configuration of the operating system.
{Building a CTOSVM 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 CTOSVM using the Link Ctos VM command (see below).}
Each configuration of CTOSVM 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 CTOSVM configuration name, such as pStnd.asm.  Also, the pStnd, pClstrLfs and pMstr operating systems include the file system which must be configured (also via Sysgen) and linked separately.  The filesystem configuration file is called fs_n.asm.  The filesystem configuration and link procedures need not be done if filesystem parameters are not to be changed.
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.
Note that it is not necessary to link custom versions of CTOSVM to add new requests.  It is preferable to use the loadable request mechanism.
If only the filesystem configuration needs to be changed, then assemble and link the filesystem and then link the CTOSVM operating system (pStnd, pMstr or pClstrLfs).  
{Assemble the filesystem prefix file using the Assemble command.
	Command  Assemble  RETURN
	Assemble
	  File name       Fs_n.asm        RETURN
	  [Errors only?]  yes             GO}
{Link the filesystem using the Link File System command.
	Command  Link File System         RETURN
	  OS type             Fs_n        RETURN
	  Version             2.4         RETURN
	  [File system name]              GO}
{If you are linking a version 2.0 CTOSVM file system, fill in the Link File System command as follows.
	Command  Link File System         RETURN
	  OS type             Fs_n        RETURN
	  Version             2.0         RETURN
	  [File system name]  FS          GO}
NOTE:  a version 2.0 CTOSVM file system should only be linked with the 2.0 CTOSVM operating system.  The file system must always be the same version as the operating system.
{Assemble an operating system prefix file using the Assemble command.
	Command  Assemble                 RETURN
	Assemble
	  File name       pClstrLfs.asm   RETURN
	  [Errors only?]  yes             GO}
{Link CTOSVM using the Link Ctos VM command.
	Command  Link Ctos VM  RETURN
	  OS type  pClstrLfs   RETURN
	  Version  2.4     GO}
{Removing Optional Services
You may remove optional services from CTOSVM by editing the .fls file for the operating system version and replacing the modules that implement the service with dummy modules.  These files are named vvv.fls, where vvv is the CTOSVM configuration name, such as pClstrLfs.fls.}
The Debugger is the only optional service.
After editing, link the operating system as described above.
{Removing the Debugger
To remove the Debugger, replace the Debugger resident modules:

    DBG.LIB( ... ) and
with
    DBG.LIB(dbgNul)
Remove the Debugger initialization module:

    DBG.LIB(t1DOnc_p)}
6.0  REQUIRED FILES
6.1  Workstation bootable disks
A bootable hard or floppy disk contains the following files in the <Sys> directory.
SysImage.sys
Sys.cmds
Exec.run
ExecMsg.bin
Signon.run
.user
InstallVdm.run
Additionally, bootable disks on workstations using character mapped video contain the following files.
Vdm_CH.run
t1Sys.font
Additionally, bootable disks on workstations using bit mapped video contain the following files.
Vdm_BM.run
1024x768_80sys.font
720x348_80sys.font
Additionally, bootable disks on workstations using GCx04 (VGA) video contain the following files.
Vdm_VGA.run
1024x768_80sys.font
720x348_80sys.font
The 11.5 Standard Software installation process installs all of the above files with one exception.  SysImage.sys is installed only if you choose to initialize (IVolume) your system disk.
7.0  SYSTEM SOFTWARE COMPATIBILITY
7.1  Operating System Features
See the Release Notice for the 2.0 CTOSVM Operating System for important information about CTOSVM feature compatability.
7.2  Real Mode (RMOS) Compatiblity
See the Release Notice for the 2.0 CTOSVM Operating System for important information about CTOSVM RMOS compatibility.
Note that this release does support the programmable interval timer (PIT) for real mode programs.  The Kernel primitives, SetTimerInt and ResetTimerInt are therefore fully supported in RMOS.
7.3  PMOS Compatibility
See the Release Notice for the 2.0 CTOSVM Operating System for important information about CTOSVM PMOS compatibility.
7.4  System Services Compatibility
The table below shows the compatiblity of the latest  versions of Convergent supplied system services with CTOSVM 2.4.  For compatibility information on other versions of CTOS, see the CTOSVM 2.0 Release Notice.

                                   CTOSVM
System Service       Ver             2.4

{Context Manager	VM		2.3
	Context Manager		2.3			yes
	ICMS		2.3			yes
}
{CTDBMS			10.1
	DBMSServer		10.1			no
	PmDBMSServer		10.1			yes
	ResDBMSServer		10.1			no
}
{CTMail			7.0
	CommunicationsMgr		7.0			yes
	MailServer		7.0			yes
	mCommunicationsMgr		7.0			no
	mMailServer		7.0			no
}
{CTNet	 		3.2						
	HDLC		3.2			yes
	NetAgent		3.2			yes
	NetServer		3.2			yes
	mHDLC		3.2			no
	mNetAgent		3.2			no
	mNetServer		3.2			no
}
{CTNet Async			1.0
	Aync		1.0			no
}
{CTNet Async			1.1
	Aync		1.1			yes
	mAsync		1.1			no
}
{CTNet Ethernet			1.0
	ENet		1.0			no
}
{CTNet Ethernet			1.1					
	ENet		1.1			yes
}
{CTNet SRP Ethernet			1.1			no
}
{CTNet X.25			1.0
	X25NISL		1.0			no
}
{CTNet X.25			1.1					
	X25NISL		1.1			yes
	mX25NISL		1.1			no
}
{Enhanced Bisync 3270			3.0
	M3270.prt		3.0			no
	M3270.sys		3.0			no
	mM3270.prt		3.0			no
	mM3270.sys		3.0			no
}
{Enhanced Bisync 3270			4.0					
	M3270.prt		4.0			yes
	M3270.sys		4.0			yes
	mM3270.prt		4.0			no
	mM3270.sys		4.0			no
}
{Generic Print System			2.3
	GpsInstall		2.3			yes
	GpsRs		2.3			yes
	GpsSp		2.3			yes
	BinaryModeDD		2.3			yes
	DaisyDD		2.3			yes
	EpFx286DD		2.3			yes
	HpLaserJetDD		2.3			yes
	Imagen8300DD		2.3			yes
	LptSimpleDD		2.3			yes
	FontServer		2.3			yes
	mGpsInstall		2.3			no
	mGpsRs		2.3			no
	mGpsSp		2.3			no
	mBinaryModeDD		2.3			no
	mDaisyDD		2.3			no
	mEpFx286DD		2.3			no
	mHpLaserJetDD		2.3			no
	mImagen8300DD		2.3			no
	mLptSimpleDD		2.3			no
	mFontServer		2.3			no
}
{ISAM			10.1
	IsamServer		10.1			no
	PmIsamServer		10.1			yes
	ResIsamServer		10.1			no
}
{Mouse Services			2.3					
	Mouse		2.3			yes
}
{Modem Server 			4.3
	ModemServer		4.3			yes
	mModemServer		4.3			no
}
{PC Emulator			4.0					
	PCServer		4.0			yes
}
{PMOS			2.0
	PmAgent		2.0			no
	PmSubAgnet		2.0			no
}
{27803780 RJE			11.0
	RJE		11.0			no
	mRJE		11.0			no
}
{SNA 3270			11.0	
	s33		11.0			yes
	s32		11.0			yes
	ms33		11.0			no
	ms32		11.0			no
}
{SNA DFC			1.1
	SnaDfc		1.1			no
}
{SNA Multi Ntwk Gtwy			1.0	
	SNAMpu		1.0			no
	MpuNcc		1.0			no
	MpuNac		1.0			no
}
{SNA Network Gateway			11.1
	SNA		11.1			no
}
{SNA Network Gateway			12.0					
	SNA		12.0			yes
	mSNA		12.0			no
}
{SNA RJE			3.0					
	sRJE		3.0			no
	msRJE		3.0			no
}
{SNA X.25 Ntwk Gtwy			1.0
	SnaX25		1.0			no
}
{SPA			2.1					
	Mover		2.1			yes
	RamDisk		2.1			yes
}
{Standard Software			11.5
	InstallQMgr		11.3			yes
	InstallSpl		11.3			yes
	NgenQicServer		11.4			yes
	MathServer		11.3			yes
	NlsServer		11.3			yes
	QueueMgr		11.3			yes
	XBif		11.5			yes
	XC002Server		11.5			yes
}
{TelexTwx Manager			1.2
	TelexTwxManager		1.2			yes
	mTelexTwxMgr		1.2			no
}
{Terminal Mail Manager			2.1
	TerminalMailMgr		2.1			yes
	mTerminalMailMgr		2.1			no
}
{Video			3.1
	InstallVdm.ru	n	3.1			yes
	Vdm_VGA		3.1			yes
	Vdm_Ch		3.1			yes
	Vdm_Bm		3.1			yes
}
{VoiceData Services			1.2
	TmServer		1.2			no
}
{VoiceData Services			2.0
	TmServer		2.0			yes
}
{Windows			2.2
	Vdm_ChW		2.2			yes
	Vdm_BmW		2.2			yes
}
{X.25 Network Gateway			10.0
	X25		10.0			yes
	mX25		10.0			no}
{7.5  Application Software Compatibility
The table below shows the compatiblity of the latest  versions of Convergent supplied application software with CTOSVM 2.4 and VAM 3.1.

                                   CTOSVM
Applications         Ver             2.4

Art Designer	2.1	yes

CCGI+	2.0	yes

Chart Designer	2.1	yes

Cluster Share	1.3	yes

Document Designer	2.2	yes but see section 13.I

Graphicslib	12.1	yes}
{8.0  HARDWARE INFORMATION
CTOSVM version 2.4 requires a minimum of 1 Mb of memory on workstations with 1.5Mb or more recommended.
8.1  Hardware Configurations Supported
CTOSVM version 2.4 supports the following hardware configurations.  The revision levels listed are the minimum required.}
Processors, Numeric Coprocessors, Memory
CP002	8 Mhz Series 286 processor
CP0A2	8 Mhz Series 286 processor with alphanumeric 
	color hardware
B25LCW	8 Mhz Series 286 processor, cluster only
B25EXP	8 Mhz Series 286 processor, higher integration
CP003	16 Mhz Series 386 processor
CP0A3	16 Mhz Series 386 processor with	alphanumeric 
	color hardware
PHD010	8 Mhz Series 286i processor with	20 Mb hard disk 
	and floppy disk
PHD011	8 Mhz Series 286i processor with	floppy disk only
PHD020	8 Mhz Series 286i processor with	80 Mb hard disk 
	and floppy disk
PHD140	20 Mhz Series 386i processor with	140 Mb hard disk 
	and floppy disk
PHD147	20 Mhz Series 386i processor with	140 Mb hard 
	disk, floppy disk and	80387 20.0 Mhz coprocessor
PHD320	20 Mhz Series 386i processor with	320 Mb hard disk 
	and floppy disk
PHD327	20 Mhz Series 386i processor with	320 Mb hard 
	disk, floppy disk and	80387 20.0 Mhz coprocessor
PHD040	25 Mhz Series 386i processor with	40 Mb hard disk 
	and floppy disk
PHD145	25 Mhz Series 386i processor with	140 Mb hard disk 
	and floppy disk
PHD148	25 Mhz Series 386i processor with	140 Mb hard 
	disk, floppy disk and	80387 25.0 Mhz coprocessor
PHD325	25 Mhz Series 386i processor with	320 Mb hard disk 
	and floppy disk
PHD328	25 Mhz Series 386i processor with	320 Mb hard 
	disk, floppy disk and	80387 25.0 Mhz coprocessor
80287	Series 286	5.33 Mhz coprocessor
80287	Series 286i 8 Mhz coprocessor
80287	Series 386 	10.67 Mhz coprocessor
XM002	512 Kb Memory Expansion
XM003	1 Mb Memory Expansion 
XM010	1 Mb Memory Expansion for 286i
XM020	2 Mb Memory Expansion for 286i
XM040	4 Mb Memory Expansion for 386i
Monitors, Graphics Controllers, Keyboards
VM001	12 monochrome monitor
VM002	14 monochrome monitor
VM003	14 monochrome bitmap monitor
VC001	15 color monitor
VC002	15 color monitor
B25GS1	high res gray scale monitor
B25CA1	high res color monitor
GC001	color graphics controller
GC003	monochrome graphics controller
GC004	VGA graphics controller
GC102	character alphanumeric color card
GC103	monochrome graphics card
GC104	VGA graphics card
KM001	keyboard
Floppy Disk, Hard Disk, Tape
FD001	dual floppy disk, revision B
FD0A1	dual floppy disk
HD002	10 Mb floppyhard disk, revision C
HD003	20 Mb floppyhard disk
HD006	20 Mb hard disk upgrade
HD011	32 Mb hard disk upgrade
HD020	85 MB hard disk upgrade
HD0A3	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
HSD040	40 Mb floppySCSI hard disk
HSD140	140 Mb SCSI hard disk module
HSX140	140 Mb SCSI disk expansion
HSD320	320 Mb SCSI hard disk module
HSX320	320 Mb SCSI disk expansion
HB001	quarterinch tape module
HSB002	SCSI quarterinch tape module
Processor Extensions
PC001	PC compatibility module
TM001	Voice processor (with modem)
VP002	Voice processor (without modem)
XC002	RS232 port expander
XE001	Ethernet module
{Unisys Datacomm Modules
}ID2	Intelligent Datacomm module
EN3	Ethernet module
TR2	Token Ring module
{8.2  Bit Map Video Compatibility
The GC003 and GC103 graphics controllers and the Series 286i workstation support both a high resolution monitor (VM003) and a medium resolution monitor (VM001 or VM002).}
These configurations do not have a hardware character map,  therefore characters and attributes are created by the Video Display Manager (software).  The VM003 has sufficient resolution to emulate the standard character attributes.  The VM001 or VM002, on the other hand, do not have sufficient resolution to have the same quality of emulation for the half bright attribute.
In cases where half bright is required and the default emulated half bright attribute is not acceptable, use the Config.sys character attribute options to change the default.   See the CTOS System Administator's Guide for more information.
Emulation of the blinking attribute is  not possible.  By default, characters with the blinking attribute are outlined.
Programs that obtain pointers to the character map from the Video Control Block (VCB) or via the GetPStructure call will not work on bit mapped workstations.  Such programs should be modified to replace the use of pointers to the character map by VAM calls.  VAM now provides operations that obsolete most reasons for direct character map access.

NOTE
Programs  running on bit mapped workstations require an additional 256 bytes of stack, compared to  programs running on character mapped workstations.

8.3  Series 386i Memory Configurations 
The Series 386i workstation can operate with up to 24Mb of memory.  In certain hardware configurations of the Series 386i (with more than 16Mb of memory) software configuration will be required for each program that is to run in memory above 16Mb.  This is because of an XBus feature called Mode 3 DMA.
Mode 3 DMA means that the XBus device generates DMA addresses in order to transfer data from the XBus device to processor memory.  Because the address is only 24bits wide, the XBus device can only access processor memory below 16Mb.  
Convergent supplied Mode 3 DMA devices consist of the HB001 tape backup module, the TM001VP002 Voice processor modules, and the XE001 Ethernet module.
On Series 386i workstations with up to 24Mb of memory and without any Mode 3 DMA modules connected to the XBus, all memory is usable by all software with no restrictions.
Series 386i workstations with Mode 3 DMA modules (either Convergent supplied or OEM supplied) connected to the XBus will run all software below a memory boundary established by CTOSVM.  CTOSVM calculates this memory boundary or fence by examining the XBus for specific modules and from information in the Config.Sys file.  Software may be run above the fence if it is configured to do so.  A later paragraph will explain how this is done, but a description of how CTOSVM calculates the fence follows:
 1.	CTOSVM sets the fence to 16Mb at boot time.  If a video card is installed in the 386i (a GC104 or GC103 for bit mapped video, or a GC102 for color alphanumeric video), CTOSVM drops the fence to 15Mb.  This provides a logical memory window (XBus memory window) for the video card between 15Mb and 16Mb.
 2.	For each additional XBus slave module found on the XBus (for those known to CTOSVM) or specified in Config.Sys, CTOSVM drops the fence down by an additional 1Mb.
 3.	CTOSVM then loads protected mode software from the fence (or top of available memory whichever is lower) downward.
Therefore a 386i with 16Mb or more of memory, configured with a video card and with a tape backup module connected would load all protected mode servers and application software downward from 15Mb.
Software may be run above the fence if it meets the following requirements:
 1.	The software must not have data buffers that are the direct target of an XBus Mode 3 DMA operation.  For example, the NGenQicServer (for the HB001 tape backup module) cannot be run above the fence since its buffers receive Mode 3 DMA data from the tape module.  However, clients of the NGenQicServer may run above the fence, since they receive their data from buffers (via a memory to memory move) in the server (which must run below the fence).  So, the Convergent versions of TapeRestore.run, TapeSelectiveBackup.run and TapeBackupVolume.run are all allowed to run above the fence.
 2.	The software must not be the client of a server that allows direct Mode 3 DMA data transfers to client memory.  The clients of TMServer.run (the Voice Processor module software) fall in this category and cannot be run above the fence.  These clients are the Operator,  Document Designer and CTMail (Voice versions).  Of course, if TMServer.run is not used (Voice is not used), the above client programs may be configured to run above the fence.
{
 Convergent Mode 3 Modules and 386i Memory Usage  
                                                  
 XBus Module                Can run above fence? 

 HB001 Tape Backup
	Server (NGenQicServer.run)					no
	Clients
		TapeBackupVolume.run				yes
		TapeSelectiveBackup.run				yes
		TapeRestore.run				yes
		QicErase.run				yes
		TapeCopy.run				yes

 TM001VP002 Voice Module
	Server (TMServer.run)					no
	Clients 
		Operator.run				no
		DocumentDesigner.run				no
		Mail.run				no

 XE001 Ethernet Module
	Server (ENETMedia.run)					no
	Clients
		Any CTNet Client software
		(any software using CTNet)				yes}
{
 Unisys Mode 3 Modules and 386i Memory Usage
                                                 
 XBus Module                Can run above fence?

 ID2 Intelligent Datacomm Module				
	Server	 (IMSP.run)				no
	Clients					yes

 EN3
	Server	 (IMSP.run)				no
	Clients					yes

 TR2
	Server (IMSP.run)					no
	Clients					yes}
If there is any doubt about meeting the above requirements, the software should only be run below the fence.  
CTOSVM 2.4 and later versions determine if any Mode 3 DMA modules and any XBus slave modules are connected to the XBus by two methods:
 1.	CTOSVM contains within its initialization data a list of all known Convergent modules.  The information specifies whether the module uses Mode 3 DMA or is an XBus slave.
 2.	Also, the system configuration file Config.Sys can contain information per XBus module.  For a given module, the entries:
		      :ModuleType: xx
       :XBusWindowSize: yyyK
       :Mode3DmaMaster: Yes or No
	describe the bus usage of a module.  The entry :ModuleType: defines the 16bit module identification of the module.  The entry :XbusWindowSize: defines the size of the XBus window that the module will use, and indicates also that the module is an XBus slave.  The entry :Mode3DmaMaster: indicates (if followed by yes) that the module uses Mode 3 DMA.  The default, if this entry is not used, is No.
Modules which are not known to CTOSVM must be configured using the above Config.Sys entries.  See the CTOS System Administrators Guide for information on Config.Sys usage.
Software may be configured to run above the fence by using the HighMemProtected or HighMemGdtProtected options in the Linker or Version command forms.  You may also use the Version command to check if software has been configured to operate above the fence.  See the Release Notice for Standard Software 11.311.4 for a description of these new options.
{
NOTE
If software is incorrectly configured to operate above the fence and is a target of Mode 3 DMA, the system will crash with an error 22 (Bus timeout).  Therefore you must be absolutely certain that the software conforms to the above rules before operating it above the fence.
}
8.4  GC102 character map on XBUS
The GC102 video module provides for a character map on the XBUS.  This is different from all previous charactermapped video, which contain the character map in the CPU module, because the character map is no longer at the physical address of 0F800h.  This reallocation of resources is transparent to all users EXCEPT those realmode programs that write directly to the character map to circumvent VAM.  These programs must use either ResetVideo or MapXbWindow to correctly set up the Extended Address Register (EAR).
{9.0  RESOURCE REQUIREMENTSUTILIZATION
9.1  Memory RequirementsUtilization
Convergent recommends that CTOSVM 2.4 operate on Series 286 and 386 workstations having at least 1.5 Mb of memory or Series 286i and 386i workstations having at least 2 Mb of memory.  The base memory of the 386i is actually 4 Mb which is above this minimum recommendation.}
CTOSVM 2.4 will operate in the 1 Mb base memory configuration of the Series 286, 286i, and 386 workstations.  However, this configuration is not recommended since the amount of memory available to applications is less than that made available by a real mode version of CTOS.
The table below shows the  memory utilization of  CTOSVM, the Video Display Manager, and the Debugger.
CTOSVM sizes are larger than the sizes of earlier versions of CTOS due to the addition of protected mode data structures (descriptor tables, page tables), the addition of code from the Context Manager, enhanced memory management, enhanced file system, nationalization, variable partitions, and  coprocessor support.
{The CTOSVM sizes given below are based on the default configuration provided in the default system generation prefix files.
CTOSVM
	pClstr	269K
	pClstrLfs	393K
	pStnd	380K
	pMstr	502K
	80386 Support	 30K
	Coprocessor Support	  7K
Video (bit mapped)	177K
Video (character mapped)	 34K
Debugger	 79K}
On Series 386 workstaions containing more than 1Mb of memory and on all 386i workstations, the OS size is increased by 30K.
On workstations containing math coprocessors, the OS size is increased by 7K in support of coprocessor context switching.  If the math coprocessor is not present and the Math Server is installed, the OS size is increased by 24K due to the RMOS floating point emulator.
On bit mapped systems, the Partition Status utility reports OS sizes as 23K larger and the Video size as 23K smaller.  This occurs because 23K of video data is allocated to the OS rather than the Video partition, so that the video data will be accessible from real mode programs.
On workstations containing an active Debugger, the OS size is increased by 79K.
9.2  386i Expansion Memory Utilization
Series 386i workstations with more than 16Mb of memory and with Mode 3 DMA devices connected to the XBus require special software configuration.  If you have such a configuration, you must read Section 8.3 of this document if you haven't already done so.  Convergent supplied Mode 3 DMA devices consist of the HB001 tape backup module, the TM001VP002 Voice processor modules, and the XE001 Ethernet module.
{9.3  Disk RequirementsUtilization
}CTOSVM installation requires at least 20Mb of hard disk capacity. 
Swap files for each workstation using the Context Manager are recommended to be each at least 3000 sectors long (approximately 1.5 megabytes).  Diskless workstations have their swap files located at the master workstation.
All configurations of the CTOSVM system image can be contained in 600 sectors.
Installation of the CTOSVM Build diskettes requires 3200 sectors (approximately 1.6M bytes).  
Each CTOSVM configuration you build requires approximately 1400 sectors.
Building all the standard configurations requires  approximately 6000 sectors (approximately 3M bytes), in addition to the space required for Standard Software and development tools.
CTOSVM 2.4 supports a maximum of 8 hard disk modules and 10 SCSI devices.
{10.0  RESTRICTIONS
10.1  Cluster Configurations
Clusters can consist of combinations  of IWS, AWS, Series 186, Series 286, Series 286i, Series 386, Series 386i workstations and an SRP.  Clusters that do NOT contain IWS or AWS workstations can operate at 1.8 megabits per second, whereas clusters containing IWS or AWS 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 workstation masters (except AWS and IWS), the cluster operates at 1.8 Mb only if [Sys]<Sys>Config.sys (at the master) contains the entry
  :ClusterLineSpeed: 1.8 Mbps

The absence of either this file or this entry in the file results in cluster speeds of 307Kb per second. See the CTOS System Administrator's Guide for details.

}
The CTOSVM pMstr operating system has been configured to support 32 users.  Workstation masters other than the Series 386i may not have the processing bandwidth to support this many users.  The actual number of users that can be supported with reasonable performance is dependent on the hardware configuration of the cluster workstations and the applications used within that cluster.
10.2  Memory Requirements for 80386 Features
CTOSVM supports the virtual 8086 environment for use by the PC Emulator on Series 386 workstations having more than 1 Mb of memory.  Series 386i workstations with base memory (4 Mb) also support the PC Emulator.
{10.3  132 Column VC002 with EV processors
The 132 column mode available with the Enhanced Video (EV) processors is not a supported configuration with the VC002 color video monitor, due to the low resolution of the monitor.  Programming the mode is not prevented, but it is not a supported option.}
{11.0  DOCUMENTATION UPDATES
11.1  Guide to Current Documentation 
The CTOSVM operating system manuals are now organized as follows:}
{The CTOS System Administrator's Guide, 1st Edition describes how to configure clusters, establish backup schedules, and other administrative tasks.}  It also includes descriptions of Executive commands most often used by the system administrator.  Changes made to the CTOSVM 2.2 release are reflected in Update Notice DAA116.
{The CTOSVM Concepts Manual, 1st Edition  describes the features and concepts of each subsystem in CTOS and covers CTOS 9.9 as well as CTOSVM.  Changes made to the CTOSVM 2.2 release are reflected in Update Notice DAA101.}
{The CTOSVM Reference Manual, 1st Edition revised, consisting of two volumes, contains a description of each CTOS procedure and is arranged alphabetically for quick reference.  This manual covers CTOS 9.9 as well as CTOSVM.
{The CTOS Programmer's Guide, 6th edition serves as a first reference for the programmer, covering practical rather than theoretical topics.  The 6th edition is new with the CTOSVM 2.2 and CTOS 9.9 releases.}
{The Status Codes Manual, 3rd edition contains complete listings of all status codes, bootstrap ROM error codes, and CTOS initialization errors.  Changes made to the CTOSVM 2.2 release are reflected in Supplement DAA107.}
{The Debugger Manual, 5th edition describes the system Debugger and the Debug File utility.
11.2  Nonvolatile ram support
      AccessNVRAM
DESCRIPTION
The AccessNVRAM procedure allows access to the 56 bits of nonvolatile memory in 286i and 386i processors.
The NVRAM is internal to a National Semiconductor MM58167A Real Time Clock integrated circuit.  For detailed information, see the specification for this part.
Fourteen nibbles of RAM are provided for alarm interrupt or general storage.  The nibbles are packed two per byte location except for two locations, 0 and 5.  The nibble at location 0 appears in the high order 4 bits, while the nibble at address 5 appears in the low order 4 bits.  The memory map of the RAM is as follows:
Location      D7 D6 D5 D4      D3 D2 D1 D0
   0            4 bits          No RAM
   1            4 bits          4 bits
   2            4 bits          4 bits
   3            4 bits          4 bits
   4            4 bits          4 bits
   5            No RAM          4 bits
   6            4 bits          4 bits
   7            4 bits          4 bits

Locations 6 and 7 are used by the 286i and 386i boot ROM.  Locations 0 through 5 may be used for general storage.
PROCEDURAL INTERFACE
AccessNVRAM (mode, iByte, pByteData) : ErcType
where
mode	is 0 to read a ram byte, or 1 to write a ram byte.
iByte	is the index to the byte to be read or written.  This must be from between 0 and 7 inclusive.
pByteData	is a single character buffer that contains the byte to be written or into which the byte read is placed.
REQUEST BLOCK
AccessNVRAM is an object module procedure.
{11.3  LoadRunFileDeallocRunFile procedures
      LoadRunFile
      DeallocRunFile
DESCRIPTION
These requests allow a program to load data or code using the LoadRunFile request and later deallocate this code or data using DeallocRunFile.  The DeallocRunFile request frees all selectors used to load the code or data.  Code or data blocks must be deallocated in a sequence exactly opposite the one in which they were loaded (that is, last loaded, first deallocated).}  These procedures are used by some language runtime packages for loading code segments.  The management of the code segments is the responsibility of the language runtime.
PROCEDURAL INTERFACE
LoadRunFile (fh, priority, fSuspend, pIdRet, pPDBRet, sPDBRet) : ErcType
where
fh	is the file handle of a run file that has been opened by the calling process.
priority	must be 255 which means that no process is to be created (although the code is loaded).  For loading a run file and creating a process, use the LoadTask procedure.
fSuspend	must be TRUE which means that the loaded file is not to be scheduled for execution.  For loading a run file and creating a process, use the LoadTask procedure.
pIdRet	is a pointer to a memory area into which the four byte identification data for this run file is stored.  This information must be used to do a subsequent DeallocRunFile operation.
pPDBRet	is a pointer to a memory area into which the process descriptor block will be placed.  See the CreateProcess procedural interface description in the CTOSVM Reference manual for the format of the returned data.
sPDBRet	is the size of the memory area where the process descriptor is placed.
{REQUEST BLOCK
Offset		Field	Size	Contents	Comment

	0	sCntInfo	1	6
	1	RtCode	1	0
	2	nReqPbCb	1	2
	3	nRespPbCb	1	1
	4	userNum	2
	6	exchResp	2
	8	ercRet	2
	10	rqCode	2	15eh	(350)
	12	fh	2	
	14	priority	2
	16	fSuspend	2
	18	pIdRet	4
	22	ssIdRet	2
	24	pPDBRet	4
	28	sPDBRet	2	}
PROCEDURAL INTERFACE
DeallocRunFile (Id) : ErcType
where
Id	is the four bytes of identification data for this run file obtained from the LoadRunFile operation.  
REQUEST BLOCK
Offset		Field	Size	Contents	Comment

	0	sCntInfo	1	6
	1	RtCode	1	0
	2	nReqPbCb	1	1
	3	nRespPbCb	1	0
	4	userNum	2
	6	exchResp	2
	8	ercRet	2
	10	rqCode	2	15fh	(351)
	12	Id	4	
{11.4  SetIBusHandlerResetIBusHandler procedures
      SetIBusHandler
      ResetIBusHandler}
{DESCRIPTION
The SetIBusHandler request allows the caller to register (with the CTOS IBus interrupt handler) a procedure to handleprocess data from a specific IBus device.  The ResetIBusHandler request allows the caller to do the opposite, that is, disconnect an IBus handler from a specific IBus device.}
PROCEDURAL INTERFACE
SetIBusHandler (wId, pProc) : ErcType
ResetIBusHandler (wId, pProc) : ErcType
where
wId	is the two byte IBus device identifier or 0FFxxh where xx is the device attribute byte (low byte) of the device identifier.  When 0FFxxh is used (such as 0FFB0h for the CT keyboard) then the pProc receives data from all devices with xxh as the low byte of their identifier.  In this case the upper identifier byte is a don't care byte.
pProc	is a pointer to a GDT Protected mode code segment.  Generally this code segment will be part of the server that handles the specific IBus device.  The pProc is called from interrupt level with a byte of data from the IBus device.  The handler will return a word value which determines how to interpret the next character from the IBus device.
REQUEST BLOCK
Offset		Field	Size	Contents	Comment

	0	sCntInfo	1	6
	1	RtCode	1	0
	2	nReqPbCb	1	2
	3	nRespPbCb	1	1
	4	userNum	2
	6	exchResp	2
	8	ercRet	2
	10	rqCode (see below)	2	15ch	(348)
				15dh	(349)
	12	wID	2	
	14	pProc	4

Note: Request code 348 is for SetIBusHandler, and code 349 is for ResetIBusHandler.
{The IBus device handler is called with the following arguments:
wRetCode = pProc(bIn, prgbEventCode, prgbCharCode,
                 pbEntries, pfQueue, fReset)
where
bIn	is the byte received from the IBus device.}
prgbEventCode	is a pointer to an event code buffer.  The installed IBus handler may place event codes in this array.  Each event code must have a corresponding character in rgbCharCode.  Event codes are queued for access by the ReadInputEvent request only if the fQueue flag is set TRUE.  See the Mouse Services Manual, A090112300, page 334 for a description of ReadInputEvent.
prgbCharCode	is a pointer to a character code buffer.  The installed IBus handler may place character codes in this array.  Each character code must have a corresponding event code in rgbEventCode.  Character codes are queued for access by the ReadInputEvent request only if the fQueue flag is set TRUE.
pbEntries	is a pointer to a variable into which is placed the number of event and character code pairs placed in the above buffers.  If bEntries is 0 (or if fQueue is false) then no events will be queued for access by ReadInputEvent.
fReset	is normally FALSE when the pProc is called.  If fReset is TRUE, then the IBus device responded with an identification sequence.  In this case, bIn is the device identification byte (high byte) of the identification sequence.
wRetCode	is a word which determines how the next character from the IBus device is to be interpreted.  The returned codes must be either zero or one.  Code zero is returned by the handler as a normal condition and informs the operating system to process IBus protocol normally.  A value of one can be returned by the handler to notify the operating system to call the handler on the next character even if the next character is a protocol character.
The IBus device handler will usually be part of a server designed to handle data from a specific device, such as a card reader.  In this case the handler will process the device data and may elect not to set fQueue, since applications may not be expected to access the card reader data via the ReadInputEvent request.  If the handler does elect to set fQueue (and queue events and character codes) then these events will be available to ReadInputEvent requestors.  If fQueue is TRUE and the device attribute byte indicates that the device is a keyboard, then the event is queued for access by the ReadKbd and ReadKbdDirect requests.  If fQueue is TRUE and the device attribute indicates the device is a pointing device (CT mouse attribute is 0) then the event is queued for access by the mouse server.
An IBus handler, by using the event queueing mechanism, can be used to filter IBus data to the keyboard or mouse for example.  In fact, a handler can effectively disable an IBus device by intercepting data from the device but not queueing the data (fQueue set FALSE).
11.5  User Number procedures
Note:  These procedures are intended for internal use only.  They are used by the IDMSS software.
      AllocUserNumbers
      DeallocUserNumbers
DESCRIPTION
The user number services allow a process to allocate or deallocate a block of user numbers.  
PROCEDURAL INTERFACE
AllocUserNumbers (cUserNum, pbBlockRet): ErcType
where
cUserNum	is the desired number of user numbers.
pbBlockRet	is the memory address into which a 3 word structure is returned.  The first word contains the first user number, the second word contains the last user number and the third word contains the block ID.
{REQUEST BLOCK
Offset		Field	Size	Contents	Comment
	0	sCntInfo	1	6
	1	RtCode	1	0
	2	nReqPbCb	1	0
	3	nRespPbCb	1	1
	4	userNum	2
	6	exchResp	2
	8	ercRet	2
	10	rqCode	2	308
	12	cUserNum	2	
	14	reserved	4
	18	pbBlockRet	4	
	22	cbBlockRet	2	6}
PROCEDURAL INTERFACE
DeallocUserNumbers (blockID): ErcType
where
blockID	is the block ID that was returned when the user numbers were allocated.
REQUEST BLOCK
Offset		Field	Size	Contents	Comment
	0	sCntInfo	1	6
	1	RtCode	1	0
	2	nReqPbCb	1	0
	3	nRespPbCb	1	0
	4	userNum	2
	6	exchResp	2
	8	ercRet	2
	10	rqCode	2	309
	12	blockIdD	2
	14	reserved	4
11.6  Get Serial Number procedures
DESCRIPTION
There are two procedures that return the  bootrom's 32bit unique serial number:  GetSerialNumber and GetSerialNumberOldOs.  GetSerialNumber is a new request in CTOSVM 2.4.  GetSerialNumberOldOs is an object module procedure in CTOS.LIB that can be called from programs that are executing on previous versions of CTOSVM.
{GetSerialNumber
PROCEDURAL INTERFACE
}GetSerialNumber (iProcessor, pIdRet): ErcType
where
iProcessor	currently must be 0.
pIdRet	the memory address of a 4byte area where the bootrom's 32bit unique serial number is returned. If the workstation does not have a serialized bootrom then error code 7 (not implemented) is returned.}
{REQUEST BLOCK
Offset		Field	Size	Contents	Comment
	0	sCntInfo	1	6
	1	RtCode	1	0
	2	nReqPbCb	1	0
	3	nRespPbCb	1	1
	4	userNum	2
	6	exchResp	2
	8	ercRet	2
	10	rqCode	2	391
	12	iProcessor	2	
	14	reserved	4
	18	pbSerNumRet	4	
	22	cbSerNumRet	2	4}
GetSerialNumberOldOs
DESCRIPTION
This object module procedure returns the bootrom's 32bit serial number.  It should be used instead of the request 'GetSerialNumber' in programs that will execute on pre2.4 CTOSVM.
{PROCEDURAL INTERFACE
GetSerialNumberOldOS (iProcessor, pIdRet): ErcType
where 
iProcessor	currently must be 0.
pIdRet	the memory address of a 4byte area where the bootrom's 32bit unique ID is returned.}
REQUEST BLOCK
GetSerialNumberOldOS is an object module procedure.
12.0  STATUS CODES
CTOSVM adds or updates the following status codes.  Note that some of these error codes and their definitions may have already been included in a later release of the Status Codes Manual.
279	Bad link.
13.0  KNOWN ERRORS AND OMISSIONS
CTOSVM 2.4 contains the following known errors and omissions.
A.	The GetFileStatus operation may return an incorrect null node name when case 11 is specified, the workstation is booted from the master, and the file is not on the system volume.
B.	Using the Debugger singlestep operation, CodeX, to inspect a communications interrupt routine that is based on a local descriptor table (LDT) descriptor is not supported and may cause a crash or hang of the system.  If it is necessary to singlestep through a communications interrupt handler, ensure that the program is linked so that its descriptors are allocated out of the Global Descriptor Table by setting the linker option [Runfile type] to GTDProtected.
C.	QueryFrameCharsAndAttrs will cause a GP Fault if requesting information for the entire screen.
D.	Calling WriteLog with cbRecord less than 3 may cause a GP Fault.
E.	Switching between contexts on processors that support Extended Video (i.e., Series 286EV, Series 386EV, and GC102) in which the contexts are set up in different character and line modes will cause the cursor to be displayed incorrectly.  Pressing one keystroke will cause the cursor to be displayed correctly.
F.	Using CTOSVM 2.4 and VAM 3.1, Document Designer will blank out the text characters and the objects which are created by Extended Multiplan and reverse the video display, when pressing the <SCROLLUP> key to display the objects.  The cursor is also gone.  This will be fixed in Document Designer 2.3.
G.	An application which is marked Do Not Swap in the Context Manager is allowed to swap if the application is manually started.  However, if the application is autostarted, then swapping will be disabled.
H.	If the master is rebooted, diskless cluster systems running CTOS 9.10 may not automatically reconnect.  If this happens, the cluster system must be rebooted in order to bring it back on line.
I.	If a file is opened by a cluster workstation on the master and the master is rebooted while the file is open, an erc 210 (invalid file handle) should be returned.  However there is a bug which sometimes returns an erc 45 (request block too large) instead.
