-
wenn die Var > 30 (oder 32 ??) Zeichen definiert ist, müssen auch diese 30 Zeichen übergeben werden
wenn var < 30 stellig, call pgm parm('abc')
Wenn var > 30 stellig, call pgm Parm('abc ... .....')
Hex 00 ist nicht immer der 'aufgefüllte' Inhalt
Das ist alles mögliche, was im Speicher steht !!
Lösung:
dclf &var *char 200
chgvar &var 'abc'
call pgm parm(&var)
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Lösung:
dclf &var *char 200
chgvar &var 'abc'
call pgm parm(&var)
Hi Robi,
Du meinst wohl eher:
dcl &var *char 200
Persönlich würde ich dem noch einen value(' ') anfügen.
Wenn die Felder sauber definiert (Länge) und auch initialisiert sind, braucht es nicht solche Klimmzüge.
Allerdings frage ich mich ob svit dieses Programm zu Testzwecken auf der Commandlinie direkt aufruft - und wenn da der Parameter zu kurz ist, ist dieser Effekt anschaulich nachzuvollziehen.
kf
-
 Zitat von camouflage
Wenn die Felder sauber definiert (Länge) und auch initialisiert sind, braucht es nicht solche Klimmzüge.
Allerdings frage ich mich ob svit dieses Programm zu Testzwecken auf der Commandlinie direkt aufruft - und wenn da der Parameter zu kurz ist, ist dieser Effekt anschaulich nachzuvollziehen.
... genau das ist der Fall von denkste!
Ursache des Problems ist, dass die AS400 immer einen Call by reference macht, sprich: Adressen übergibt und keine Werte. Beim interaktiven Aufruf werden Literale übergeben, die keine auswertbare Adresse haben, beim SBMJOB stimmen die Adressräume vom Aufrufer und dem Aufgerufenen Job nicht überein - in beiden Fällen wird deshalb zur Laufzeit ein Übergabebereich erstellt, mit genau den Eigenschaften, wie beim command call beschrieben. Mit einem eigenen Command cann man das toppen, da dort jeder einzelne Parameter beschrieben wird.
D*B
-
@Dieter
Hast mich gleich nachdenklich gemacht, da diese Problematik nicht mehr so present ist. War wohl nur ein netter Versuch von mîr.
Offensichtlich bleiben wirklich nur Commands als sauberste Lösung übrig, wenn die Parameterstruktur zu komplex ist.
Mehr diesem Thema unter diesem Link:
Get the SBMJOB Command's CMD Parameter to Cooperate
kf
-
Das Problem ist doch der eingebettete Call im SBMJOB.
Also müssen die Daten in der benötigten Länge übergeben werden.
Allerdings kann man tatsächlich beliebige Daten übergeben da der Empfänger da nicht bekannt ist.
Wenn ich also 201 Bytes mit dem "!" am Ende übergebe und der Empfänger nur 200 Bytes definiert, kommt er an das "!" gar nicht dran und es muss nicht entfernt werden.
Aber wie Dieter schon sagt, sauber ist das nicht.
-
... natürlich kann ich das auch alles in 32er Happen zerhacken, oder vorher die Blanks escapen und nachher wieder erzeugen, oder rechts trimmen und als varchar schicken und wieder auffüllen und zig andere bitfummlerische Tricks. Problem ist dabei nur, daß bei fehlerhafter Bedienung einer solchen Wackelschnittstelle sehr seltsame Fehler an völlig anderer Stelle auftauchen können; zudem setzt man hierbei auch auf undokumentiertem Verhalten auf, wenn der Compiler dann morgen mehr prüft als heute, kriegt man das Gegurke möglicherweise nicht einmal mehr gewandelt. Letzteres ist vor nicht allzulanger Zeit bei der trickreichen Übergabe einstelliger Parameter und CALLPRC passiert!!!
D*B
-
Ochnö, für variable Übergabe (ist ja schließlich by reference) nütze ich das Durchreichen von Char(1) sehr häufig.
Ist ja gemein, wenn dass plötzlich vom Compiler abgelehnt wird, ist ja schließlich CLLE und keine HLL.
In RPGLE kann ich die PRC ja selber deklarieren, was da auch schon klappte ist "* value", also als Pointer by Value.
Das ist zwar Huddel, der Compiler frisst es aber.
-
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?
-
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.
-
... 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
 Zitat von 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?
-
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.
-
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 + ''')';
Similar Threads
-
By Dominik Meyer in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 13-01-07, 15:16
-
By hww in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 12-12-06, 15:27
-
By Luebbert in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 13-09-06, 11:39
-
By muadeep in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 27-06-06, 11:31
-
By mott in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 09-12-05, 09:06
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks