Gnosis, as described in this manual, is designed for the IBM 370. Gnosis is designed to solve the security, sharing, pricing, reliability and extensibility requirements of a commercial computer service.
The Gnosis kernel circumscribes and completely defines the things that all other programs that run on the 370 can do. IBM would call the kernel a System Control Program {SCP}. The Gnosis kernel allows complete access to the non-privileged instructions but completely controls the main storage and I/O devices. With these facilities, the kernel provides 4096-byte pages that are kept in main storage when they have been recently used, and on disk otherwise.
It is possible to install programs in Gnosis that cooperate with other programs in a variety of senses. This cooperation can range from complete trust to mutual mistrust. Examples of the latter are still uncommon partly because current operating systems are insufficiently discriminating to allow the desired interactions while preventing the undesired ones.
“It must be remembered that there is nothing more difficult to plan, more doubtful of success, or more dangerous to manage, than the creation of a new system.
For the initiator has the enmity of all who would profit by the preservation of the old institutions and merely lukewarm defenders in those who would gain by the new ones.”
Machiavelli “The Prince”
Some branches in this manual are marked with keywords. The keywords used are:
{nonref} means the branch has no reference information.
{security} means the information is primarily security-related.
{ni} means the facility is not implemented at this time.
{spec} describes ideas and speculations.
{obsolete} describes facilities that have been superseded and whose use we discourage.
{a date} means the information applies only to releases after the given date.
{arcane}See (printmanual,) for details concerning the production of this manual in hard copy.
Origin of Authority
Keys to an object will typically produce, on command, a key of less authority {weaker} to the same object.
{kernel}A Bottom-up View of Gnosis
{kernel}The First Few Functional Layers in Gnosis
This section contains the statements that can be made about all keys at all levels of description.
Meters, Resources and Charge Sets
The Memory Tree and Virtual Addresses, or How a Program Accesses Data
Generally Available Primary Functions
Meter Keys
Initially charge set keys will be held only by the scheduler.
UNSPEC {Obsolete, to be deimplemented}
1 - Key was already unprepared
2 - Key was a hook key and can't be unprepared
3 - Domain holding key could not be unprepared
4 - Domain keys node key not a node key (domain malformed)
KDIAG(2;NODE_KEY==>c;) Unprepare a node.\
1 - Key not prepared.
2 - Not a node key.
3 - Node could not be unprepared.
DIAG4C(kt;==>X'0EFE';)
See (diag4c-access) for access to this key.
Objects to Organize and Store Data and Keys
Two Ready-made Segment Keepers
File Transfer Mechanisms Between Hosts
Primitive Command System Factory
A factory for user environments
Small Integer Allocator Factory {SIAF}
Weakener(kt; ==> X'100D';)
METCTL can be thought of as the simplest political scheduler, or a tool of a political scheduler.
METCTLC can be found in PUB just now.
Formal Description .Text[Hdr]=“Formal Description”;
Using It Today .Text[Hdr]=“Using It Today”;
See (p3,osiorestrict) for further hints about file support.
The OS simulator supports programs which believe they are running on a system which is a derivative of OS/360. The programs may have originally been written for the OS environment, or may have been designed specifically for use under Gnosis but compiled by a “higher” level language processor such as the PL/I Optimizer, FORTRAN H extended, or COBOL. Gnosis does not require {nor support} customized versions of such language processors. Consequently the IBM versions {which think they are producing output to run in OS} are used, and it becomes necessary to simulate the OS environment to the extent necessary to run those programs.
OS I/O simulation routines allow programs written for use with IBM's BSAM, BDAM, QSAM, and ISAM access methods to access data in Gnosis Record Collections (p2,rcc) or standard co-routines without modification. The simulation routines allow great interchangeability of data between programs. OS programs may use any access method {which has meaning} to access any Gnosis data. The simulation routines automatically convert Gnosis data to whatever format the OS program expects.
Nearly all of the power of all of the OS access methods may be exercised for data stored in record collections. However, since co-routines are by their nature a unidirectional string of data, only sequential operations may be supported for data stored in co-routines.
The OS simulation is provided by installing an OS simulator as the domain keeper for any domain which contains programs designed to run under OS. The simulator is invoked by Gnosis whenever the program executes a supervisor call {SVC} instruction, and whenever the program gets a program or timer interrupt. If the program executes an unsupported SVC, or fails {traps} in some way not understood by the simulator, the program domains apparent domain keeper is called. For all practical purposes, the fact that the OS simulator is a domain keeper is transparent to both the program and its programmer.
The OS simulator is designed on the assumption that it is the only holder of a domain key to the domain executing the OS program. It provides a synthetic domain key, however, that may be used by debugging programs such as DDT. This key may be used {seemingly} to install the debugger as the domain keeper. Such programs may be surprised that certain interrupts appear not to occur. This is because they were handled by OSSIM instead.
See (p2,osfactories) for the source of environments such as this and about additional functionality.