Using the sift-down effect in VTAM definition statements

The sift-down effect allows you to code an operand on a higher-level node (for example, PU is a higher-level node than LU) so that you do not need to recode it on each lower-level node for which you want the same value. Many of the operands whose values sift to lower-level nodes do not affect the higher-level nodes on which they are coded but can be coded there to take advantage of sifting.

You can override the sifted values at any point in the hierarchy of definition statements. To override the sifted values for a specific lower-level node, use either of the following methods:
  • Code the same operand with a different value on the lower-level node. The recoded value applies only to the specific node on which it is coded and all lower-level nodes. All other nodes at the same level will use the sifted value. For example, if you code a sifted value of 2 on an operand of a PU definition statement that has multiple subordinate LU definition statements and then code a value of 4 for the same operand on the third LU statement, the third LU will use the value of 4 and all other LUs subordinate to the PU will use the sifted value of 2.
  • Code the same operand with no value, followed by a comma. This causes the default value to replace the sifted value. For example, if you want to automatically logon all but one LU under a PU to application APPL1, you could code LOGAPPL=APPL1 on the PU statement and LOGAPPL=, on the one LU you do not want automatically logged on. The sifted value from the PU definition statement would apply to all LU definition statements except the one on which LOGAPPL=, is coded, whether the other LU definition statements precede or follow it.

The operands to which sifting applies are identified in the definition statement and operand table in each topic, in the column labeled "Sift Effect". For information about definition statement sequencing and the sift-down level for each NCP operand, see NCP, SSP, and EP Resource Definition Reference.

Note: For resources added through dynamic reconfiguration, sifting takes place within the hierarchy of minor nodes being added. Operand values coded in the original hierarchy do not sift down to those resources dynamically defined.