Java Aufruf an Stored Procedure RPG ServicePGM

[Fuerchau]

Nachtrag:

Nachrichten-ID . . . . . . . : RNX1216
Nachrichtendatei . . . . . . : QRNXMSG
Bibliothek . . . . . . . . : QSYS

Nachricht . . . : Fehlernachricht &5 wurde während &13 für Datei &7
angezeigt.
Ursache . . . . : RPG-Prozedur &1 in Programm &3/&2 hat die Nachricht &5
empfangen, während eine implizite Operation &13 für Datei &7 ausgeführt
wurde. Die tatsächliche Datei ist &8.
Fehlerbeseitigung: Das Jobprotokoll auf eine vollständige Beschreibung von
Nachricht &5 prüfen und den für die Programmpflege verantwortlichen Benutzer
benachrichtigen. Lautet der Eintrag für die Ein-/Ausgabeeinheit für die
Datei SPECIAL, ist unter Umständen keine Nachricht im Jobprotokoll
vorhanden.

[boonkelz]

Guten Morgen

Danke für die Info und ich habe dazu auch gleich 2 Fragen:

1.
Ich verzweifel langsam aber sicher mit den Parametern:

Ich habe laut Liste
http://publib.boulder.ibm.com/infoce...rbafyppcsp.htm
nun folgendes angegeben und es kommt immer ein Dezimaldatenfehler im Joblog:

Java:

CallableStatement cstmt = the400.prepareCall("{CALL " + AS400_LIBRARY + ".SP_GETOBJ(?, ?, ?, ?, ?)}",
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); BigDecimal firma = new BigDecimal ("01");
BigDecimal objekt = new BigDecimal ("0002215");
BigDecimal objektArt = new BigDecimal ("1");
BigDecimal objektGeshh = new BigDecimal ("1");

// set inputs
cstmt.setBigDecimal(1, firma); // firma
cstmt.setBigDecimal(2, objekt); // objekt
cstmt.setBigDecimal(3, objektArt); // objektArt
cstmt.setBigDecimal(4, objektGeshh); // objektGeshh


// set outputs
cstmt.registerOutParameter(5, java.sql.Types.CHAR); // objektbezeichnung

Stored Procedure:
CREATE PROCEDURE STAMOBJ.SP_GETOBJ (
IN FIRMA NUMERIC(2, 0) ,
IN OBJEKT NUMERIC(7, 0) ,
IN OBJEKTART NUMERIC(1, 0) ,
IN OBJEKTGESHH NUMERIC(1, 0) ,
OUT OBJETKBEZ CHAR(28) )
LANGUAGE RPGLE
SPECIFIC STAMOBJ.SP_GETOBJ
NOT DETERMINISTIC
READS SQL DATA
CALLED ON NULL INPUT
PROGRAM TYPE SUB
EXTERNAL NAME 'STAMOBJ/S_TESTDP(GETOBJEKTBEZ)'
PARAMETER STYLE GENERAL

RPG Prozedur:
getObjektBez B Export
getObjektBez PI
p#firma 2 0
p#obj 7 0
p#objA 1 0
p#objG 1 0
p#obbzg 28

2.
Die Sache, welche von Dir vorher angesprochen wurde, bezüglich des offenen Dateizugriffes:
Hier kam nämlich zuerst auch ein Fehler
und als ich in die Bilbiotheksliste schaute, die dieser Job gerade offen hatte, war die Bibliothek nicht vorhanden.

Der Job hatte nur Bibliotheken der QSYSLIBL und unsere Daten sind in einer Bilbiothek, die in der QUSRLIBL definiert ist. Kann man hier einfach die Bibliothek der Dateien von der QUSRLIBL in die QSYSLIBL geben, oder gibt es da auch noch eine andere Möglichkeit ?

Vielen Dank im Voraus

[BenderD]

auf Wunsch des Fragers gelöscht!

[boonkelz]

die libl kann man in den Treiber Properties setzen, aber warum dieser ganze Wackelhaufen mit dem RPG Java Mix??? Das ist aus Java 1 (in Worten eins) SQL Statement!!!

D*B

Treiber Properties: wäre nett, wenn du genau schreibst, wo dies ist.

Wackelhaufen: danke für den tollen Input. Ich habe nicht erst gestern zu programmieren begonnen. Aber ob du es glaubst oder nicht, es gibt Möglichkeiten auch komplexen RPG Code aus Java aufzurufen (diese Strategie soll sogar von sogenannten Profis empfohlen sein). Und diese eine Methode ist einfach ein Test um das ganze anzuleiern.

Ich denke, ein Forum ist dazu da, um Hilfestellung zu bekommen.
Auf Besser-wissende-Antworten kann ich gut und gerne verzichten.

