Mit der Steueranweisung MAX legen Sie die Maximalwerte, Timer, Prozesszahlen und Systemparameter einer UTM-Anwendung fest, wie beispielsweise:
Name der Anwendung
Basisname bzw. Basisverzeichnis für UTM-Dateien
einfache oder doppelte KDCFILE-Führung
Größe einer UTM-Seite (Blockgröße für UTM-Speicher und -Puffer)
Größe von Pagepool, Wiederanlaufbereich, Cache etc.
Maximalwerte für Anzahl der
Prozesse
Keycodes
GSSBs
LSSBs
UTM-Seiten im Puffer für Benutzer-Protokollsätze etc.
Schwellwert für die Größenüberwachung der SYSLOG-Dateigenerationen, wenn die SYSLOG als FGG angelegt ist (Operand SYSLOG-SIZE)
Auf BS2000-Systemen: Standard-Sprachumgebung der UTM-Anwendung (Operand LOCALE)
ob SM2 zur Überwachung der Performance in der Anwendung eingesetzt werden kann
Die Parameter der Steueranweisung MAX können Sie auf mehrere MAX-Anweisungen aufteilen. Ist der gleiche Operand versehentlich in mehreren MAX-Anweisungen angegeben, wird die erste Angabe als gültig angenommen.
Pflichtoperanden
APPLINAME=, KDCFILE= und TASKS=
Jeder Pflichtoperand muss genau einmal angegeben werden.
Zusätzliche Pflichtoperanden auf Unix-, Linux- und Windows-Systemen:
SEMKEY= bzw. SEMARRAY= (Semaphorschlüssel), IPCSHMKEY=, KAASHMKEY= und CACHESHMKEY=
In OSI TP-Anwendungen zusätzlich: XAPTPSHMKEY= und OSISHMKEY=.
Hinweis für UTM-Cluster-Anwendungen auf Unix-, Linux- und Windows-Systemen:
Wenn Sie einen der Operanden APPLINAME, APPLIMODE, GSSBS, LSSBS, KB oder NB ändern, dann müssen Sie neben der initialen KDCFILE auch die UTM-Cluster-Dateien neu erzeugen, indem Sie bei der OPTION-Anweisung GEN=(CLUSTER,KDCFILE) angeben.
Im Anschluss an die Beschreibung der Operanden dieser Anweisung finden Sie noch einmal alle Operanden der MAX-Anweisung übersichtlich in einer Tabelle zusammengefasst.
MAX |
[ APPLIMODE={ SECURE | FAST } ] ,APPLINAME=appliname [ ,ASYNTASKS={ atask_number | (atask_number,service_number) } ] [ ,BLKSIZE={ 2K | 4K | 8K } ] [ ,CACHESIZE=( number,paging { ,NORES | RES } 1 { ,PS | DS } 1 ) ] [ ,CLRCH={ c | C'c'| X'xx' } ] [ ,CONN-USERS=number ] Pflichtoperand auf Unix-, Linux- u. Windows-Systemen [ ,CONRTIME=time ] [ ,DATA-COMPRESSION={ STD | YES | NO } ] [ ,DEAD-LETTER-Q-ALARM=number ] [ ,DESTADM=destination ] [ ,DPUTLIMIT1=( day,hour,minute,second ) ] [ ,DPUTLIMIT2=( day,hour,minute,second ) ] [ ,GSSBS=number ] [ ,HOSTNAME=name ] [ ,KB=length ] ,KDCFILE=( filebase [, { SINGLE | DOUBLE } ] ) [ ,KEYVALUE=number ] [ ,LEADING-SPACES={ NO | YES } ] [ ,LPUTBUF=number ] [ ,LPUTLTH=length ] [ ,LSSBS=number ] [ ,MOVE-BUNDLE-MSGS={ YES | NO } ] [ ,NB=length ] [ ,NRCONV=number ] [ ,OSI-SCRATCH-AREA=value ] [ ,PGPOOL=( number,warnlevel1,warnlevel2 ) ] [ ,PGPOOLFS=number ] [ ,PGWTTIME=time ] [ ,PRIVILEGED-LTERM = <lterm-name> ] [ ,QTIME=( qtime1,qtime2 ) ] [ ,RECBUF=( number,length ) ] [ ,RECBUFFS=number ] [ ,REDELIVERY=(number1, number2) ] [ ,RESWAIT={ time1 | ( time1, time2 ) } ] [ ,SM2={ NO | OFF | ON } ] [ ,SPAB=length ] [ ,STATISTICS-MSG={ NONE | FULL-HOUR } ] [ ,SYSLOG-SIZE=size ] [ ,SYSTEM-TASKS={ *STD | number } ] ,TASKS=number [ ,TASKS-IN-PGWT=number ] [ ,TERMWAIT=time ] [ ,TRACEREC=number ] [ ,TRMSGLTH=length ] [ ,USLOG={ SINGLE | DOUBLE } ] zusätzliche Operanden auf BS2000-Systemen [ ,BRETRYNR=number ] [ ,CARDLTH=length ] [ ,CATID=( catalog_A,catalog_B ) ] [ ,LOCALE=( [ lang_id ][,[ terr_id ][ ,ccsname ] ] ) ] [ ,LOGACKWAIT=time ] [ ,MP-WAIT=number ] [ ,PRINCIPAL-LTH=length ] [ ,REQNR=number ] [ ,SAT={ ON | OFF } ] [ ,VGMSIZE=number ]
zusätzliche Operanden auf Unix-, Linux- und Windows-Systemen
,CACHESHMKEY=number ,IPCSHMKEY=number [ ,IPCTRACE=number ] ,KAASHMKEY=number ,OSISHMKEY=number nur Pflicht, wenn Sie OSI TP-Partner generieren ,{ SEMARRAY=( number,number1 ) | SEMKEY=( number,...) } ,XAPTPSHMKEY=number nur Pflicht, wenn Sie OSI TP-Partner generieren |
1 NORES | RES und PS | DS nur auf BS2000-Systemen. Statt PS oder DS kann auch die Langform PROGRAM-SPACE bzw. DATA-SPACE angegeben werden.
APPLIMODE= legt fest, ob es sich um eine UTM-S- oder UTM-F-Anwendung handelt. | ||||||||||||||||||||||
SECURE | Die Anwendung wird als eine UTM-S-Anwendung generiert. Bei UTM-S sichert openUTM alle Benutzerdaten auch über ein Anwendungsende und einen Systemausfall hinaus. UTM-S garantiert bei allen Störungen die Sicherheit und Konsistenz der Anwendungsdaten. Bei abnormalem Ende einer UTM-S-Anwendung findet beim nachfolgenden Start ein automatischer Restart statt. Zu diesem Zweck sichert openUTM bei dieser Variante am Transaktionsende alle Änderungen. Standard: SECURE | |||||||||||||||||||||
FAST | Die Anwendung wird als eine UTM-F-Anwendung generiert. Bei UTM-F wird zugunsten der Performance auf Plattenein/-ausgaben verzichtet, mit denen bei UTM-S die Sicherung von Benutzer- und Transaktionsdaten durchgeführt wird. Bei einer stand-alone UTM-F-Anwendung sichert openUTM nur Benutzerkennworte und Änderungen in der Konfiguration, die mittels dynamischer Administration vorgenommen wurden. Diese Konfigurationsänderungen bleiben somit auch für den nächsten Anwendungslauf verfügbar. Änderungen an den Benutzerdaten dagegen werden in UTM-F-Anwendungen nicht gesichert. UTM-F-Anwendungen sind für Einsatzfälle geeignet, bei denen die Performance das wichtigste Kriterium ist, die Restart-Fähigkeit aber keine Rolle spielt. Dies trifft zu bei reinen Auskunftssystemen oder wenn alle Sicherungsfunktionen über das verwendete Datenbanksystem erbracht werden können. In UTM-Cluster-Anwendungen werden Cluster-weit gültige Benutzerdaten auch bei UTM-F gesichert. | |||||||||||||||||||||
APPLINAME= | appliname Name der UTM-Anwendung. appliname kann max. 8 Zeichen lang sein. Durch appliname wird ein Transportsystemzugriffspunkt definiert, über den Verbindungen zur UTM-Anwendung aufgebaut werden können. Pflichtoperand Wenn, z.B. für die verteilte Verarbeitung über das LU6.1-Protokoll, mehrere Anwendungsnamen notwendig sind, so können Sie mit der BCAMAPPL-Anweisung weitere Anwendungsnamen für diese Anwendung vergeben. In APPLINAME= wird der primäre Anwendungsname festgelegt. a ppliname muss im lokalen System eindeutig sein und darf nicht mit ’$’ beginnen. Es gelten für appliname die Namenskonventionen für BCAM-Anwendungen. Der mit appliname definierte Transportsystemzugriffspunkt unterstützt das Transportprotokoll NEA. appliname darf nicht mit einer Ziffer beginnen, da BCAM dies nicht erlaubt und die Anwendung sonst nicht gestartet werden kann. Dabei ist zu beachten, dass KDCDEF etwaige Ziffern nicht abfängt. appliname ist beim Verbindungsaufbau vom Terminal (Dialog-Terminal-Prozess) anzugeben. Sollen über den mit APPLINAME= definierten Anwendungsnamen Verbindungen zu Partner-Anwendungen aufgebaut werden, dann müssen Sie für den Anwendungsnamen zusätzlich eine BCAMAPPL-Anweisung angeben, siehe hierzu die Beschreibung der BCAMAPPL-Anweisung im Abschnitt "BCAMAPPL - Weitere Anwendungsnamen definieren". | |||||||||||||||||||||
ASYNTASKS= | (atask_number,service_number) legt die Betriebsmittel fest, die maximal für die Bearbeitung von Asynchron-Aufträgen belegt werden dürfen. | |||||||||||||||||||||
atask_number | Maximale Anzahl der Prozesse (BS2000-Tasks bzw. Workprozesse auf Unix-, Linux- und Windows-Systemen) der Anwendung, die gleichzeitig die Bearbeitung von Aufträgen an Asynchron-Transaktionscodes übernehmen. Mit diesem Operanden kann man verhindern, dass langlaufende Asynchron-Verarbeitungen den Dialog-Betrieb beeinträchtigen. ASYNTASKS=0 bewirkt, dass keine Asynchron-TAC-Klassen generiert werden können. Standard: 1 | |||||||||||||||||||||
service_number | Maximale Anzahl der Asynchron-Vorgänge, die gleichzeitig offen sein dürfen. Sie sollten service_number größer als atask_number wählen, wenn einer der beiden folgenden Fälle auftreten kann:
Treten diese Fälle in der Anwendung auf und ist service_number zu klein gewählt, dann kann es vorkommen, dass die Asynchron-Verarbeitung vorübergehend blockiert wird, weil service_number inaktive Vorgänge existieren. Es können dann keine neuen Asynchron-Vorgänge gestartet werden, obwohl zu diesem Zeitpunkt kein UTM-Prozess einen Asynchron-Vorgang bearbeitet. Standard: atask_number | |||||||||||||||||||||
BLKSIZE= | Größe einer UTM-Seite Beachten Sie, dass abhängig von der BLKSIZE-Angabe jeder Benutzerspeicherbereich im Pagepool mindestens 2K, 4K oder 8K belegt. Für UTM-Cluster-Anwendungen dürfen Sie nur BLKSIZE=4K oder 8K angeben. Standard:
mögliche Werte: 2K, 4K, 8K Auf BS2000-Systemen müssen Sie BLKSIZE=4K oder 8K angeben, wenn:
| |||||||||||||||||||||
BRETRYNR= | number Der Operand gilt nur für BS2000-Systeme. Bei der Ausgabe von Asynchron-Nachrichten an einen Dialog-Partner mit PTYPE=APPLI (PTERM-Anweisung) hat BRETRYNR keine Bedeutung. Wird eine solche Nachricht vom Transportsystem wegen einer temporären Engpasssituation abgewiesen, dann gibt openUTM den Prozess zunächst frei, baut die Verbindung aber nicht ab. Nach einer Wartezeit von 3 Sekunden versucht openUTM erneut bis zu dreimal, die Nachricht an BCAM zu übergeben. Gelingt die Übergabe auch dann nicht, wird wiederum 3 Sekunden gewartet, bevor die nächsten 3 Versuche unternommen werden etc. Standard: 10 | |||||||||||||||||||||
CACHESHMKEY= | number Der Operand gilt nur für Unix-, Linux- und Windows-Systeme. Pflichtoperand. | |||||||||||||||||||||
CACHESIZE= | (number, paging, NORES oder RES, PS oder DS) (NORES, RES und PS, DS nur auf BS2000-Systemen. Statt PS oder DS kann auch PROGRAM-SPACE bzw. DATA-SPACE angegeben werden) CACHESIZE= steuert Größe und Eigenschaften des Cache-Speichers (siehe auch openUTM-Handbuch „Konzepte und Funktionen“). Die Werte beeinflussen die Performance Ihrer UTM-Anwendung. | |||||||||||||||||||||
number | Anzahl der UTM-Seiten des Cache-Speichers. Die Größe einer UTM-Seite wird im Operanden BLKSIZE= festgelegt. Über den Cache-Speicher werden alle Zugriffe auf den Pagepool abgewickelt, d.h. alle Ein- und Ausgaben von LSSBs, GSSBs, TLS, LPUT-Nachrichten und FPUT-Nachrichten, MPUT-Nachrichten an Clients, sowie einige UTM-Verwaltungsdaten. Das Schreiben auf KDCFILE erfolgt erst dann, wenn im Cache-Speicher kein Platz mehr ist oder wenn die Transaktion beendet wird. KDCDEF rundet diese Zahl auf ein ganzzahliges Vielfaches von 32 auf. Standardwert: BS2000-Systeme: Liegt der Cache-Speicher auf BS2000-Systemen im Programmraum (PS), dann wird der Cache-Speicher in einem Common Memory Pool angelegt, dessen Größe immer ein Vielfaches von 1 MB beträgt. Das BS2000-System rundet den mit CACHESIZE angegebenen Wert automatisch auf. Um keinen Adressraum zu verschenken, sollte CACHESIZE in Vielfachen von 1 MB angefordert werden. | |||||||||||||||||||||
paging | gibt an, wieviel Prozent der Seiten des Cache-Speichers bei Engpasssituationen auf einmal auf die KDCFILE geschrieben werden sollen, um den Cache-Speicher zu entlasten. Es werden jedoch mindestens 8 Seiten ausgelagert. Dieser Wert kann mit dem Administrationskommando KDCAPPL CACHE=%_utm_pages geändert werden. Standardwert: 70 (%) | |||||||||||||||||||||
NORES | Der Parameter gilt nur für BS2000-Systeme. Standard: NORES | |||||||||||||||||||||
RES | Der Parameter gilt nur für BS2000-Systeme. Der Verbrauch residenter Seiten durch das Einrichten eines residenten Cache-Speichers kann nicht mit dem COREBIAS-Operanden des BS2000-Kommandos BIAS kontrolliert werden. | |||||||||||||||||||||
PS oder PROGRAM-SPACE | ||||||||||||||||||||||
Der Parameter gilt nur für BS2000-Systeme. Der UTM-Cache wird im Programmraum angelegt. Standard: PS | ||||||||||||||||||||||
DS oder DATA-SPACE | ||||||||||||||||||||||
Der Parameter gilt nur für BS2000-Systeme. Der UTM-Cache wird in einem oder mehreren Datenräumen angelegt. Ist der UTM-Cache größer als 2GB generiert, dann verteilt UTM den Cache auf mehrere Datenräume, da ein Datenraum maximal 2GB groß sein darf. Die Option, den UTM-Cache in einem Datenraum anzulegen, sollte nur dann gewählt werden, wenn ein sehr großer UTM-Cache benötigt wird und der Adressraum (Program Space) dafür nicht ausreicht. Die Nutzung eines Datenraums für den UTM-Cache ist immer mit geringen Performance-Einbußen verbunden, die sich aus der Art und Weise ergeben, wie ein Programm auf Daten in einem Datenraum zugreifen kann. Diese Performance-Nachteile werden allerdings für Anwendungen, die einen großen UTM-Cache benötigen, aufgewogen durch die Vorteile, die ein großer UTM-Cache durch die Reduzierung von Datei-IOs mit sich bringt. Vor allem für UTM-F Anwendungen kann es vorteilhaft sein, einen sehr großen UTM-Cache in einem Datenraum anzulegen. Bei UTM-F werden Cache-Puffer nur bei Cache-Engpass auf Datei geschrieben. Wenn der UTM-Cache groß genug generiert ist, können bei diesen Anwendungen sämtliche Datei-IOs auf den Pagepool entfallen. Die Maximalgröße für einen UTM-Cache in Datenräumen beträgt 8 GB. D.h.:
DATA-SPACE darf nicht zusammen mit RES angegeben werden. | ||||||||||||||||||||||
CARDLTH= | laenge Der Operand gilt nur für BS2000-Systeme. Länge der Ausweisinformation in Bytes. Wenn der Ausweisleser zur Ergänzung der Berechtigungs-Prüfung verwendet wird, speichert openUTM die Ausweisinformation in der Länge ab, die sich aus dem Maximum dieser Länge und dem bei MAX PRINCIPAL-LTH generierten Wert ergibt. CARDLTH muss so groß sein, dass für alle USER Anweisungen mit USER ..., CARD = (pos, string) gilt: pos + Laenge (string) -1 <= CARDLTH. Standard: 0 Bei einem Wert > 255 nimmt KDCDEF ohne Warnung 255 an. | |||||||||||||||||||||
CATID= | (catalog_A,catalog_B) Der Operand gilt nur für BS2000-Systeme. Wenn Sie mit CATID arbeiten, geben Sie bei KDCFILE=filebase (siehe Abschnitt "MAX - UTM-Anwendungsparameter definieren") den Basisnamen ohne die CATID an. Solange Sie die KDCFILE einfach führen, geben Sie mit catalog_A die CATID an, der die KDCFILE zugeordnet werden soll. catalog_B wird in diesem Fall nicht angegeben. Bei doppelter Dateiführung der KDCFILE (siehe Abschnitt "Die KDCFILE") können Sie Dateien mit dem Suffix A der CATID catalog_A zuordnen und Dateien mit dem Suffix B der CATID catalog_B. Geben Sie bei doppelter Dateiführung nur catalog_A an, werden jeweils beide Dateien dieser CATID zugeordnet. | |||||||||||||||||||||
CLRCH= | definiert ein Zeichen, mit dem der KB-Programmbereich und der SPAB am Ende eines Dialog-Schrittes überschrieben werden. Mögliche Angaben sind: c Dabei ist c ein alphanumerisches und x ein hexadezimales Zeichen. Standard: Die Bereiche KB und SPAB werden nicht überschrieben. | |||||||||||||||||||||
CONN-USERS= | number Auslastung der Anwendung steuern
Benutzerkennungen und Clients, die mit Administrationsberechtigung generiert wurden, können sich auch dann noch an die UTM-Anwendung anmelden, wenn die maximale Anzahl der gleichzeitig arbeitenden Benutzerkennungen bereits erreicht wurde. Standardwert auf BS2000-Systemen: 0 (d.h. keine Beschränkung) Unix-, Linux- und Windows-Systeme: | |||||||||||||||||||||
CONRTIME= | time (connection request time)
Kommt beim Start der Anwendung oder per Administrationskommando KDCPTERM bzw. KDCLPAP keine Verbindung zu diesen Partnern zustande, so versucht auch in diesem Fall openUTM im Abstand von CONRTIME= die Verbindung wiederaufzubauen. Bei CONRTIME=0 macht openUTM keinen Versuch die Verbindung aufzubauen. Ausnahme: Bei Asynchron-Nachrichten an OSI TP-Partner wird dann eine Wartezeit von 10 Minuten gesetzt. Standard: 10 Min. | |||||||||||||||||||||
DATA-COMPRESSION= | Mit diesem Parameter kann für eine Anwendung die Datenkomprimierung erlaubt oder nicht erlaubt werden. | |||||||||||||||||||||
YES | Eine Datenkomprimierung ist erlaubt und eingeschaltet. Die Datenkomprimierung kann administrativ ausgeschaltet werden, z.B. durch KDCAPPL. | |||||||||||||||||||||
NO | Eine Datenkomprimierung ist nicht erlaubt und ausgeschaltet. Diese Einstellung kann administrativ nicht geändert werden. | |||||||||||||||||||||
STD | Für UTM-S Anwendungen (APPLIMODE=S) ist eine Datenkomprimierung erlaubt und eingeschaltet. Diese Voreinstellung kann administrativ geändert werden. Standard: STD Der Durchschnittswert der pro Datenkomprimierung eingesparten UTM-Seiten kann per Administration abgefragt werden, z.B. per Kommando KDCINF STAT (siehe openUTM-Handbuch „Anwendungen administrieren“) oder per WinAdmin bzw. WebAdmin. | |||||||||||||||||||||
DEAD-LETTER-Q-ALARM | steuert die Überwachung der Anzahl von Nachrichten in der Dead Letter Queue. Bei jedem Erreichen des Schwellwertes number wird die Meldung K134 ausgegeben. Für diese Meldung kann das Ziel MSGTAC definiert werden, um eine automatische Behandlung der Dead Letter Queue durchzuführen. Standard: 0, die Überwachung ist ausgeschaltet. | |||||||||||||||||||||
DESTADM= | destination gibt den Empfänger an, an den openUTM die Ergebnisse von Administrationsaufrufen schickt, die asynchron verarbeitet wurden. Für destination kann angegeben werden:
Standard: Leerzeichen, d.h. kein Ziel, die Ergebnisse gehen verloren. | |||||||||||||||||||||
DPUTLIMIT1= | (day,hour,minute,second) definiert die spätestmögliche Ausführungszeit eines Auftrags bei relativer oder absoluter Zeitangabe: Ausführungszeitpunkt < DPUT-Aufrufzeitpunkt + DPUTLIMIT1 Für die Zeitangabe in DPUTLIMIT1 gilt: | |||||||||||||||||||||
day | Maximalwert: 364 | |||||||||||||||||||||
hour | Maximalwert: 23 | |||||||||||||||||||||
minute | Maximalwert: 59 | |||||||||||||||||||||
second | Maximalwert: 59 Standardwert: DPUTLIMIT1 (360, 0, 0, 0) Für die Operanden DPUTLIMIT1 und DPUTLIMIT2 muss gelten: DPUTLIMIT1 + DPUTLIMIT2 <= (364, 23, 59, 59) < 365 Tage D.h. geben Sie für DPUTLIMIT1 (364, 23, 59, 59) an, so müssen Sie DPUTLIMIT2=(0, 0, 0, 0) angeben. | |||||||||||||||||||||
DPUTLIMIT2= | (day,hour,minute,second) Die Zeitangabe beim DPUT-Aufruf enthält keine Jahreszahl. Außerdem kann der gewünschte Ausführungszeitpunkt bereits vorüber sein, wenn sich der DPUT-Aufruf verzögert hat. Daher muss entschieden werden, ob der Ausführungszeitpunkt eines Auftrags mit absoluter Zeitangabe dem vergangenen, laufenden oder nächsten Jahr zugerechnet werden soll. Da gilt, dass DPUTLIMIT1 + DPUTLIMIT2 < 1 Jahr sein müssen, liegt höchstens eine dieser drei Alternativen im erlaubten offenen Zeitintervall (Aufrufzeitpunkt - DPUTLIMIT2, Aufrufzeitpunkt + DPUTLIMIT1):
DPUTLIMIT2 ermöglicht also bei einem zeitgesteuerten Auftrag mit absoluter Zeit-Angabe die Rückdatierung des angegebenen Ausführungszeitpunkts in die Vergangenheit. Bei relativer Zeitangabe gibt es keine Rückdatierung. DPUTLIMIT1 begrenzt die Vordatierung von Aufträgen mit relativer oder absoluter Zeitangabe in die Zukunft. Beispiel1 Der DPUT-Aufrufzeitpunkt ist (005,0,0,0). Vergangenes und aktuelles Jahr sind keine Schaltjahre.
-|---------------|------------- ... --------------|-----------| 360 5 305 360 FFFFFFFFFFFFFFFFFDDDDDDDDDDDDD ... DDDDDDDDDDDDDDD Beispiel 2 DPUTLIMIT1 und DPUTLIMIT2 sind genauso definiert wie in Beispiel 1 , der DPUT-Aufrufzeitpunkt ist aber (360,0,0,0).
-|---------------|------------- ... ----------|-------------| 350 360 295 350 FFFFFFFFFFFFFFFFFDDDDDDDDDDDDD ... DDDDDDDDDDD Standardwerte siehe Operand DPUTLIMIT1 | |||||||||||||||||||||
GSSBS= | number Maximale Anzahl von GSSBs (globale Sekundärspeicherbereiche), die gleichzeitig in der Anwendung existieren können. Standard: 32 | |||||||||||||||||||||
HOSTNAME= | name BS2000-Systeme: Unix-, Linux- und Windows-Systeme: HOSTNAME darf nur in stand-alone Anwendungen angegeben werden. In UTM-Cluster-Anwendungen können Sie einen virtuellen Rechnernamen im Parameter VIRTUAL-HOST der CLUSTER-NODE-Anweisung angeben. Name des Hosts, der als Absenderadresse angegeben wird, wenn eine Verbindung von der UTM-Anwendung aus aufgebaut wird. HOSTNAME= wird in Cluster-Systemen benötigt, die beim Verbindungsaufbau als Absenderadresse die übernehmbare („relocatable“) IP-Adresse und nicht die stationäre IP-Adresse verwenden. | |||||||||||||||||||||
IPCSHMKEY= | number Der Operand gilt nur für Unix-, Linux- und Windows-Systeme. Schlüssel für das Shared Memory Segment, das zur Kommunikation zwischen Workprozessen einerseits und den Dialog-Terminal- bzw. Drucker-Prozessen sowie dem Timerprozess (externe Prozesse einer Anwendung) andererseits dient. Die Schlüssel sind globale Parameter auf Unix-, Linux- und Windows-Systemen. Es darf nur ein Schlüssel angegeben werden. number ist als Dezimalzahl anzugeben. Pflichtoperand. | |||||||||||||||||||||
IPCTRACE= | number Der Operand gilt nur für Unix-, Linux- und Windows-Systeme. Im Testmodus (Starten mit TESTMODE=ON; openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“) schreibt openUTM Einträge in den Trace-Bereich des IPC (Shared Memory Segments für die Kommunikation zwischen Prozessen). Diese Einträge enthalten interne Informationen für Diagnosezwecke. Ein Eintrag belegt 32 Byte. Mit IPCTRACE wird die Anzahl von Einträgen festgelegt. Wird diese Zahl überschritten, so überschreibt openUTM bereits vorhandene Einträge vom ältesten an. Standard: 1060 Eine Angabe < 1 oder > 32500 wird von KDCDEF ohne Meldung durch den Minimal- bzw. Maximalwert ersetzt. | |||||||||||||||||||||
KAASHMKEY= | number Der Operand gilt nur für Unix-, Linux- und Windows-Systeme. Schlüssel für das Shared Memory Segment, in dem die anwendungsglobalen Daten abgelegt werden. Die Schlüssel sind globale Parameter auf Unix-, Linux- und Windows-Systemen. Es darf nur ein Schlüssel angegeben werden. number ist als Dezimalzahl anzugeben. Pflichtoperand. | |||||||||||||||||||||
KB= | length legt die Länge des Kommunikationsbereiches (KB) in Byte fest. KB-Kopf und KB-Rückgabebereich werden bei der Länge nicht berücksichtigt. Standard: 512 | |||||||||||||||||||||
KDCFILE= | filebase Basisname der KDCFILE, der Benutzer-Protokolldatei und der System-Protokolldatei SYSLOG. Pflichtoperand. BS2000-Systeme: | |||||||||||||||||||||
SINGLE | Die KDCFILE soll einfach geführt werden. Wird die KDCFILE aufgespalten (siehe Abschnitt "KDCFILE aufspalten"), so werden alle KDCFILE-Dateien einfach geführt. Standard: SINGLE | |||||||||||||||||||||
DOUBLE | Die KDCFILE soll aus Sicherheitsgründen doppelt geführt werden. Wird die KDCFILE aufgespalten (siehe Abschnitt "KDCFILE aufspalten"), so werden alle KDCFILE-Dateien doppelt geführt. Für UTM-Cluster-Anwendungen darf nur SINGLE angegeben werden. | |||||||||||||||||||||
KEYVALUE= | number Wert des größten Keycodes der Anwendung und damit auch Wert des größten entsprechenden Lockcodes, der für einen Transaktionscode oder ein Terminal als Zugriffschutz vergeben werden kann. Standardwert: 32 Ausnahmen:
Bei einem Wert < 1 setzt KDCDEF ohne Meldung KEYVALUE=1. | |||||||||||||||||||||
LEADING-SPACES= | gibt an, wie führende Leerzeichen in einer Nachricht von einem Terminal oder von einer TS-Anwendung (PTERM ... PTYPE=APPLI oder SOCKET) behandelt werden. | |||||||||||||||||||||
YES | Führende Leerzeichen in einer Nachricht werden beim Aufruf eines Teilprogramms an das Teilprogramm weitergereicht. | |||||||||||||||||||||
NO | Führende Leerzeichen werden ausgeblendet. Standard: NO | |||||||||||||||||||||
LOCALE= | (lang_id,terr_id,ccsname) Der Operand gilt nur für BS2000-Systeme. definiert die Standard-Sprachumgebung der UTM-Anwendung (siehe auch Abschnitt "UTM-Meldungen"). Das hier generierte Locale wird den Benutzerkennungen und den Clients, die sich über LTERM-Partner oder LTERM-Pool anschließen, als Standardwert für die Sprachumgebung zugeordnet. Die Standardeinstellung ist wirksam, solange für diese Objekte in den entsprechenden USER-, LTERM- oder TPOOL-Anweisungen kein eigenes Locale definiert wird. Das Meldungsmodul, dessen Sprach- und Territorialkennzeichen in den Anweisungen MESSAGE ...,LOCALE= und MAX ...,LOCALE= übereinstimmen, wird das Anwendungs-Meldungsmodul. Meldungen an die Meldungsziele SYSOUT, SYSLST und CONSOLE sendet openUTM aus diesem Anwendungs-Meldungsmodul. Außerdem bestimmen die Angaben im Anwendungs-Meldungsmodul die Meldungsziele für eine Meldung. | |||||||||||||||||||||
lang_id | Max. zwei Zeichen langes Sprachkennzeichen für die UTM-Anwendung. Standard: Leerzeichen | |||||||||||||||||||||
terr_id | Max. zwei Zeichen langes Territorialkennzeichen. Das Territorialkennzeichen ist frei wählbar. Standard: Leerzeichen | |||||||||||||||||||||
ccsname | (coded character set name) Standard: Leerzeichen, d.h. 7-Bit-Betrieb | |||||||||||||||||||||
LOGACKWAIT= | time Der Operand gilt nur für BS2000-Systeme. Zeit in Sekunden, die openUTM maximal auf eine Quittung von Ausgabegeräten warten soll. Diese Quittung ist
Trifft in diesem Zeitraum die Quittung nicht ein, z.B. wegen Papierende bei Druckern, baut openUTM die logische Verbindung zu dem Gerät ab. Standard: 600 | |||||||||||||||||||||
LPUTBUF= | number Größe des LPUT-Puffers in UTM-Seiten. Im LPUT-Puffer der KDCFILE werden die LPUT-Daten zwischengespeichert. Diese LPUT-Daten werden erst dann in die Benutzer-Protokolldatei kopiert, wenn number überschritten wird. Die Benutzer-Protokolldatei USLOG ist nur während dieses Kopier-Vorgangs geöffnet. Standard: 1 ACHTUNG! LPUTBUF * Größe UTM-Seite >= LPUTLTH + Länge KB-Kopf (84 Byte) | |||||||||||||||||||||
LPUTLTH= | length Maximale Länge der Benutzerdaten in LPUT-Sätzen in Byte (ohne KB-Kopf). Die maximale Länge eines Satzes in der Benutzer-Protokolldatei ergibt sich damit aus (siehe auch openUTM-Handbuch „Anwendungen programmieren mit KDCS“, Benutzer-Protokolldatei): length + 84 Byte (KB-Kopf) + 12 Byte (Längenfelder) Standard: 1948 BS2000-Systeme: Soll die Benutzer-Protokolldatei USLOG auf einer Non-Key-Platte (NK2, NK4) eingerichtet werden, dann müssen Sie length so wählen, dass: length + 100 Byte gleich einem Vielfachen von 2 KByte (auf NK2-Platten) oder 4 KByte (auf NK4-Platten) ist. Damit kann der Plattenplatz optimal genutzt werden. Die 16 Byte Block-spezifische DVS-Verwaltungsinformation stehen somit für Benutzerdaten nicht zur Verfügung. Nähere Information dazu findet sich im BS2000-Handbuch „Einführung in das DVS“. | |||||||||||||||||||||
LSSBS= | number Maximale Anzahl von LSSBs (lokale sekundäre Speicherbereiche), die in einem Vorgang erzeugt werden können. Standard: 8 | |||||||||||||||||||||
MOVE-BUNDLE-MSGS= | Mit diesem Parameter kann für eine Anwendung das automatische Umhängen wartender Asynchron-Nachrichten eines Slave-LTERMs, Slave-LPAPs oder Slave-OSI-LPAPs ohne Verbindung zur Partneranwendung erlaubt werden. | |||||||||||||||||||||
YES | Nach Ablauf der in MAX CONRTIME definierten Wartezeit oder nach 10 Minuten (bei CONRTIME=0) hängt UTM wartende FPUT-Nachrichten automatisch um an einen Slave des Bündels mit aufgebauter Verbindung. | |||||||||||||||||||||
NO | Asynchron-Nachrichten an einen Slave werden grundsätzlich nicht über einen anderen Slave gesendet. Standard: NO | |||||||||||||||||||||
MP-WAIT= | number Der Operand gilt nur für BS2000-Systeme. gibt an, wie viele Sekunden openUTM maximal auf den Anschluss eines Prozesses an einen Common Memory Pool wartet. Standardwert: 180 ACHTUNG! Der Standardwert von 180 Sekunden sollte nur im Ausnahmefall geändert werden, wenn sich beispielsweise ein Prozess mit K078 ENQAR und einem Userdump mit dem Returncode KDCSST01 beendet. | |||||||||||||||||||||
NB= | length legt die maximale Länge eines Arbeitsbereiches fest für:
Anzugeben ist die Länge des größten Nachrichtenbereiches der Teilprogramme in Byte. Standard: 2048 | |||||||||||||||||||||
NRCONV= | number (number of conversations) Es gilt folgender Grenzwert: Anzahl der Benutzerkennungen + Anzahl der Vorgänge, die maximal gekellert werden dürfen (Anzahl der Vorgänge=number * Anzahl der Benutzerkennungen)<= 500000 Wird der Grenzwert 500000 überschritten (durch die Angaben bei NRCONV, in der RESERVE-Anweisung, siehe Abschnitt "RESERVE - Tabellenplätze für UTM-Objekte reservieren", und durch die Anzahl der USER-Anweisungen, siehe Abschnitt "USER - Benutzerkennungen definieren"), dann legt openUTM automatisch weniger Einträge für die Vorgangskellerung an. Es können dann nicht alle Benutzer gleichzeitig number viele Vorgänge kellern. Standard: 0 | |||||||||||||||||||||
OSISHMKEY= | number Der Operand gilt nur für Unix-, Linux- und Windows-Systeme. Schlüssel für das Shared Memory Segment, das bei der Kommunikation über OSI TP von OSS verwendet wird. Für number ist der Schlüssel als Dezimalzahl anzugeben. OSISHMKEY ist Pflichtoperand, falls die Anwendung über OSI TP kommuniziert. | |||||||||||||||||||||
OSI-SCRATCH-AREA= | value Größe in KB eines UTM-internen Arbeitsbereichs zur dynamischen Ablage von Daten, wenn mit dem OSI TP-Protokoll gearbeitet wird. Standard: 256 Auf BS2000-Systemen wird der Arbeitsbereich während des Anwendungslaufs gegebenenfalls automatisch vergrößert. Unix-, Linux- und Windows-Systeme | |||||||||||||||||||||
PGPOOL= | (number,warnlevel1,warnlevel2) legt die Größe des Pagepools in Anzahl UTM-Seiten und die Warnstufen für die Pagepool-Belegung fest. | |||||||||||||||||||||
number | Anzahl der UTM-Seiten, die für den Pagepool in der KDCFILE verwendet werden sollen (siehe Abschnitt „Pagepool"). Die Größe einer UTM-Seite wird im Operanden BLKSIZE= generiert. Standard: 100 Bei einem Wert < 20 setzt KDCDEF ohne Meldung PGPOOL=20. Unix-, Linux- und Windows-Systeme | |||||||||||||||||||||
warnlevel1 | Numerischer Wert (Prozentwert), der angibt, bei welcher Belegung des Pagepool die erste Warnung (Meldung K041) ausgegeben wird. Standard: 80 | |||||||||||||||||||||
warnlevel2 | Numerischer Wert (Prozentwert), der angibt, bei welcher Belegung des Pagepool die zweite Warnung ausgegeben werden soll. Nach Überschreiten von warnlevel2 werden Asynchron-Aufträge abgewiesen. In diesem Fall erhält der Benutzer eine K-Meldung und einem Teilprogramm wird ein entsprechender Returncode übermittelt. Standard: 95 | |||||||||||||||||||||
PGPOOLFS= | number Anzahl der Dateien, auf die der Pagepool aufgeteilt werden soll. Bei PGPOOLFS=0 liegt der Pagepool in der Hauptdatei (auf BS2000-Systemen in der Datei filebase.KDCA, auf Unix-, Linux- und Windows-Systemen in der Datei KDCA im Dateiverzeichnis filebase). Zweite Exemplare bei doppelter Dateiführung (MAX ...,KDCFILE=(...,DOUBLE)) werden bei number nicht mitgezählt. Die Dateinamen vergibt KDCDEF. Standard: 0, d.h. der Pagepool liegt in der Hauptdatei Maximalwert (BS2000-Systeme): 99 (bzw. PGPOOL=number / 2) Minimalwert:
| |||||||||||||||||||||
PGWTTIME= | time Zeit in Sekunden, die ein Teilprogramm nach einem blockierenden Aufruf (z.B. PGWT-Aufruf) maximal auf das Eintreffen von Nachrichten warten darf. Während dieser Wartezeit bleibt ein Prozess der UTM-Anwendung exklusiv für dieses Teilprogramm reserviert. Standard: entspricht time in TERMWAIT=time | |||||||||||||||||||||
PRINCIPAL-LTH= | length Dieser Operand gilt nur für BS2000-Systeme. Maximale Länge eines Kerberos-Principals in Byte. Wenn ein Kerberos-Dialog mit einem Client durchgeführt wird, speichert openUTM die Kerberos-Information in der Länge ab, die sich aus dem Maximum dieser Länge und der bei MAX CARDLTH generierten Länge ergibt. Wenn die Kerberos-Information länger ist, wird sie auf diese Länge verkürzt abgespeichert. Standard: 0 | |||||||||||||||||||||
PRIVILEGED-LTERM= | lterm-name Kennzeichnet ein LTERM als privilegierte Verbindung. Aufträge, die über dieses LTERM an die UTM-Anwendung gerichtet werden, werden von UTM in Situationen, in denen die UTM-Anwendung stark ausgelastet ist, bevorzugt behandelt. Um auch unter Last reaktionsfähig zu sein, werden für eine UTM-Anwendung zusätzliche Prozesse gestartet, die als UTM-System-Prozesse bezeichnet werden. Die UTM-System-Prozesse bearbeiten nur ausgewählte Aufträge. Dies sind in erster Linie interne Aufträge oder Aufträge eines Administrators, der über das privilegierte LTERM an die UTM-Anwendung angemeldet ist. Siehe auch Operand MAX SYSTEM-TASKS auf Abschnitt "MAX - UTM-Anwendungsparameter definieren" . Um diese Funktionalität optimal nutzen zu können, sollte das PRIVILEGED-LTERM immer explizit generiert werden. Nur dadurch können alle Mechanismen greifen, durch die dieses LTERM in Last-Situation bevorzugt werden kann. Im Einzelnen wird Folgendes empfohlen:
Wird über dieses LTERM eine Verbindung aufgebaut, dann gilt Folgendes:
Das LTERM muss in einer LTERM-Anweisung als Dialog-LTERM generiert sein. Wird kein PRIVILEGED-LTERM generiert, so wird es wie folgt dynamisch bestimmt:
| |||||||||||||||||||||
QTIME= | (qtime1, qtime2) Legt die Zeit fest, die ein Vorgang maximal auf das Eintreffen von Nachrichten für Service-gesteuerte Queues warten darf. Die Zeiten gelten für USER-Queues, TAC-Queues und Temporäre Queues. Für das Warten in Dialog- bzw. Asynchron-Vorgängen kann jeweils ein eigener Maximalwert definiert werden. Wird in einem Teilprogrammlauf eine größere Wartezeit angegeben als die in QTIME= generierte, dann setzt openUTM die Wartezeit auf den generierten Wert zurück. | |||||||||||||||||||||
qtime1 | maximale Wartezeit in Dialog-Vorgängen in Sekunden | |||||||||||||||||||||
qtime2 | maximale Wartezeit in Asynchron-Vorgängen in Sekunden Standard: 32767 (Sekunden) | |||||||||||||||||||||
RECBUF= | (number,length) Größe des transaktionsgesicherten Wiederanlaufbereichs definieren. In den Wiederanlaufbereich werden Daten geschrieben, die für den Wiederanlauf nach Transaktions- oder Systemfehler benötigt werden. Zum Wiederanlaufbereich siehe Abschnitt "Wiederanlaufbereich". | |||||||||||||||||||||
number | Anzahl UTM-Seiten pro Prozess, die in der KDCFILE zur Aufnahme von Daten für den Wiederanlauf nach Systemfehler verwendet werden sollen. Die Größe einer UTM-Seite wird mit dem Operanden BLKSIZE= festgelegt. Wählt man diesen Bereich groß, wird die laufende Anwendung weniger belastet. Der Wiederanlauf nach Systemfehler dauert jedoch länger. Ist der Bereich klein, wird die laufende Anwendung stärker belastet, der Wiederanlauf nach Systemfehler ist jedoch schneller. Standard: 100 (pro Prozess) | |||||||||||||||||||||
length | Größe des Puffers in Byte, der pro Prozess der Anwendung zur Zwischenspeicherung von Wiederanlaufdaten zur Verfügung steht. Die Daten werden für den Wiederanlauf nach Transaktions- oder Systemfehler benötigt. Standard: 8192 | |||||||||||||||||||||
RECBUFFS= | number Anzahl der Dateien, auf die der Wiederanlaufbereich aufgeteilt werden soll. Bei RECBUFFS=0 liegt der Wiederanlaufbereich in der Hauptdatei der KDCFILE. Zweite Exemplare bei doppelter Dateiführung (MAX ...,KDCFILE=(...,DOUBLE)) werden bei number nicht berücksichtigt. Die Dateinamen vergibt KDCDEF. number darf nicht größer sein, als die in TASKS= angegebene maximale Prozessanzahl. Geben Sie für number einen größeren Wert an, so wird der Standardwert angenommen. Standard: 0 | |||||||||||||||||||||
REDELIVERY= | (number1, number2) Maximale Anzahl wiederholter Zustellungen einer Asynchron-Nachricht, nachdem der Vorgang bzw. die Transaktion zurückgesetzt wurde. number1 und number2 gelten für unterschiedliche Nachrichtenziele. | |||||||||||||||||||||
number1 | Maximale Anzahl wiederholter Zustellungen für Nachrichten an einen Asynchron-TAC. Die Zustellung wird immer dann wiederholt, nachdem ein Asynchron-Vorgang mit PEND ER/FR oder System PEND ER abnormal beendet wurde, ohne dass zuvor mindestens eine Transaktion erfolgreich abgeschlossen worden war. Ein erneuter Start eines Asynchron-Vorgangs nach PEND RS innerhalb der ersten Transaktion zählt nicht als Neuzustellung! | |||||||||||||||||||||
number2 | Maximale Anzahl wiederholter Zustellungen für Nachrichten an eine Service-gesteuerte Queue. Die Zustellung wird immer dann wiederholt, nachdem die Nachricht verarbeitet und die Transaktion zurückgesetzt wurde. Die Anzahl der erneuten Zustellungen wird beim DGET-Aufruf im KB-Rückgabebereich ausgegeben. Standard: (0, 255) Ein Wert 0 bedeutet, dass die Nachricht nach dem Rücksetzen, abhängig vom Wert in TAC ...,DEAD-LETTER-Q, gelöscht oder in der Dead Letter Queue gesichert wird. Wird ein Wert auf 255 gesetzt, dann wird eine Nachricht ggf. beliebig oft zugestellt. Beachten Sie daher, dass ein solcher Wert zu einer Endlosschleife führen kann, z.B. wenn ein Teilprogramm wegen eines Programmierfehlers zurückgesetzt wird. Außerdem kann die Nachricht bei einer Endlosschleife nicht in der Dead Letter Queue gesichert werden. | |||||||||||||||||||||
REQNR= | number Dieser Operand gilt nur für BS2000-Systeme. Maximale Anzahl der zu einer Zeit für eine Datei in einem UTM-Prozess parallel abgesetzten PAM-Schreib-/Leseaufträge. Mit diesem Wert kann die Parallelität von Ein- und Ausgaben in gewissen Grenzen beeinflusst werden. Standard: 20 | |||||||||||||||||||||
RESWAIT= | (time1,time2) (resource wait) | |||||||||||||||||||||
time1 | Zeit in Sekunden, die ein Teilprogramm maximal auf ein von einer anderen Transaktion gesperrtes Betriebsmittel warten soll: GSSBs, TLSs, ULSs und auf BS2000-Systemen evtl. LTERM-Partner bei ANNOAMSG=N. RESWAIT=0 bedeutet, dass das Anwendungsprogramm nicht wartet. Ist ein benötigtes Betriebsmittel durch eine andere Transaktion gesperrt, erhält das anfordernde Teilprogramm sofort einen entsprechenden Returncode. Standard: 120 Auf BS2000-Systemen ist die reale Wartezeit abhängig von der Genauigkeit, mit der die Börsenwartezeit beim Betriebssystem eingestellt wurde. | |||||||||||||||||||||
time2 | Zeit in Sekunden, die maximal auf ein von einem anderen Prozess gesperrtes Betriebsmittel gewartet werden soll. Wird die maximale Wartezeit time2 überschritten, dann beendet sich die Anwendung abnormal. Sie sollten die Angabe für time2 nicht zu klein wählen, denn bestimmte Aktivitäten in der UTM-Anwendung müssen von einem Prozess durchgeführt und abgeschlossen werden, bevor in einem anderen Prozess die gleichen Aktivitäten angestoßen werden können. Beispiel Insbesondere muss die für time2 angegebene Zeit mindestens so groß sein wie die längste Bearbeitungszeit (Realzeit) der im Folgenden beschriebenen Fälle:
Standard: 300 Wird für time2 der Wert 0 angegeben, nimmt KDCDEF ohne Meldung den Standardwert 300 an. Wird ein Wert zwischen 0 und 300 angegeben, gibt KDCDEF eine entsprechende Meldung aus. | |||||||||||||||||||||
SAT= | (security audit trail) Mindestprotokollierung von Ereignissen mit SAT | |||||||||||||||||||||
ON | Die SAT-Protokollierung wird eingeschaltet. Es wird eine Mindestprotokollierung mit SAT eingeschaltet für folgende Ereignisse:
Die Mindestprotokollierung kann durch Preselection erweitert und gesteuert werden. Die Preselection wird generiert durch die Anweisung SATSEL und den Operanden SATSEL= in den Anweisungen USER und TAC. Durch das Administrationskommando KDCMSAT können die bei der Generierung eingestellten Preselection-Werte geändert werden. | |||||||||||||||||||||
OFF | Die SAT-Protokollierung wird ausgeschaltet. Die SAT-Protokollierung kann mit dem SAT-Administrations-TAC KDCMSAT ein- und ausgeschaltet werden (siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“). Standard: OFF | |||||||||||||||||||||
SEMARRAY= | (number,number1) Dieser Operand gilt nur für Unix-, Linux- und Windows-Systeme. Bereich von Semaphore Schlüssel (semaphore array) für die anwendungsglobalen Semaphore (Prozesssynchronisation). Die Semaphore Schlüssel sind globale Parameter auf Unix-, Linux- und Windows-Systemen. Mit SEMARRAY geben Sie einen Startwert number und eine Anzahl number1 an. openUTM belegt diese Schlüssel, indem vom Startwert ausgehend jeweils 1 addiert wird. Näheres erfahren Sie bei Ihrem System-Administrator. Die Parameter SEMARRAY= und SEMKEY= schließen sich gegenseitig aus. Der Vorteil von SEMARRAY= gegenüber SEMKEY= ist, dass mehr als zehn Semaphorschlüssel belegt werden können. Zur Berechnung der für eine UTM-Anwendung benötigten Semaphorschlüssel lesen Sie bitte die Beschreibung der Systemglobalen Betriebsmittel im openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“. Pflichtoperand, wenn SEMKEY= nicht angegeben wurde. | |||||||||||||||||||||
number | Numerische Angabe des Startwertes | |||||||||||||||||||||
number1 | gibt die Anzahl von Schlüsseln an, die belegt werden sollen. Minimalwert: 1 | |||||||||||||||||||||
SEMKEY= | (number,...) (semaphore key) Semaphore Schlüssel für die anwendungsglobalen Semaphore (Prozess-Synchronisation). Die Semaphore Schlüssel sind globale Parameter auf Unix-, Linux- und Windows-Systemen. Es dürfen max. 10 Semaphore Schlüssel in einer Liste definiert werden. Alle Semaphore Schlüssel (number,...) werden als Dezimalzahlen angegeben. Näheres erfahren Sie bei Ihrem System-Administrator. Die Parameter SEMARRAY= und SEMKEY= schließen sich gegenseitig aus. Der Vorteil von SEMARRAY= gegenüber SEMKEY= ist, dass mehr als zehn Semaphorschlüssel belegt werden können. Zur Berechnung der für eine UTM-Anwendung benötigten Semaphorschlüssel lesen Sie bitte die Beschreibung der Systemglobalen Betriebsmittel im openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“. Pflichtoperand, wenn SEMARRAY nicht angegeben wurde. | |||||||||||||||||||||
SM2= | legt fest, ob die UTM-Anwendung zur Überwachung der Performance Daten an openSM2 liefern soll. | |||||||||||||||||||||
NO | Die Performanceüberwachung mit openSM2 wird für die UTM-Anwendung generell ausgeschlossen. D.h. die UTM-Anwendung kann keine Daten an openSM2 liefern, und der UTM-Administrator kann die Datenlieferung an openSM2 auch nicht einschalten. | |||||||||||||||||||||
OFF | Die UTM-Anwendung kann Daten an openSM2 liefern. Der Administrator muss jedoch die Lieferung der Daten an openSM2 mit dem Administrationskommando KDCAPPL SM2=ON einschalten. Er kann die Lieferung der Daten auch jederzeit mit KDCAPPL SM2=OFF wieder ausschalten. Standardwert: OFF | |||||||||||||||||||||
ON | Die UTM-Anwendung kann Daten an openSM2 liefern. Die Lieferung von Daten wird automatisch beim Start der UTM-Anwendung eingeschaltet. Der Administrator der UTM-Anwendung kann sie jederzeit mit dem Administrationskommando KDCAPPL SM2=OFF wieder ausschalten. | |||||||||||||||||||||
SPAB= | length Maximale Länge des SPAB (Standard Primärer Arbeitsbereich) in Byte Standard: 512 | |||||||||||||||||||||
STATISTICS-MSG= | legt fest, ob openUTM die Statistikmeldung K081 stündlich erzeugen soll oder nicht. | |||||||||||||||||||||
FULL-HOUR | Die Statistikmeldung K081 wird jede Stunde erzeugt und in die SYSLOG geschrieben. Gleichzeitig setzt openUTM folgende Anwendungs-spezifische Statistikwerte auf Null zurück:
| |||||||||||||||||||||
NONE | Die Statistikmeldung K081 wird nicht erzeugt und die oben angegebenen Statistikwerte werden nicht automatisch auf 0 zurückgesetzt. Standard: FULL-HOUR | |||||||||||||||||||||
SYSLOG-SIZE= | size Automatische Größenüberwachung für die System-Protokolldatei SYSLOG durch openUTM generieren.
Der UTM-Administrator kann den generierten Schwellwert verändern und die Größenüberwachung im Betrieb bei Bedarf ein- oder ausschalten (z.B. mit dem Administrationskommando KDCSLOG). Standard: 0 (keine Größenüberwachung) | |||||||||||||||||||||
SYSTEM-TASKS= | Steuert die Anzahl der UTM-System-Prozesse. Um eine Anwendung reaktionsfähig zu halten und auch in diesen Situationen z.B. interne Aufträge zur Transaktionsbeendigung, die Kommunikation zwischen den Knoten einer UTM-Cluster-Anwendung, oder Aufträge eines Administrators bearbeiten zu können, startet UTM zusätzlich zu den vom Anwender generierten und gestarteten Prozessen noch weitere Prozesse, sogenannte UTM-System-Prozesse. Von den UTM-System-Prozessen werden i.A. keine Teilprogrammläufe ausgeführt und sie kommen nur in Engpass-Situationen für interne Aufträge zum Einsatz. Dadurch belasten die zusätzlichen UTM-System-Prozesse den Rechner nur geringfügig. | |||||||||||||||||||||
*STD | *STD bedeutet, dass UTM (bis zu) drei zusätzliche Prozesse für die Anwendung startet, die dann als UTM-System-Prozesse genutzt werden. In Abhängigkeit von der Anzahl der für die Anwendung gestarteten Tasks werden der zweite, vierte und siebte Prozess einer Anwendung ein UTM-System-Prozess. *STD ist der Standardwert. | |||||||||||||||||||||
number | Anzahl der UTM-System-Prozesse, die für die Anwendung maximal zusätzlich gestartet werden sollen. Der Wert 0 bedeutet, dass kein UTM-System-Prozess gestartet wird. Minimalwert: 0 Werte größer 10 werden ignoriert und auf 10 abgebildet. Die nachstehende Tabelle zeigt für den Generierungswert SYSTEM-TASKS=*STD, wie viele UTM-System-Prozesse in Abhängigkeit vom Start-Parameter TASKS zusätzlich gestartet werden:
Werden mehr als drei UTM-System-Prozesse generiert, dann werden in Abhängigkeit des Wertes von SYSTEM-TASKS und der Anzahl gestarteter Prozesse auch der 11., 21., 31., 41., 51., 61. und 71. Prozess ein UTM-System-Prozess. | |||||||||||||||||||||
TASKS= | number Maximale Anzahl der Prozesse, die gleichzeitig für die Anwendung eingesetzt werden können. Pflichtoperand. Minimalwert: 2 Ein Wert < 2 wird von KDCDEF ohne Meldung durch 2 ersetzt. Die aktuelle Anzahl der Prozesse wird beim Start der Anwendung festgelegt. Beim Start können Sie auch TASKS=1 angeben. Der Administrator kann dann die Anzahl der Prozesse im laufenden Betrieb dynamisch anpassen (z.B. mit dem Administrationskommando KDCAPPL). Weder die beim Start angegebene Anzahl der Prozesse noch die vom Administrator eingestellte Anzahl darf den hier generierten Wert überschreiten. | |||||||||||||||||||||
TASKS-IN-PGWT= | number legt die maximale Anzahl der Prozesse der UTM-Anwendung fest, in denen gleichzeitig Teilprogramme mit blockierenden Aufrufen wie z.B. der KDCS-Aufruf PGWT ablaufen dürfen. Der Wert von TASKS-IN-PGWT muss kleiner sein als der Wert des Operanden TASKS. Wird TASKS-IN-PGWT=0 angegeben, so kann keine TAC-Klasse und kein Transaktionscode (TAC) generiert werden, für die/den blockierende Aufrufe erlaubt sind (siehe TAC/TACCLASS ...,PGWT=). In diesem Fall muss in allen TACCLASS- und TAC-Anweisungen PGWT=NO angegeben werden, siehe hierzu auch die Anweisungen TAC im Abschnitt "TAC - Eigenschaften von Transaktionscodes und TAC-Queues festlegen" und Abschnitt im Abschnitt "TACCLASS - Prozess-Anzahl für TAC-Klassen festlegen". Standardwert: 0 | |||||||||||||||||||||
TERMWAIT= | time (terminal wait) Zeit in Sekunden, die in einer Mehrschritt-Transaktion (d.h. nach PEND KP) maximal zwischen einer Dialog-Ausgabe an den Partner und der anschließenden Dialog-Antwort vom Partner verstreichen darf. Dieser Wert gilt für alle Dialoge, in denen der Partner die Client-Rolle spielt (Terminals, UPIC-Clients, OSI TP-, LU6.1- und LU6.2-Auftraggeber). Bei Terminal-Clients z.B. entspricht time der Denkzeit des Benutzers nach PEND KP. Standard: 600 | |||||||||||||||||||||
TRACEREC= | number Maximale Anzahl der Einträge in den von openUTM geführten Prozessspezifischen Trace-Bereichen. Dieser Wert gilt für die Trace-Bereiche
openUTM schreibt in diese Bereiche Trace-Informationen für Diagnosezwecke. Länge der Einträge:
Standard: 32500 Ein Wert < 1 wird von KDCDEF ohne Meldung durch den Standardwert ersetzt, ein Wert > 32500 durch den Maximalwert. | |||||||||||||||||||||
TRMSGLTH= | length Legt den Maximalwert fest für:
Standard: 32700 Byte BS2000-Systeme: | |||||||||||||||||||||
USLOG= | legt die einfache oder doppelte Dateiführung für die Benutzer-Protokolldatei USLOG fest. | |||||||||||||||||||||
SINGLE | Die Benutzer-Protokolldatei soll einfach geführt werden. Standard: SINGLE | |||||||||||||||||||||
DOUBLE | Die Benutzer-Protokolldatei soll aus Sicherheitsgründen doppelt geführt werden. Näheres zur Benutzer-Protokolldatei finden Sie im openUTM- Handbuch „Einsatz von UTM-Anwendungen“. | |||||||||||||||||||||
VGMSIZE= | number Dieser Operand gilt nur für BS2000-Systeme. Für das Vorgangs-Memory eines SQL-Datenbanksystems können Sie mit diesem Parameter einen Pufferbereich in der angegebenen Größe generieren. Damit wird auch der Anteil eines Benutzers am Pagepool begrenzt. VGMSIZE= wird in KB angegeben. Ist der zum PEND-Zeitpunkt aktuell zu sichernde VGM-Bereich größer als number, wird der Vorgang mit PEND ER abgebrochen. Standardwert: 32 KB | |||||||||||||||||||||
XAPTPSHMKEY= | number Dieser Operand gilt nur für Unix-, Linux- und Windows-Systeme. Schlüssel für das XAPTP Shared Memory Segment. Die Schlüssel sind globale Systemparameter. XAPTPSHMKEY ist Pflichtoperand, falls die Anwendung über OSI TP-Protokoll kommuniziert. | |||||||||||||||||||||
Die folgende Tabelle zeigt den Verwendungszweck der einzelnen Operanden der MAX-Anweisung sowie deren Standardwerte im Überblick:
Operand | Verwendungszweck | Pflicht | Standardwert |
|---|---|---|---|
betriebssystemunabhängige Operanden | |||
APPLIMODE= | Wahl einer UTM-Variante: UTM-S oder UTM-F | SECURE | |
APPLINAME= | Name der UTM-Anwendung | X | - |
ASYNTASKS= | Asynchron-Verarbeitung (Anzahl Prozesse für Asynchron-Verarbeitung und gleichzeitig offener Asynchron-Vorgänge) | 1, 1 | |
BLKSIZE= | Größe einer UTM-Seite festlegen | 2K (in UTM-Cluster-Anwendungen 4K oder 8K) | |
CACHESIZE= | Tuningmaßnahme (Größe und Eigenschaften des Cache-Speichers) | Systemabhängig: BS2000-Systeme: (1024,70%, NORES, PS) | |
CLRCH= | Zeichen zum Überschreiben von KB und SPAB | keines | |
CONN-USERS= | Anzahl der gleichzeitig aktiven Benutzer bzw. Clients beschränken | Systemabhängig: | |
CONRTIME= | automatischer Verbindungsaufbau (Wartezeit für Wiederaufbau einer Verbindung) | 10 Min | |
DATA-COMPRESSION= | Datenkomprimierung steuern | STD | |
DEAD-LETTER-Q-ALARM= | Überwachung des Nachrichten-Aufkommens in der Dead Letter Queue | 0, d.h. keine Überwachung | |
DESTADM= | asynchrone Administration | keine | |
DPUTLIMIT1= | zeitgesteuerte Aufträge (obere Schranke) | 360 Tage | |
DPUTLIMIT2= | zeitgesteuerte Aufträge (untere Schranke) | 1 Tag | |
GSSBS= | GSSB-Speicherbereiche (Maximal-Anzahl) | 32 | |
HOSTNAME= | virtueller Hostname für die UTM-Anwendung | 8 Leerzeichen | |
KB= | maximale Länge des Kommunikationsbereich | 512 | |
KDCFILE= | KDCFILE zuordnen | X | - |
KEYVALUE= | Zugriffsschutz nach dem Lock-Keycode-Konzept (Nummer des größten Keycodes) | 32 | |
LEADING-SPACES= | Führende Leerzeichen in Nachrichten von Terminals oder von TS-Anwendungen (PTYPE=APPLI/SOCKET) an das Teilprogramm weiterreichen | NO | |
LPUTBUF= | Protokollierung von Benutzerdaten mit LPUT (Anzahl PAM-Seiten im Pagepool) | 1 | |
LPUTLTH= | Protokollierung von Benutzerdaten mit LPUT (Maximale LPUT-Nachrichtenlänge) | 1948 Byte | |
LSSBS= | LSSB-Speicherbereiche (maximale Anzahl) | 8 | |
MOVE-BUNDLE-MSGS= | automatisches Umhängen wartender Asynchron-Nachrichten eines Slave-LTERMs, Slave-LPAPs oder Slave-OSI-LPAPs | NO | |
NB= | maximale Länge des Nachrichtenbereichs | 2048 | |
NRCONV= | Maximalzahl gekellerter Vorgänge | 0 | |
OSI-SCRATCH-AREA= | Größe für UTM-internen Arbeitsbereich in KB | 256 | |
PGPOOL= | Pagepool-Größe und Warnstufen | 100 UTM-Seiten, 80%, 95% | |
PGPOOLFS= | Tuningmaßnahme: Aufteilung Pagepool | Pagepool in KDCFILE | |
PGWTTIME= | maximale Zeit für den KDCS-Aufruf PGWT | TERMWAIT=time | |
PRIVILEGED-LTERM= | Privilegiertes LTERM festlegen | - | |
QTIME= | Maximale Zeit für das Warten auf Nachrichten von Service-gesteuerten Queues festlegen | 32767 Sekunden | |
RECBUF= | Tuningmaßnahme:Größe Wiederanlaufbereich in KDCFILE bzw. Prozess-spezifischem Systemspeicher | 100 UTM-Seiten pro Prozess, 8192 Byte | |
RECBUFFS= | Tuningmaßnahme: Aufteilung Wiederanlaufbereich | Wiederanlaufbereich in KDCFILE | |
REDELIVERY= | Maximale Anzahl wiederholter Zustellungen einer Asynchron-Nachricht festlegen | 0 für UTM-gesteuerte Queues, 255 für Servicegesteuerte Queues | |
RESWAIT= | Wartezeit auf ein durch eine andere Transaktion (time1) bzw. durch einen anderen Prozess (time2) gesperrtes Betriebsmittel (z.B. GSSB, TLS) | 120 sek / 300 sek | |
SM2= | Lieferung der UTM-Daten an SM2 zulassen und ein-/ausschalten | OFF | |
SPAB= | maximale SPAB-Länge | 512 | |
STATISTICS-MSG= | Statistikmeldung K081 erzeugen und Zählerstände automatisch zurücksetzen lassen | FULL-HOUR | |
SYSLOG-SIZE= | automatische Größenüberwachung der SYSLOG-Datei durch openUTM festlegen | 0 | |
SYSTEM-TASKS= | Anzahl UTM-System-Prozesse | *STD | |
TASKS= | Anzahl UTM-Prozesse | X | - |
TASKS-IN-PGWT= | Anzahl der Prozesse für blockierende Aufrufe | 0 | |
TERMWAIT= | maximale Wartezeit auf eine Dialog-Eingabe innerhalb einer Transaktion | 600 sek | |
TRACEREC= | Platz reservieren für Diagnoseinformation (Anzahl der Einträge) | 32500 | |
TRMSGLTH= | maximale Nachrichtenlänge | 32700 Byte | |
USLOG= | Benutzer-Protokolldatei einfach oder doppelt führen | einfach | |
BS2000-spezifische Operanden | |||
BRETRYNR= | Kommunikation mit BCAM (Anzahl Versuche der Nachrichtenübergabe) | 10 | |
CARDLTH= | Ausweisleser für KDCSIGN-Prüfung | 0 | |
CATID= | Katalogkennungen für die KDCFILE festlegen | Standard-CATID | |
LOCALE= | Standard-Sprachumgebung festlegen | Leerzeichen | |
LOGACKWAIT= | Unterstützung von Ausgabegeräten (Wartezeit auf Quittung) | 600 sek | |
MP-WAIT= | maximale Wartezeit pro Prozess für Anschluss an Common Memory Pool | 180 sek | |
PRINCIPAL-LTH= | maximale Länge eines Kerberos-Principals in Bytes | 32 | |
REQNR= | Tuningmaßnahme: PAM-I/O-Aufträge (maximale Anzahl paralleler Aufträge) | 20 | |
SAT= | Mindestprotokollierung von Ereignissen mit SAT | OFF | |
VGMSIZE= | Größe des Pufferbereichs für das Vorgangsgedächtnis eines SQL-Datenbanksystems | 32KB | |
Unix-, Linux- und Windows-spezifische Operanden | |||
CACHESHMKEY= | Schlüssel für Shared Memory Segment (anwendungsglobale Puffer für Dateizugriffe) | X | - |
IPCSHMKEY= | Schlüssel für Shared Memory Segment (Kommunikation zwischen UTM-Prozessen) | X | - |
IPCTRACE= | Anzahl UTM-Einträge in IPC-Trace festlegen | 1060 | |
KAASHMKEY= | Schlüssel für Shared Memory Segment (anwendungsglobale Daten) | X | - |
OSISHMKEY= | Schlüssel für Shared Memory Segment von OSS | bei OSI TP | - |
SEMARRAY= | Bereich von Semaphore Schlüssel für anwendungsglobale Semaphore (alternativ zu SEMKEY) | X | - |
SEMKEY= | Semaphore Schlüssel für anwendungsglobale Semaphore (alternativ zu SEMARRAY) | X | - |
XAPTPSHMKEY= | Schlüssel für das XAPTP Shared Memory Segment | bei | - |