View Full Version : CPYSPLF unterschiedliches Verhalten im Batch und interaktiv
Seiten :
1
2
3
4
5
6
[
7]
8
Wie ist das Jobdatumsformat der beiden Jobs? Was steht in &PFAD?
Das ist ein Job: Hauptprogramm erstellt 1 oder 2 Dateien, welchen dann an unterschiedliche CL-Pgm Übergeben werden. Aus diesen wird dann das letzte CL aufgerufen, welches den CPYSPFL machen soll.
Haben uns die variablen ausgeben lassen wollen mit sndpgmsg aber das fliegt auch.
Da ich Systemmässig nicht so bewandert bin gehe ich nach der Mittagspause mit der letzten Antwort von Baldur zu meinen Kollegen in Operations.
Dann lass dir doch endlich mal den Zugang zum System geben!
Mit diesem ewigen stochern im Nebel kommst du nicht weiter und mit Raten kommen wir nicht weiter.
Bisher war es bei der AS/400 immer so, dass man beim Auftreten des Fehlers die besten Analyse-Möglichkeiten hat.
Bei Windowsprogrammen ruft der Kunde gerne an mit "Windows hat ein Problem festgestellt und das Programm muss beendet werden" und fragt dann "Warum? Können Sie mir da helfen?".
... MCH3601 beim DMPCLPGM und SNDPGMMSG ist doch eindeutig, da fehlt es nur an Einsicht.
Ende 2016 gabs wohl eine Änderung "Parameter verlängern".
Wurden auch alle geänderten Programme aufs Kundensystem kopiert?
Je nach Aufruf aus einem COBOL-PGM
WRK-EMAIL-INTERN-MAILADDI PIC X(200).
WRK-EMAIL-INTERN-PGM PIC X(10).
CALL 'LEACDTZET' USING WRK-EMAIL-INTERN-MAILADDI
WRK-EMAIL-INTERN-PGM
oder aus einem CL-PGM
DCL VAR(&MADDI) TYPE(*CHAR) LEN(200)
DCL VAR(&MPGM) TYPE(*CHAR) LEN(10)
CALL PGM(LEACDTZET) PARM(&MADDI &MPGM)
Ende 2016 gabs wohl eine Änderung "Parameter verlängern".
Wurden auch alle geänderten Programme aufs Kundensystem kopiert?
Hallo,
ich installiere immer alle Programme, da ich in allen die eine oder andere kleine Adaptierung auf Grund neuer Anforderungen machen musste.
Daher sind auf Test- und Produktivsystem die Objekte auf gleichem Quellcode basierend gewandelt und verschickt.
Nun, der obige Hinweis kann da durchaus schon mal geprüft werden.
Bekommt ein Programm einen kürzeren Parameter als es erwartet, überschreibt dieses durchaus Daten, die hinter dem übergebenen Inhalt liegen können.
Denn schließlich darf sich jedes Programm darauf verlassen, dass es den Platz des Parameters vollständig verwenden darf.
Dadurch kommt es aber durchaus zu Überschreibungen anderer Inhalte, an denen aber auch schon mal Pointer stehen könnten. Werden diese nun zerstört, kommt es durchaus später zu Ungereimtheiten wie MCH3601.
Da gibts eine Sonderbehandlung auf System ZL958 ...
Wie sind die beiden Parameter im Programm LEACLUSR definiert?
IF COND(&SYSTEM *EQ 'ZL958') THEN(DO)
CALL PGM(LEACLUSR) PARM(&USER &NAME)
ENDDO
IF COND(&SYSTEM *NE 'ZL958') THEN(DO)
CHGVAR VAR(&NAME) VALUE(&SYSTEM)
ENDDO
Da gibts eine Sonderbehandlung auf System ZL958 ...
Wie sind die beiden Parameter im Programm LEACLUSR definiert?
Danke, das war es. Vor wenn man dann in Ruhe und nicht unter dauerndem Druck der Kollegen nachschaut findet man den Fehler.
Vor lauter Variablen einfach immer die falschen nachgeschaut.
Nun, ich wollte gerade mal empfehlen, einfach als letzte Variable im CL eine 5K-Variable zu definieren.
Der CLP-Compiler legt hinter den lokalen Variablen noch jede Menge weitere, initialisierte, Variablen und Pointer an, die durch einen Pufferüberschreiber zerstört werden.
Nach 68 Posts doch endlich den Fehler gefunden.
Vielleicht sollte man generell in seinen CLP's einfach eine 5/10k-Variabiable zum Schluss definieren;-).
@Baldur
Asche über mein Haupt aber das war wieder einmal so wie immer.
Du schreibst einen Job aus mehreren Programmen, dann kommt eine neue Anforderung, Du erweiterst das ganze und machst einen Flüchtigkeitsfehler. Dann versuchst Du diesen zu finden, was meist nicht gelingt bis jemand Fremder mit Grundwissen der Materie drüberschaut und schon ist er gefunden.