QShell im Batch

[malzusrex]

Hallo Gemeinde,

brauche da mal wieder Hlfe zur QShell.
Die habe ich in einem RPG eingebunden. Wenn ich das Programm auf der Grünen Zeile aufrufe,
dann ist alles Okay. Läuft das Teil im Batch, macht er nix. Ich sehe auch nichts im Joblog.
Das gleiche (nur ein anderer Pfad) läuft auf diversen anderen Kisten ohne Probleme..



h DftActGrp(*no) BndDir('QC2LE') Option( *NoDebugIO )
h DatFmt(*dmy.) TimFmt(*hms:) DatEdit(*dmy.) DecEdit('0,') Debug(*yes)
....
* Prozeduren
d System pr 10i 0 extproc('system')
d * value options(*string)
* Datenbereiche
d Pfadname s 255 dtaara( MyDtaara )
/free
In *Lock PfadName; // Holen Pfad-IFS aus DTAARA
Out PfadName;
// Lesen IFS mit Hilfe der QSH
system( 'qsh cmd(''ls ' + %Trim( PfadName ) +
' >/qsys.lib/MyLib.lib/MyFile.file/MyFile.mbr ' +
'2>/dev/null'')' );
/end-free


Und Mylib ist dabei nicht die QTEMP

Gruß
Ronald

[Fuerchau]

Ich weiß ja nicht, warum man das immer so kompliziert machen muss.
Ein CLP ist da besser für geieignet.
Zumal du dann z.B. STDOUT und STDERR direkt in eine PF überschreiben kannst.
STDERR ist nicht zu vernachlässigen. "ls" schreibt da z.B. rein, wenn nichts gefunden wurde bzw. wenn die QSH einen Fehler vermerkt. Dieser wird nämlich nicht ins Joblog geschrieben.

Wie ist denn der Pfadname aufgebaut?
Wenn der Leerzeichen enthält musst du diesen in Hochkomma/Anführungszeichen setzen sonst funktioniert der "ls" nicht.

QCMDEXC mit Monitor-Gruppe wäre besser geeignet, dann kommt der Aufruffehler CPF-Irgendwas in die SDS. "system()" fängt alle Fehler kommentarlos ab.

[malzusrex]

Der Pfad sieht so aus:
/HOME/BLABLA/

Warum kein CL?
Gute Frage. Sicher hatte ich mal nur ein Beispiel im RPG. Kann mir das ja mal mit dem CL anschauen..

Von dem QCMDEXC hatte ich mich mal gelöst, da ich den System einfach besser fand..
Gruß
Ronald

[BenderD]

... das mit dem Cl, Geschmacksache, sagte der Affe und biss in die Seife.
- system oder QCMDEXC? Ich bevorzuge da auch system, man sollte aber den Returncode abfragen und die CPF kriegt man da auch, da braucht es folgende Deklaration:
d EXCP_MSGID s 7 import('_EXCP_MSGID')
und da steht die dann drin (bei system ist der monitor bereits mit eingebaut)

Ansonsten kann man den OVR auch aus dem RPG raus machen, wo ist da das Problem?

D*B

[Fuerchau]

Ich habe ja nichts von "Problem" gesagt.
Es gibt halt immer komplizierte und einfache Lösungen.
Ich bevorzuge halt letztere.

[malzusrex]

Ich habe das Listing jetzt in ein CL gepackt.
Sieht übersichtlicher aus.
Danach hatte ich zwar das Problem mit Error 3489..
.. Habe das dann aber ins QINTER geschubst. Sieht soweit nicht schlecht aus

Danke
Ronald

hier das CL zum Listen


pgm

dcl &Path *char 255

rtvdtaara MyDtaara &Path

cd &path

ovrdbf stdout MyLib/MyDirFile
ovrdbf stderr MyLib/MyErrFile

qsh cmd('ls')

dltovr stdout
dltovr stderr

endpgm

Beide Files wurden vorher mit CRTPF RCDLEN(255) erzeugt

[Fuerchau]

Komisch, ich hatte da noch nie Probleme und ich benutze QSH sehr häufig.
Leider komme ich an das Dokument nicht dran:
http://www-01.ibm.com/support/docview.wss?crawler=1&uid=nas8N1010013

Ich löse ds gerne etwas anderes, da mit dem CD die Jobumgebung beeinflusst wird:

chgvar &qsh ('cd "' *cat &path *tcat '";ls')
qsh cmd(&qsh)

[Christian Bartels]

Das erwähnte Dokument erläutert, dass der Fehlercode 3489 daher kommen kann, dass im Subsystem QBATCH nur ein Job aktiv sein darf, die (Unix-artige) Umgebung QShell zum Ausführen des Befehls aber einen weiteren Job abspalten müsste. Abhilfe schaffen die Befehle:
CHGSBSD SBSD(QBATCH) MAXJOBS(*NOMAX)
CHGJOBQE SBSD(QBATCH) JOBQ(QGPL/QBATCH) MAXACT(*NOMAX) SEQNBR(10)
Sollte man aber nur machen, wenn es auch okay ist, dass beliebig viele Jobs im QBATCH gleichzeitig laufen.

Mit freundlichen Grüßen,
Christian Bartels.

[Fuerchau]

OK, deshalb habe ichden Fehler nicht.
Im SBS ist *NOMAX definiert, je JOBQ-Prio aber nur 1.
Der der QSH/JAVA-Job nicht per JOBQ reinkommt, zieht hier *NOMAX fürs SBS.
Beim SBMJOB über JOBQ ist wieder nur 1 (ggf. je Prio) Job erlaubt.