Dieses Dokument beschreibt, wie Sie einen Natural Web I/O Interface Server konfigurieren.

Die folgenden Themen werden behandelt:

• Konfigurationserfordernisse für z/OS

• Web I/O Interface Server-Konfigurationsdatei für z/OS

• Konfigurationsparameter für den Web I/O Interface Server

• Beispiel für eine Web I/O Interface Server-Konfigurationsdatei

• Web I/O Interface Server Datasets für z/OS

• Web I/O Interface Server User Exits

Konfigurationserfordernisse für z/OS

Die folgenden Themen werden behandelt:

• Parametereinstellungen für Language Environment (LE)

• Externe Security-Konfiguration

• SSL TLS-Unterstützung

• Konfigurieren der Port-Sharing-Komponente

Parametereinstellungen für Language Environment (LE)

Ein Natural Web I/O Interface Server benötigt die folgende z/OS-LE-Parameterkonfiguration:

ENVAR(TZ=CET-1DST) CET

Sie können die z/OS-Sprachumgebungsparameter festlegen:

• Mit dem Parameter PARM, der in der EXEC-Karte des Startjobs des Natural Web I/O Interface Server angegeben ist. Die Länge der Optionen ist durch die maximale Länge des Parameters PARM begrenzt.

• Assemblieren Sie ein LE/370-Laufzeitoptionsmodul CEEUOPT und verlinken Sie es mit dem Lademodul des Natural Web I/O Interface Server.

Externe Security-Konfiguration

Wenn Sie den Web I/O Interface Server so konfigurieren, dass er die Web I/O Interface Clients auf dem Server impersoniert (Web I/O Interface Server-Konfigurationsparameter SECURITY_MODE=IMPERSONATE oder IMPERSONATE_LOCAL), muss der Web I/O Interface Server "programmgesteuert" ausgeführt werden. Unter RACF sind die folgenden Definitionen für den Web I/O Interface Server erforderlich:

• Die Ressource BPX.SERVER muss definiert sein, und das Web I/O Interface Server-Konto muss READ-Zugriff auf diese Ressource haben.

