|
|
United States-English | |
|
|
 |
|
ACC Utilities Reference Guide > Chapter 2 TTGEN - ZCOM System Table Generator
Creating the TTGEN Configuration File |
|
|
The TTGEN configuration file is an ASCII text file that describes the size and configuration information of a ZCOM system. TTGEN compiles this file and generates a corresponding binary “memory image file,” which will be used by ZMON to initialize and start up the run-time ZCOM sub-system with the specified configuration. The first statement in the configuration file (aside from compiler directives {#include or #define} or C-style comments) must be the string “TTGEN” (without the quotation marks). This may be followed by a list of options; see “Running TTGEN” for the various options available. The configuration file is organized into sections; each section having its own section header and subparameters. The section headers are indicative of the information required to configure the ZCOM sub-system. The headers are case-insensitive and are as follows: TTGEN (TTGEN file control line) The sections must occur in the order as given above. Text enclosed with a slash-asterisk (/*) and asterisk-slash (*/), or lines commencing with a semi-colon (;) or an asterisk (*), are treated as comments and ignored. The tilde character (~) at the end of a line is used as a continuation character, indicating that the next line is a continuation of this line. The lines may be in free format - the number of spaces between each parameter is variable. Fields are separated by tabs, spaces, comma (,), or colon (:). Multiple tabs or spaces collapse to one (this is not true for commas and colons). Strings are quoted by single quote (') or double quote ("). Numeric fields may be in the following formats:
This line must precede all the other configuration and definition sections. It is to indicate that the source file is for TTGEN. TTGEN will complain if this line is missing. There is no configuration information that goes with this section. Comments or “#include” statements may appear before this line. For example: #include "TTGENdefine"
The Configuration section is used to define the global parameters for the ZCOM message system. Some of these parameters have default values that will be used if the parameter is not specified. However, it is recommended that all values are entered, since the default values will not be optimal for every configuration. Note that throughout this chapter, the term “Terminal ZLU” is used to refer to a physical or logical entity, not necessarily an actual physical terminal device. For example, a terminal ZLU might refer to a physical entity such as a HDLC/LAP-B link or a terminal. A terminal ZLU could also refer to a logical entity such as a Virtual Circuit or “loopback protocol” module. Configuration System-name "<name>" ASCII name which describes this instance of the run-time ZCOM sub-system. Maximum of 79 characters. (Include the double quotes in the configuration file, as shown above.) Number of spare program ZLUs to be allocated. Program ZLUs are only associated with programs and drivers that use the ZCOM API. Each program uses at least one program ZLU. The default number of spare program ZLUs is 256. The valid range of values is 1...10000 (ZCOM_MAXPZLU in /opt/acc/include/zcom/zcomsys.h). The maximum number of terminal ZLUs that may be defined in this system. This number must be as big as the largest terminal number defined in the terminal definition section of the TTGEN configuration file. While the Terminal-ZLU parameter value may exceed the number of terminal ZLUs defined in the terminal definition section, note that each terminal ZLU is allocated 40 bytes of space even if it does not have a terminal assigned to it. It is useful to allow gaps in the ZLU numbers to allow for expansion. This avoids having to reallocate the existing ZLU numbers. In addition, dynamically allocated terminal ZLUs are taken from unused terminal entries. The valid range of values is 1...65535 (ZCOM_MAXTZLU in /opt/acc/include/zcom/zcomsys.h). Total number of logical terminal tables in this configuration. While this value may be greater than the number of logical terminals configured - to allow for programmatic additions while the system is running - it must not be less than the number of physical terminals which are connected to the system. In most configurations, the Logical-Term and Physical-Term parameters are set to the same value. This value must not be greater than the number defined in Terminal-ZLU. The valid range of values is 1...65535 (ZCOM_MAXLTERM in /opt/acc/include/zcom/zcomsys.h). Total number of physical terminal tables in this configuration. While this value may be greater than the number of physical terminals configured - to allow for programmatic additions while the system is running - it must not be less than the number of physical terminals which are connected to the system. This value must not be greater than the number defined in Logical-Term. The valid range of values is 1...65535 (ZCOM_MAXPTERM in /opt/acc/include/zcom/zcomsys.h). Total number of node entries in this configuration. Each “Local-Node” and “Remote-Node” definition
in the Node-Definition section
requires one node entry. This value may be greater than the number
of nodes defined. The unused entries may be used to dynamically
create a node definition using the Dynamic System Configuration
services (currently not supported). The valid range of values is
1...20 (ZCOM_MAXNODE in Total number of interface tables in this configuration. Each entry in the “Interface-Definition” section uses one interface table. The interface tables are numbered from 0, hence this value must be at least one greater than the number of ACC card statements in Interface-Definition section. That is, it must be larger than the largest interface card number defined. You may want to specify a larger value to allow for programmatic additions while the system is running (using the Dynamic System Configuration functions). The valid range of values is 1...64 (ZCOM_MAXIFT in /opt/acc/include/zcom/zcomsys.h). Block of memory (free buffer area), from which all buffers are allocated to the ZCOM sub-system. The range of valid values is 1024...2147483645 (0x7FFFFFF, ZCOM_MAXBPOOL in /opt/acc/include/zcom/zcomsys.h). Default is 3 Mbytes. Must be a multiple of 4. The kernel memory plus the ZCOM memory size cannot exceed available physical memory. The recommended minimum is 200 Kbyte (e.g., for a small test environment). The buffer pool plus the size of the ZCOM tables should not exceed the amount of memory gen'd into the kernel for the ZCOM subsystem (controlled through the zcom_mem_size parameter in the system file). For a production environment, use the following method to estimate the required Buffer-Pool size: BUFFER-POOL size = <Card> x <Rate> x <Time> x (<Length> + 200) x 1.5
200 is the memory overhead per message (in bytes). 1.5 is the scaling factor to allow for usable gaps in buffer pool Example: For a 100% busy system with 8 mux cards with 57.6k links, and an average message length of 100 bytes, the Buffer-Pool size should be at least: 8 x 576 x 5 x (100 + 200) x 1.5 = 10 Mbytes The size in bytes of an LTT extension area. An extension area can be associated with a logical terminal table (LTT). The extension area, if present, would appear at the end of the LTT (hence, the total LTT size would be "size of system data" (ZCOM area and user-maintainable area) plus "size of extension area". Currently, LTT system data (ZCOM area and user-maintainable area) is 400 bytes). Only one Logical-Size value can be defined in your TTGEN configuration file. Thus, there is only one extension-area size for all LTTs. This also means that if you define a Logical-Size, then every LTT will have an extension area. Logical-Size defaults to 0 (i.e., no extension). Define any value as needed (or just leave it out for a default of zero, i.e., no extension). The valid range of values is 0 or 8...2048 (ZCOM_MAXLSIZE in /opt/acc/include/zcom/zcomsys.h), and the value must be a multiple of 8. This parameter enables application programs to reserve some of the spare data area (of the terminal information) for a group of terminals. It is defined according to the application number (as set up in the TERM or LTERM parameters). There may be up to 20 Logical-Data statements. Note that Logical-Size must be defined first. The following information is required if this parameter is specified: Logical-Data <appln> <label> <offset> <size>
The default maximum number of messages that can be queued on a program ZLU if the limit is not specified in the zopen call. This parameter is used to prevent defects in applications that use the ZCOM API from consuming all of the available memory in the buffer pool. Specifically, for ZCOM applications that fail to read messages from their program ZLU queue. The valid range of values is 1...2147483647 (0x7FFFFFF, ZCOM_MAXQLIM). It defaults to 2147483647 (ZCOM_MAXQLIM). The maximum number of transmit messages for each physical terminal table (terminal ZLU). This parameter is used to prevent poorly designed ZCOM application programs from consuming all of memory in the buffer pool when sending data to a terminal ZLU. (The valid range of values is 1...2147483647 (0x7FFFFFF, ZCOM_MAXQLIM). Defaults to 2147483647 (ZCOM_MAXQLIM). Note that when this number of messages is reached on a terminal transmit queue and another zsend is attempted, ZCOM returns error code ZELIMIT (-51). The maximum number of bytes in the unacknowledged queue for each terminal. The data on this queue is also resident in the buffers on the interface card, where buffer space is limited. This parameter avoids swamping the transmit buffers on the interface card with data for only a few (or perhaps one) terminals. That is, this parameter is used to insure that each terminal ZLU gets its fair share of the link transmit bandwidth. The valid range of values is 1...2147483647 (0x7FFFFFF, ZCOM_MAXQLIM). Defaults to 2147483647 (ZCOM_MAXQLIM). The recommended value is 5,000 bytes or less. This limit applies to ACC cards other than the E1/T1 ACC cards and the Z7340A 8-port PCI ACC card. ACC E1/T1 cards and the Z7340A ACC have their own port-limit value, mentioned in the E1T1-Port-Limit section further down. The default limit (in bytes) of all unacknowledged transmit messages to terminals on a port. This parameter controls how much outbound data is allowed onto the ACC card for each port. Each port has 24,000 bytes of memory available for outbound data buffers (including protocol packets). This parameter is used to prevent the host from exceeding the available memory on the card, thereby causing the host to retry the transaction. This parameter applies to all non-E1/T1 ports on the system. The recommended value is 20,000 bytes. It must be less than 24,000 bytes. Note that you may override this global value on a port-by-port basis by using the Port-Limit parameter in the Port-Definition section. This limit applies to E1/T1 ACC cards and the Z7340A 8-port PCI ACC card. The default limit (in bytes) of all unacknowledged transmit messages to terminals on a subchannel of a port on an ACC E1/T1 card, or a port of the Z7340A 8-port PCI ACC card. This parameter is identical in function to the Port-Limit parameter mentioned previously; however, this parameter only applies to the ACC E1/T1 card and the Z7340A 8-port PCI ACC card. The recommended value is 100K bytes. The recommended value assumes many subchannels per port. Note that you may override this global value on a port-by-port basis by using the Port-Limit parameter in the Port-Definition section. If your configuration uses just a few subchannels on a port, you should use the Port-Limit parameter in the Port-Definition section to increase the limit for that particular port only. The Interface-Definition section is used to specify the ACC cards to be included in the system. For each interface defined, ttgen reserves an interface table, which contains all required information for controlling the hardware. The Interface-Definition section takes either one of the two forms shown, where the second form refers to HP 9000 Series K systems. Interface-Definition The valid subheadings for the Interface-Definition <card_type> section are:
Each ACC card must be defined here as a separate record, commencing with one of the listed valid subheaders. The other entries after the subheading are as follows: An interface number (nn), which must be sequential, precedes the bus and slot numbers. There is a maximum of 64 interfaces on the system (from 0 to 63). The bus and slot numbers define the physical location of the interface card in the computer. The method of determining the addressing information that is used for the bus and slot fields is to use ioscan, after the hardware is installed in the system. To find the address information for all of the ACC cards on a system, run: ioscan -f | grep -i ACC For these systems, there is no bus converter: The bus value is 0. The address returned by ioscan will be a card address. For example, if the ioscan reported that the first ACC card on the system is at card address 4, and the second is at card address 12, the corresponding ttgen Interface-Definition statements would be: <card_type> 0 0:4 /opt/acc/<card-type>/x25.zabs For these systems, the address information returned from ioscan is in the format of BB/CC, where BB is the bus converter address and CC is the card address. For example, if the ioscan returns that the first ACC card on the system is at card address 4, and a second card is at 12, the corresponding ttgen Interface-Definition statements would be: <card_type> 0 2:8 /opt/acc/<card-type>/x25.zabs For these systems, the address information returned from ioscan is in the format of BB/BB/CC, where BB/BB is the bus converter address and CC is the card address. For example, if the ioscan returns that the first ACC card on the system is at slot location 1, bus address 8/0/1.0, and a second card is at slot location 3, bus address 8/0/3.0, the corresponding ttgen Interface-Definition statements would be: <card_type> 0 8:0:1 /opt/acc/<card-type>/x25.zabs For these systems, the address information returned from ioscan is in the format of BB/BB/CC, where BB/BB is the bus converter address and CC is the card address. For example, if the ioscan returns that the first ACC card on the system is at location 10/16/8, and a second card is at 10/4/4, the corresponding ttgen Interface-Definition statements would be: <card_type> 0 10:16:8 /opt/acc/<card-type>/x25.zabs For these systems, the address information returned from ioscan can vary in length. The only significant value is the slot number. Any values preceding the slot number should be ignored. For example, if the ioscan returns that an EISA ACC card on the system is at either location 4/0/2, or location 10/20/5/2, the corresponding ttgen Interface-Definition statement would be: Z7400A 0 0:2 /opt/acc/<card-type>/x25.zabs The parameters listed below may be specified immediately after a 4-channel E1/T1 or 8-channel PCI serial interface card <card-type> definition, on the following line or lines, in any order. Their purpose is to allow some flexibility in the allocation of memory and resources on the ACC card. The total memory available on this card is 16M-bytes. These parameters allow you to fine tune how this memory is divided up between internal tables and I/O buffers. Any of these parameters may be omitted, in which case defaults are applied, which should be sufficient for most applications. The use of defaults for these parameters is recommended.
In order to modify these parameters it is necessary to first know what the current defaults are. This can be achieved on a running system by using the "zscan" utility. The "it" command displays the values of these parameters for a given ACC card number. For example % zscan> it 0 will show information about ACC card 0. The following parameters may be specified if the user wishes to modify the usage of available table space.
The number of terminal tables in use on an ACC card roughly corresponds to the number of Physical Terminal Tables defined and dynamically created for the card. If, for example, there were many unused terminal tables, then the space could be better utilized for I/O buffers instead. The default value of this parameter is ACC card type dependent.
The firmware on the E1/T1 and 8-channel PCI cards use fixed sized I/O buffers to hold inbound and outbound data messages and protocol packets. If a data message is larger than the buffer size, multiple buffers are allocated to hold the message. The buffer size may be increased or decreased to allow for the most common expected message size. If the buffer size is too small then messages are fragmented by the firmware, increasing ACC CPU overhead. If the buffer size is too large then buffer space is being wasted by short messages. The size of the internal header/trailer of the buffer us 16 bytes. Protocol headers are in addition to this. The default buffer size is 160 bytes.
The maximum number of buffers available on the card. The size of each buffer is determined by the zbufsize parameter. The default is ACC card type dependent. For the Z7340A 8-channel PCI ACC, this parameter should not be specified, as it will default to using all remaining free memory for ACC buffers.
Determines the maximum number of messages and (depending on the protocol in use) packets which can be simultaneously handled by the ACC card. The default value of this parameter is ACC card type dependent.
There is one pool of message headers on the ACC E1/T1 and 8-channel PCI cards. This parameter limits the number of message headers which can be used by any one subchannel (E1/T1) or port (Z7340A card) at any given moment. This parameter is used to prevent one subchannel or port from monopolizing this critical card resource. The default value for this parameter is ACC card dependent. A low value for mquota will severely restrict normal operation of the ACC card. Values of mquota below 1,000 should not be specified.
There is one pool of buffers on the ACC card and this parameter limits the number which can be used by any one subchannel at any moment. This parameter prevents the traffic on one subchannel from consuming more than its fair share of this limited card resource. The default value for this parameter is ACC card dependent. A low value for bquota will severely restrict normal operation of the ACC card. Values of bquota below 2,000 should not be specified. The following parameters have defaults set according to the requirements of the firmware. They should not be modified unless otherwise instructed by Hewlett Packard.
These parameters represent the number internal timer resources in the ACC card. Each timer occupies 8 bytes, with an 8 bytes header for group of timers. t0, t1, and t3 all default to 4108 bytes (1026 timers). The t3 default value is ACC card type dependent. The timer entries are required for normal operation of the protocols. If there are too few timers, unexpected protocol operation may occur.
The driver and ACC firmware transfer data using a protocol capable of transferring multiple messages in each direction in a single transaction. Each such transaction requires only a single interrupt to the driver. A small delay in the data transfer protocol ensures that the protocol runs efficiently, transferring several messages per transaction when they are available. Too small a delay may result in unnecessary system CPU utilization. A larger delay will increase the latency of message transfers to and from the ACC interface. The default value of 5 milliseconds has been chosen after careful performance measurements by Hewlett-Packard. The default value is strongly recommended.
The E1/T1 ACC cards and the Z7340A 8-channel PCI ACC have the ability to capture ACC internal events in a trace buffer in the internal memory of the ACC card. The size of this trace buffer can be increased to enable more events to be captured. Each internal event occupies 16 bytes. A value of 0 prevents firmware tracing from being enabled, and will allow the memory to used for other ACC resources. The default value of this parameter is 524,288 bytes.
This parameter specifies the options for the internal firmware tracing. A value of 0 disables all firmware tracing. The traceopt keyword may be specified multiple times for a single interface. The values specified will be ORed together to produce the desired value of the traceopt parameter. Table 2-1 Format of traceopt Word
Symbolic values for the traceopt parameters are defined in the /opt/acc/cfg/ttgendefine include file. Please consult this file for the keywords to use to select the various firmware tracing options. Trace information will be available to HP support in an ACC dump file if tracing is enabled when the ACC dump is taken. HP support may provide additional information on extracting trace information from a live ACC card if required to assist in diagnosing a particular problem. Example of specifying E1/T1 and Z7340A tunable parameters: Z7340A 1 0:8 /opt/acc/z7340a/x25.zabs The terminal tables, buffers, message headers, and timer tables occupy a fixed amount of memory. The amount of memory used is: ttablesize*ttablenbr+zbufsize*zbufnbr+mheadnbr*80+"tsize parameters"+tracesize If this exceeds the available space (16M-bytes), "zmon" will report the problem when the firmware is being downloaded to the ACC card. In the Port-Definition section, a port entry must be defined for all ports that are referenced by the terminal definitions in the Terminal-Definition section. The parameters must be specified in the order shown, since some of the parameters are dependent on those that occur earlier in the line. This section must begin with the following line: Port-Definition Format for V series or X series interface card: Port in:p pmode baud source mode mult encode parity stop Format for E1/T1 interface card: Port in:p pmode source fmode encode options The primary subheading for the Port-Definition section. Each port has to be defined on a separate line commencing with the subheading "Port". Other entries after the port subheading for the V series or X series interface are shown below, followed by entries for the E1/T1 interface.
For more information on the features marked "Z7330B only" refer to the Siemens document Framing and Line Interface Component for PCM 30 and PCM 24 - FALC-LH PEB 2255 Version 1.3 Data sheet.
The following option parameters may then appear in any order, as needed.
Example: Port 0:0 T1RJ45 EXT ESF B8ZS RCF The Subchannel-Definition section is only used with an E1/T1 ACC card. In the Subchannel-Definition section, subchannels are associated with timeslots on an E1 or T1 interface. Subchannels defined in this section can then be referenced in the section “Terminal-Definition”. The ACC card has 32 subchannels available on each physical E1/T1port. Timeslot 0 (zero) is used for internal timing by the E1/T1 hardware, so timeslots 1 to 31 are available to be associated with subchannels as required.
A T1 interface carries 24 timeslots, each with a bandwidth of 64k bits per second. With some types of framing (e.g. SF or SuperFrame), one bit of every octet is used to carry control and timing signals, so the bandwidth is effectively reduced to 56k bits per second. The 24 timeslots available are numbered from 1 to 24 and may be associated with any of the subchannels from 0 to 31, although it is recommended you only use subchannels 1 to 24. Multiple timeslots may be combined on a single subchannel. An E1 interface carries 32 timeslots, each with a bandwidth of 64k bits per second. Timeslot 0 is used to carry control and timing signals, so only timeslots 1 to 31 may be used. The 31 timeslots available are numbered from 1 to 31 and may be associated with any of the subchannels from 0 to 31. It is recommended you restrict your use of subchannels to the range 1 to 31. Multiple timeslots may be combined on a single subchannel. Required parameters must be specified in the order shown. Optional parameters are specified with key-words. Subchannel-Definition
Examples: Subch 0:1:2 HDLC ITBS=2 INV=OFF ts:1:ffh ts:15:ffh This associates timeslots 1 and 15 with subchannel 2 of port 1 on ACC card 0. This gives a bandwidth of 128k bits per second over the subchannel. Subch 5:2:12 HDLC ITBS=4 INV=OFF ts:3:feh This associates timeslot 3 with subchannel 12 of port 2 on ACC card 5. A timeslot fill mask of FEh has been specified so only 7 bits of each octet are used to carry user data. This gives a bandwidth of 56k bits per second over the subchannel. ITBS has been set to 4 which indicates that there must be less than 31 subchannels defined. This section specifies all the terminals on the system. Note that the term "terminal" is used to generically refer to any type of physical device or logical entity (such as an X.25 Virtual Circuit). Terminal-Definition (Example from the "TTGEN Configuration File Example" at the end of this section): Term 0119 1:1 X25.SVC.IN 0000h 3200h 99 0 0 0 0 "Level.3 SVC IN" Each terminal must be defined as a separate record commencing with either the subheading "Term", or the subheading "Pterm" with an associated "Lterm" entry. The entries after the subheading are shown in the following two examples. Example for V Series or X Series Interface Term ZLU in:p type poll select appl inst brnch work area [callno] "desc" Example for E1/T1 Interface Term ZLU in:p:sch type poll select appl inst brnch work area [callno] "desc"
The physical terminal option words may be set by specifying "OPTION" (case-insensitive) with the required value after a Term or Pterm definition. The lower 8 bits of the first option word and all 16 bits of any subsequent words are used in terminal configuration in the ACC card during ZCOM system startup. Their use and meaning is protocol dependent. Refer to the relevant protocol reference manual for details. The default value for the first word is obtained from the device table. The default value for all subsequent words is zero. Option opt-word [optional-opt-word] A method of defining a physical terminal which has a number of logical terminals associated with it. The subparameter Term, above, creates a one-to-one correspondence of physical terminals to logical terminals. Thus Pterm consists of a subset of the subparameters used for the Term parameter. (See under Term above.) Pterm in:p type poll select [callno] Each logical terminal that is to be linked to the physical terminal, as described in Pterm above, must be defined in this section under this parameter. The logical terminal subparameters are a subset of those that occur in the Term parameter of the Terminal-Definition section of the TTGEN configuration file. (See under TERM above.) Lterm ZLU type logical_address appl inst brnch work area "desc"
This subparameter allows the user to set up and initialize a buffer of values in a Logical-Data area of the logical terminal table (LTT) extension area. The Ldata subparameter is related to the previous Lterm or Term parameter that came before it. In other words, the affected LTT extension area belongs to the LTT created for the previous Lterm or Term parameter. An Ldata subparameter after a Pterm parameter will cause an error to be reported. Note that a Logical-Data area must be defined before you can use the Ldata parameter. Ldata can be offset anywhere within its Logical-Data area. Multiple Ldata areas in the same Logical-Data area must not overlap or go beyond the end of the Logical-Data area. Ldata is associated with the Term or Lterm parameter previously defined before it. Term and Lterm entries have application numbers associated with them. Ldata resides in a Logical-Data area that has an application number associated with it. The application number of this Logical-Data area and the Term or Lterm parameter must match, or the application number of the Logical-Data area must be zero (0). Else an error will be reported. To set up data within the LTT extension area or Logical-Data area, "location", "format" and "data" must be specified as follows: Ldata location format data, data, ...
Example
Ldata 0 STRING "User-Data" The above example defines the first 9 bytes of extension area to be ASCII "User-Data", the first 4 bytes of region "X25CNT" to be binary 0, 7, 200, and 255, and the next 3 16-bit values (i.e., 6 bytes) of the same region to be 3000, 5000, and 60000. The Repeat keyword is used to replicate Term, Pterm, or Lterm entries. When the Repeat statement is encountered, it will duplicate the Term, Pterm, or Lterm defined immediately before the repeat statement by the number of times indicated. The ZLU numbers of the replicated entries are assigned by incrementing the original ZLU number by one for each entry created. For example, the statements: Term 060 1:1 X25.SVC.IN 0000h 3200h 99 0 0 0 0 "Level.3 SVC IN" These two statements would cause the following Term entries to be automatically created by TTGEN: Term 061 1:1 X25.SVC.IN 0000h 3200h 99 0 0 0 0 "Level.3 SVC IN" The Node-Definition section is optional, and is used to specify all nodes that are to be included in the ZCOM subsystem. If Node-Definition is left out completely, Local-Node defaults to 1, with no remote nodes configured. If Node-Definition is specified, then at least Local-Node must be defined (whereas Remote-Node is optional). Node-Definition This defines the "low" and "high" water marks for the ZNODE queue. This queue is used to hold the data messages to be sent to the remote nodes (such as, a remote API request, response data to a remote system, etc.). The LDM (ZCOM driver) uses the high and low water marks to control the data flow between the LDM and the ZNODE daemon. When the number of pending messages on the ZNODE queue reaches the high-water mark, programs initiating remote requests are suspended to avoid excessive buffers being held on the ZNODE queue. When the number of messages in the ZNODE queue drops below the low-water mark, such suspended programs are allowed to resume execution. Note that this mechanism is only applicable to programs initiating remote requests and does not limit the messages or responses generated as a result of ZCOM subsystem operation (e.g. when a terminal returns a message to its receiver on a remote system). There is one special provision provided to prevent the ZCOM subsystem from suspending programs issuing remote requests. If the low and high water marks are set to the same value, issuing a remote request when the number of messages on the ZNODE queue is at or above the high-water mark will cause the request to be rejected immediately with the error code ZENBUSY (-1). If the Flow-Control parameter is not specified, then a default low-water mark of 0 and high-water mark of MAX_INT is used (e.g. flow control is disabled). The node definition for the local system. If Node-Definition is specified, then Local-Node is mandatory, regardless of whether any remote nodes are defined. The parameter is the node number of the local node. Only one local node can be defined. The node definition for remote nodes. Multiple "Remote-Node" definitions are allowed. Each entry defines the configuration of one remote ZCOM system. The <node> field is a unique number identifying the remote system. The <timeout> field specifies the maximum time (in seconds) to wait for a response for a request sent to this remote system. The <hostname> field is the alias name or IP address (in dot format) of the remote system. Up to 4 hosts names may be specified (one for each LAN card), and the traffic load is shared between the hosts. The specified host names must be defined in the "/etc/hosts" file. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
