IBM Support

Confused about NETMAP.CHECK on Connect:Direct for z/OS? Here is what you need to know. (Or why do I need 2 NETMAP.CHECK entries in my Init Parms?)

Technical Blog Post


Abstract

Confused about NETMAP.CHECK on Connect:Direct for z/OS? Here is what you need to know. (Or why do I need 2 NETMAP.CHECK entries in my Init Parms?)

Body

NETMAP.CHECK can be confusing. Here is how to determine your current settings along with considerations to make sure the settings meet your needs.

First consider these key points:

  • NETMAP.CHECK only applies to inbound connections.
  • Netmap checking for SNA and TCP is independently configured.
  • You can verify just the Node name, or a combination of Node name and communications address.
  • You can choose to allow sessions with a warning or reject them with a failure.

Refer to the Global Initialization Parameters section in the Connect:Direct 6.2 documentation here for information on the NETMAP.CHECK syntax.

Step 1 – Determine your current NETMAP.CHECK settings.

In the ISPF IUI screen, enter 'ADMIN;INQ;IPRM'.

(For alternate ways to view Init Parms, see Technote 1123731: Want to view ALL of your C:D z/OS Init Parms, including default values?)

You should see one or both of these lines:

NETMAP.CHECK            => ALL,ALL     ,FAIL
NETMAP.CHECK (TCP)      => TCP,NODENAME,FAIL

Step 2 – Understand the meaning of your current settings.

Determine whether SNA checking, TCP checking or both are used.

One entry shows (TCP) while the other one is just NETMAP.CHECK. The TCP entry means you are checking TCP connections. The other entry is for SNA. You will always see the SNA entry (even if the setting is NO). You will only see the TCP line when TCP checking is turned on.

If you do not have the NETMAP.CHECK (TCP) entry, then you are NOT checking TCP against the Netmap.

If you want to check all traffic, both SNA and TCP against the Netmap, you need 2 NETMAP.CHECK entries.

Step 3 – Determine which NETMAP.CHECK settings you need.

Decide if you want to check both SNA and TCP. Each of those is configured independently.

The values for NETMAP.CHECK are specified in 3 parameters as follows:

NETMAP.CHECK=(parm1,parm2,parm3)

parm1 turns SNA or TCP on or off.

NO – turn off SNA Netmap checking; if you code NO, then parm2 and parm3 are not permitted

ALL – perform SNA Netmap checking

TCP – perform TCP Netmap checking (TCP is always off unless you code this value)

parm2 determines if the communications address is verified with the Node name.

ALL – check Node name and communications address

BOTH – same as ALL

NODENAME – verify the Node name only (do not check the communications address

Warning! If you use ALL or BOTH, make sure that your Netmap includes all possible communications addresses for each node. This may involve using ALT.COMM.

parm3 controls whether the incoming access is blocked or allowed with warnings.

FAIL – block the session if not in the Netmap.

WARN – allow the session but log a warning.

PASS – allow the session without warning or errors.

Tip – If you are turning NETMAP.CHECK on for the first time, consider using WARN rather than FAIL at first. This will prevent existing transmissions from being unexpectedly blocked. After addressing any Netmap issues, you can switch to FAIL.

Example:

These 2 statements provide maximum Netmap checking. You can adjust them to suit your requirements. They check both SNA and TCP, validate the Node name and communications address, and block incoming sessions that fail the Netmap check.

NETMAP.CHECK = (ALL,ALL,FAIL)
NETMAP.CHECK = (TCP,ALL,FAIL)

[{"Type":"MASTER","Line of Business":{"code":"LOB59","label":"Sustainability Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSFGBN","label":"IBM Sterling Connect:Direct for z\/OS"},"ARM Category":[{"code":"a8m0z000000cwV7AAI","label":"CONFIGURATION"}],"Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"All Versions"}]

UID

ibm11123653