IEAFP allows you to request that, for your work unit, the system will stop saving additional floating point status. This status consists of the additional floating point registers (FPRs) 1, 3, 5, 7-15 and the floating point control (FPC) register. In addition, the system will stop saving vector register status.
You would typically use this service only when you are a server task which "subdispatches" unrelated units of work (that is, CICS transactions). To avoid subsequent units of work being penalized by the floating point actions of previous units of work, the additional FP status saving function of the operating system can be turned off. When a unit of work actually begins to use FP, all appropriate status saving will be resumed.
IEAFP allows you to request that the system stop saving vector register status, while continuing to save additional floating point status.
The requirements for the caller are:
Environmental factor | Requirement |
---|---|
Minimum authorization: | Problem state and PSW key 8-15 |
Dispatchable unit mode: | Task or SRB |
Cross memory mode: | Any PASN, any HASN, any SASN |
AMODE: | 31-bit |
ASC mode: | Primary or access register (AR) |
Interrupt status: | Enabled or disabled for I/O and external interrupts |
Locks: | The caller is not required to hold any locks on entry. The caller may hold the local, CMS, or CPU lock. |
Control parameters: | None |
The caller can include the IHAFPRET mapping macro to get equate symbols for the return and reason codes provided by the IEAFP macro.
IEAFP must not be issued from an asynchronous exit routine.
Before issuing the IEAFP macro, the caller does not have to place any information into any general purpose register (GPR) or access register (AR) unless using it in register notation for a particular parameter, or using it as a base register.
Some callers depend on register contents remaining the same before and after issuing a service. If the system changes the contents of registers on which the caller depends, the caller must save them before issuing the service, and restore them after the system returns control.
None.
The IEAFP macro is written as follows:
Syntax | Description |
---|---|
name | name: symbol. Begin name in column 1. |
␣ | One or more blanks must precede IEAFP. |
IEAFP | |
␣ | One or more blanks must follow IEAFP. |
STOP | |
STOPVECTOR | |
,RETCODE=retcode | retcode: RS-type address or register (2) - (12). |
,RSNCODE=rsncode | rsncode: RS-type address or register (2) - (12). |
The parameters are explained as follows:
To code: Specify the RS-type address of a fullword field, or register (2)-(12).
To code: Specify the RS-type address of a fullword field, or register (2)-(12).
None.
Macro IHAFPRET provides equate symbols for the return and reason codes.
The following table identifies the hexadecimal return and reason codes and the equate symbol associated with each reason code. IBM support personnel may request the entire reason code, including the xxxx value.
Return code | Reason code | Equate symbol, meaning, and action |
---|---|---|
0 | — | Equate symbol: IeafpRc_OK Meaning: IEAFP request successful. Action: None required. |
8 | — | Equate symbol: IeafpRc_InvParm Meaning: IEAFP request specifies parmeters that are not valid. Action: Refer to the action provided with the specific reason code. |
8 | xxxx0801 | Equate symbol: IeafpRsnBadFunction Meaning: Incorrect value passed to target routine. Action: Check for possible storage overlay. |
C | — | Equate symbol: IeafpRc_Env Meaning: Environmental error Action: Refer to the action provided with the specific reason code. |
C | xxxx0C01 | Equate symbol: IeafpRsnFromAsynchExit Meaning: IEAFP was issued from an asynchronous exit routine. Action: Avoid issuing IEAFP from an asynchronous exit routine. |
IEAFP STOP