Abstract: A method is disclosed for providing added central processing power upon specific request in a processing system with an emulated processing unit, the method having further advantage by providing the additional processing power without a reboot of the operating system. The method also provides for a billing mechanism providing for increased charges for the added processing power.

Abstract: Two unique instructions for the instruction set of a target 36-bit machine which is emulated on a host 64-bit machine are provided in order to achieve visibility, to an emulated application program, of a “containing” word stored in the memory of the host machine. A “LOAD64” instruction loads the emulator memory location representing an emulated “Q” (supplementary accumulator) register with the “normal” 36-bits of the containing word. At the same time, the “upper” 28 bits of the 64-bit containing word is copied into the emulator memory location representing an emulated “A” (accumulator) register. Thus, the emulated 36-bit machine “sees” and can examine the 64-bit word in its entirety. A “Store64” instruction stores the emulated “Q” register contents into the lower 36-bits of the 64-bit containing word, and at the same time stores the lower 28 bits of the emulated “A” register contents into the upper 28 bits of the 64-bit containing word.

Abstract: Two unique instructions for the instruction set of a target 36-bit machine which is emulated on a host 64-bit machine are provided in order to achieve visibility, to an emulated application program, of a “containing” word stored in the memory of the host machine. A “LOAD64” instruction loads the emulator memory location representing an emulated “Q” (supplementary accumulator) register with the “normal” 36-bits of the containing word. At the same time, the “upper” 28 bits of the 64-bit containing word is copied into the emulator memory location representing an emulated “A” (accumulator) register. Thus, the emulated 36-bit machine “sees” and can examine the 64-bit word in its entirety. A “Store64” instruction stores the emulated “Q” register contents into the lower 36-bits of the 64-bit containing word, and at the same time stores the lower 28 bits of the emulated “A” register contents into the upper 28 bits of the 64-bit containing word.

Abstract: Two unique instructions for the instruction set of a target 36-bit machine which is emulated on a host 64-bit machine are provided in order to achieve visibility, to an emulated application program, of a “containing” word stored in the memory of the host machine. A “LOAD64” instruction loads the emulator memory location representing an emulated “Q” (supplementary accumulator) register with the “normal” 36-bits of the containing word. At the same time, the “upper” 28 bits of the 64-bit containing word is copied into the emulator memory location representing an emulated “A” (accumulator) register. Thus, the emulated 36-bit machine “sees” and can examine the 64-bit word in its entirety. A “Store64” instruction stores the emulated “Q” register contents into the lower 36-bits of the 64-bit containing word, and at the same time stores the lower 28 bits of the emulated “A” register contents into the upper 28 bits of the 64-bit containing word.

Abstract: When a fault-on-fault condition arises in a data processing system which follows a backup fault procedure in the fault handling process, control is passed to dedicated firmware. Fault flags are reset and information vital to maintaining operating system control is sent to a reserved memory (which can be written to in limited circumstances) under firmware control. Control is then transferred to an Intercept process resident in the reserved memory which attempts to build a stable environment for the operating system to dump the system memory. If possible, a dump is taken, and a normal operating system restart is carried out. If not possible, a message with the vital fault information is issued, and a full manual restart must be taken. Even in the latter case, the fault information is available to help in determining the cause of the fault-on-fault.

Abstract: A fault number is utilized by microcode fault handling to index into a fault array pointer table containing a plurality of pointers to entry descriptors describing fault handling routines. The pointer resulting from the indexing is utilized to retrieve an entry descriptor. The entry descriptor is verified and if valid, is utilized to setup the environment for the appropriate fault handling routine and to enter such. The fault array pointer table is located in a reserved memory that cannot be overwritten by I/O. During the boot process, the fault array pointer table entries, along with a fault-on-fault pointer are updated to point at entry descriptors stored in the reserved memory. Additionally, the fault-on-fault entry descriptor that rebuilds the processor environment if necessary from information in reserved memory.

Abstract: A fault number is utilized by microcode fault handling to index into a fault array pointer table containing a plurality of pointers to entry descriptors describing fault handling routines. The pointer resulting from the indexing is utilized to retrieve an entry descriptor. The entry descriptor is verified and if valid, is utilized to setup the environment for the appropriate fault handling routine and to enter such. The fault array pointer table is located in a reserved memory that cannot be overwritten by I/O. During the boot process, the fault array pointer table entries, along with a fault-on-fault pointer are updated to point at entry descriptors stored in the reserved memory. Additionally, the fault-on-fault entry descriptor that rebuilds the processor environment if necessary from information in reserved memory.

Abstract: When a fault-on-fault condition arises in a data processing system which follows a backup fault procedure in the fault handling process, control is passed to dedicated firmware. Fault flags are reset and information vital to maintaining operating system control is sent to a reserved memory (which can be written to in limited circumstances) under firmware control. Control is then transferred to an Intercept process resident in the reserved memory which attempts to build a stable environment for the operating system to dump the system memory. If possible, a dump is taken, and a normal operating system restart is carried out. If not possible, a message with the vital fault information is issued, and a full manual restart must be taken. Even in the latter case, the fault information is available to help in determining the cause of the fault-on-fault.

Abstract: In a data processing system with multiple processors, failing processors are replaced with spare processors. This allows the system to continue to operate without degradation. An intercept process is notified of a processor failure so that it can collect processor registers and states. If the registers and states are collected correctly, an indication is set that relief is possible. The intercept process notifies a service processor of the failure and then halts the failed processor. The service processor then notifies the operating system of the failure and that relief is possible. If fast relief is acceptable, a spare processor is initialized and resumes execution with the state and registers of the failed processor. A service processor modeling file controls the number of active and spare processors in a system. Spare processors sharing the same L2 cache with the failed processor are preferred as replacements.

Abstract: A fault number is utilized by microcode fault handling to index into a fault array pointer table containing a plurality of pointers to entry descriptors describing fault handling routines. The pointer resulting from the indexing is utilized to retrieve an entry descriptor. The entry descriptor is verified and if valid, is utilized to setup the environment for the appropriate fault handling routine and to enter such. The fault array pointer table is located in a reserved memory that cannot be overwritten by I/O. During the boot process, the fault array pointer table entries, along with a fault-on-fault pointer are updated to point at entry descriptors stored in the reserved memory. Additionally, the fault-on-fault entry descriptor that rebuilds the processor environment if necessary from information in reserved memory.

Abstract: A fault number is utilized by microcode fault handling to index into a fault array pointer table containing a plurality of pointers to entry descriptors describing fault handling routines. The pointer resulting from the indexing is utilized to retrieve an entry descriptor. The entry descriptor is verified and if valid, is utilized to setup the environment for the appropriate fault handling routine and to enter such. The fault array pointer table is located in a reserved memory that cannot be overwritten by I/O. During the boot process, the fault array pointer table entries, along with a fault-on-fault pointer are updated to point at entry descriptors stored in the reserved memory. Additionally, the fault-on-fault entry descriptor that rebuilds the processor environment if necessary from information in reserved memory.

Abstract: A fault handling process in a computer system subject to CPU design errors and functioning under an operating system (OS) having an integral fault handling module includes the steps of: setting an intercept flag when a central processor fault occurs if the fault is to be directed to a preprocessor; establishing a safestore frame which includes information identifying the type of fault and whether the intercept flag is set; and transferring control to the OS fault handling module; then in the OS fault handling module, determining whether the intercept flag is set; if the intercept flag is not set, handling the fault in the OS fault module; if the intercept flag is set, transferring control from the OS fault module to an Intercept Process written in machine language; and handling the fault in the Intercept Process.