CPYSPLF im CLLE - ist das ein BUG

[camouflage]

Hallo Forum,
Ich hab da eine komische Situation in einem CL:

Ich setze einen CPYSPLF Command ab

CPYSPLF FILE(&SPLF) TOFILE(*TOSTMF) JOB(&JOBN) +
SPLNBR(&SPLN) TOSTMF(&OBJNAME) +
WSCST(*PDF) STMFOPT(*REPLACE)

Nun, der Befehl wird nicht ausgeführt, da das JOB Keyword nur 10 Stellen annimmt, obwohl der Jobname korrekt mit 28 Stellen übergeben wurde. Klar kann ich den Wert splitten, doch sollte das ja so auch funktionieren. Und nun kommt's, gebe ich den Command wie oben auf der Befehlszeile so ein, klaglose Ausführung. Die anderen Spoolfile Befehle DSP und DLT funktionieren.

Kennt das jemand?
Danke.

Vergessen: V7R5

[Fuerchau]

Der Job muss in 3 Einzelwerten mit "/" getrennt eigegeben werden. Das kannst du auch per Prompt mit %sst(...) eingeben. Wenn das Feld zu klein ist, kannst du das per "& " (also mit Leerzeichen) einfach erweitern.

[camouflage]

Baldur,
dafür hab ich die Nerven nicht, wie mich IBM schon manch graues Haar gekostet hat. Immerhin hab ich noch welche ;-)

Ich pfeif auf das CLLE und bau mir den Command innerhalb des RPG Programmes zusammen und rufe ihn mit QCMDEXC. Aus, fertig, Schluss, Basta!!

[Fuerchau]

Da ich beim Programmieren faul bin, hätte ich das schneller in CL geschrieben;-).
Außerdem musst du das in RPG dann statt mit %SST mit %subst() zusammenstoppeln.
Wo ist da dann der Unterschied?

[camouflage]

Baldur,
ich war ja auch nicht entzückt. Offensichtlich nimmt er im CL für den CPYSPLF Command für den Job nur 10 Stellen an, obwohl ich ihm den ganzen Job Ausdruck geschickt habe, also mit den / /. Das RPG Programm hatte ich schon, also hab ich mir etwas Zeit gegönnt, nun läuft's. Gewöhn mir die CL Krücke je länger je mehr ab.

[Fuerchau]

Im CL muss man das tatsächlich in 3 Variablen übergeben, da der "/" Bestandteil der Sprache ist, so wie der ":" im ILERPG Parameter trennt. Da würdest du ja auch nicht auf die Idee kommen, das als Feld mit "ABC:1234:XYZ" zu übergeben.
QCMDEXC analysiert und interpretiert den Befehl so, wie wenn du ihn eingegeben hättest um dann den CALL des Befehlprogrammes durchzuführen, während ein CMD im CL intern den direkten Aufruf bereits enthält und eine Interpretation nicht mehr nötig ist.

[camouflage]

Da würdest du ja auch nicht auf die Idee kommen, das als Feld mit "ABC:1234:XYZ" zu übergeben.

Nö, grundsätzlich nicht, doch wenn mir das System den fertig formulierten Job als ganzes Feld zur Verfügung stellt, warum nicht. Ehrlich, ich hab langsam die Schnauze voll. Da schwafelt die ganze Welt von Modernisierung, dabei hab ich selbst das Gefühl, die ganze i(erei) kommt langsam selbst an ihre Grenzen. Da stellt man mit x SQL definierten Abfragen eine ganze Reihe an Funktionen bereit, nur das Hintenraus lässt zu wünschen übrig. Kommt hinzu das die ganze Frickelei kein Mensch bezahlen möchte. So, das musste mal sein. Abgesehen davon, der mit den Vierecken ist kein Deut besser. Und über die Abo-Idee von (big - war mal) Blue, schweig ich besser.

[Fuerchau]

Ja, das ist schon immer das Problem mit Altsprachen, wie CL.
Ich habe schon oft RPG-Programme als CMD-Prozessor geschrieben.
Wenn man da eine DS als Parameter mit mehreren Feldern definiert, können diese unterschiedliche Typen haben.
Das CMD selber erwarten dann die Parameter einer DS in /-Notation um sie dann typgerecht in die Struktur zu stellen. Das ist alles.
Dies gilt auch für (ILE)RPG. Wenn du da einen Jobwert in 3 Parametern erwartest, kannst du halt nicht in der /-Notation kommen.

Und was ist mit den tausenden von API's, die eben auch Einzelparameter statt "xxx/yyy" erwarten?
Da kannst du dann halt nur auf andere Sprachen wie C', Java, JS, u.v.m. kommen.
Und was glaubst du wie oft ich da RegEx verwenden muss, um z.B. /-Notation o.ä. wieder in Einzelfelder zu zerlegen?

[camouflage]

J
Dies gilt auch für (ILE)RPG. Wenn du da einen Jobwert in 3 Parametern erwartest, kannst du halt nicht in der /-Notation kommen.

Baldur, doch kann ich. Eigentlich wollte ich es beruhen lassen, es ist nun mal so. Doch so wie ich im ACS meine SQLs teste, teste ich auch die Commands auf der Befehlszeile. Und wenn die Befehlszeile diese Notation zulässt, muss es das CL auch können, nichts anderes. Und zum erwähnten Prompten im CL. Was nützt es, wenn der Prompt den Parameter zulässt und das CL nachher mit einem Fehler abstürzt, weil es die ganze Job Notation nicht kennt. Just my 2 cts und nu is gut.

[B.Hauser]

Hast Du Dir eigentlich schon mal den Service GENERATE_PDF im Bibliothek SYSTOOLS angeschaut?
https://www.ibm.com/docs/en/i/7.5?to...calar-function

[camouflage]

Danke Birgitta für den Hinweis. Nein, kannte ich bislang nicht - aber gute Alternative. Leider hinkt mir IBM bzgl. PDFs wieder meilenweit hinterher. Für mich unbegreiflich, dass man in der heutigen Zeit nicht mal nativ ein PDF-A hinbekommt. Auch mit Systools nicht! Ist doch nur peinlich, dass man dafür wieder auf andere Lösungen zurückgreifen muss. Und Gumbo kann wohl halbpatzig ein A-PDF Format, aber zu einem A3 sind sie auch nicht fähig.

[Fuerchau]

Nun ja, wenn man eben kein Geld einsetzen will um entsprechende Tools zu kaufen, schaut man halt in die Röhre. Da gibts schon einige Produkte, die das können;-).