[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Sep 2004
    Beiträge
    336

    Python script unter QSH und Fehlerhandling

    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

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.368
    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).
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Sep 2004
    Beiträge
    336
    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.

  4. #4
    Registriert seit
    Nov 2020
    Beiträge
    360
    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.

  5. #5
    Registriert seit
    Sep 2004
    Beiträge
    336
    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.

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.368
    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?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Sep 2004
    Beiträge
    336
    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.

  8. #8
    Registriert seit
    Nov 2020
    Beiträge
    360
    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.

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.368
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. Fehlerhandling RPG
    By alex61 in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 23-05-23, 11:43
  2. QSH und Script
    By ebschubert in forum NEWSboard Programmierung
    Antworten: 0
    Letzter Beitrag: 19-05-09, 08:55
  3. QSH Script Ausführen
    By andwaw in forum NEWSboard Programmierung
    Antworten: 4
    Letzter Beitrag: 21-04-08, 14:27
  4. Python auf AS400
    By perry_rhodan in forum IBM i Hauptforum
    Antworten: 0
    Letzter Beitrag: 03-02-05, 10:16
  5. automatisiertes QSH-Script mit jar
    By beebof in forum NEWSboard Programmierung
    Antworten: 2
    Letzter Beitrag: 29-01-03, 08:37

Tags for this Thread

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •