What does NetMaster use MVS consoles for:
NetMaster uses MVS consoles for only one purpose. That purpose is, to issue a command to the operating system and then read the responses to the command, and only the responses to the command issued.
The commands may be executed by a NetMaster background userid or by any user logged on to a NetMaster region.
NetMaster does not use consoles to read messages issued by the operating system that were not specifically solicited by a command from a NetMaster region.
Issuing a command from a NetMaster Region.
To issue a command from NetMaster to the operating system there are two methods available to a user.
Both methods check to ensure that the user issuing the command has been granted the level of authority to perform the function and then pass the command to the operating system.
The OPSYS method does no further checking and sends the command to the operating system via a console and does not return the response to the command from the operating system to the user.
The SYSCMD method does additional checks to ensure that all the features required to issue operating system commands are included in the NetMaster region. It also checks for the character $ to see if a JES command was attempted, if the command is a JES command then we check to determine if the system is JES2 or JES3 and if the JES character to be used differs from a standard $.
In addition SYSCMD supports the use of keywords to allow a user to pass specific requirements with the command that override default settings. These keywords include WAIT, MIGID, OPT and CON and can contain values for specific circumstances as required by a user, and are checked by SYSCMD processing prior to issuing the command to the operating system.
After completing these checks NetMaster then issues the command to the operating system and return the responses from the operating system to the user via a console.
What Type of Consoles are supported by NetMaster.
NetMaster supports two separate console types
Extended MCS consoles (also known as EXTMCS or EMCS consoles)
Differences between JES and EMCS consoles.
JES consoles are the 'older' way of defining consoles for software products to use.
For a JES console to be available, it must be defined in SYS1.PARMLIB member CONSOLxx and an IPL must be performed for the console to become available.
This limits the number of consoles available, and has the disadvantage of requiring an IPL every time a new console is needed.
JES consoles have the advantage of being dedicated to the software product they are assigned to and can be slightly more efficient than EMCS consoles for performance purposes.
JES consoles have a limited number available and only 99 can be defined across a SYSPLEX for all software products to use.
EMCS consoles are the 'newer' way of defining consoles for software products to use.
EMCS consoles are dynamically created by the operating system and require no definition in SYS1.PARMLIB nor is an IPL required for them to be made available.
The number of EMCS consoles that can be made available for use by a NetMaster region is 254 per region, this number can be dynamically changed without requiring any operating system changes or an IPL.
NetMaster uses a retained pool of EMCS consoles methodology to ensure that a dedicated number of consoles are always available for immediate use. This allows NetMaster to obtain the same performance advantage for EMCS consoles as JES consoles enjoy by having consoles always available for use.
The NetMaster Support Team recommends that EMCS consoles be used for NetMaster whenever possible. How Consoles are defined in a NetMaster region.
In NetMaster there is a parameter group for the configuration of the console requirements for each region.
To access this parameter group, select the shortcut /PARMS. The parameter group is named $RM CONSOLES.
This parameter group has two panels for defining all the required information about console usage, many of the parameters will be given a value by default.
An example of the first panel is below
The following fields are required
CONSOLES - Console Specifications
Type of Consoles to Acquire .................+
Max Consoles to Acquire ......................
Max Consoles to Retain .......................
These parameters define the type of consoles being used - either EXTMCS or JES.
The maximum number of consoles that NetMaster will acquire at any point.
The maximum number of consoles that NetMaster will retain in a pool for immediate use.
When NetMaster starts it has no consoles acquired for use.
NetMaster issues its first operating system command, it will acquire a console to issue the command and when it has completed the process of issuing the command and reading the responses, it will check to determine if the maximum number of consoles currently retain has been reached. If the number of consoles currently retained is less than the defined maximum then it will retain the console for future use.
Once a console is retained it is available for immediate use, so that NetMaster is not required to perform the function of acquiring another console and hence the performance overhead associated with acquiring and releasing consoles to the operating system is removed. NetMaster will use one of the retained consoles if one is available when it executes a command, only when more consoles are required than are currently retained will NetMaster acquire a new console.
There is no recommendation by the NetMaster Support Team about the number of consoles that should be set in these parameters. The number of consoles required is dependant of the amount and type of monitoring being performed by each NetMaster region, however in the help screen for this panel there is some guidance in the number of consoles that should be considered depending on circumstances.
From our experience it is reasonable to start with the number 20 for consoles to acquire and 6 to retain, and then monitor the actual use at peak times by entering the NetMaster command SHOW CONSOLES. This will allow you to determine the number of consoles actually used and adjust the figure to a higher or lower number as necessary.
One important point to note is that there is no downside to defining a larger number of consoles than is actually required, this number is a maximum that can be acquired, but does not mean it is the number that will be acquired. If 50 consoles are defined as the maximum number to acquire and the NetMaster region only ever needs 10 at its peak workload, we never attempt acquire the other 40 consoles and hence there is no performance loss by over-estimating the number of consoles.
Additional parameters on page1 of the $RM Console parameter group.
The following only apply if the Console Type is EXTMCS:
Console Name Prefix ....................... CS17
Restrict Console Suffix Range ............. YES (Yes or No)
Acquire with Migration ID (default) ....... NO (Yes or No)
Name of Migration ID Determination Exit ... NO
Subsystem Command Prefix Chars (for Exit).
If the console type of EXTMCS then the console name prefix is required, by default it will be the same as the NetMaster Id for the region.
The prefix is used to build the console name - using the parameters from the above example will result in a console name of ZCS17nnn (where nnn is the suffix range from 001 to 255).
In addition if the console suffix range is specified as Yes, (and the maximum number of consoles to use was specified as 10), the consoles acquired will be named ZCS17001 - ZCS17010. This is useful to ensure that a specific set of console names are used when NetMaster is required to issue commands to other software products that must have each valid console defined to it e.g. CICS
Migration IDs are a method that enables programs that do not support named consoles to use a console number alias. When Extended MCS consoles first became available some programs were not designed to support this type of naming. However programs that require migration ids are now rarely encountered and the NetMaster Support Team recommends that this field be set to NO, unless you have a specific requirement for this type of processing.
In the event that Migration IDs are required for using consoles with NetMaster, it should be noted that this does limit the number of EMCS consoles that can be used in this way to 150 consoles across the SYSPLEX.
The Migration ID Determination Exit and Subsystem Command Prefix Character parameter fields are only used when the Acquire with Migration ID is set to YES, so these parameters should not need to be defined or updated.
On the second panel of parameter group the following parameters are defined.
The values shown above are the defaults which NetMaster will automatically populate these fields with and they should be sufficient for the vast majority of MVS systems.
There is a very good help section on the purpose of these parameters which will not be repeated in this document, it can be accessed by pressing F1 whilst in the parameter group panels.
However as the parameter Master Console Lock Duration may cause concern due to the phrase ?Master Console Lock' it should be emphasized that this parameter does not affect the MVS master console processing on an LPAR or SYSPLEX.
This parameter is only used when a NetMaster command to the operating system is issued with the parameter CON=MASTER
The use of CON=MASTER is not supported if Extended MCS consoles are used by NetMaster - so this parameter is only used if JES consoles are being used.
When it is used it allows NetMaster users to enter a command as though it was issued from a master console and read all messages received by the master console for the time period specified. This option was made available for use with JES consoles for specific requirements with automation processes, and NetMaster continues to support the function for those clients who still use JES consoles and require access to this option. Useful Command
The SHOW CONSOLES NetMaster command is very useful both for determining current console usage and for determining console efficiency by a NetMaster region.
The results of this command show the current parameter settings, the number and names of the consoles that are in use or have been retained for future use.
In addition there are statistics that can be used to help determine how efficiently the current console definition is.
From these statistics
It can be determined that there have been 104 logical requests for a console and 7 physical requests for a console (111 commands issued) and 7 consoles have actually been acquired in total to process the requests.
As shown here, the percentage of commands that required a physical acquisition of a console (NetMaster having to acquire a console from MVS to issue the command) is 6.73%. If this number is a low number it indicates that NetMaster was able to service the need for a console from its current pool rather than the performance overhead of having to perform a call to MVS to acquire the console prior to the command being issued.
The average time it took to perform the physical acquisition of a console is 0.15 seconds, in this example, this time is the additional time required for each command to process when a physical acquire of a console is performed. As 104 of the console uses were logical acquires (using a console from the retained pool) that means that over 10 seconds of unnecessary processing time were eliminated due to an efficient console definition.
On a busy system there would also more data in the average time physically released and the percentage physically released as well as some of the other fields By viewing this data you can determine whether or not your current console definition is sufficient for your NetMaster requirements or if changes to your console definitions can enhance your regions performance in this area.
A full explanation of all the statistics fields from a SHOW CONSOLES command can be found in the description of message id N86E21.
Specific Questions CA has been asked about Consoles and NetMaster.
IBM health check software flags NetMaster's use of consoles and its specific settings of ROUTCDE=ALL and MSCOPE=*ALL as bad.
There have been anecdotal reports of this setting causing system problems. This has been investigated by CA and no problems or system outages have ever been caused by having these settings on a console. However these settings may cause an excess of traffic when NetMaster routes commands across LPARs in a SYSPLEX, and we have addressed this scenario with an APAR. For release 11.0 of NetMaster the APAR is NZ13516
Does NetMaster support the IBM console restructure for z/Os (JBB7727 and JBB7728)
Yes, NetMaster r11.0 supports the IBM Console restructure, earlier releases of NetMaster have APARs available to add the required support which can be obtained from SupportConnect or by contacting Technical Support.
The OPDATA TRACKING Utility highlights NetMaster as non compliant with the z/OS1.6 version of IEAVG700.
We have resolved this situation with an APAR. For release 11.0 of NetMaster the APAR is NZ18509
The OPDATA TRACKING Utility highlights NetMaster as using 1 byte console-ids 1 byte IDs are being phased out from z/OS1.4 (with JBB7727) and it is expected that 1 byte IDs will not be supported after z/OS1.7.
NetMaster has used 4 byte IDs since 1993; but has retained some settings that appeared to use 1 byte IDs to ensure compatibility with applications incapable of communicating with 4 byte IDs. For NetMaster r11.0 we have applied changes so that we are no longer highlighted by this utility as using 1 byte ids.