Hilfe für api RSLVSP benötigt

[BenderD]

was hast du denn wirklich vor? vielleicht hat ja jemand einen Vorschlag für dich!

D*B

Ich weis in meinem Programm nicht ob das Objekt was ich Suche ein *SRVPGM oder *PGM ist. Da dachte ich mir, guck ich erstmal ob es ein *PGM ist und wenn der zurückgegeben Parameter *null ist guck ich mal ob es ein *SRVPGM ist. Vieleicht sollte ich mir da auch noch mal was einfallen lassen, ist jetzt wo ich so drüber nachdenke auch nicht wirklich optimal.

Gruß
Xanas

[Xanas]

Also ich hab ein Service Programm was das QSQPRCED kapselt.

in der qsqp400 Datenstruktur gibt es da so ein usePointers in verbindung mit dem mainProgrammpointer.

zu den Systempointern kam ich weil...

Ich hatte bisher immer den Mainprogramm namen der Callers meines Serviceprogrammes gesetzt, das hat aber zu Problemen geführt, wenn das Programm im Betrieb neu kompiliert wurde, weil der Programmname dann Pötzlich so ein "Qirgenwas" in der QRPGLEOBJ war. Dann dachte ich mir das kanns doch nicht sein, also die Doku noch mal gelesen und bin dabei über die Systempointer gestolpert, also dachte ich probier es doch mal damit.

So und dabei bin ich dann über das oben geschilderte Problem gestolpert.

[Fuerchau]

Da frage ich mich nun, was du mit dem API eigentlich bezweckst und ob es mit dynamischem SQL oder CLI nicht besser lösbar wäre.

Ansonsten kann dein Aufrufer ja über deine Schnittstelle den Programmnamen mitgeben (der steht ja nun mal in der SDS).

[BenderD]

ich würde mal meinen, dass du da denselben Tod stirbst, da der RSLVSP auch über Name und Bibliothek geht und dann den Bezug zu der QRPLOBJ auch nicht bekommt.
Das einfachste wird sein, den SystemPointer in deinem Serviceprogramm zu Beginn zu ermitteln und dann zu cachen.

D*B

Also ich hab ein Service Programm was das QSQPRCED kapselt.

in der qsqp400 Datenstruktur gibt es da so ein usePointers in verbindung mit dem mainProgrammpointer.

zu den Systempointern kam ich weil...

Ich hatte bisher immer den Mainprogramm namen der Callers meines Serviceprogrammes gesetzt, das hat aber zu Problemen geführt, wenn das Programm im Betrieb neu kompiliert wurde, weil der Programmname dann Pötzlich so ein "Qirgenwas" in der QRPGLEOBJ war. Dann dachte ich mir das kanns doch nicht sein, also die Doku noch mal gelesen und bin dabei über die Systempointer gestolpert, also dachte ich probier es doch mal damit.

So und dabei bin ich dann über das oben geschilderte Problem gestolpert.

[Xanas]

ich würde mal meinen, dass du da denselben Tod stirbst, da der RSLVSP auch über Name und Bibliothek geht und dann den Bezug zu der QRPLOBJ auch nicht bekommt.
Das einfachste wird sein, den SystemPointer in deinem Serviceprogramm zu Beginn zu ermitteln und dann zu cachen.

D*B

Zu begin Ruft jedes Programm meine Init routine auf, dann wurde das Programm in die qsqp400 struktur geschrieben und wird nicht mehr geändert.

Das Problem ist genau das Cachen, hat über den Namen nicht Funktioniert, deswegen lag meine Hoffnung in dem Pointer, der dann immer noch eben auf das Objekt zeigt, was auf einmal die die QRPGLEOBJ geschupst wurde.

Ich hab nämlich mal so eine Krücke gebaut und mir den Namen über den Callstack vor jedem execute ermittelt und siehe da keine SQL-System Fehler mehr, aber das ging mit zu sehr auf die Performance.

[BenderD]

genauso geht das auch!
in der init mit RSLVSP den ProcPointer des main programms holen und cachen, wenn main programm *PGM oder *SRVPGM sein kann, dann muss man das dem Programm eh' mitteilen (oder notfalls vorab ermitteln)

D*B

Zu begin Ruft jedes Programm meine Init routine auf an wurde das Programm in die qsqp400 struktur geschrieben und wir dann nicht mehr geändert.

Das Problem ist genau das Cachen hat über den Namen nicht Funktioniert, deswegen lag meine Hoffnung in dem Pointer der Dann noch eben auf das Objekt zeigt, was auf einmal die die QRPGLEOBJ geschupst wurde.

