|
|
This chapter describes the basic operation of Cisco IOS for S/390. It includes these sections:
This section describes the operator commands available to Cisco IOS for S/390 users.
Cisco IOS for S/390 can be run as a batch job or as a started task. Many installations route started JCL output to a purge output class. Running Cisco IOS for S/390 as a batch job (as opposed to a started task) may provide valuable information in the JES logs if problems arise. Due to cross-memory services restrictions in MVS, the JES initiator is terminated after Cisco IOS for S/390, running as a batch job, is stopped. For this reason it is probably better to run Cisco IOS for S/390 as a started task. Use the appropriate start command to start the Cisco IOS for S/390 JCL procedure.
Orderly shutdown of Cisco IOS for S/390 notifies the application layer facilities that a shutdown has been requested. These facilities can then terminate prior to the termination of the underlying protocols. Orderly shutdown also lets the IFS task groups that make up Cisco IOS for S/390 (TCP, APP, DNR, MAP, and SNM) terminate gracefully with regard to the various interdependencies and interfaces that exist between them.
If you are using the Inter-User Communications Vehicle (IUCV), examine the T01LOG output data set for message T01IU001I (Connection to IUCV Established). If Cisco IOS for S/390 cannot connect to IUCV, message T01IU004I displays.
If Cisco IOS for S/390 fails to connect to IUCV, it will continue to retry at 30 second intervals until successful connection.
Each task group is started by an IFS START command in the command file. This command, in turn, specifies the configuration file member that contains the parameters to be used by the task group as it starts. The main configuration member for the task group is specified by CNFG(xx) on the IFS START command for the task group. Some task groups also use secondary configuration members from the PARM data set as specified in their main configuration file. Generally speaking, a task group dynamically loads various other programs and tables from the STEPLIB data set during initialization and later, as needed.
The IJT task group uses IJTCFGxx, as this task group controls all other task groups. Therefore, you cannot restart this task group without stopping and restarting the entire Cisco IOS for S/390 address space.
Shutdown can be initiated by these methods:
The MVS operator is prompted after the STOP command to confirm the shutdown operation.
The first stop request places Cisco IOS for S/390 into "drain" or "slow shutdown" mode. In this mode, Cisco IOS for S/390 lets existing protocol and API activity continue for an indefinite period of time and does not proceed with other termination functions until the completion of these activities. User Level Protocol Processes (ULPPs) (for example, FTP, SMTP) and API applications are notified that drain mode is in effect. As a result, API applications should begin their termination procedures.
The first P command causes the following for each task group:
Since no new API endpoints or protocol sessions can be established when drain mode is in effect, listening endpoints receive a return code indicating the drain state. The socket interface interprets this return code and terminates certain socket functions in drain mode. Idle server tasks should disconnect from the API in this situation, letting Cisco IOS for S/390 come down.
If a second operator stop request is issued, Cisco IOS for S/390 enters "stop" or "fast shutdown" mode. In fast shutdown mode, any remaining API endpoints and ULPPs are notified to terminate immediately. This results in the termination of all protocol connections and the purging of all pending or outstanding API requests.
The second P command causes the following for each task group:
Normally, only one or two operator stop requests are necessary to terminate Cisco IOS for S/390. However, it is possible for API applications to require a third stop request. The third stop request terminates the remaining Cisco IOS for S/390 components regardless of an API application's refusal to issue the required API termination functions. A third stop request also forces detaching of MVS tasks within the APP task group. More than three operator stop requests have no effect on the termination of Cisco IOS for S/390. If necessary, the MVS CANCEL command can be used.
The third P command causes the following for each task group:
TCP: Stop immediately regardless of active users. Note that if the operator replied N to message T01SO012, this is treated as a second stop and message T01SO012 is reissued.
APP: Stops immediately.
DNR: Stop immediately.
MAP: Stop immediately.
SNM: Stops immediately.
If the address space does not terminate normally after 3 stop commands, issue the F TCPACCES,ILATCH command to see if there are any hung latches. If any latches are hung, issue F TCPACCES,ILATCH FREE LATCH(nn), where nn is the latch number for each hung latch. Shutdown should then proceed. If there are no hung latches after the third P command, issue F TCPACCES,SVCDUMP. When the SVCDUMP is complete, issue C TCPACCES to cancel the address space and contact technical support, supplying the SVCDUMP for problem resolution.
The individual IFS task groups within Cisco IOS for S/390 can be stopped and started independently with the IFS subsystem STOP and START commands.
If the DNR task group terminates abnormally, you can restart it without terminating and restarting the remainder of Cisco IOS for S/390. Read START for more information on restarting task groups.
The normal method of shutting down Cisco IOS for S/390 is to issue the MVS STOP (P) command. If you plan to install maintenance on the Cisco IOS for S/390 base product before restarting Cisco IOS for S/390, use the following command to stop Cisco IOS for S/390:
f runtcp,P CLEARor
%P CLEARThe P CLEAR command specifies to clear modules and control blocks from CSA and the subsystem hooks installed by this address space.
In addition, the P CLEAR command also performs the normal processing associated with an MVS STOP (P) command. Use the CLEAR option to stop Cisco IOS for S/390 before applying the updates. This command also lets Cisco IOS for S/390 use the most recent versions of the base modules when it is restarted.
The command must be issued using the subsystem recognition character, (in other words, P CLEAR) or by using the MVS modify command (in other words, F Cisco IOS for S/390,P CLEAR).
When a P CLEAR is issued, it is possible that Cisco IOS for S/390 takes an SOC1 or SOC4 during termination. This is normal due to the missing CSA control blocks and modules. Only one P CLEAR is needed to clear the CSA.
After a P CLEAR command is issued, it may be necessary to follow the additional stopping instructions for Cisco IOS for S/390. For more information, read the section on STOP.
Although in general it is not needed, individual task groups can be stopped and restarted while Cisco IOS for S/390 is running.
To stop a task group, issue the IFS STOP tgi command from the MVS operator console.
To restart a task group, issue the IFS START tgi command from the MVS operator console (tgi is the task group identifier). One or more IFS START commands can be issued from a command script as shown in the startup example in Startup JCL Customization.
The TSO command CONVXL8 converts a table from editable text to binary. Read the description of the CONVXL8 command, later in this chapter.
The TSO command LOADXL8 works like the CONVXL8 command, but reads the load module from compiled Cisco IOS for S/390 translate tables as input. Read the description of the LOADXL8 command, later in this chapter.
The IJT command, ILATCH, is a latch lock utility that displays and frees latches used by OpenEdition (UNIX System Services) sockets. It can be used to serialize resources in the local address space. Read the description of the ILATCH command, later in this chapter.
To activate the major node to VTAM for Cisco IOS for S/390, issue the following command:
V NET,ACT,ID=A03ACCESThis command also activates the naval LUs required for Server Telnet and the client user commands (for example, FTP, FTP2, etc.).
The JCL provided on the distribution tape is functionally equivalent to that listed in the following topics, but may differ in the order of JCL statements or the contents of comment statements included in the JCL. (See Table 2-1). The sample startup JCL, RUNTCP, is in TRGINDX.CNTL(RUNTCP).
| DD Statement | Description |
| ABNLIGNR DD | Disable the Abend-Aid program product |
| ARPAHELP DD | Defines a PDS whose members contain the HELP text displayed by Server Telnet and Server FTP |
| DNRERR DD | DNR error log file |
| DNRLOG DD | DNR log file. |
| GTDERR DD | GateD error log file. |
| GTDLOG DD | GateD log file. |
| GTDTRC DD | GateD trace log file. |
| MAPERR DD | Port mapper error log file |
| MAPLOG DD | Port mapper logging file |
| SNMLOG DD | SNM task group logging file |
| STEPLIB DD | Defines the load library for Cisco IOS for S/390; these data sets must be APF-authorized |
| SYSHELP DD | Defines the help data set for the Cisco IOS for S/390 task groups. |
| SYSPARM DD | Defines the PARM data set that contains all the configuration file members which provide the parameters for the various task groups within Cisco IOS for S/390. |
| SYSPRINT DD | DNR and Port Mapper logging file. |
| SYSPROC DD | Defines the PARM data set from which command scripts (command file members) are obtained by the IJT task group. In particular, the PARM data set contains the command file member STARTxx, which contains the commands to start Cisco IOS for S/390 |
| SYSSNAP DD | Defines the data set to receive dynamic formatted dumps created via the IFS SNAP operator command (if no SNAP parameter list is specified) |
| SYSUDUMP DD | Contains formatted system dumps |
| T01LOG | Defines the log file |
| SYSABEND | Contains system dumps |
//RUNTCP JOB //* //* SAMPLE JCL PROCEDURE TO RUN TCP/IP //* THIS JCL CAN BE USED WITH ANY INTERFACE //* //* EDIT THE TRGINDX, SSN, SRC, SOUT, CMND SYMBOLIC PARAMETERS //* //* VERIFY THAT THE JOB CARD AND NAMING CONVENTIONS MEET //* YOUR SITE'S JCL REQUIREMENTS, THEN SUBMIT THIS JOB. //* //TCPIP PROC TRGINDX='TRGINDX', TARGET LIBRARIES DSN INDEX // SSN=ACSS, DFLT SUBSYSTEM NAME // SRC='%', DFLT SUBSYSTEM RECOGNITION CHAR // SOUT='*', CHOOSE A HOLD NONPURGE SYSOUT CLASS // CMND=START00 DFLT STARTUP COMMAND SCRIPT NAME // CNFG=00 IJTCFGxx SUFFIX //* //TCPIP EXEC PGM=IFSSTART,REGION=6144K,TIME=1440, // PARM='IFSINIT,U=&SSN,P=T01,SR=&SRC,SO=&SOUT,CM=&CMND,CF=&CNFG' //* //STEPLIB DD DISP=SHR,DSN=&TRGINDX..LOAD // DD DISP=SHR,DSN=&TRGINDX..SASLINK //* //* WARNING: THE LOAD DATA SET MUST NEVER BE ADDED TO THE LINK LIST. //* TCPACCESS' ELEMENT NAMES ARE NOT UNIQUE AND COULD AFFECT //* THE OPERATIONS OF OTHER SOFTWARE. THE LOAD DATA SET SHOULD //* ALWAYS BE REFERENCED THROUGH A STEPLIB OR JOBLIB STATEMENT. //* //* CONFIGURATION DATA SETS //* //SYSPARM DD DISP=SHR,DSN=&TRGINDX..PARM //SYSPROC DD DISP=SHR,DSN=&TRGINDX..PARM //* //* LOG DATA SETS //* //T01LOG DD SYSOUT=&SOUT //SYSPRINT DD SYSOUT=&SOUT //DNRLOG DD SYSOUT=&SOUT //DNRERR DD SYSOUT=&SOUT //GTDLOG DD SYSOUT=&SOUT //GTDERR DD SYSOUT=&SOUT //GTDTRC DD SYSOUT=&SOUT //MAPLOG DD SYSOUT=&SOUT //MAPERR DD SYSOUT=&SOUT //SNMLOG DD SYSOUT=&SOUT //* //* DUMP DATA SETS //* //SYSUDUMP DD SYSOUT=&SOUT //* //* MISC DATA SETS //* //ARPAHELP DD DISP=SHR,DSN=&TRGINDX..HELP //SYSHELP DD DISP=SHR,DSN=&TRGINDX..HELP //ABNLIGNR DD DUMMY /* DISABLE ABEND-AID PROCESSING */
Make the following changes to the startup JCL on the PROC statement:
| TRGINDX= | Enter the high level qualifier of the Cisco IOS for S/390 data sets. |
| SSN= | Enter the subsystem ID you are using.
Alias for SSN is U. Default is ACSS. |
| SRC= | Enter the subsystem recognition character you are using. (Verify that it does not conflict with any other subsystems you are running.)
Alias for SRC is SUBS. Default is %. |
| SOUT= | Choose an installation defined SYSOUT class that will be held and not automatically purged at job or started task termination. IFS uses this SYSOUT class for dynamically allocated SYSOUT data sets produced during task ABENDs, output from the operator SNAP command, and task initialization to print copies of the task startup PARM members.
Alias for SOUT is SYSO. Default is *. |
| CMND= | Enter the name of the STARTxx member in the PARM library.
Alias for CMND is CMD. Default is START00. |
| CNFG= | Enter the suffix of the IJTCFGxx configuration member.
Alias for CNFG is CFG. Default is 00. |
| PRFX= | Application prefix. For Cisco IOS for S/390 this is T01.
Alias for PRFX if PFX. |
Caution Many installations route started task JCL output to a purge class to be deleted at started task termination. If an installation's default SYSOUT class is purged at job or started task termination and is using SOUT='*', then all dumps and/or SNAPs produced will be lost.
These are the only changes required. Copy the JCL stream from TRGINDX.CNTL(RUNTCP) to your started task procedure library.
You are now ready to start Cisco IOS for S/390. Before doing so, it is a good idea to review the installation steps in the Cisco IOS for S/390 Release Notes to ensure that you have made all the necessary changes.
To start Cisco IOS for S/390, issue the MVS START command.
To shut down the address space you can use either the subsystem recognition character (%) or the MVS STOP command (P Cisco IOS for S/390). The system will request confirmation with the following message:
T01IF013R Confirm request to stop A/S -- Reply 'Y' or 'N'As termination continues, messages will be issued indicating that various components are terminating.
The T01LOG logspin utility lets you specify that the T01LOG SYSOUT file be closed and re-opened on a regular basis determined by either the number of lines, a period of time, or by a combination of the two. The logspin utility is implemented by including the necessary spin parameter on the LOGGING statement in the IJTCFGxx member. Read the Cisco IOS for S/390 Customization Guide for information about the IJTCFG member.
This feature is useful for customers who have long uptimes where spool usage can grow to the point that it impacts Cisco IOS for S/390 performance.
This feature, along with the addition of FREE=CLOSE on the T01LOG DD statements, lets you examine, print, and/or purge output at the convenience of the installation and prevent uncontrolled growth of the spool.
If you specify FREE=CLOSE on the T01LOG DD statement, it will cause the SYSOUT data set to be freed and made available on the output queue. Without this DD parameter, at the closing of the T01LOG file, the output will remain as part of the total job output with each iteration of output appended to the last.
The STARTxx member in the PARM library is an IFS command script that tells Cisco IOS for S/390 which task groups to start and which configuration members to use.
The STARTxx member is the highest level configuration file, as it points to the configuration members for each of the task groups. It is pointed to by the CMND= symbolic parameter in the startup JCL procedure.
The default file, START00, as distributed, contains the following:
DISPLAY IFS DISPLAY SRC START TCP CNFG(00) START APP CNFG(00) START DNR CNFG(00) START MAP CNFG(00) START SNM CNFG(00) SET TEST ON TGB(IJT)
The individual commands are described later in this chapter. Do not eliminate any of them. For installation purposes, the ones of interest are the START commands for the TCP and DNR task groups. When initially installing Cisco IOS for S/390, there is no need to make changes to the any of the other groups listed.
This section describes, in reference form, the functions, syntax, and arguments of all the Cisco IOS for S/390 system commands.
The most commonly used commands are the following:
| TASK | Display active task groups. |
| STATUS | Display maintenance status of a task group. |
| P CLEAR | Remove system hooks at shutdown. |
| STOP TGI | Stop the task group (indicated by TGI). |
| START TGI CNFG ( xx ) | Start the task group TGI using CNFG( xx ), where xx is the task group identifier for the task group you are starting. |
| REFRESH LUPARM ( APPLUPxx ) | Refresh LUPOOL and LU information for Server Telnet usage. |
SRC is an optional parameter. If no SRC is specified, there will not be an SRC (and all commands issued to the Cisco IOS for S/390 address space must be done via the MVS MODIFY command).
Most commands are processed by an implied task group depending on the command object. Some commands provided by Cisco IOS for S/390, such as SNAP, can be directed to a specific task group; in this case, the task group identifier must be placed between the SRC and the verb.
Use this command to direct the SNAP command to the API task group:
TCP SNAP ALLThe SNAP command, entered simply as SNAP, is directed to the jobstep task group (IJT) since the task group identifier is omitted. The keyword ALL indicates to SNAP the IFS trace table.
These are the valid task group identifiers:
| TCP | TCP/IP stack |
| APP | TCP/IP applications |
| DNR | Domain Name Resolver |
| IJT | IFS Jobstep Task |
| MAP | Port Mapper |
| SNM | Simple Network Management Agent Task |
These are the command verbs. If none of these are specified, DISPLAY is assumed. The action taken for each verb is described below:
| DISPLAY | Displays the status of the command object. |
| MODIFY | Modifies or changes the value of the command object. The keyword ADD, DELETE, or UPDATE usually appears as an operand in this command. |
| VARY | Changes the status of the command object in an orderly manner. The keyword ON or OFF usually appears as an operand in this command. |
Some command objects, such as SNAP, support only the DISPLAY form and ignore the another specified verb.
Verb action is performed on command objects. SNAP is a command object. The SNAP command can be entered in these ways:
You can enter command objects spelled exactly as they are shown or you can use an acceptable abbreviation. You can abbreviate any object by entering only the significant characters. That is, you must type as much of the object as is necessary to distinguish it from other objects.
These operands for the SNAP command specify either a JES SYSOUT class or, alternately, an MVS SNAP:
SNAP CLASS(A) /* JES SYSOUT CLASS */ SNAP MVS /* MVS SNAP */
The types of operands used with commands are positional and keyword.
Positional operands follow the command object in a prescribed sequence.
You must replace the TGI with the actual three-character task group identifier when you enter the command.
When you want to enter a positional operand that is a list of several names or values, the list must be enclosed within parentheses. The names or values must not include unmatched parentheses.
Some keywords let you specify values. Place the value inside parentheses following the keyword. The following is a typical keyword with a value:
TG ( TGI )You select the task group identifier desired and substitute that value for TGI when you enter the operand.
TG ( IJT )The SNAP command includes the keywords CLASS and MVS. Abbreviations for CLASS are C, CL, CLA, and CLAS; abbreviations for MVS are M and MV.
In addition, some commands allow unique abbreviations or aliases for some of their keywords.
These Cisco IOS for S/390 commands can be processed by any active task group in a Cisco IOS for S/390 address space. If the task group identifier is not specified, the command is processed by the jobstep task group (IJT). The commands are SNAP and STATUS.
Use the SNAP command for debugging purposes to spin off (dynamically allocate and free) a SYSOUT data set containing a formatted snap dump of control blocks for a task group:
| TGI | Specifies the three-character task group identifier of the task group to process the command. If not specified, IJT is assumed. |
| MVS | Specifies an MVS formatted snap dump instead of a Cisco IOS for S/390 formatted snap dump. The output goes to the SYSSNAP DD data set that is not dynamically freed (in other words, the address space must be stopped to make it available for printing if SYSSNAP is a SYSOUT data set). |
| ALL | Specifies to include the Cisco IOS for S/390 internal trace table in a Cisco IOS for S/390 formatted snap dump. Applications may also include extra information. |
| CLASS( SYSOUT_class ) | Specifies an override value for the SYSOUT class to dynamically allocate. The default class is specified by the SOUT= symbolic parameter in the JCL procedure for this address space. |
The following are examples of this command:
SNAPUse the STATUS command to display the maintenance status of a task group. The version and release numbers are displayed.
[ TGI ] STATUSThe following are examples of this command:
STATUSAll the configuration variables contained in the TCPCFGxx member, which are processed during startup, can be dynamically reprocessed with a set of operator commands. The net effect can be compared to a limited startup with only selected items from the TCPCFGxx member, but without recycling the entire Cisco IOS for S/390 address space. For more details, read the description of the TCPCFGxx member in the Cisco IOS for S/390 Customization Guide.
The LNI and DEVICE commands activate and de-activate local network hardware interfaces.
The DELETE command removes specified items from the active configuration.
The UPDATE command is not a single action command, but instead reads a member containing a list of commands and/or configuration statements. The configuration statements are identical to those in the startup TCPCFGxx member, and the LNI, DEVICE, and DELETE commands can be included. The default member name is TCPCFGUP, but command syntax allows any name to be used.
The provision to include commands among configuration statements becomes significant where state conditions are enforced. For example, to replace an active LNI, it must first be stopped, then deleted, before the configuration statement is processed. Finally, since this is not in startup, the device must be started manually. The member to the UPDATE command can contain a list of these activities, and the entire sequence can be activated with one command.
The distinction between adding to a configuration, or replacing, is based on whether the item itself allows multiples. For example, multiple LNIs are permissible, so a replacement will require a prior deletion. Inversely, a statement like TCP is always a total replacement.
For example, you have a configuration with a MEDIA named CETIETH, and a CETI device with the address 884 and DEVICE name CETI0884. You want to replace the CETI controller with one with an address of E50. The MEDIA name came from the NAME keyword on the MEDIA statement, and the DEVICE name was internally generated. Both names can be displayed with a NETSTAT CNFG command.
The typical sequence of steps would be as follows:
1 . Extract the CETI statement from the TCPCFGxx startup member into a new member (conveniently named TCPCFGUP). This CETI statement will contain the following:
DEVADDR(E50),MEDIANAME(CETIETH) . . .
2 . Since this is a replacement, the previous LNI must be stopped and deleted. Ahead of the CETI statement, add the following commands:
DEVICE STOP NAME(CETI0884) DELETE LNI NAME(CETI0884)
3 . Since this is NOT started, LNI activation is not automatic, so following the CETI statement, add the following:
DEVICE START NAME(CETI0E50)
The DEVICE name is predictable in this case, as the last 4 characters consist of the hardware channel/device address.
4 . Execute the UPDATE command.
If this is an addition of a new LNI, rather than a replacement of an existing one, Step 2, above, is not required.
The dynamic configuration commands can be executed as individual commands (entered from the console), or can be imbedded in the TCPCFGUP member to be activated via the UPDATE command where they will be executed as individual commands entered from the console. This allows combining a series of sequences, such as deletions and additions, into one member, then executing them all with one command.
All statements in TCPCFGUP are assumed to be additions to the existing configuration.
In addition to the startup statements in the TCPCFGUP member, TCPCFGUP can also contain any of the other three dynamic configuration operator commands. When placed in the TCPCFGUP member, these commands will be executed as individual commands entered from the console. This allows combining a series of sequences, such as deletions and additions, into one member, then executing them all with one command.
| target | Item to be deleted. Choices are:
· ARP - Invalidates an ARP table entry. · DEVICE - Deletes a device and its associated LNIs. The LNI state must be stopped. · LNI - Deletes an LNI. If the LNI is the only one associated with a device, the device will also be deleted. Driver configurations that support multiple LNIs tied to one device may require several LNI deletions. The current LNI state must be stopped. · MEDIA - Deletes a MEDIA block. All associated NETWORKs and LNIs must have been deleted prior to issuing a MEDIA deletion. · NETWORK - Deletes a NETWORK block. · ROUTE - Deletes a ROUTE table entry. |
| PARAMETER | The type of target. Choices are:
· DEST( value ) - Dotted decimal IP address; must be specified when deleting a ROUTE entry. See ROUTER, below. · IPADDR( value ) - Dotted decimal IP address; must be specified whenever a protocol address is required. Use to identify a NETWORK block and when deleting ARP, NETWORK, or ROUTE entries. Alias: PA · MAC( hex_value ) - 12-character hexadecimal string specifying the 6-byte hardware address used when deleting ARP entries. · MEDIANAME( name ) - Must be specified whenever there is an association with a specific MEDIA block. Use when deleting ARP or ROUTE entries. A MEDIA block deletion can be identified by either NAME(name) or MEDIANAME( name ). · NAME( name ) - Must be included whenever a specific identification of a DELETE target is required. Use when deleting MEDIA, LNI, or DEVICE entries. · ROUTER( value ) - Dotted decimal IP address; must be specified when deleting a ROUTE entry. Both DEST and ROUTER parameters are functionally identical to those on the ROUTE statement in the TCPCFGxx startup member. Alias: GATEWAY |
| START | Initiates activity on a DEVICE. The current state must be stopped. |
| STOP | Terminates device activity. The current state must be active. |
| NAME( dev_name ) | DEVICE name. If the name is not known, issue the NETSTAT CNFG command to identify it. |
| START | Initiates activity on an LNI driver. The current state must be stopped. |
| STOP | Terminates driver activity. The current state must be active. |
| NAME( lni_name ) | Name of the LNI. If the name is not known, issue the NETSTAT CNFG command to identify it. |
The UPDATE command behaves differently from the other dynamic configuration commands. It contains no information itself, but activates commands in a member.
The UPDATE command also allows for some items that are not in the startup file, in addition to the other three dynamic configuration commands.
The UPDATE command adds new configuration data to an operational gateway. The parameters for the UPDATE command specify a member name that contains configuration statements as they would appear in the startup member TCPCFGxx. The update member name can default to TCPCFGUP, and must be available in the same DD definitions as the TCPCFGxx member.
For more details, read the description of the TCPCFGxx member in the Cisco IOS for S/390 Customization Guide.
UPDATE [ CNFG ( mem_name ) ] [ MEMBER ( mem_name ) ] [ IGNORE | TERM ]| CNFG( mem_name_suf ) | Two character suffix for a member name starting with TCPCFG.
Default: UP Alias: CFG, CONFIG |
| MEMBER( mem_name ) | The entire member name. If the default name (TCPCFGUP) is not used, either CNFG or MEMBER should be specified. If both are specified, CNFG is ignored.
Default: TCPCFGUP Alias: MBR |
| IGNORE | TERM | Dictates the reaction when encountering an invalid statement in the TCPCFGUP member.
IGNORE issues an error message and proceeds to the next statement TERM issues an error message and terminates Default: TERM |
This section describes the REFRESH command, which is processed by the APP task group.
| APP | Specifies the name of the task group to which the command is directed. This is optional; the REFRESH command is always directed to the APP task group. |
| TASK | Specifies the task number of the task within the APP task group to which the command is to be directed. If only one APP task is active, specify TASK(1). |
| LUPARM( mem_name ) | Specifies the member of the SYSPARM configuration data set from which the refresh is to be performed. The LU pool will be refreshed from this member. |
| GREETING( mem_name ) | Specifies the member of the ARPAHELP data set from which the new Server Telnet greeting is to be read. Subsequent Telnet sessions will be presented with the greeting found in this member. |
This section describes DUMP and PURGE commands, which are processed by the DNR task group.
Use the DUMP command to produce formatted dumps of the DNR cache, the configuration table, or both. These dumps are written to DNRLOG.
[ DNR ] DUMP [| CACHE | Specifies that DNR cache data is to be dumped:
· DATA--Specifies the host name or Internet address for which a cache dump is to be performed. · NAMES--Specifies that all cached domain names be dumped. This is the default if CACHE is specified with no operands. |
| NAMESERVER | Specifies that, for the specified domain name, the name servers used to resolve names within that domain are to be dumped. |
| STATIC | Specifies that static configuration data is to be dumped. If no argument is specified, all static configuration data is dumped. These are the available arguments:
· ALIAS--Dump DNRALCxx configuration data · HOST--Dump DNRHSTxx configuration data · NAMESERVER--Dump DNRNSCxx configuration data · NETPREF--Dump DNRNPCxx configuration data · NETWORK--Dump DNRNETxx configuration data · RPC--Dump DNRRPCxx configuration data · PROTOCOL--Dump DNRPRTxx configuration data · SEARCHLIST--Dump DNRSLCxx configuration data · SERVICES--Dump DNRSVCxx |
If the DUMP command is issued with no arguments, then all cache and static configuration data is dumped.
The DNR task group identifier is optional; the DUMP command is automatically directed to the DNR task group, even if it is omitted.
The following are examples of the DUMP command:
DNR DUMP CACHEThis section describes commands processed by the GateD (GTD) task group.
The GATED DUMP command generates a formatted dump.
GATED DUMPThe GATED SCAN command performs an immediate rescan of the interface.
GATED SCANThe GATED STOP command shuts down GateD.
GATED STOPThe GATED TRACE command suspends or resumes tracing (in other words, this is a toggle).
GATED TRACEThis section describes commands processed by the jobstep (IJT) task group.
Use the GTF command to display or modify the settings of GTF trace event flags. A trace event is recorded only when an event is turned on (with this command) and the task group executing a module that invokes a trace event is in GTF mode (for more information, read SET). If there is no jobname the trace applies only to the TCP address space.
[ DISPLAY | MODIFY ] GTF [ ON | OFF ]| DISPLAY | MODIFY | Specifies whether to display or modify the settings of GTF trace event flags. |
| ON | OFF | Specifies to select only those events that are turned on or off for display, or to turn on or off a specified event(s) for modify.
If neither ON nor OFF is specified with DISPLAY, the on/off state of an event is not considered for inclusion in the display. Either ON or OFF is required with MODIFY. |
| EI ( event_id ) | Select the event identifier(s) listed (1-8 alphanumerics). |
| CB ( cb_id ) | Select the events for the control block identifier(s) listed (1-4 alphanumerics). |
| MOD ( mod_name ) | Select the events generated by the module(s) listed (1-4 alphanumerics). A name stem is permitted, for example, if IFSP is specified, all modules with names beginning with IFSP are included. |
| ALL | Select all events. |
The following are examples of this command:
GTF OFFUse the HELP command to obtain online information about the function, syntax, and operands of commands. This reference information is contained in the SYSHELP DD data set(s) and is displayed at your console in response to your request for help. Enter HELP without operands to obtain an introduction to using the help facility. Enter the HELP command with the operand COMMANDS to obtain a list of all the Cisco IOS for S/390 commands for which help is available.
HELP [ cmnd_name | COMMANDS | GENERAL POOL ]| cmnd_name | Specifies the full name of a command for which help information is requested. |
| COMMANDS | Requests a list of all commands for which help information is available. |
| GENERAL | Requests a display of the general format and syntax of Cisco IOS for S/390 commands. |
| POOL | Requests a display of Cisco IOS for S/390 pools. |
The following are examples of this command:
HELPThis command has no arguments or keywords.
Latches are locking mechanisms that can be used to serialize resources more granular than an address space. For example, you would use a latch to serialize resources in the local address space.
If a latch is allocated by a program but not freed, it may cause other programs requesting that same latch to hang.
The IJT command ILATCH displays and frees latches used by OpenEdition (UNIX System Services) sockets.
The alias for the ILATCH command is ILA.
There are three different versions of the ILATCH command:
ILATCH [ DISPLAY | FREE ] [ TIME ( seconds ) ] [ LATCH ( latch_num ) ]| DISPLAY | Display all latches held more than the time specified by TIME. It can be restricted to display a specific latch number (latch_num) if it has been held more than the specified time.
Default: DISPLAY |
| FREE | Free all latches or the latch specified by latch_num if held for more than the time specified by TIME( seconds ). |
| TIME( seconds ) | Specifies the time, in seconds, that the latch has been held.
Default: 60 seconds |
| LATCH( latch_num ) | Specifies the latch number (latch_num).
Default: All latches |
| MSG | NOMSG | MSG specifies that the message T00IF041 END OF ILATCH COMMAND is displayed.
NOMSG suppresses that message. Default: DISPLAY TIME( 60 ) MSG |
| CONTENTION | Lists the history of prior latch contentions. |
| MSG | NOMSG | MSG specifies that the T00IF041 END OF ILATCH COMMAND is displayed. NOMSG suppresses that message.
Default: DISPLAY TIME( 60 ) MSG |
| TRON | Activates ILATCH tracing. |
| TROFF | Stops adding to existing table entries. The table itself is not released, and is still available for display. |
| TRACE | Displays table entries. The RC is the return code leaving the GET request. All other displayed information is based on entry to the GET routine. |
| TRESET | Release the storage. This command is not required between a TRON/TROFF cycle and another TRON activation with new parameters, but should be used as a clean-up after all tracing is done. |
| ENTRIES( nn ) | Dictates the table size (the number of entries you want to monitor).
Default: 31; however, this may not be sufficient if KEEP is specified. |
| KEEP | NOKEEP | KEEP controls whether tracing should provide a historic record, or just keep track of unreleased latches. NOKEEP specifies that entries that are released are not retained. The NOKEEP table can be relatively small.
Default: NOKEEP |
| MSG | NOMSG | MSG specifies that the message T00IF041 END OF ILATCH COMMAND is displayed; NOMSG suppresses that message.
Default: DISPLAY TIME( 60 ) MSG |
| CLASS (class) | Specifies the SYSOUT class.
Default: Class specified as SOUT= keyword of PARM field. |
| DEST ( destination ) | Specifies the SYSOUT destination.
Default: no destination. |
| NOW | When this parameter is issued through the console, an immediate logspin is done. |
| PRINT ( subparm) | Subparameters are processed left to right. Valid values:
ALL - WTO/PRINT all messages, all types NONE - WTO/PRINT no messages (ALL,types - WTO/PRINT given types for all components (component,ALL - WTO/PRINT all messages for given component (component,NONE - WTO/PRINT no messages for given component (component,types - WTO/PRINT given messages for given component |
| ROUTCDE (list) | Specifies the MVS routing codes for console messages. list can be one or more valid MVS routing codes, separated by commas. Routing code ranges can be specified by separating them with a hyphen.
IFSPARM LOGGING ROUTECD(2) IFSPARM LOGGING ROUTECD(3,4,8-11) IFSPARM LOGGING ROUTECD(9-11) Default: No routing code. This means console messages are routed according to the defaults specified in the MVS SYSGEN. Range: 1-16 |
| SPIN (
LINES ( lines ) | MINUTES ( minutes ) | SYNC ) | NOSPIN | Determines when the log file will be closed and reopened.
LINES - Number of lines to be written to each log file before it is closed and reopened. MINUTES -Duration of time before logout is done. Alias for MINUTES is TIME. SYNC - Synchronizes to the hour. Default: NOSPIN |
| WTO ( subparameter ) | Subparameters are processed left to right. Valid values:
ALL - WTO/PRINT all messages, all types NONE - WTO/PRINT no messages (ALL,types - WTO/PRINT given types for all components (component,ALL - WTO/PRINT all messages for given component (component,NONE - WTO/PRINT no messages for given component (component,types - WTO/PRINT given messages for given component |
You can also change logging dynamically with the MODIFY command. For example:
MODIFY job_name LOGGING parameter(s)| mod_name [ ... ] | Module name(s) to display (1-8 alphanumerics). |
| ALL or * | Display all resident modules. |
The following are examples of this command:
MODULE *Use the MEM command to display up to 1024 bytes of virtual storage.
MEM addr | * [ DECLEN ( nnn ) | HEXLEN ( xxx ) MOD ( mod_name ) ]| addr or * | Starting display address. It can be entered as an explicit address or as an asterisk (*) with a module name (MOD( mod_name ) ) parameter. |
| MOD( mod_name ) | Module name. |
| DECLEN | HEXLEN | Length. It can be specified as decimal (DECLEN( nnn ) ) or hexadecimal (HEXLEN( nnn ) ), with a maximum of 1024.
If not specified, default value = 16. Alias for DECLEN is LEN; it can be abbreviated to DECL. HEXLEN has no alias but can be abbreviated to HEXL. |
Use the MVS command to display the MVS environment and, optionally, the contents of selected control blocks.
MVS [ IFS | JESCT | LNKLST | SCVT | SMCA | SSCT ]| IFS | Displays the subsystem communication vector table address and name of each defined IFS-based subsystem. |
| JESCT | Displays the address of the JES control table and the name of the primary JES. |
| LNKLST | Displays the names of the data sets in the MVS Link Library List. |
| SCVT | Displays, in dump format, the MVS secondary communications vector table. |
| SMCA | Displays, in dump format, the SMF Control Area. |
| SSCT | Displays the subsystem communication vector table address and name of each defined subsystem. |
The following are examples of this command:
MVSThe P command terminates all task groups and the address spaces. Optionally, it removes the subsystem hooks installed by this address space at initialization.
P [ CLEAR ]| CLEAR | Specifies to clear the subsystem hooks installed by this address space before returning to MVS. To update Cisco IOS for S/390 after applying maintenance, use the CLEAR option to stop Cisco IOS for S/390 before applying updates. In addition to providing normal stop processing, this also clears control blocks and certain modules in the CSA and lets Cisco IOS for S/390 use the most up-to-date versions of the base modules when it is restarted. S0C1/S0C4 messages during termination after a P CLEAR are normal and can be ignored. Only one P CLEAR is needed to clear the CSA. |
The following are examples of this command:
PUse the POOL command to display the statistics or attributes of data area pools. A pool is a collection of fixed-length data areas residing in a single MVS storage subpool managed by Cisco IOS for S/390 without the overhead of GETMAIN/FREEMAIN.
POOL [ ( pool_name [ ... ] ) | * ] [ ATTR ]| pool_name | Specifies the name of pool(s) to be displayed. Options are:
· ATCB -- Address space task block. · DSRB -- Domain Name Resolution Request Block. · FRR -- IFS Recovery Element. · IPTH -- IUCV only, path to TCP. · MB1 -- Buffer pool for moving data - 128 bytes. · MB2 -- Buffer pool for moving data - 384 bytes. · MB3 -- Buffer pool for moving data - 640 bytes. · MB4 -- Buffer pool for moving data - 1152 bytes. · MB5 -- Buffer pool for moving data - 1536 bytes. · MB6 -- Buffer pool for moving data - 2048 bytes. · MB7 -- Buffer pool for moving data - 5120 bytes. · MB8 -- Buffer pool for moving data - 10240 bytes. · MB9 -- Buffer pool for moving data - 16384 bytes. · MBA -- Buffer pool for moving data - 32768 bytes. · MSRB -- Message Service Request Block. · MWA -- Module Work Area. · QCB -- Queue Control Element for pools. · SAW -- Socket API function. · SEPM -- Socket endpoint. · SNMP -- SNMP data. · SPCB -- Transport Provider (only 3 required total). · SRB -- IFS Service Request Block. · STAK -- Module Stack Block for workareas. · XAE -- SNMP Request/Response header. · XWA -- Cross Memory Workarea. |
| ATTR | Specifies to display the pool attributes instead of statistics. Pool attributes are the values used to control expansion and minimum or maximum values. (Set by the POOLDEF configuration parameter statement or the default.) |
Default values for the POOL options are described in the following table:
| Value | Initial | Minimum | Expand | Contract |
|---|---|---|---|---|
| ATCB | 32 | 32 | 16 | 32 |
| FRR | 100 | 200 | 50 | 0 |
| IPTH | 64 | 64 | 32 | 64 |
| MB1 | 32 | 128 | 16 | 128 |
| MB2 | 32 | 256 | 16 | 256 |
| MB3 | 32 | 192 | 16 | 128 |
| MB4 | 32 | 160 | 16 | 128 |
| MB5 | 16 | 128 | 8 | 64 |
| MB6 | 16 | 96 | 4 | 32 |
| MB7 | 8 | 48 | 8 | 16 |
| MB8 | 4 | 32 | 4 | 16 |
| MB9 | 4 | 16 | 4 | 16 |
| MBA | 2 | 8 | 2 | 8 |
| MSRB | 200 | 400 | 100 | 0 |
| MWA | 100 | 200 | 50 | 75 |
| QCB | 100 | 200 | 50 | 0 |
| SAW | 64 | 512 | 32 | 256 |
| SEPM | 16 | 256 | 32 | 128 |
| SPCE | 3 | 3 | 1 | 3 |
| SRB | 100 | 200 | 50 | 0 |
| STAK | 40 | 20 | 20 | 0 |
| XWA | 112 | 160 | 24 | 0 |
The DSRB, SNMP, and XAE pools have no defaults; you must give explicit values for them.
The following are examples of this command:
POOLUse the SET command to set execution options for a task group.
SET [ DEMO | TEST | GTF ]| DEMO | TEST | GTF | Specifies which mode to set:
· DEMO--Some messages and/or processing is performed only in DEMO mode. · TEST--Some messages and/or processing is performed only in TEST mode. Some API and APP trace events are recorded only in TEST mode. · GTF--GTF events are recorded only when GTF mode is on. |
| ON | OFF | Specifies to turn the specified mode on or off. |
| TG( TGI [ ... ] ) | ALL | Specifies the three-character task group identifier affected by the mode change or ALL. If not specified, all active task groups are affected. |
The following are examples of this command:
SET DEMO ONUse the SRC command to display or modify the subsystem recognition character for the address space.
[ DISPLAY ] SRC| char | Specifies the new subsystem recognition character (1 alphanumeric) for the address space. The change is effective immediately. This must be a character acceptable by MVS console services. If no character is entered, there will not be any subsystem recognition character. |
The following are examples of this command:
SRCUse the START command to start a task group and to specify initialization parameter overrides.
START [ TGI CNFG( xx ) MEMBER( mem_name ) ]| TGI | Specifies the three-character task group identifier of the task group to be started. |
| CNFG( xx ) | Specifies the two character suffix to be used in constructing the name of the configuration parameter file. The name takes the form TGICFGxx, where TGI is the task group identifier specified with the STARTxx command. If CNFG() is not specified, a value of 00 is assumed for xx.
The configuration parameter member resides in the SYSPARM DD data set(s) and provides site-specific configuration parameter values for the task group being started. |
| MEMBER( mem_name ) | Specifies the name of a command script to be invoked when task group initialization has completed (1-8 alphanumerics). The command script resides in the SYSPROC DD data set(s). |
The following are examples of this command:
START DNR CNFG( 01 )Use the STCK command to convert the binary 8-byte clock value to a useful date and time.
STCK X'hex_string'Syntax Description
| hex_string | Specifies the 8-byte binary clock value as stored by the STCK instruction. This value is expressed as a 16-character hex string within quotes. |
The following is an example of this command:
STCK X'AF82198271FB4401'Use the STOP command to terminate a task group. The task group performs an orderly shutdown before terminating. Static control blocks are left in a state to be reused if the task group is started again. Depending on the specific task group, the stop request can be delayed to let work in progress complete.
STOP [ TGI ]| TGI | Specifies the three-character task group identifier of the task group to be terminated. |
Use the SVCDUMP command to generate a system formatted dump. There are no parameters with this command.
Use the TASK command to display the active task groups. Information displayed includes execution-related flags, dispatch count, and the date/time of task group initialization.
TASK [ ( TGI [ ... ] ) ]| TGI | Specifies the three-character task group identifier of the task group to be displayed. |
If TGI is omitted, all task groups are displayed.
The following are examples of this command:
TASKUse the TRACE command to display the current trace table status, to turn internal tracing on or off, and to set the internal trace table size. The trace table is formatted and included in an IFS-formatted snap dump if an ABEND occurs.
[ DISPLAY ] TRACE| ON | OFF | Specifies to enable or disable internal tracing |
| SIZE( number ) | Specifies the size (number) of the trace table as a number of 4K (4096) pages (1 or 2 decimal digits). Each entry in the trace table is 64 bytes long. The maximum number of 4K pages is 2048.
Use the SIZE parameter only when ON is also specified. Default: 16 4K pages(64K) |
| FIXED | Specifies that the trace table be in fixed storage, allowing trace capture of I/O-related events. Normally this facility is not required, but may sometimes be requested for diagnostic purposes. |
The following are examples of this command:
MODIFY TRACE OFFUse the VSM command to display virtual storage usage statistics. This command uses no parameters.
This section describes the TSO commands available for Cisco IOS for S/390 OpenEdition (UNIX System Services) socket users.
The TSO command CONVXL8 converts a table from editable text to binary.
CONVXL8 creates a data set with three records. Each record is 256 bytes in length. The first record has "*TCP/IP translate tables" (in EBCDIC) starting in column one, with the remainder of the record padded with EBCDIC blanks (X'40'). The second record will have 256 EBCDIC values representing the ASCII-to-EBCDIC translation. The third record will have 256 ASCII values representing the EBCDIC-to-ASCII translation.
File names use TSO prefix as defined by TSO rules. A fully qualified data set name needs to be enclosed in quotes. A data set name without quotes may have a user specified prefix placed before the name. This prefix is defined by the user's TSO profile. Refer to TSO documentation for more information about prefixes.
CONVXL8 INPUT OUTPUT| INPUT | Specifies the source data set to be converted. The data set must be in standard IBM format for SBCS translation tables. If input is a PDS member, INPUT should be specified as dsname(member).
This parameter is required. Note: Cisco IOS for S/390 translate tables in the SAMP data set are not in this format. Use the TSO command LOADXL8 to prepare them for use with OpenEdition (UNIX System Services). Read the section LOADXL8 Command, following, for more information. Default: None |
| OUTPUT | Specifies the output data set created by the conversion. If output is a PDS member, OUTPUT should be specified as dsname(member).
This parameter is required. Default: None |
This command will read USER.LIB.SOURCE(TRANS) and create a translate table in USER.LIB.TRANTAB:
CONVXL8 LIB.SOURCE(TRANS) LIB.TRANTABThis command will read SYSTEM.TCP.DATA(TRAN) and create a translate table in SYSTEM.BIN.TRANS:
CONVXL8 'SYSTEM.TCP.DATA(TRAN)' 'SYSTEM.BIN.TRANS'LOADXL8 has the same functionality as the CONVXL8 command, but it reads the load module from compiled translate tables as input. Note that it does not read the source. It loads the module from STEPLIB or TSO TASKLIB. The load module referred to is the Cisco IOS for S/390 translate table used by the rest of Cisco IOS for S/390. It can be converted for OpenEdition (UNIX System Services) use with this command.
LOADXL8 MODULE OUTPUT| MODULE | Specifies the load module name in the STEPLIB/TASKLIB data sets.
Note: You do not explicitly specify the data set name in the command line; just the member name. Default: None |
| OUTPUT | Specifies the destination of the output data set created by the conversion. If output is a PDS member, OUTPUT should be specified as dsname(member).
This parameter is required. Default: None |
These output files are used by OpenEdition (UNIX System Services) DNR services only. Cisco IOS for S/390 continues to use its own translation load modules within the product. You can convert several members and place them in a PDS but OpenEdition (UNIX System Services) will use only the one placed in the sequential data set 'PREFIX.STANDARD.TCPXLBIN'.
LOADXL8 ENGLISH 'PREFIX.STANDARD.TCPXLBIN'This section describes how to build command scripts that are a prearranged executable sequence of IFS task group commands and command script statements that can be invoked by specifying the command script name prefixed with a percent sign (%). The STARTxx PARM member is an example of a command script.
Command scripts are read from the SYSPROC DD data set(s) and a sample START00 script is provided in the PARM data set. A command script can be invoked at address space initialization by specifying the command script name with the CMND= parameter in the JCL procedure for an IFS address space. Command scripts can also be invoked using the IJT START command with the MEMBER(xxx) option.
The command script to start Cisco IOS for S/390 is member STARTxx in the PARM data set. The command data set is specified by DDNAME SYSPROC in the run-time JCL. Member STARTxx is specified by CMND=STARTxx in the PARM field on the EXEC statement. Member STARTxx was established during installation and customization as described in the Cisco IOS for S/390 Customization Guide. Alternate STARTxx members can be created and overridden on the PROC CMND field, in other words, S RUNTCP,CMND=START99.
The following is a sample command script to start GTF and turn tracing on for some events in a task group named TGI, and then to invoke another command script named TGICMNDS:
SET GTF OFF /* TURN GTF MODE OFF FOR ALL TASK GROUPS */ SET GTF ON TG(TGI) /* TURN GTF MODE ON FOR TGI */ MOD GTF OFF ALL /* TURN OFF ALL GTF EVENTS */ MOD GTF ON CB(SDWA PARM MODI) /* TURN ON DESIRED EVENTS */ %TGICMNDS /* INVOKE COMMAND SCRIPT FOR TGI TASK GROUP */
Special command statements valid only within a command script are provided to do these tasks:
The special commands are as follows:
| FLUSH | NOFLUSH | FLUSH specifies that the command input stack be purged (flushed) when execution of a command statement fails. This is useful to suppress further command execution if a critical command in a sequence fails.
NOFLUSH specifies that the command input stack continue to be processed even if execution of a command statement fails. Default is NOFLUSH. |
| LIST | NOLIST | LIST specifies that command statements should be displayed before execution.
NOLIST specifies that command statements not display. Default is LIST. |
|
|