Python script unter QSH und Fehlerhandling

[itec01]

Hallo,
wie kann ich am besten Fehler im Python Script ermitteln?
Wird aufgerufen unter QSH und sollte einen Fehler zurückgeben.
Lt. Google wäre STDOUT eine Variante, nur wenn das auch nicht klappt. Es sollte irgendwie etwas globales sein.
Danke schon mal.
Klaus

[Fuerchau]

Python hat doch eine eigene Entwicklungs-/Testumgebung und sollte auf einem PC genauso funktionieren.
Wo die DB liegt, ist da doch eigentlich vollkommen egal.
Ich teste meine Java-Programme ja auch in Eclipse (nicht in der RDi-Variante).

[itec01]

Ich muss das schon unter AS/400 Bedingungen testen, weil es auch von der AS/400 mit QSH aufgerufen wird und ich wissen muss, ob alles gelaufen ist.

[Andreas_Prouza]

Ich habe hier noch nicht ganz verstanden was das Ziel ist.
Soll der Aufrufer eine Rückmeldung erhalten wenn der Call abstürtzt?
Oder soll dass unabhängig vom Aufrufer geprüft werden können?

Grundsätzlich leite ich die STDOUT immer in ein Error-Logfile im IFS um.
Denn STDOUT kann ja verloren gehen, wenn es nicht zufällig als SPLF im Job abgespeichert wird.

Ich habe letztens angefangen in meinem Blog einen Beitrag zu schreiben, wie PASE-Umgebung aufgerufen werden soll, da ich QSH Aufrufe vermeiden sollte, wenn es um ein "Service" geht:
https://github.com/andreas-prouza/blog/issues/4

@AS/400 Bedingung:
Ich entwickle meine Python Applikationen auf meinen lokalen Linux PC (könnte man auch mit einer Linux VM machen).
Bei Linux bin ich ziemlich nahe der AS/400 Umgebung.

[itec01]

Hallo Andreas,
ich habe eine AS/400 Anwendung, die EDI Daten an eine Spedition überträgt.
Nun verlangt die Spedition die EDI Daten in ein bestehendes Excel Template ab Zeile 19 zu füllen.
Dies habe ich nun mit python hinbekommen, sprich ich übergebe eine ID an das Script. Das Script führt mit der ID ein SQL aus und ermittelt die Daten. Dabei schreibe ich in die Excel Datei. Sollte in diesem Prozess ein Fehler auftreten, muss ich ich das in dem führenden RPG Programm wissen, damit ich entsprechend reagieren kann.
Hast du zufällig ein Beispiel, wie das mit STDOUT funktionieren kann?
Mittlerweile hat ja auch die IBM vieles für Python entwickelt, sprich import ibm_db_dbi / toolkit, evt. geht da auch mehr.

[Fuerchau]

STDOUT/STDERR kann man bereits vor Aufruf QSH/QPASE mit OVRDBF in eine Non-DDS-PF umleiten.
Die kann ich dann mit beliebigen anderen Programmen oder SQL auswerten.
Dasselbe geht i.Ü. auch per STDIN um Input der Konsole vom QSH/PASE/... zu lesen, falls mal die Anzahl der Parameter nicht ausreichen.
Das habe ich bei FTP, QSH und Java schon verwendet. Warum soll es nicht auch mit PASE gehen?

[itec01]

ich denke, das kann gehen:
python script:
import sys
try:
x = 1/0
except:
sys.exit(100)

QSH CMD('python3 /temp/python/error.py')
Resultmessage: Command ended normally with exit status 100.

[Andreas_Prouza]

Da das Python hier eigentlich ein Service wäre, mache ich sowas immer wie folgt:

1. (z.B. via SBMJOB) im Batch starten.
2. Der Aufrufer schreibt in eine Tabelle die nötigen Infos für das Service
2.1 Will ich das ganze synchron haben:
2.1.1 erstellt der Aufrufer eine Client DTAQ
2.1.2 Den Namen der DTAQ (inkl. Lib) übergibt der Aufrufer zusammen mit der ID an das Service
2.1.3 Der Aufrufer horcht auf seine eigene DTAQ auf Antwort vom Service
2.2 Will ich das ganze asynchron, übergebe ich nur die ID ohne Antwort DTAQ
2. Python horcht dann auf seine DTAQ nach neuen Aufträgen (SQL: Receive Data Queue).
3. Verarbeitet den Request
4. Schreibt das Ergebnis + Status + mögliche Fehlermeldung + was auch immer, in die Tabelle mit der ID zurück
5. Wurde eine Antwort-DTAQ mitgegeben, schickt das Service noch ein kurzes "fertig" an die DTAQ

Das kann man auch schön parallelisieren indem einfach weitere SBMJOBs abgesetzt werden.
Das ist alles schön transparent, erweiterbar, austauschbar usw.

[Fuerchau]

Statt SBMJOB's kann man auch Prestart-Jobs ADDPJE nehmen. Diese werden beim Start des Subsystems gestartet und können dynmaisch in der Anzahl konfiguriert werden.
Ein CHGSBS wirkt da sofort um 1, 10 oder 100 parallele Jobs zu starten. Das geht genauso wie mit den ODBC-Jobs QZDASOINIT.