Lg

[Fuerchau]

Soweit ich weiß, werden in Service-Programmen keine *INZSR-Routinen aufgerufen, eine globale Datei wird also ggf. nicht automatisch geöffnet.

Desweiteren würde ich dir ein SQLRPGLE-Serviceprogramm empfehlen, so dass SQL das Öffnen und ggf. offen halten (ODP) übernimmt, ausserdem kannst du direkt mit SELECT ... INTO ... arbeiten.

Bei der Verbindung gibst du in der Url die Default-LIB an:
url = jdbc:as400://MYSYS/MYLIB

[RobertPic]

Noch eine mögliche Fehlerquelle:

cstmt.registerOutParameter(5, java.sql.Types.CHAR); // objektbezeichnung 

Er fängt bei den Outputparametern wieder bei 1 zu zählen an, zumindest habe ich das so in Erinnerung...

Ich umgehe diese Zählerei indem ich immer alle Parameter INOUT setze. Man muss halt für alle auch den Output-Type setzen.

Um Umwandlungsprobleme auszuschließen, vereinfache dein Beispiel vielleicht nocheinmal und verwende zu CHAR's.

/Robert

[boonkelz]

Noch eine mögliche Fehlerquelle:

cstmt.registerOutParameter(5, java.sql.Types.CHAR); // objektbezeichnung 

Er fängt bei den Outputparametern wieder bei 1 zu zählen an, zumindest habe ich das so in Erinnerung...

Ich umgehe diese Zählerei indem ich immer alle Parameter INOUT setze. Man muss halt für alle auch den Output-Type setzen.

Um Umwandlungsprobleme auszuschließen, vereinfache dein Beispiel vielleicht nocheinmal und verwende zu CHAR's.

/Robert

Vielen Dank für diesen tollen Tip,
ich habe es mittlerweile geschafft, alpha und numerische Daten über die Stored Procedure zu erhalten.

lg
Hannes

[boonkelz]

Soweit ich weiß, werden in Service-Programmen keine *INZSR-Routinen aufgerufen, eine globale Datei wird also ggf. nicht automatisch geöffnet.

Desweiteren würde ich dir ein SQLRPGLE-Serviceprogramm empfehlen, so dass SQL das Öffnen und ggf. offen halten (ODP) übernimmt, ausserdem kannst du direkt mit SELECT ... INTO ... arbeiten.

Bei der Verbindung gibst du in der Url die Default-LIB an:
url = jdbc:as400://MYSYS/MYLIB

Hallo
Zunächst mal vielen Dank für die Hilfe,
Ich habe das nun so gemacht und es funktioniert:

public void beispielMitDateienObjektbezeichnung() throws ClassNotFoundException, SQLException {


// Connection Variables
String AS400_ADDRESS = "xxx";
String AS400_USERNAME = "xxx";
String AS400_PASSWORD = "xxx";
String AS400_LIBRARY_FILES = "STAMDAT";
String AS400_LIBRARY_PROCEDURES = "STAMOBJ";

// START: Connection Block
Class.forName("com.ibm.as400.access.AS400JDBCDrive r");
try {
// Aufrufen der Standard Bilbiothek sollte hier immer die STAMDAT sein, denn sonst kann man bei den STORED Procedures auf Dateien in STAMDAT nicht darauf zugreifen !!!!
the400 = DriverManager.getConnection("jdbc:as400://" + AS400_ADDRESS + "/" + AS400_LIBRARY_FILES, AS400_USERNAME, AS400_PASSWORD);
System.out.println("Connection successful!");
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

// END: Connection Block

try{

// START: Call the Stored Procedure

// getBet mit 5 mal inout Parametern numerisch und alpha mit Dateien:
CallableStatement cstmt = the400.prepareCall("{CALL " + AS400_LIBRARY_PROCEDURES + ".SP_GETBEZ(?, ?, ?, ?, ?)}",
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);

System.out.println(cstmt.toString());

Die Sache mit dem SQLRPGLE-Serviceprogramm:

Dazu muss man doch auf der iSeries einiges an Sourcen schreiben bzw. reinkopieren, damit man das ausführen kann, oder ? (laut hier im Forum und Google), bzw. was bringt das denn genau ???


Lg
Hannes

[Fuerchau]

Da braucht man nichts reinkopieren.
Wichtig ist nur ggf. die Commit-Option per

exec sql set options commit=*none;

Alles andere bringt der Compiler automatisch mit (SQLCA, SQLCOD usw.).

Bei der Prozedurdeklaration ist noch "contains SQL" erforderlich, das wars dann.

Und SQL bringt einfach mehr Vorteile, die hier aufzuzählen sprengt den Rahmen.