[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Aug 2006
    Beiträge
    2.072

    Cobol und Call und Variablen

    Hallo *all,

    ich habe zu meinem Problem im Cobol Handbuch nachgelesen, aber die Lösung nicht gefunden.

    Problem:
    Programm A (OPM-Cobol) ruft Programm B (ILE-Cobol / Dynamic Programm Call) auf, setzt eine Variable und kehrt mit go back zurück.

    Ich hätte erwartet das die Variable bei erneutem Aufruf noch den alten Wert hat.
    Hat er aber nicht.
    Eine Initalisierung nehme ich nicht vor.

    Im Handbuch steht:
    Returning from a SubprogramTo return control from a subprogram, the subprogram may end with an EXITPROGRAM, a GOBACK, or a STOP RUN statement. If the subprogram ends withan EXIT PROGRAM or a GOBACK statement, control returns to its immediatecaller without ending the run unit. An implicit EXIT PROGRAM statement isgenerated if there is no next executable statement in a called program. If thesubprogram ends with a STOP RUN statement, all programs in the run unit up tothe nearest control boundary are ended, and control returns to the program priorto the control boundary.A subprogram is usually left in its last-used state when it ends with EXITPROGRAM or GOBACK. The next time it is called in the run unit, its internalvalues will be as they were left, except that all PERFORM statements areconsidered to be complete and will be reset to their initial values. In contrast, amain program is initialized each time it is called. There are two exceptions:v A subprogram that is dynamically called and then canceled will be in the initialstate the next time it is called.v A program, which has the INITIAL clause specified in its PROGRAM-IDparagraph, will be in the initial state each time it is called.224 ILE COBOL Programmer’s Guide."

    Was muß ich machen damit die Werte erhalten bleiben?

    GG

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... falls Dein ILE COBOL ACTGRP *NEW hat, würde ich den Effekt verstehen und dem Programm eine benamte ACTGRP (= Programmname) spendieren.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #3
    Registriert seit
    Aug 2006
    Beiträge
    2.072
    Tja,
    da stand vorher ACTGRP Qile drin.
    Habe es versucht mit einem anderen Wert.

    Der Satz: There are two exceptions:v A subprogram that is dynamically called and then canceled will be in the initialstate the next time it is called.
    Macht mich nicht hoffnungsfroh.
    Da ich ja leider mit den APIs arbeiten muß, muß ich doch auch ILE benutzen.
    Und da beißt sich die Katze wieder in den Stetz.

    Würde es mir helfen, 2 ILE Programme zu machen?
    Sprich OPM Cobol A ruft dynamisch ILE Programm B auf und das ruft statisch Programm C auf?

    Sprich B dient als "Wrapper"?

    Es ist so schön wenn man denkt: Gleich bist Du am Ziel nur um dann festzustellen das man weiter davon entfernt ist als vorher....

    GG

  4. #4
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... gewöhn Dir mal diesen unsäglichen goback ab und verwende stattdessen EXIT PROGRAMM - eventuell brauchts noch den IBM Schnörkel AND CONTINUE RUN UNIT .
    QILE war schon OK, das ist auch eine benamte; ACTGRP = Programmname ermöglicht ein Programm gezielt von außen mit RCLACTGRP zu killen.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    OPM-Cobol läuft immer in der DFTACTGRP, CBLLE per Default in QILE.
    Damit Sind 2 ACTGRP's im Spiel und dann geht das so nicht.
    Variante 1 (am Einfachsten):

    ACTGRP(*CALLER), damit läuft das Programm in der selben ACTGRP und auch der selben RUN UNIT.

    Variante 2:
    Mit eigener ACTGRP, egal ob QILE oder benannt, ist tatsächlich der Return entscheidend:

    EXIT PROGRAM: Falls nicht Hauptprogramm, dann Return.
    STOP RUN: Beenden der gesamten Rununit der ACTGRP (gefährlich, da in tiefster Ebene das höchste Programm beendet wird.

    GOBACK: versucht zuerst ein EXIT PROGRAM, wenn erfolglos da letztes, dann STOP RUN.

    Wenn das höchste Programm der RUN UNIT in eigener ACTGRP aktiv bleiben soll, dann geht das tatsächlich nur per
    EXIT PROGRAM AND CONTINUE RUN UNIT.
    Dies wird nur auf höchster Aufrufebene ausgewertet und klappt natürlich nicht bei ACTGRP(*NEW).

    Den Begriff RUN UNIT kennen die RPG'ler nicht, da hier i.W. alles per *INLR gesteuert wird.
    Auch gibt es in RPG/LE keine Möglichkeit in einer Kette von Calls das oberste Programm mit allen dazwischen zu beenden (siehe STOP RUN).
    Es ist wirklich so, dass ein STO RUN auch in der 5. Ebene funktioniert solange alle Calls in der selben ACTGRP laufen. Alle CLP's/RPGLE's dazwischen werden gleich mit gecancelt.
    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

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    @Dieter:
    Wenn man den GOBACK vermeiden will, ist die Kombination EXIT PROGRAM, STOP RUN erforderlich.
    Wenn ein COBOL-Programm das erste der Rununit ist, macht das Programm nach dem EXIT PROGRAM nämlich weiter.
    Ist das nicht die letzte Anweisung der Quelle, läuft der in die nächsten Routinen rein, egal ob SECTION oder nicht.
    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
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    @Dieter:
    Wenn man den GOBACK vermeiden will, ist die Kombination EXIT PROGRAM, STOP RUN erforderlich.
    Wenn ein COBOL-Programm das erste der Rununit ist, macht das Programm nach dem EXIT PROGRAM nämlich weiter.
    Ist das nicht die letzte Anweisung der Quelle, läuft der in die nächsten Routinen rein, egal ob SECTION oder nicht.
    ... ich habe da mal gelernt:
    im COBOL Steuerprogramm (erstes der Run Unit) Ende mit STOP RUN.
    in COBOL Sub Programmen EXIT PROGRAM.
    und habe das auch auf /36 AS/400 und unter MVS immer so gemacht.
    Und wenn ich die COBOL Reference richtig gelesen habe, dann lässt der EXIT PROGRAM AND CONTINUE RUN UNIT. die ACTGRP am Leben.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Dies ist ja soweit auch korrekt.
    Aber wie alles im Leben werden die Welten schon mal gemischt.
    Solange du in der reinen COBOL-Welt bist ist ja auch fast alles OK.

    Per Definition war einmal ein Programm das erste in der Rununit.
    Bis jemand auf die Idee kam, das Programm mal aus einem anderen COBOL aufzurufen.
    Der wunderte sich dass der Aufruf nie zurückkam, da das Programm nun mal einen STOP RUN ausführte.

    Umgedreht wurde ein COBOL-Unterprogramm aus einem CLP im Batch aufgerufen.
    Das Unterprogramm wusste dies aber nicht und machte nach dem EXIT PROGRAM weiter.
    Nun muss man wissen, dass ein "PERFORM LABEL" kein echter Unterprogrammaufruf ist.
    Der Compiler generiert einen GOTO "hinter den Perform" am Ende des LABEL/SECTION (ein EXIT mitten in einer SECTION ist wirkungslos).
    Folgender Code führt dann zu einer Endlosschleife:

    MAIN SECTION.
    MAIN-000.
    PERFORM SUB
    EXIT PROGRAM.

    SUB SECTION.
    SUB-000.
    * mach was
    SUB-999.
    EXIT.

    Der Perform generiert hinter SUB-999 einen GOTO auf das EXIT PROGRAM-Statement.
    Der EXIT PROGRAM ist wirkungslos da ja erstes Programm in der RUN UNIT.
    Das Programm macht bei SUB SECTION einfach weiter.
    Der interne GOTO ist noch aktiv, das Programm macht bei EXIT PROGRAM weiter.

    Ein simpler GOBACK oder ein STOP RUN nach dem EXIT PROGRAM hätte das verhindert.
    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

  9. #9
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... ich vermeide zwar solche Konstruktionen, aber warum nicht: ich werde mir also in Zukunft angewöhnen zu dem Gürtel (EXIT PROGRAM.) noch Hosenträger (STOP RUN.) anzuziehen, dazwischen aber zumindest QMHSNDPM bemühen und eine Abbruch Message schicken (dann bräuchte ich auch die Hosenträger eigentlich nicht mehr).

    D*B
    ...,der sich jetzt auch an die alte Empfehlung erinnert als erstes ein COBOL Programm in den Callstack zu legen (kann ein wrapper von QMDEXC sein), damit die COBOL Runtime immer drin ist.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  10. #10
    Registriert seit
    Aug 2006
    Beiträge
    2.072
    Zitat Zitat von BenderD Beitrag anzeigen
    ... gewöhn Dir mal diesen unsäglichen goback ab und verwende stattdessen EXIT PROGRAMM - eventuell brauchts noch den IBM Schnörkel AND CONTINUE RUN UNIT .QILE war schon OK, das ist auch eine benamte; ACTGRP = Programmname ermöglicht ein Programm gezielt von außen mit RCLACTGRP zu killen.D*B
    Das Go Back brauche ich mir nicht ab zu gewöhnen, erwähnte ich bereits das dieses Programm per Copy Paste und Modify aus dem Internet entstand.....Wobei, wenn ich mich Recht erinnere sind eigentlich alle Programme bei mir Copy & Paste & Modify.Ich habe glaube ich 1985 das erste und letzte mal ein Programm mit den Worten Programm ID begonnen.....GG

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    @Dieter
    Diese alte Empfehlung kannst du heute getrost vergessen. Diese galt zu OPM-Zeiten.
    Seit ILE gibt's ja je ACTGRP eine eigene RUN UNIT.
    Wieviele davon willst du schon mal anlegen?
    Da könntest du ja aus Sicherheitsgründen auch schon mal Java mitstarten, wer weiß, vielleicht brauchts ja später im Job noch einer.
    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

  12. #12
    Registriert seit
    Aug 2006
    Beiträge
    2.072
    @Fuerchau,
    wie heißt es doch so schön, You made my Day.
    Wenn ja jetzt nicht Fastenzeit wäre hätte ich dich ja glatt auf ein Bier eingeladen....
    Danke

    GG

Similar Threads

  1. Lebensdauer von static Variablen
    By dschroeder in forum NEWSboard Programmierung
    Antworten: 17
    Letzter Beitrag: 22-01-15, 16:23
  2. Begrenzung im Debugger bei der Anzeige von Variablen erhöhen?
    By SourceCoder in forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 03-04-14, 12:22
  3. Call Programm vs. Service-PGM
    By malzusrex in forum NEWSboard Programmierung
    Antworten: 17
    Letzter Beitrag: 15-11-13, 12:21
  4. CL Variablen konvertieren
    By danielfeurstein in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 22-07-02, 16:19
  5. Remote Function Call -> SAP
    By areichelt in forum NEWSboard SAP
    Antworten: 2
    Letzter Beitrag: 24-02-02, 17:44

Berechtigungen

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