Global Signon Defaults
The IBM® Connect:Direct® administrator can define global signon defaults so that users do not have to individually alter their signon default values to increase their allocation. By implementing a global signon default, you can avoid insufficient space being allocated for the temporary data set upon signon as well as SB37 ABENDs.
A temporary data set (TEMP DSN) is allocated at SIGNON to the IUI, which uses the system default allocation parameters. At times, this allocation is insufficient causing SB37 failures if a large amount of data is returned for a command request. The facilities available via SIGNON defaults (SD) are not global and each individual user must alter their default values to increase the allocation.
To change the default values, use member DGAXCXDF from $CD.SDGASAMP to assemble and link module DGAXCXDF with the new values for TEMP DSN. You can edit and submit $CD.SDGAJCL member DGAJCXDF to do the assembly and link edit. Once the module is assembled and linked, all user who sign on via an API will be subject to the new default global signon settings.
After you implement global signon defaults, allocation parameters during SIGNON can come from the following three sources, which are listed from lowest to highest precedence:
- Defaults from macro DGA$UICB specified by programs such as DGADBATC, DGADCHLA, and DGADCMDP. This is considered a legacy source of SIGNON allocation parameters.
- The SIGNON command, whose parameters come from wherever the invoker of the command decides, for example, the IUI can save SIGNON parameters in a user's ISPF profile dataset. Like the DGA$UICB macro, this is considered a legacy source of SIGNON allocation parameters.
- The DGAXCXDF load module, which the administrator can control.
DGA$XDEF Syntax and Parameters
$CD.SDGASAMP member DGAXCXDF consists of one statement, the macro DGA$XDEF, in $CD.SDGAMAC and should not be changed. To modify the DGAXCXDF member, first copy it and then alter it to suit your installation's requirements.
The following shows the DGA$XDEF syntax and defaults:
|
The following table lists the parameters that make up the DGA$XDEF load module:
Parameter | Description |
---|---|
OVERRIDE | Specifies when a legacy source can override the
global signon defaults assigned by the DGA$XDEF load module. If not
specified, defaults to ALLOW (a null value is invalid). Values are:
|
ALOCTYPE | Specifies the allocation type. If not specified, defaults to space allocation by cylinder–CYL (a null value is invalid). |
ALOCPRI | Specifies the primary allocation of storage. If not specified, defaults to a o1. |
ALOCSEC | Specifies the secondary allocation of storage. If not specified, defaults to a o1. |
ALOCUNIT | Specifies the unit type of the TEMP DSN. If not specified, has no default. |
ALOCVOL | Specifies volume serial number of the TEMP DSN. If not specified, has no default. |
The other DGA$XDEF macro parameters are converted into the well known JCL space parameters. All DGA$XDEF macro parameters other than OVERRIDE are converted into the JCL SPACE parameters and can take any valid value that can be specified in JCL. The one exception is that the ALOCTYPE parameter supports only TRK (Track) and CYL (Cylinder).
ISPF Messages Displayed During Signon
If the DGAXCXDF load module was successfully located at IUI SIGNON, new ISPF messages are displayed upon entry to the IUI Signon Defaults (SD) panel. (If DGAXCXDF was not present at IUI SIGNON, no ISPF message is displayed.) Both the short and long message components are generated. The exact text of the ISPF messages is based on:
- Settings in the DGAXCXDF load module,at the time of SIGNON
- The user's ISPF profile variables for the temporary data set
The user will see one of the following ISPF short messages, which states what the DGAXCXDF OVERRIDE setting was when they signed on:
- OVERRIDE=DISALLOW
- OVERRIDE=ALLOW
- OVERRIDE=ALLOWGT
- OVERRIDE=ALLOWLT
The ISPF long message component provides the following information:
- The values for the current temporary data set allocation
- An explanation of where the values came from and why
The following is an example of a typical ISPF long message example:
|