Abbruch wegen E/A-Operation auf geschlossene Datei

[M Scheid]

Mein Problem ist folgendes:
Aufruf eines Pgm, in dem eine Datei (Printerfile) mit UsrOpn definiert ist. Am Anfang des Programms wird die Datei durch Open geöffnet, es erfolgt die Ausgabe und am Ende eine Close-Anweisung. Beim ersten Aufruf gibt es keinerlei Probleme. Wird das Pgm danach ein zweites Mal aufgerufen, erfolgt der oben genannte Abbruch.

Weitere Infos:


Abbruch erfolgt auf i5 mit V5R3, auf einer i5 mit V5R2 funktioniert alles wie es soll (mehrfacher Aufruf hintereinander möglich)
Es spielt keine Rolle ob es sich bei dem Pgm um RPG oder RPGLE handelt.
Es spielt auch keine Rolle, ob Pgm mit V5R1 oder V5R2 umgewandelt wurde.
Wenn ich das Pgm debugge, sind alle Parameter, Variablen und der Ablauf beimn ersten Aufruf ok. Beim zweiten Aufruf erfolgt der Abbruch direkt nach Aufruf des Pgm in Headerzeile. Es wird keine C-Bestimmung abgearbeitet.
Wenn ich mir nach dem ersten Aufruf den Job ansehe, ist alles wie es sein soll: entsprechende Datei ist geschlossen, keine Dateiüberschreibungen vorhanden, SPLF aus erstem Druck ordnungsgemäß erstellt
Ich hoffe es kann mir jemand weiter helfen. Besten Dank im Voraus.

[Fuerchau]

Ggf. ein Problem bei der Aktivierungsgruppe.
Versuche es mal mit ACTGRP(*NEW), zusätzlich Meldung an IBM.

[kuempi von stein]

...Versuche es mal mit ACTGRP(*NEW)

wo gibt man diesen Parameter an, wenn man ein "Stand-Alone-RPG-Proramm" hat, welches mit CRTRPGPGM erstellt wird?

Ich tippe auf Programmfehler/Logikfehler. Möglicherweise schwirrt da nen Objekt mit gleichen Namen rum?

Und das die Meldung schon beim Programmaufruf kommen soll, finde ich absolut merkwürdig.

k.

[M Scheid]

Habe ich soeben getestet, leider erfolgt der Abbruch immer noch.

Eins hatte ich vergessen zu erwähnen: Ein Workaround ist, dass der Fehler nicht auftritt, wenn ich in einem vorhergehenden Pgm den Befehl RCLRSC absetze der Fehler nicht auftritt.

[M Scheid]

wo gibt man diesen Parameter an, wenn man ein "Stand-Alone-RPG-Proramm" hat, welches mit CRTRPGPGM erstellt wird?

Ich tippe auf Programmfehler/Logikfehler. Möglicherweise schwirrt da nen Objekt mit gleichen Namen rum?

Und das die Meldung schon beim Programmaufruf kommen soll, finde ich absolut merkwürdig.

k.

Wenn es ein Logik-Fehler wäre, dürfte es beim ersten Mal schon nicht funktionieren.

Die Aktivierungsgruppe kann beim Umwandeln eine RPGLE Pgms geändert werden unter den Zusätzlichen Attributen ist Standardaktivierungsgruppe auf *NO zu setzen, dann erscheinen weitere Parameter.

[Fuerchau]

Da scheint irgend ein interner Status noch nicht zu stimmen.
RCLRSC ist sicherlich nicht falsch, zusätzlich bei PGM-Ende *INLR=*ON sicherstellen.

@Kuempi:
Das geht nur bei ILE. OPM landen immer in der *DFTACTGRP, da reicht aber RCLRSC (was ich sowieso immer grundsätzlich einbaue).

[M Scheid]

Mit *INLR = *ON gehts, auch wenn man danach RCLRSC weglässt.

Was mich aber irritiert ist, dass es auf der einem i5 auch mit Return und ohne RCLRSC geht und es sind die gleichen Pgms mit dem gleichen Objektstand und der gleichen Source.

[kuempi von stein]

Hello Fuerchau,

sorry für meine provokante Frage.
Ich wollte nur das Argument


Es spielt keine Rolle ob es sich bei dem Pgm um RPG oder RPGLE handelt.

entkräften.
Das da in der ACTGRP was nicht korrekt läuft, war eigentlich klar.

Und ein fehlendes *INLR=*ON IST ein Programmiererfehler. :-))

Das haben unsere Jungs schon vor 20 Jahren als erste C-Anweisung gemacht. (Die RPG-Logik ausser Kraft setzen)
Und dann nen Do *Hival hinterher... *lach*
Bis auf die wenigen Ausnahmen wo es noch gebraucht wird...

Anyway.. ich rede zuviel und arbeite zu wenig.

Bye

k.

[Fuerchau]

@M Scheid
Ich würde auf jeden Fall eine Fehlermeldung an IBM schicken !

@Kuempi
*INLR=*OFF kann schon Sinn machen, da ein wiederholter Aufruf dann schneller ist. Insbesonders wenn man nur kleine Routinen im Programm hat.
Bei ILE macht man das ja nun wohl mit SRVPGM'n, aber wer redesigned schon seine alten Anwendung ausser per CVTRPGSRC ;)