Unglaublich aber Wahr

[woodstock99]

ich will nicht mehr....
heute hats wieder nicht funktioniert...
ich gebs auf ....
weiß nicht was da los ist

[Pikachu]

Wie sieht denn der OVRDBF genau aus?

[woodstock99]

OVRDBF FILE(XXXX) TOFILE(XXXX/XXXXX) +
OVRSCOPE(*JOB) OPNSCOPE(*JOB)

[Pikachu]

Ok, das sieht normal aus. Vielleicht ist ja im RPG-Programm was mit MOVELs wo die Zielvariablen nicht mit Leerzeichen aufgefüllt werden oder sowas in diese Richtung?

[woodstock99]

@pikachu...

nö das isses nicht...
ich glaub es liegt am wetter.... wenns bei uns regnet dann gehts wenn nicht dann gehts nicht....

der oberhammer ist ja wie gesagt gestern hats funktioniert
wie die monate davor auch ....
wie gesagt hab sowas noch nie erlebt uns kapier es auch überhaupt nicht.. null , nothing, niente

[BenderD]

... mit dem Gejammer wird das nix, das Problem sitzt meistens vor dem Bildschirm!

D*B

@pikachu...

nö das isses nicht...
ich glaub es liegt am wetter.... wenns bei uns regnet dann gehts wenn nicht dann gehts nicht....

der oberhammer ist ja wie gesagt gestern hats funktioniert
wie die monate davor auch ....
wie gesagt hab sowas noch nie erlebt uns kapier es auch überhaupt nicht.. null , nothing, niente

[cbe]

OVRDBF FILE(XXXX) TOFILE(XXXX/XXXXX) +
OVRSCOPE(*JOB) OPNSCOPE(*JOB)

Hallo Woodstock,

gibt es in dem rufenden Programmbaum evtl. einen gleichlautenden OVRDBF?
Dann greift dieser OVRDBF nicht, da die AS400 dann auf den vorigen zugreift (um das zu verhindern kann man den Parameter SECURE auf *YES stellen)

Und eine Idee zum Debuggen:
Mach den Ablauf ganz normal im kompletten Programmbaum und debugge von einer anderen Sitzung aus:
1. STRSRVJOB ErsteSitzung
2. STRDBG PROGRAMM
3. Aufruf in ersterSitzung

Evtl. fällt Dir dann was auf.
Dann hast Du auch Zeit satt, die OVRs und offenen Dateien zu prüfen.

Viel Erfolg
Christian

[woodstock99]

moin moin,

@cbe...

also ich habe nur ein cl programm das 21 solcher ovrdbfs enthält wobei die anzahl ja für die tonne ist.. diese cl called mein programm...

zum testen der offenen pfade usw habe ich bis jetzt halt immer z.b wenn ich ein programm debuge die methode

shift + esc drücken , dann 3 eingeben . dann f10 und zusatzzahl die 14 .... dann sehe ich ja auch die offenen pfade usw.. und die passen (((......

aber zu jugend forscht zwecken teste ich deine variante gleich mal aus

[woodstock99]

@cbe


1. STRSRVJOB ErsteSitzung
2. STRDBG PROGRAMM
3. Aufruf in ersterSitzung



1. STRSRVJOB ErsteSitzung mit attributen der zweiten

3 .. aufruf in zweiter sitzung oder??

[BenderD]

... das ist soweit alles perfekt, aber wenn ich das alles richtig verstanden habe, hat es ja beim debug immer gefunzt und ist dann irgendwann (wenn keiner geguckt hat) schief gegangen. Der Punkt ist also: die Konstellation zu finden, wo es nicht ging! Dafür gibt es zwei Ansatzpunkte:
a) Journalisierung der betreffenden Datei (oder besser aller)
b) verbessertes Errorhandling im Programm
Am Besten beides!!!
zu b: minimal bei dem verdächtigten chain bei nicht gefunden alle Informationen protokollieren (z.B. per QMHSNDPM eine CPF9898 an das Joblog schicken mit Inhalt der Keywerte als Hexadecimalwerte, sowie die Informationen aus der einzubauenden INFDS

D*B

moin moin,

@cbe...

also ich habe nur ein cl programm das 21 solcher ovrdbfs enthält wobei die anzahl ja für die tonne ist.. diese cl called mein programm...

zum testen der offenen pfade usw habe ich bis jetzt halt immer z.b wenn ich ein programm debuge die methode

shift + esc drücken , dann 3 eingeben . dann f10 und zusatzzahl die 14 .... dann sehe ich ja auch die offenen pfade usw.. und die passen (((......

aber zu jugend forscht zwecken teste ich deine variante gleich mal aus

[cbe]

Hallo Woodstock,

Debuggen eines anderen Jobs ist nicht so schwierig und oft hilfreich:


nimm an Du hast 2 Sitzungen:
SESSIONA - hier willst Du Dein Programm P aufrufen
SESSIONB - hier willst Du debuggen


In SESSIONB aufrufen:

STRSRVJOB SESSIONA
(wenn mehrere gefunden werden, den aktiven mit 1 auswählen)

STRDBG P und Haltepunkt setzen
(bzw. STRISDB je nachdem)


Anschl. in SESSION A das problematische Programm aufrufen (dort ohne Debug)
Wenn P den Haltepunkt erreicht, geht in SESSIONB der Debugger an.


Um den Job genauer anzuschauen könntest du in SESSIONC aufrufen:
WRKJOB SESSIONA und z.B. die offene Datei prüfen.



Das funktioniert so ähnlich übrigens auch mit Batch-Jobs

Gruß, Christian

[woodstock99]

@cbe ...

danke nochmal für deine genauere ausführung aber das hatte ich schon gechecked .... .. mein post sollte eigentlich nur ein hinweis sein das punkt drei in einer zweite sitzung gemacht wird....

aber ..... uPPPPSSSS sorry das sind frage zeichen.. bin auch schon blöd.... sorry dast deswegen soviel tippseln hast müssen

@bender danke für den tipp
aber ich bin heute nicht dazugekommen.....
aber heute ist es wieder gelaufen...
ich hab keine ahnung warum..



der chain müsste immer klappen weil..

ich verwende das feld länderkennzeichen aus dem kundenstammsatz und mache dann einen chain auf die länderdatei selber und lese einen wert aus....

falsche werte können im länderkennzeichen nicht drin stehen weil ersten wird bei der erfassung gegen tabelle geprüft und zweitens habe ich schon die länderkennzeichen im kundenstamm kontrolliert ob die vom wert her passen und die passen alle...