[gelöst] SQL geht INTERAKTIV aber nicht im BATCH

[dabeda]

Hallo!

Bin mit meinem Latein am Ende.
Hab ein Programm dass einen SQL-String dynamisch, je nach Benutzerauswahl, baut und diesen dann an ein CL übergibt. Das CL stellt sich selbst nach BATCH und ruft ein SQL-RPG auf.
Wenn ich es online ausführe dann funktionierts einwandfrei, aber sobald es im BATCH laufen soll krieg ich Fehler -104. Der String ist aber korrekt, sonst würds ja interaktiv auch net gehn, oder?
Im String sind auch keine qualifizierten Bibliotheksangaben, es werden nur die Dateien angegeben und die LIBL stimmt auch.

Das Programm wird unter V5R3 für V5R1 kompiliert um mit den Auslandsmaschinen kompatibel zu bleiben.

Der String sieht dann in etwa so aus:

select
lgkdnr, kdnam, kdplz, kdort, lgarnr, arnam, lgtt, lgmm, lgjj, lglag, lgchar, lcchar, sum(lgmg),
sum(lcmg), lgls#, lglsd
from lgbew left outer join lgbewch
on lgbib=lcbib and lgjj=lcjj and
lgmm=lcmm and lgtt=lctt and
lgbwzt=lcbwzt and lglag=lclag and lgarnr=lcarnr and lgblkz=lcblkz and
lgbwnr=lcbwnr
join kdsta on kdbib=lgbib and kdnr=lgkdnr
join arsta on arbib=lgbib and ararnr=lgarnr
where (lgarnr=131314 and
(lgchar in ('06170' , '06171' , '06172' , '06174' , '06178') or lcchar in ('06170' , '06171' , '06172' , '06174' , '06178'))
or lgarnr=131322 and (lgchar in ('06086' , '06088' , '06144' , '06149' , '06178' , '06179') or lcchar in ('06086' , '06088' , '06144' , '06149' , '06178' , '06179'))) and lgbib='BIB' and lgbart in ('110' , '111')
group by lgkdnr, kdnam,
kdplz, kdort, lgarnr, arnam, lgjj, lgmm, lgtt, lglag, lgchar, lcchar, lgls#, lglsd order by lgkdnr, lgarnr, lgjj, lgmm,
lgtt, lgchar, lcchar, lgls#, lglsd

Vielleicht gibts ja eine simple (wie so oft) Lösung.

lg Peter

[Fuerchau]

Wie übergibst du den String denn an Batch ?
Per "SBMJOB ... CMD(CALL ...)" hast du ein Längenproblem, was hier des öfteren schon diskutiert wurde.

CALL übergibt genau die Länge, die du angibst:

DCL &FELD *CHAR 120

CALL ... PARM('1234556........')

übergibt genau diese Zeichen, der Rest deines Feldes ist SCHROTT !!!

Solange deine Anweisung < 1024 Bytes ist, kannst du den Inhalt in der *LDA übergeben.
Größere Zeichenfolgen nur per selbstgestricktem CMD oder per Datei.

[dabeda]

Ja ich übergeb ihn mit CALL ... PARM
Der String ist *CHAR und 16384 groß.
Im anschließenden SQLRPG mach ich dann ein:
cmd=%trim(command)
prepare s1 from :cmd

und dann das DECLARE. Beim DECLARE kommt dann bereits der Fehler (-104).
Die Variable CMD ist auch 16384 groß.

Aber wenn ich das SBMJOB im CL überspringe und ein einfaches CALL mit Parametern mache, dann funktionierts einwandfrei.

[cbe]

Hallo,

versuch doch mal, das Programm zu debuggen.

(Debuggen eines Batch-Jobs:
1. zu Beginn des Batch-Programms einen DLYJOB 60 oder so einbauen, damit Du eine Chance hast, die folgenden Befehle einzugeben
2. Nach Programmstart auf irgendeiner Kommandozeile STRSRVJOB auf den _laufenden_ Batchjob
3. und dann STRDBG auf das Programm)

Dann wird oft vieles klarer.

Gruß
Christian

[dabeda]

Hab ich schon gemacht, der String wird ganz normal übergeben und wenn ich mir die Variable vor PREPARE und DECLARE anschaue dann stimmt der String auch. Einen Step nach DECLARE ist SQLCOD=-104

lg Peter

[RobertMack]

Hallo, schau mal hier:
http://searchopensource.techtarget.com/ITKnowledgeExchange/questionArchiveInlineView/0,296672,sid39_gci1093810,00.html
Gruß,
Robert

[dabeda]

Die Reihenfolge der Anweisungen stimmt, das Problem ist nur dass es im BATCH nicht läuft. Wenn ich ein normales CALL mache gehts, bei SBMJOB gehts nicht.

lg Peter

[dabeda]

Glaub ich hab den Fehler.
Fuerchau hat wie immer Recht, aber ich habs net gleich verstanden.:o
Nach dem Command steht im String X'00' drinnen bis zum Ende.
Das kann nicht funktionieren.

Ich eruiere jetzt einfach im vorherigen RPG die definitive Länge und übergebe das als Parameter mit, dann ein CMD=SUBST(CMD:1:LEN#)
und schon funktionierts.:rolleyes:

Vielen Dank für die Antworten!

lg Peter

[Fuerchau]

Um gerade solchen Problemen aus dem Weg zu gehen empfielt sich hier die Erstellung eines eigenen CMD's mit korrekten Parametern.
Dann klappts auch mit SBMJOB, da man nicht CALL sondern das eigene CMD verwendet.

Dass in der Variable nur X'00' nach den gültigen Werten stand war auch eher Zufall.