Wir haben Heute die NOP Version 5.3.1 in unserer Testumgebung installiert. In kürze werden wir über unsere Erfahrungen an dieser Stelle berichten. :roll:
Wer hat schon die 5.3.1 installiert? :?:
Gruß Torsten
Seit 22.04. im BS2000 installiert (Testumgebung) aber noch nicht näher angeschaut. Läuft aber anscheinend, hab noch keine Fehlermeldung von den laufenden Testjobs … 
GUI kommt im Laufe der Woche noch dazu (wenn ich denn mal Zeit finde).
Hallo,
wir haben folgende erste Erfahrung bei der Einführung von NOP 5.3 gesammelt.
- unbedingt die SORTSIZE beachten bei der Datenmigration (JOB E.I082)
- SAT 3.3.1 RCFIND und RCGET (neu) auf off setzen
- kopieren von SATSLS-P in die SYSEOR
Gruß Tade
das ist immer ein laufender Punkt, gerade bei großen Umgebungen :lol:
das betrifft die Steplibs - siehe auch Document ID: 309884 in der Knowledge Base - funktioniert NOPSLS-P nicht mehr/falsch ??
hm - was ist der Grund, dass ihr auf Response Code 113 anders reagiert ?
Gruß Uli
Guten Morgen und Danke Ulli das du immer mal reinschaust.
Vielleicht kommen ja noch ein paar mehr User dazu.
Wir haben dann schon einen Fehler gefunden, oder es ist so gewollt?
Bei Symbolen, die mit “P-******” als Symbolnamen definiert sind, wird von dem API NOPSY4N in der Funktion T kein Wert mehr geliefert. RC=1 Symbol nicht gefunden. 
Ich werde hierzu einen Incident erstellen.
Gruß Torsten
Hallo Ulli,
nach der Migration funktionierte NOPED–P nicht richtig.
Ich sollte vom Support aus die SATSLS-P aus der SYSSAT nach SYSEOR kopieren. Sollte mit den SP1 korrigiert sein.
Default ist RCFIND und RCGET auf on gesetzt.
Fehlerbild
Naechste geplante Netzwerk-Starts wurde nicht angezeigt mit Fehlermeldung : Response Code 113
Gruß Tade
NxtSt (PF11) bringt bei mir einen Fehler 3113 bei SYSEOR/TA-LI–P
das dürfte auch der eure sein ?!!!
über die gerade installierte GUI kann ich mir über Allgemein/Nächste Aktivierungen was anzeigen lassen
RCFIND ist hier mit Hacken, RCGET ohne …
Gruß Uli
Hallo Ulli,
ich hatte das gleiche festgestellt.
Laut Aussage Support sollen beide Parameter auf off gestellt werden.
Hallo Ulli,
habt ihr im Test auch das NOM aktiv?
Wir haben einen Fehler im NOP Log.
NOM API-Fehler 9152 ······························
NAT5999 - ENTIRE SYSTEM SERVER node not active.
:evil:
Was kann das sein?
Es werden keine dateien bzw. Sysout an das NOM übergeben.
Torsten
RCGET und RCFIND =OFF kann ich mittlerweile positiv bestätigen, hilft :idea:
NOM klappt hier
1615 27.04 13:37 Deadline, neu: 28.04.10 12:30 ···············
1615 27.04 13:37 Gestartet: JobId 3958 Kn. 45 UserId ESM2 RZ ·
1615 27.04 13:38 Ok beendet ··································
1615 27.04 13:38 Uebergabe an NOM initialisiert (Sysout) ·····
1615 27.04 13:38 NOM < (45) $ESM2.AV.TEST-NODES.1615.045-BS2 ·
1615 27.04 13:38 Sysout-Datei an NOM uebergeben ··············und kommt auch an
13:38:52 NOM7015 Benutzt UEXXMLSY/SYSNOMU um XMLOUT zu verarbeiten.
13:38:52 NOM7016 Report XMLOUT / 1390899 geoeffnet.
13:38:52 NOM7016 Report SYSOUT-2 / 1390897 geoeffnet.
13:38:52 NOM7016 Report ERROR-SYM / 1390898 geoeffnet.
13:38:52 NOM4205 37 Zeilen in (NOM/40/138) geladen.
13:38:52 NOM7015 Benutzt UEXREP6/FRIES um SYSOUT-2 zu verarbeiten. evtl. abweichende Version ??? NOM3216, ESY342 hier
Hallo Ulli,
Danke für die Antwort.
Mit welcher NPR Version seit ihr unterwegs?
Wir haben V3.4.2 im Einsatz.
letzte Zeile meines Posts - dummerweise neumodisch als ESY bezeichnet
scheint mir die gleiche wie bei euch …
Hallo,
dürch ein altes NOMTP01N in der SYSNOMU ist der NOM API-Fehler 9152 (NAT5999 - ENTIRE SYSTEM SERVER node not active) aufgetreten.
Gruß Tade
:!:
eben im KnowledgeCenter drüber gestolpert:
es gibt seit gestern das erste Fix zu
- NOP531 (Document ID: 324629) und
- SAT331 (Document ID: 322755)
Hallo zusammen !
Seit vorgestern läuft bei uns NOP531 mit CF1 in einer Testumgebung unter z/OS. Installation war insgesamt problemlos.
Ein wenig gekämpft habe ich mit den Einträgen im SYSSATU(SATPnnn): Im SATSTART-Teil kann man jetzt den SATVERS-Parameter für NOP weglassen, für den RPC ist aber nach wie vor der alte Eintrag nötig (SATVERS=32); ansonsten gibt es einen ‘RPCWATCH (0940) - unexpected *DATA 5’ in der WATCHDOG-Task.
Im OGC-Diagramm gibt es einige nette Verbesserungen, z.B. Tooltip-Funktion (siehe OGC-ReleaseNotes): Positionieren des Cursors auf eine Linie zeigt Start und Endpunkt der Linie.
Viele Grüße
Reiner
Hallo,
zur Info.
Nach einspielen vom NOP 5.3.1 SP1 tritt bei uns folgender Fehler auf.
NAT1316 in EJANOM-P (4475)
weiter
EOR2064 in Task 4 (eoj handler)
An die SAG gemeldet
für die SYSOUT-Übergabe kann ich das so nicht bestätigen
13:16 Ok beendet ·······························
13:16 Uebergabe an NOM initialisiert (Sysout) ··
13:17 NOM < (25) $AV.AV.TEST-NODES.1631.025-BS2
13:17 Sysout-Datei an NOM uebergeben ···········wo tritt das bei euch auf, Tade :?:
Hallo Ulli,
genaues kann Bernd Miltzow (AV) dazu sagen.
Ich musste wieder auf NOP 5.3.1 ohne SP zurückfallen.
Gruß Tade
Hallo Ulli,
so richtig was Genaues kann ich auch nicht dazu sagen. Nur soviel:
Der Fehler tritt beim ersten Job auf, der in den Outputbedingungen Natural-Prozeduren aufruft. In diesen Prozeduren kommen die API’s NOPSYR2N und NOPUSY4N zur Ausführung. Leider sind die LOG’s durch das Zurücksetzen der DB wieder weg. So bleibt es erstmal bei dieser Vermutung.
Gruß Bernd
Hallo NOP531 - Nutzer,
bei uns ist NOP531 seit 21.05.2010 auf der Testumgebung.
Wir haben ein Incident aufgemacht, da Nutzer die nicht fuer SYSDBA zugelassen sind in der Netzwerk-Verwaltung bzw. Aktive Job-Netzwerke mittels “M” wie aendern auf die Mastersymboltabelle A von SYSDBA Zugriff haben. Zugriff bedeutet hier lesen, schreiben und löschen.
Das in der Systemverwaltung von NOP angelegte Nutzerprofil wird in der Netzwerkverwaltung (Master bzw. Aktiv) bei dem Zugriff auf die Symboltabellen völlig ignoriert!
Gruß Beate