SBMJOB und Parameterübergabe

[svit]

mit Command funktioniert. Danke.

das heisst:
für SBMJOB(Call.... Parm(abc)) wird eine Kopie im Speicher erstellt und die Leerstellen nicht erkannt.
Ich nutze als Parameter eine
Ext.Ds->
Feld1(100A),
Feld2(200A),
Feld3(200A)
alle Felder sind nur bis zur Hälfte Gefüllt der Rest ist mit HEX'00' gefüllt.
Folgendes unklar:
die DS wird doch als ein String(500A) gesehen. Ich wurde verstehen wenn nur die Letzten Leerstellen von dem Feld3 mit HEX'00' gefüllt oder?

[Fuerchau]

Es würde reichen, das letzte Byte zu füllen.
Das CMD funktioniert deshalb, weil über die Parameterdefinition zu kurze Werte dann mit Blanks automatisch gefüllt werden.

Wie bereits oben schon mal gesagt wäre der korrekte Call eben so:

CALL MYPGM PARM('langer inhalt _____')

Wichtig ist ja, dass der Parameter in korrekter Länge übergeben wird und das schafft man nur mittels Hochkomma (zu beachten ist ggf. die Hochkommaverdoppelung).

Der Unterschied zwischen dem CALL-CMD und einem CALL im CLP ist der, dass der Compiler den CALL direkt in einen Programmaufruf ändert und somit die Variablen by reference übergeben werden.

[BenderD]

... wie sieht denn dein command aus? wenn die Definition des Commands die Schnittstelle richtig abbildet, wird da garnix mit HEX '00' oder anderen weisen Frauen gefüllt...

D*B

mit Command funktioniert. Danke.

das heisst:
für SBMJOB(Call.... Parm(abc)) wird eine Kopie im Speicher erstellt und die Leerstellen nicht erkannt.
Ich nutze als Parameter eine
Ext.Ds->
Feld1(100A),
Feld2(200A),
Feld3(200A)
alle Felder sind nur bis zur Hälfte Gefüllt der Rest ist mit HEX'00' gefüllt.
Folgendes unklar:
die DS wird doch als ein String(500A) gesehen. Ich wurde verstehen wenn nur die Letzten Leerstellen von dem Feld3 mit HEX'00' gefüllt oder?

[svit]

D*B:
Command funktioniert. und es werden Keine Hex wert übergeben.
die Beschreibung bezog sich auf SBM und Call.

Fuerchau:
ich habe eine RPG Programm welches die DS füllt und anschliesend das CL aufruft. das CL macht SBMjob mit DS als parameter.

Mir geht es jetzt nur die Problematik zu verstehen.
Was läuft im Speicher ab.

[Fuerchau]

Das liegt nicht am Speicher sondern in der Natur von Kommandos.

Ein CALL im CLP ruft nicht das CMD-CALL wie aus der Kommandozeile auf sondern direkt den Maschinenbefehl Call analog zum Call in RPG/COBOL.

Wenn CMD's aufgerufen werden, wird das Kommando im Speicher zusammengebaut (Runtimeroutinen des CLP's) und dann wie mit QCMDEXC aufgerufen.
Der Kommando-Interpreter hat nun mal die Angewohnheit:
Bei Zeichenketten ohne Hochkomma, die restlichen Blanks zu entfernen und wenn keine Sonderzeichen/Zahlen vorhanden sind, das Ergebnis in Großbuchstaben zu konvertieren.

Das Hauptkommando ist hier der SBMJOB der mit Parametern gefüllt wird.
Einer davon ist das halt das CMD-CALL.
Analog zu RPG wird also folgendes gemacht:

MyCall = 'CALL MYPGM PARM(' + MyDs + ')';

Möchtest du die DS als Ganzes übergeben so ist das Ganze anzupassen:

MyCall = 'CALL MYPGM PARM(''' + MyDs + ''')';

[BenderD]

D*B:
Command funktioniert. und es werden Keine Hex wert übergeben.
die Beschreibung bezog sich auf SBM und Call.

http://newsolutions.de/forum-systemi...html#post82300

Wie dieser Übergabebereich erstellt wird, beschreibt die Bedienerhilfe des Parameters PARM des Befehls call:

- alles numerische wird als dec (15 5) erstellt
- alle Alfa Felder mit mindestens 32 bzw. mit aktueller (rechts getrimmter) Länge

Falls dass dann im aufgerufenen Programm anders deklariert ist, kann es zu undokumentierten Effekten kommen, z.B.:
- Absturz wg. nicht numerischer Daten
- HEX00 Werte am rechten Rand
- Überlappung von Inhalten
- Machine Check wg. Pointer Fehler
- ...

Das Command Objekt beschreibt nun genau diesen Übergabestack in den dann die übergebenen Parameterliterale (vor dem Submit!) eingefüllt werden.

D*B

[Fuerchau]

Kleine Korrektur:
Vor dem Submit erfolgt nur die Aufbereitung des zu übergebenden Befehls als Gesamtstring!

Erst im gestarteten Job wird dieser String durch den Commandprozessor wieder zerlegt und nach obigen Kriterien dann der Speicherbereich aufgebaut und das auszuführende Programm aufgerufen.

Allerdings ist das Entfernen von "überflüssigen" Leerzeichen beim Submit bereits erfolgt.

[BenderD]

... das Command Objekt macht einiges mehr, was hier nicht zum Verständnis nötig ist (z.B.: special values übersetzen etc.) und wird sowohl vor dem submit, als auch nach dem submit aufgerufen.

D*B

Kleine Korrektur:
Vor dem Submit erfolgt nur die Aufbereitung des zu übergebenden Befehls als Gesamtstring!

Erst im gestarteten Job wird dieser String durch den Commandprozessor wieder zerlegt und nach obigen Kriterien dann der Speicherbereich aufgebaut und das auszuführende Programm aufgerufen.

Allerdings ist das Entfernen von "überflüssigen" Leerzeichen beim Submit bereits erfolgt.

[Fuerchau]

Ja, das betrifft das SBMJOB-Command selber aber nicht das darin eingebettete auszuführende CMD.

Der Job wird initiiert und das auszuführende CMD bzw. die RQSDTA werden als Request-Message in die Job-MSGQ gestellt.
Über die Routing-Entries im Subsystem wird das zu startende Programm ermittelt (default QCMD).
Dieser liest die Nachricht aus der Job-MSGQ und führt dann das Command mittels Transfercontrol (TFRCTL) aus.

Über die Routing-Entries könnte ich auch ein eigenes Programm aufrufen lassen und mit den Daten die ich per RCVMSG abholen muss dann was ganz anderes machen.

[BenderD]

@Baldur: ich bleibe bei meinem Einspruch!
das unter Parameter CMD des SBMJOB eingetragene Command wird vor dem SBMJOB benutzt, um den Übergabebereich zu erstellen und zu füllen (erkennbar daran, dass man Parameter prompten kann etc.)
Im submitteten Job wird der command dann wieder benutzt um das command processing programm aufzurufen und die Parameter dafür aufzubereiten (erkennbar daran, das validity checker ausgeführt werden etc.)

D*B

[KM]

Hallo,

hier hab ich auch noch einen aktuellen Beitrag von Joe Pluta zu diesem Thema gefunden.

Practical CL: The 32-Character Solution | CL

Gruß,
KM

[Pikachu]

CL Programming - Using the CALL Command