Ich hab nämlich mal so eine Krücke gebaut und mir den namen über den Callstack vor jedem execut ermittelt. Und siehe da keine SQL-System fehler mehr, aber das ging mit zu sehr auf die Performance.

[Xanas]

genauso geht das auch!
in der init mit RSLVSP den ProcPointer des main programms holen und cachen, wenn main programm *PGM oder *SRVPGM sein kann, dann muss man das dem Programm eh' mitteilen (oder notfalls vorab ermitteln)

D*B

Gut, dann bin ich ja wenigstens auf dem richtigem Weg. Aber ich versuchs mal ohne den monitor hin zu bekommen.

Vielen Dank euch Beiden.

[BenderD]

am einfachsten mit c- function access auf Existenz prüfen. (Beispiel hierzu in INSTREAM und OUTSTREAM auf meiner Open Source Seite)

D*B

Gut, dann bin ich ja wenigstens auf dem richtigem Weg. Aber ich versuchs mal ohne den monitor hin zu bekommen.

Vielen Dank euch Beiden.

[Xanas]

So hat super funktioniert, bei der Entscheidung wegen der Objektart hab ich mich jetzt vor erst mal auf die Nameskonventionen unser Firmer verlassen, aber mit den SystemPointern klappt wie erwartet.

Gibts eigentlich ein öffendliches Interesse an an so einem Serviceprogramm?

[Xanas]

Die Verwendung könnte dann so aussehen.

#SQL_init();

#SQL_setCursor('PARTSTA');

query = 'SELECT kern, intbe1 
      + 'FROM partsta '
      + 'WHERE intbe1 like ?';

if #SQL_prepare( query: SQL_OPEN_READ );
  search.intbe1 = '%1502%';

   #SQL_bindParam( 1: %addr( search.intbe1 )
                 : SQL_VARCHAR: %len( search.intbe1 ) );
   if #SQL_open();
     #SQL_bindParam( 1: %addr( result.kern )
                  : SQL_CHAR: %len( result.kern ) );
    #SQL_bindParam( 2: %addr( result.intbe1 )
                  : SQL_CHAR: %len( result.intbe1 ) );
    // Für Faule geht auch das
    //#SQL_bindResultStructure( %addr( result ): %len( result ) );

    dow #SQL_fetch();
        dsply result;
    enddo;

    #SQL_close();

    endif;
endif;

#SQL_free(); 

[BenderD]

eine Kleinigkeit habe ich noch zu meckern:
Knastfrei wäre besser, #&$§ und Co. werden im EBCDIC nicht konsistent übertragen und da kann es passieren, dass das, was mit deutscher CCSID funzt, sich mit anderer CCSID nicht wandeln lässt.
Ansonsten wäre das nicht so völlig uninteressant, weil man mal überlegen könnte, ob man so ein Teil transparent remote (per Java JDBC Bridge) und lokal zugreifen lassen könnte.

D*B

Die Verwendung könnte dann so aussehen.

#SQL_init();

#SQL_setCursor('PARTSTA');

query = 'SELECT kern, intbe1 
      + 'FROM partsta '
      + 'WHERE intbe1 like ?';

if #SQL_prepare( query: SQL_OPEN_READ );
  search.intbe1 = '%1502%';

   #SQL_bindParam( 1: %addr( search.intbe1 )
                 : SQL_VARCHAR: %len( search.intbe1 ) );
   if #SQL_open();
     #SQL_bindParam( 1: %addr( result.kern )
                  : SQL_CHAR: %len( result.kern ) );
    #SQL_bindParam( 2: %addr( result.intbe1 )
                  : SQL_CHAR: %len( result.intbe1 ) );
    // Für Faule geht auch das
    //#SQL_bindResultStructure( %addr( result ): %len( result ) );

    dow #SQL_fetch();
        dsply result;
    enddo;

    #SQL_close();

    endif;
endif;

#SQL_free(); 

[Xanas]

Jaja die Kleinigkeit würde ich auch nicht mehr machen, aber die Kollegen wollten Serviceprogramm Funktionen sofort erkennen und so sind wir, unwissend wie wir waren, auf das Knast-Zeichen gekommen.

Gibt's denn irgend ein SVN oder so was, wo AS/400 Knechte, so was als Open Source ablegen könnten. Natürlich würde ich dann vorher noch eine Knastfreie Version erstellen. Und noch andere offensichtliche Klopper ausräumen.