• Die in der Startjobdefinition des Web I/O Interface Server definierten LOAD-Datasets müssen für die Programmklasse ** definiert sein.

  ralt program ** addmem('natural load library') uacc(read) ralt program **
  addmem('NWO load library'//NOPADCHK) uacc(read) ralt program ** addmem('user
  load library'//NOPADCHK) uacc(read) 

• SETR WHEN(PROGRAM) REFRESH

  Darüber hinaus muss jeder Client, der eine Verbindung zum Server herstellt, in RACF definiert sein und die Berechtigung zur Nutzung der z/OS Linux System Services erhalten haben.

SSL TLS-Unterstützung

• SSL/TLS über AT-TLS
• Verwaltung von Zertifikaten unter z/OS
• Verwendung von RACF Key Rings
• Verwendung von Key Databases
• Wie konfiguriert man TCP/IP für AT-TLS?
• Wie verifiziert man die AT-TLS-Konfiguration?
• Häufig gestellte Fragen
• Generierung eines Natural Web I/O Interface Server-Zertifikats

SSL/TLS über AT-TLS

Die SSL/TLS-Unterstützung für den Natural Web I/O Interface Server basiert auf der z/OS Communication Server-Komponente AT-TLS (Application Transparent-Transport Layer Security).

AT-TLS bietet SSL/TLS-Verschlüsselung als konfigurierbaren Dienst für Socket-Anwendungen. Es wird als zusätzliche Schicht über dem TCP/IP-Protokoll-Stack realisiert, die die SSL/TLS-Funktionalität in nahezu oder sogar vollständig transparentem Modus für Socket-Anwendungen nutzt. AT-TLS bietet drei Betriebsmodi. Siehe z/OS Communications Server, IP Programmer’s Guide and Reference. Version 1, Release 9, Chapter 15, IBM manual SC31-8787-09.

Diese Modi sind:

• Basic

  Die Sockets-Anwendung läuft ohne Änderungen im transparenten Modus, ohne zu erkennen, dass eine verschlüsselte Kommunikation über AT-TLS stattfindet. So können ältere Anwendungen ohne Änderung des Quellcodes im gesicherten Modus ausgeführt werden.

• Aware

  Die Anwendung erkennt, dass sie im gesicherten Modus läuft, und kann TLS-Statusinformationen abfragen.

• Controlling

  Die Sockets-Anwendung erkennt AT-TLS und steuert die Verwendung der AT-TLS-Verschlüsselungsdienste selbst. Das bedeutet, dass die Anwendung zwischen gesicherter und ungesicherter Kommunikation wechseln kann.

Beim Natural Web I/O Interface Server wird für seine SSL/TLS-Implementierung der Basic-Modus verwendet. Das heißt, ein als SSL/TLS-Server konfigurierter Server lehnt Anfragen von ungesicherten Clients ab.

Verwaltung von Zertifikaten unter z/OS

Zertifikate, die mit AT-TLS verwendet werden sollen, können unter z/OS auf zwei Arten verwaltet werden. Sie werden entweder in RACF Key Rings oder in Key Databases gespeichert, die sich im z/OS Linux-Dateisystem befinden. Welches dieser Verfahren tatsächlich angewendet wird, ist im AT-TLS Policy Agent Configuration File für den z/OS TCP/IP-Stack definiert, der vom Natural HTTPS Client verwendet wird.

IBM liefert mit jedem z/OS-System eine Reihe gängiger CA-Root-Zertifikate mit. Wenn Key Rings zur Speicherung von Server-Zertifikaten verwendet werden sollen, müssen diese Root-Zertifikate vom Systemadministrator manuell in die Key Rings importiert werden. Wenn IBM neuere Ersatzzertifikate für abgelaufene Root-Zertifikate liefert, müssen alle betroffenen Key Rings entsprechend aktualisiert werden.

Im Gegensatz zu Key Rings enthalten Key Databases den aktuellen Satz von Root-Zertifikaten automatisch, nachdem diese neu erstellt wurden. Die Notwendigkeit, immer den neuesten Satz von Root-Zertifikaten zu pflegen, gilt jedoch auch für die Alternative der Key Database.

Verwendung von RACF Key Rings

In RACF werden digitale Zertifikate in sogenannten Key Rings gespeichert. Das RACF-Kommando RACDCERT wird zum Erstellen und Verwalten von Key Rings und Zertifikaten verwendet, die in diesen Key Rings enthalten sind.

Siehe z/OS Security Server RACF Security Administrator’s Guide, IBM manual SA22-7683-11, and z/OS Security Server RACF Command Language Reference, IBM manual SA22-7687-11.

Verwendung von Key Databases

Alternativ zu RACF können Zertifikate in Key Databases gespeichert werden, die sich im Dateisystem der z/OS Linux Services befinden. Für die Erstellung und Pflege von Key Databases muss das Dienstprogramm GSKKYMAN verwendet werden.

Siehe z/OS Cryptographic Services PKI Services Guide and Reference, IBM manual SA22-7693-10.

Wie konfiguriert man TCP/IP für AT-TLS?

Gehen Sie folgendermaßen vor:

1. Setzen Sie in der TCP/IP-Konfigurationsdatei die Option TTLS in der TCPCONFIG-Anweisung.

2. Konfigurieren und starten Sie den AT-TLS Policy Agent. Dieser Agent wird von TCP/IP bei jeder neuen TCP-Verbindung aufgerufen, um zu überprüfen, ob es sich um eine SSL/TLS-Verbindung handelt.

3. Erstellen Sie die Policy Agent-Datei mit den AT-TLS-Regeln. Die Policy Agent-Datei enthält die Regeln, die festlegen, welche Verbindung SSL/TLS ist.

Siehe auch z/OS Communications Server: IP Configuration Guide, Chapter 18 Application Transparent Transport Layer Security (AT-TLS) data protection.

Die Beispiel-Policy-Agent-Datei definiert den Server mit dem Jobnamen, der mit NWODEV beginnt und als Listener an Port 4843 empfängt, um SSL/TLS zu verwenden.

In dem Beispiel wird die Zertifikatsdatenbank in der HFS-Datei /u/admin/CERT.kdb erwartet.

TTLSRule ConnRule01~1 { LocalAddrSetRef addr1 RemoteAddrSetRef
addr1 LocalPortRangeRef portR1 RemotePortRangeRef portR2 Jobname NWODEV*
Direction Inbound Priority 255 TTLSGroupActionRef gAct1~NWO_Server
TTLSEnvironmentActionRef eAct1~NWO_Server TTLSConnectionActionRef
cAct1~NWO_Server } TTLSGroupAction gAct1~NWO_Server { TTLSEnabled On }
TTLSEnvironmentAction eAct1~NWO_Server { HandshakeRole Server
EnvironmentUserInstance 0 TTLSKeyringParmsRef keyR1 } TTLSConnectionAction
cAct1~NWO_Server { HandshakeRole Server TTLSCipherParmsRef
cipher1~AT-TLS__Silver TTLSConnectionAdvancedParmsRef cAdv1~NWO_Server }
TTLSConnectionAdvancedParms cAdv1~NWO_Server { CertificateLabel NDV_TEST_CERT }
TTLSKeyringParms keyR1 { Keyring /u/admin/CERT.kdb KeyringStashFile
/u/admin/CERT.sth } TTLSCipherParms cipher1~AT-TLS__Silver { V3CipherSuites
TLS_RSA_WITH_DES_CBC_SHA V3CipherSuites TLS_RSA_WITH_3DES_EDE_CBC_SHA
V3CipherSuites TLS_RSA_WITH_AES_128_CBC_SHA } IpAddrSet addr1 { Prefix
0.0.0.0/0 } PortRange portR1 { Port 4843 } PortRange portR2 { Port 1024-65535
}

Wie verifiziert man die AT-TLS-Konfiguration?

Überprüfen Sie die Ausgabe des Policy-Agent-Jobs JESMSGLG auf:

EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR
<your TCP/IP address space>: TTLS

Diese Meldung zeigt eine erfolgreiche Initialisierung an.

Überprüfen Sie die Ausgabe des Policy-Agent-Jobs JESMSGLG auf:

EZZ8438I PAGENT
POLICY DEFINITIONS CONTAIN ERRORS FOR <your TCP/IP address space>:
TTLS

Diese Meldung weist auf Fehler in der Konfigurationsdatei hin. Weitere Informationen finden Sie in der Datei syslog.log.

Gilt die Konfigurationsregel für den Server?

Versuchen Sie, eine Verbindung zum Server herzustellen, und überprüfen Sie syslog.log auf Folgendes:

EZD1281I TTLS Map CONNID: 00018BED LOCAL:
10.20.91.61..4843 REMOTE: 10.20.160.47..4889 JOBNAME: NWODEV42 USERID: NWOSRV
TYPE: InBound STATUS: Enabled RULE: ConnRule01~1 ACTIONS: gAct1
eAct1~NWO_Server cAct1~NWO_Server

Der obige Eintrag zeigt an, dass die Verbindung zu Port 4843 SSL/TLS-fähig ist.

Häufig gestellte Fragen

Gibt es weitere Informationen zur Fehlerbehebung?

Siehe auch z/OS V1R8.0 Comm Svr: IP Diagnosis Guide: 3.23, Chapter 29 Diagnosing Application Transparent Transport Layer Security (AT-TLS)

Wie schaltet man die P-Agent-Ablaufverfolgung (Trace) ein?

Siehe Comm Svr: IP Configuration Reference, Chapter 20 Syslog deamon and Comm Svr: IP Configuration Guide, Chapter 1.5.1 Configuring the syslog daemon (syslogd)

Fehler beim Verbindungsaufbau

Suchen Sie den Rückgabecode RC und den entsprechenden GSK_-Funktionsnamen im P-Agent-Trace.

Siehe System SSL Programming und suchen Sie den RC im Chapter 12.1 SSL Function Return Codes.

Beispiel-Trace mit trace=255:

EZD1281I TTLS
Map CONNID: 00002909 LOCAL: 10.20.91.61..1751 REMOTE: 10.20.91.117..443
JOBNAME: KSP USERID: KSP TYPE: OutBound STATUS: A EZD1283I TTLS Event GRPID:
00000003 ENVID: 00000000 CONNID: 00002909 RC: 0 Connection Init EZD1282I TTLS
Start GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 Initial Handshake
ACTIONS: gAct1 eAct1 AllUsersAsClient HS-Client EZD1284I TTLS Flow GRPID:
00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Call GSK_SECURE_SOCKET_OPEN -
7EE4F718 EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909
RC: 0 Set GSK_SESSION_TYPE - CLIENT EZD1284I TTLS Flow GRPID: 00000003 ENVID:
00000002 CONNID: 00002909 RC: 0 Set GSK_V3_CIPHER_SPECS - 090A2F EZD1284I TTLS
Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Set GSK_FD -
00002909 EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909
RC: 0 Set GSK_USER_DATA - 7EEE9B50 EZD1284I TTLS Flow GRPID: 00000003 ENVID:
00000002 CONNID: 00002909 RC: 435 Call GSK_SECURE_SOCKET_INIT - 7EE4F718
EZD1283I TTLS Event GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 435
Initial Handshake 00000000 7EEE8118 EZD1286I TTLS Error GRPID: 00000003 ENVID:
00000002 CONNID: 00002909 JOBNAME: KSP USERID: KSP RULE: ConnRule01 RC: 435
Initial Handshake EZD1283I TTLS Event GRPID: 00000003 ENVID: 00000002 CONNID:
00002909 RC: 0 Connection Close 00000000 7EEE8118 

Generierung eines Natural Web I/O Interface Server-Zertifikats

Unter z/OS können SSL/TLS-Zertifikate mit dem Linux-System Services-Dienstprogramm GSKKYMAN erstellt werden. Die folgenden Schritte müssen ausgeführt werden, um ein neues Zertifikat zu erstellen, das für die SSL/TLS-gesicherte Kommunikation zwischen dem Natural Web I/O Interface Client und dem Server verwendet werden soll:

1. Starten Sie eine Shell Session aus TSO oder verbinden Sie sich über Telnet mit der z/OS Linux Shell.

2. Starten Sie GSKKYMAN.

3. Erstellen Sie eine neue Key Database oder öffnen Sie eine vorhandene.

4. Erstellen Sie ein selbstsigniertes Zertifikat, beispielsweise vom Typ "User or server certificate with 2048-bit RSA key" (Benutzer- oder Serverzertifikat mit 2048-Bit-RSA Key).

5. Exportieren Sie das Zertifikat in eine (HFS-)Datei. Wählen Sie Base64 ASN.1 DER als Exportformat.

Diese generierte Datei kann nun mit FTP im Übertragungsformat ASCII auf den/die Natural Web I/O Interface Client(s) kopiert werden. Auf der Client-Seite sollte die empfangene Datei mit der Dateiendung .CER gespeichert werden. Das Zertifikat kann nun vom Natural Web I/O Interface Client verwendet werden.

Wenn Zertifikate in einem RACF Key Ring gespeichert sind, muss das generierte Zertifikat mit dem Kommando RADCERT in den entsprechenden Key Ring importiert werden.

Zertifikate, die auf einer anderen Plattform, z.B. auf einem Windows-PC, erstellt wurden, können ebenfalls in einen RACF Key Ring oder in eine Key Database importiert werden.

Ausführliche Informationen zur Verwendung des Dienstprogramms GSKKYMAN finden Sie in der Dokumentation zum IBM Communications Server, z. B. in den folgenden Handbüchern:

z/OS Communications Server IP Configuration Guide Version 1 Release 2 (IBM manual SC31-8775-01

oder

z/OS Communications Server Cryptographic Services System Secure Sockets Layer Programming (IBM manual SC24-5901-04).

Für die Generierung von Zertifikaten unter Windows steht auf mehreren Websites ein kostenloses Dienstprogramm namens Ikeyman zum Download bereit. Ikeyman ist ebenfalls ein IBM-Produkt und bildet die Funktionalität von GSKKYMAN auf der Windows-Plattform ab.

Konfigurieren der Port-Sharing-Komponente

Die TCP/IP-Port-Sharing-Komponente des z/OS TCP/IP-Kommunikationssubsystems ermöglicht es mehreren Listenern, auf derselben Kombination aus Port und IP-Adresse empfangsbereit zu sein. Um dies im TCP/IP-Stack zu aktivieren, müssen Sie das Schlüsselwort SHAREPORT oder SHAREPORTWLM zur PORT-Profilanweisung hinzufügen, die den TCP-Port für die Serverinstanzen reserviert. Ausführliche Informationen finden Sie unter PORT Statement im Kapitel TCP/IP profile (PROFILE.TCPIP) and Configuration Statements im IBM Manual z/OS Communications Server: IP Configuration Reference.

Sie können den NWO-Server wie im Abschnitt Starten des Natural Web I/O Interface Server beschrieben starten. Sie müssen den verwendeten Port mit dem Parameter PORT_NUMBER in der Konfigurationsdatei des NWO-Servers definieren. Wenn die Port-Sharing-Komponente aktiviert ist, kann die Started Task mehrfach ausgeführt werden, um mehrere Instanzen eines NWO-Servers zu starten, die am selben Port empfangsbereit sind.

• Serverkennung (Server-ID)
• Zuverlässigkeit
• Planung
• TRACE, STDOUT und STDERR

Serverkennung (Server-ID)

Da die Serverkennung zur Identifizierung eines Servers im Serververzeichnis verwendet wird, müssen Sie eine eindeutige Serverkennung festlegen. Die Serverkennung wird als Parameter an den NWO-Server übergeben. Sie müssen die Parameter in der PARM-Karte der Started Task festlegen. Beispiel:

//NWOSRV  EXEC PGM=NATRNWO,REGION=0M,TIME=20,
//  PARM=('POSIX(ON) STACK(64K,32K,ANY,FREE) TRAP(ON,NOSPIE) ',
//    'TERMTHDACT(UADUMP),ENVAR(TZ=CET+0DST) /SERVERID')

Zuverlässigkeit

Wenn mehrere NWO-Server über einen Port empfangsbereit sind und ein Server ausfällt, kann die Arbeitslast weiterhin von den verbleibenden Servern bewältigt werden. Aus Sicht des Benutzers bleibt der vom NWO-Server angebotene Dienst verfügbar.

Planung

Wenn eine Anfrage für eine neue Verbindung eingeht, ist es Aufgabe des z/OS-Betriebssystems, die Anfrage an einen der empfangsbereiten Server weiterzuleiten. Die Verbindungen werden anhand einer gewichteten Round-Robin-Verteilung auf der Grundlage der Akzeptanzeffizienzanteile (Servers' accept Efficiency Fractions/SEFs) der Server auf die verfügbaren Server verteilt. Sobald eine Sitzung gestartet wurde, wird sie auf diesem Server ausgeführt, bis sie beendet ist.

Sie können eine Sitzung in der Trace-Datei mit dem folgenden Code identifizieren:

Start of Session:
26 10:16:45 0000000E Worker task active, SID=DED9D087D842B606, client: USER

End of session:
26 10:21:53 0000000E Worker task disconnect, client: USER
26 10:21:53 0000000E Free LTCB...and finish

TRACE, STDOUT und STDERR

Jeder Server verfügt über eigene STGTRACE-, STGSTDO- und STDSTGE-Dateien, die Teil des Job-Protokolls jedes Servers sind. Es ist möglich, die Ausgabe der Dateien in einen sequenziellen Dataset umzuleiten. Dazu muss jedoch sichergestellt werden, dass jedem Server ein eigener sequenzieller Dataset zugewiesen ist. Andernfalls kann die Ausgabe der Dateien keinem bestimmten Server zugewiesen werden.

Web I/O Interface Server-Konfigurationsdatei für z/OS

Einer Konfigurationsdatei wird der Name <serverid>C (z. B. NWOS1C) oder alternativ STGCONFG zugewiesen.

Die Konfigurationsdatei ist eine Textdatei, die sich in einem Dataset oder in einer HFS-Datei unter z/OS befindet.

Die Konfigurationsdatei enthält die Server-Konfigurationsparameter in Form einer Schlüsselwort=Wert-Syntax: keyword=value. Darüber hinaus kann sie Kommentare enthalten, deren Anfang mit einem Hash-Symbol (#) gekennzeichnet ist.

Siehe auch das unten gezeigte Beispiel für eine Web I/O Interface Server-Konfigurationsdatei.

Konfigurationsparameter für den Web I/O Interface Server

Für den Web I/O Interface Server stehen folgende Konfigurationsparameter zur Verfügung:

• COMPATIBILITY_MODE

• FRONTEND_NAME

• FRONTEND_OPTIONS

• FRONTEND_PARAMETER

• HANDLE_ABEND

• HOST_NAME

• HTPMON_ADMIN_PSW

• HTPMON_PORT

• IGNORE_PRESENT_SERVER

• INITIAL_USERID

• KEEP_TCB

• O4I

• PASSWORD_MIXEDCASE

• PORT_NUMBER

• SECURITY_MODE

• SECURITY_SYSLOG

• SESSION_PARAMETER

• SESSION_TIMEOUT

• THREAD_NUMBER

• THREAD_SIZE

• TRACE_FILTER

• TRACE_LEVEL

• UPPERCASE_SYSTEMMESSAGES

COMPATIBILITY_MODE

Die aktuelle Version des Natural Web I/O Interface (NWO) setzt voraus, dass sie mit der neuesten Version von Natural ausgeführt wird. Bei der Ausführung mit älteren Natural-Versionen wird der Fehler NAT7729 NWO and Natural version do not agree (NWO- und Natural-Version stimmen nicht überein) ausgegeben. Dies liegt daran, dass NWO eine Teilmenge der Funktionen mit dem Client aushandeln muss, und zwar zu einem Zeitpunkt, zu dem die verwendete Natural-Version noch nicht bekannt ist.

Wenn Sie NWO mit einer früheren Version von Natural ausführen möchten, können Sie diesen Parameter auf YES setzen. Es wird empfohlen, diesen Parameter auf seinem Standardwert zu belassen, wenn Sie NWO mit der neuesten Version von Natural ausführen möchten, da in diesem Fall COMPATIBILITY_MODE=YES die Funktionalität unnötig einschränken würde.

Beispiel:

COMPATIBILITY_MODE=YES

FRONTEND_NAME

Dieser Konfigurationsparameter gibt den Namen des Natural-Frontends an, das zum Starten einer Natural-Sitzung verwendet werden soll. Das Frontend befindet sich in einem PDS-Member.

Es gibt keinen Standardwert.

Beispiel:

FRONTEND_NAME=NATvrsSV

FRONTEND_OPTIONS

Die Werte dieses Konfigurationsparameters können verwendet werden, um zusätzliche Optionen für das Natural-Frontend festzulegen.

Sie können die oben genannten Optionen nach Belieben kombinieren, indem Sie ihre Werte addieren und das Ergebnis wie im folgenden Beispiel einstellen.

Beispiel:

FRONTEND_OPTIONS=07

Die Einstellung in diesem Beispiel aktiviert die Optionen 01, 02 und 04.

FRONTEND_PARAMETER

Dieser optionale Konfigurationsparameter enthält zusätzliche Natural-Frontend-Parameter, wie in der Startup Parameter Area angegeben.

 FRONTEND_PARAMETER = 'MSGCLASSX ' 

Es gibt keinen Standardwert.

Weitere Informationen finden Sie im Abschnitt Natural im Batch-Modus in der Natural Operations-Dokumentation.

Beispiel:

FRONTEND_PARAMETER='MSGCLASSX '

Die Einstellung in diesem Beispiel legt fest, dass X die Standardausgabeklasse für CMPRINT ist.

HANDLE_ABEND

Wenn außerhalb der Natural-Verarbeitung ein Abbruch in der Server-Verarbeitung auftritt, wird dieser Abbruch nicht von der Natural-Abbruchbehandlung abgefangen. Aus diesem Grund verfügt der Natural Web I/O Interface Server bei einem Abbruch über eine eigene Wiederherstellung.

Es wird empfohlen, diesen Parameter auf seinem Standardwert zu belassen, um die Auswirkungen eines Abbruchs auf einen einzelnen Benutzer zu beschränken. Wenn Sie den Wert dieses Parameters auf NO setzen, beendet jeder Fehler in der Server-Verarbeitung die gesamte Server-Verarbeitung. Das heißt, er wirkt sich auf alle Benutzer aus, die auf diesem Server arbeiten.

Beispiel:

HANDLE_ABEND=NO

HOST_NAME

Dieser optionale Konfigurationsparameter ist nur erforderlich, wenn der Server-Host mehrere TCP/IP-Stacks unterstützt.

Es gibt keinen Standardwert.

Beispiel:

HOST_NAME=node1

oder

HOST_NAME=157.189.160.55

HTPMON_ADMIN_PSW

Dieser Konfigurationsparameter definiert das Passwort, das für bestimmte Überwachungsaktivitäten (z. B. Terminate Server) des HTML Monitor Client erforderlich ist.

Es gibt keinen Standardwert.

Beispiel:

HTPMON_ADMIN_PSW=GHAU129B

HTPMON_PORT

Ein Web I/O Interface Server kann so konfiguriert werden, dass er eine HTTP-Monitor-Task hostet, die den in einem Webbrowser ausgeführten HTML Monitor Client unterstützt. Es ist nicht erforderlich, diese Monitor-Task auf jedem Server auszuführen. Mit einer einzigen Task können Sie alle Server überwachen, die auf einem Knoten ausgeführt werden.

Dieser Konfigurationsparameter definiert die TCP/IP-Portnummer, unter der die Server-Monitor-Task von einem Webbrowser aus verbunden werden kann.

Es gibt keinen Standardwert.

Beispiel:

HTPMON_PORT=3141

IGNORE_PRESENT_SERVER

Dieser Konfigurationsparameter gilt in Verbindung mit dem Web I/O Interface Server CICS Adapter.

Ein Web I/O Interface Server weist eine sogenannte Serverumgebung zu, die die serverabhängigen gemeinsamen Ressourcen enthält.

Diese Umgebung ist für jeden Web I/O Interface Server einzigartig und bezieht sich auf den Servernamen. Wenn ein Web I/O Interface Server mit Web I/O Interface Server CICS Adapter abnormal beendet wird, kann dies zu einer blockierten Web I/O Interface Serverumgebung innerhalb der CICS-Region führen. Dies hat zur Folge, dass ein Neustart des Servers mit der Fehlermeldung NAT9913 fehlschlägt.

Wenn Sie einen Web I/O Interface Server mit IGNORE_PRESENT_SERVER=YES starten, kann dies einen bereits laufenden Server beschädigen, der denselben Servernamen und dieselbe CICS-Region verwendet.

Beispiel:

IGNORE_PRESENT_SERVER=YES

INITIAL_USERID

Bei der Serverinitialisierung erstellt der Natural Web I/O Interface Server eine temporäre Natural-Sitzung, um die Eigenschaften der installierten Natural-Umgebung abzurufen.

Dieser Konfigurationsparameter gibt die Benutzerkennung an, die für diese Natural-Sitzung verwendet werden soll.

Beispiel:

INITIAL_USERID=NWOINITU

Siehe auch Web I/O Interface-Clients müssen in Natural Security definiert sein.

KEEP_TCB

Standardmäßig beendet die Remote-Natural-Sitzung einer zugeordneten Umgebung ihre TCB, sobald Sie den Fokus innerhalb von Natural Studio auf eine andere zugeordnete Umgebung umschalten. Wenn Sie den Fokus wieder zurückschalten, wird die Remote-Sitzung mit einer anderen TCB ausgeführt.

Die maximale Anzahl aktiver TCBs entspricht der Anzahl der verbundenen Clients.

Der Konfigurationsparameter KEEP_TCB legt fest, ob die Remote-Natural-Sitzung während ihrer gesamten Laufdauer denselben TCB verwenden soll. Dies ist erforderlich, wenn Sie Adabas verwenden und der Adabas-Parameter ADANAME auf ADAUSER gesetzt ist oder wenn Sie auf Db2 zugreifen möchten. Es kann auch erforderlich sein, wenn Sie auf 3GL-Programme zugreifen, die für aufeinanderfolgende Aufrufe unter demselben TCB ausgeführt werden müssen.

Beispiel:

KEEP_TCB=YES

O4I

Mit diesem Parameter können Sie Serverdaten für Optimize for Infrastructure erfassen.

PASSWORD_MIXEDCASE

Mit diesem Parameter können Sie festlegen, ob die im Verbindungsdialog angegebenen Passwörter in Großbuchstaben umgesetzt werden sollen oder nicht.

Dieser Parameter gilt nur bei

SECURITY_MODE=IMPERSONATE, IMPERSONATE_LOCAL oder IMPERSONATE_REMOTE.

Beispiel:

PASSWORD_MIXEDCASE=YES

PORT_NUMBER

Dieser Konfigurationsparameter definiert die TCP/IP-Portnummer, unter der der Server verbunden werden kann.

Es gibt keinen Standardwert.

Beispiel:

PORT_NUMBER=3140

SECURITY_MODE

Der Natural Web I/O Interface Server bietet ein Sicherheitskonzept, das auch die Ressourcen des Betriebssystems abdeckt. Die Anmeldedaten des Clients werden vom betriebssystemabhängigen Security-System validiert, und die Client-Anfrage wird unter den Kontodaten des Clients ausgeführt.

Mit dem Parameter SECURITY_MODE können Sie festlegen, auf welcher Ebene (im Batch-Modus z/OS oder unter CICS) Sie die Aktivitäten eines Web I/O Interface Client impersonieren möchten.

Es gibt keinen Standardwert.

Beispiel:

SECURITY_MODE=IMPERSONATE

SECURITY_SYSLOG

Schreiben einer Konsolenmeldung bei Security-Problemen mit der externen Security. Es wird eine Zeile in die Konsole geschrieben, zum Beispiel 'Aug-23 16:22:46.77 S0305217 BPXM023I (INITUSER) SERVERID - Ungültige Benutzer-ID angegeben.' Weitere Informationen zum Grund finden Sie im entsprechenden Trace- oder Fehlerprotokoll des Servers.

Beispiel:

SECURITY_SYSLOG=YES

SESSION_PARAMETER

Dieser optionale Konfigurationsparameter definiert Sitzungsparameter, die der im Verbindungsdialog des Natural Web I/O Interface Client angegebenen Parameterzeichenkette vorangestellt werden.

Es gibt keinen Standardwert.

Beispiel 1:

SESSION_PARAMETER='NUCNAME=NATNUCvr' +
'PROFILE=(NWOPARM,18006,48),ADAMODE=0,' +
'BPI=(TYPE=NAT,SIZE=6044),BPI=(TYPE=EDIT,SIZE=2048)', +
'BPI=(TYPE=SORT,SIZE=1024)'

- dabei steht vr für die Versions- und die Release-Nummer.

Beispiel 2:

SESSION_PARAMETER=FNAT=(10,930)

Die Einstellung im zweiten Beispiel legt fest, dass jede Sitzung auf diesem Natural Web I/O Interface Server mit dem Session-Parameter FNAT=(10,930) gestartet wird, der an die vom Benutzer angegebenen Parameter oder die Definitionen im Konfigurationsparameter DEFAULT_PROFILE angehängt wird.

SESSION_TIMEOUT

Beenden inaktiver Sitzungen, wenn der Wert des Parameters SESSION_TIMEOUT erreicht ist. Überprüfung einmal täglich um HH:MM (24 Stunden) oder alle n Minuten, ob Sitzungen länger als n Minuten inaktiv sind.

Der Server startet nicht, wenn ein ungültiger Parameter SESSION_TIMEOUT angegeben wird.

Beispiele:

SESSION_TIMEOUT=19:30,480

Jeden Tag um 19:30 Uhr werden Sitzungen gelöscht, die länger als 480 Minuten inaktiv sind.

SESSION_TIMEOUT=360,480

Alle 360 Minuten werden Sitzungen gelöscht, die länger als 480 Minuten inaktiv sind.

THREAD_NUMBER

Dieser Konfigurationsparameter gibt die Anzahl der physischen Speicher-Threads an, die vom Natural-Frontend zugeordnet werden sollen, d. h. die Anzahl der Sitzungen, die parallel ausgeführt werden können.

Beispiel:

THREAD_NUMBER=5

THREAD_SIZE

Dieser Konfigurationsparameter gibt die Größe jedes physischen Speicher-Threads an, der die Natural-Sitzungsdaten zum Zeitpunkt der Ausführung enthält.

Beispiel:

THREAD_SIZE=800

TRACE_FILTER

Mit diesem optionalen Konfigurationsparameter können Sie das Tracing durch einen logischen Filter einschränken, um das Volumen der Server-Trace-Ausgabe zu reduzieren, zum Beispiel:

TRACE_FILTER="Client=(KSP P*)"

Jede Anfrage der Benutzerkennung KSP und jede Anfrage der Benutzerkennungen, die mit einem P beginnen, werden protokolliert.

Siehe Trace-Filter im Kapitel Betrieb des Natural Web I/O Interface Server.

TRACE_LEVEL

Beispiel:

TRACE_LEVEL=0x00000011

or alternativ

TRACE_LEVEL=31+27

Die Einstellung im Beispiel schaltet die Bits 31 und 27 ein.

UPPERCASE_SYSTEMMESSAGES

Dieser Konfigurationsparameter dient zum Aktivieren oder Deaktivieren der Umsetzung aller NWO-Fehlermeldungen und Trace-Ausgaben in Großbuchstaben. Diese Funktion ist für Kunden gedacht, die Zeichensätze ohne definierte Kleinbuchstaben verwenden.

Beispiel für eine Web I/O Interface Server-Konfigurationsdatei

 # This is a comment
SESSION_PARAMETER=profile=(stgqa,10,930) fuser=(10,32) CFICU=ON THREAD_NUMBER=2
THREAD_SIZE=700 FRONTEND_NAME=NATOS42L # and another comment PORT_NUMBER=4811

Web I/O Interface Server Datasets für z/OS

Der Natural Web I/O Interface Server benötigt die folgenden Datasets:

Alternativ können Sie jeden Dataset-Namen durch die Server-ID qualifizieren.

Web I/O Interface Server User Exits

User Exit NSECUX01

Dieser User Exit ist nur anwendbar, wenn der Parameter SECURITY_MODE auf IMPERSONATE oder IMPERSONATE gesetzt ist.

Mit diesem User Exit können Sie die für die RACF-Anmeldung verwendete Benutzerkennung anpassen. Dies ist nützlich, wenn sich die RACF-Benutzerkennungen und die in Natural verwendeten Benutzerkennungen gemäß einer standardisierten Regel unterscheiden. Beispielsweise entspricht jede RACF-Benutzerkennung der entsprechenden Natural-Benutzerkennung, der zwei Dollarzeichen ($$) vorangestellt sind.

Wenn der Exit (das Lademodul NSECUX01) in der Lademodul-Verkettung des Web I/O Interface gefunden wird, wird er unter Verwendung der Standard-Linkage-Konventionen (direkter Zweig unter Verwendung einer BASR-Anweisung) aufgerufen, bevor der Benutzer gegenüber RACF validiert wird.

Die folgenden Parameter werden an den Exit übergeben:

Der Exit wird unter Verwendung von Standard-Linkage-Konventionen aufgerufen.

Beispiel für einen in C implementierten User Exit:

#include
<string.h> #include <stdio.h> # pragma linkage (NSECUX01,
FETCHABLE) void NSECUX01(char sUid[64]) { char sUidTemp[64]; printf("Uex got
usid:%s\n", sUid); strcpy(sUidTemp, sUid); sprintf(sUid, "$$%s", sUidTemp);
printf("Uex ret usid:%s\n", sUid); return; }

Der oben genannte Exit erweitert jede Benutzerkennung um zwei vorangestellte Dollarzeichen ($$), wenn sie für die RACF-Anmeldung verwendet wird.