SCACP$HELP.HLB  —  SET  VC  Qualifiers

1    /CHECKSUMMING

       /CHECKSUMMING
       /NOCHECKSUMMING

    Enables or disables checksum verification on the selected VCs to
    the specified nodes.

    You can use this command alone or in combination with the system
    parameter NISCS_PORT_SERV. (For more information, see online help
    for NISCS_PORT_SERV.)

    Note that the the SET VC/CHECKSUMMING setting is not valid beyond
    the life of the system. Therefore, you might want to include SET
    VC/CHECKSUMMING commands in your startup file, or reissue these
    commands at the next boot.

2    /COMPRESSION

       /COMPRESSION
       /NOCOMPRESSION

    Enables or disables sending compressed data by the specified VCs.
    The default is /NOCOMPRESSION.

    Usage notes:

    o  Compression is used only if the partner node has a PEdriver
       version that supports it.

    o  You can also enable the use of compression with the NISCS_
       PORT_SERV system parameter. For more information about NISCS_
       PORT_SERV, see the System Parameter appendix in this manual.

    o  The /NOCOMPRESSION qualifier does not override compression
       enabled by setting bit 2 of NISCS_PORT_SERV.

3    /ECS_MAX_DELAY

       /ECS_MAX_DELAY=n
       /NOECS_MAX_DELAY

    Sets a management-specified lower bound on the maximum delay (in
    microseconds) an ECS member channel can have. The value for n can
    be any value between 0 and 3000000. /NOECS_MAX_DELAY disables a
    prior management delay setting.

    You can use this command to override the PEdriver automatically
    calculated delay thresholds to ensure that all channels with
    delays less than the value supplied for n are included in the
    VC's ECS.

    The command operates as follows: Whenever at least one tight peer
    channel has a delay of less than the management-supplied value,
    all tight peer channels with delays less than the management-
    supplied value are automatically included in the ECS. When all
    tight peer channels have delays equal to or greater than the
    management setting, the ECS membership delay thresholds are
    automatically calculated and used. The /NOECS_MAX_DELAY qualifier
    disables management control by setting the management delay value
    to zero.

    You must determine an appropriate value for your configuration by
    experimentation. An initial value of 2000 (2 ms) to 5000 (5 ms)
    is suggested.

                                 CAUTION

       By overriding the automatic delay calculations, you
       can include a channel in the ECS whose average delay is
       consistently greater than 1.5 to 2 times the average delay
       of the fastest channels. When this occurs, the overall
       VC throughput becomes the speed of the slowest ECS member
       channel.

       An extreme example is when the management delay permits a
       10 Mb/s Ethernet channel to be included with multiple 1 Gb/s
       channels. The resultant VC throughput drops to 10 Mb/s.

    Note that the SET VC/ECS_MAX_DELAY setting is not valid beyond
    the life of the system. Therefore, you might want to include SET
    VC/ECS_MAX_DELAY commands in your startup file or reissue these
    commands at the next boot.

4    /EXCLUDE

       /EXCLUDE=(nodename[,...])

    Excludes VCs to specific nodes, which you can use wildcards to
    specify.

5    /WINDOW

       /WINDOW=RECEIVE=n
       /WINDOW=NORECEIVE

    Sets a management-specified upper bound on the receive window
    size (that is, the number of out-of-order packets this VC holds
    in its resequencing cache while awaiting the next in-order packet
    or packets).

    You can use this qualifier to override the automatically
    calculated receive window size. This ensures that the VC has
    enough buffering to receive the expected maximum number of out-
    of-order packets.

    Usage notes:

    o  The window size value n must be an exact power of 2.

       Never use settings that cause the receive window of a VC to
       be smaller than the transmit window of the partner node.
       Otherwise, the partner can send packets that cannot be
       cached when a packet is lost. This results in unnecessary
       retransmissions, and might cause channels not to be used
       because they become "lossy." This leads to the remaining
       restrictions listed.

    o  Always decrease the receive window size of a VC's partner node
       before decreasing a VC's receive window size.

       VSI recommends using SYSMAN to decrease both the local and the
       remote VC transmit window sizes before increasing the local
       and remote receive window sizes (as shown in the example).

    o  Always increase the receive window size of a VC's partner node
       before increasing a VC's transmit window size.

       VSI recommends using SYSMAN to increase both the local and the
       remote VC receive window sizes before increasing the local and
       remote transmit window sizes.

    o  Whenever you enter the SET VC/WINDOW=RECEIVE command, the
       following sequence of events occurs:

       1. The VC's current resequencing cache is emptied.

       2. The VC partner node automatically retransmits any discarded
          packets.

       3. As a result of 2, the VC and channel retransmit counts
          increase.

       4. A few messages similar to the following might be displayed,
          indicating that one or more channels has temporarily become
          "lossy":

              %PEA0, Excessive packet losses on LAN Path from EWA to EWC
                     on REMOTE NODE STAR

       5. The partner node recovers automatically within a few
          seconds.

    o  You can use the SCACP> CALCULATE WINDOW_SIZE command to assist
       you in selecting the size to use for transmit and receive
       windows.

6    /WINDOW

       /WINDOW=TRANSMIT=n
       /WINDOW=NOTRANSMIT

    Sets a management-specified upper bound on the transmit window
    size (that is, the number of out-of-order packets this VC sends
    while awaiting acknowledgment of the transmitted packets) to n.
    The /WINDOW=NOTRANSMIT qualifier resumes automatic control of the
    window size and changes the management transmit window size to
    zero.

    You can use the /WINDOW=TRANSMIT qualifier to override the
    automatically calculated transmit window size to ensure that the
    VC has enough buffering to receive the expected maximum number of
    out-of-order packets.

    Usage notes:

    o  The window size value n must be an exact power of 2.

       Never use settings that cause the receive window of a VC to
       be smaller than the transmit window of the partner node.
       Otherwise, the partner can send packets that cannot be
       cached when a packet is lost. This results in unnecessary
       retransmissions, and might cause channels not to be used
       because they become "lossy". This leads to the following
       restrictions.

    o  Always decrease the transmit window size of a VC's partner
       node before decreasing a VC's receive window size.

       VSI recommends using SYSMAN to decrease both the local and the
       remote VC transmit window sizes before increasing the local
       and remote receive window sizes.

    o  Always increase the receive window size of a VC's partner node
       before increasing a VC's transmit window size.

       VSI recommends using SYSMAN to increase both the local and the
       remote VC receive window sizes before increasing the local and
       remote transmit window sizes (as shown in the example).

    o  You can use the SCACP CALCULATE WINDOW_SIZE command to assist
       you in selecting the size to be used for transmit and receive
       windows.
Close Help