RTVJOBA im CL (&USRLIBL)

[mahones]

Hm, ich dachte, ich habe geschrieben, dass ich die Hochkommata gar nicht selber setze...wie soll ich sie dann also wegnehmen?

Meine Alternative sieht / sah so aus:

DCL        VAR(&PARM1) TYPE(*CHAR) LEN(100) 
DCL        VAR(&PARM2) TYPE(*DEC) LEN(15 5)
...
CHGVAR     VAR(&PARM1) VALUE('CHGLIBL LIBL(' *TCAT +
             &LIBL *TCAT ')')                      
CHGVAR     VAR(&PARM2)  VALUE(200)
...
Pgroramm-Aufruf
...
CALL       PGM(QCMDEXC) PARM(&PARM1 &PARM2)

Dann kommen aber "blöde" Fehler, weil scheinbar Sonderzeichen (von wo auch immer) hinten angehängt werden:

Zeichenfolge '    XÃ  . ' enthält ein ungültiges Zeichen.
Zeichenfolge ' .        ' enthält ein ungültiges Zeichen.
Zeichenfolge '          ' enthält ein ungültiges Zeichen.

Im DUMP sieht eigentlich alles korrekt aus:

&PARM1                   *CHAR          100       'CHGLIBL LIBL(QGPL       Q'
                                    +26           'TEMP      GRUPPE20   DATE'
                                    +51           'NST20  DATENOM20  GRUPPES'
                                    +76           '20)                      '

[ILEMax]

Dann kommen aber "blöde" Fehler, weil scheinbar Sonderzeichen (von wo auch immer) hinten angehängt werden:

das liegt daran das 200 das doppelte von 100 ist
der ILEMax

[mahones]

das liegt daran das 200 das doppelte von 100 ist
der ILEMax

Das war die (total logische, simple) Lösung...
Lag wohl daran, dass ich erst beides auf 200 hatte (vorher sogar auf 2800) und dann nur den einen Wert geändert habe. Aber auch beim Kopieren hierher ists nicht aufgefallen.

Wobei das ja eine Sache ist, die mich oft aufregt, dass das System sich wohl aus dem Speicher mehr als den vorgesehenen Bereich nimmt, um damit vermeintliche Leerstellen aufzufüllen.

Danke euch

PS: Die Lösung mit dem %SST hatte ich auch irgendwo gesehen - aber da dachte ich mir, dass das aus einer Zeit stammen müsste, wo es die "neue" Möglichkeit noch nicht gab.
...wobei ich die Syntax mit dem "'CHGLIBL LIBL(' !< &USRLBL !< ') CURLIB(' !< &CURLIB !< ')'" noch nicht kannte...

[Fuerchau]

Das System nimmt nur soviel Speicher, wie ihm mitgeteilt wird, was er sich nehmen darf.
Erfordert ein Aufruf eine Längeninformation, so sollte die Länge zum bereitgestellten Speicher nun mal passen.
Der Speicher ist einfach "endlos" hintereinander, nur die Definition von Variablen beschränkt den Zugriff.
Ich kann durchaus eine Variable (HLL-Programme) von 16MB definieren und komme somit an vieles dran, was eigentlich nicht vorgesehen ist.
Durch VARLEN-Felder oder aber auch Längenparameter muss der programmtechnisch Zugriff eingeschränkt werden.
Bei Varlen-Feldern kann ich durch direkten Zugriff auf die Längeniformation auch hier blödsinn betreiben.
Dem System ist hier keine Schuld zu geben.
Einzig "neuere" Sprachen wie Java und .NET erlauben hier keine Manipulationen.
Nicht umsonst gibt es Viren (Stichwort Bufferintrusion), wo ich mittels C/C++ an nicht gewünschte Speicheradressen komme.

Auch gibt es halt immer wieder Programmfehler, die mitunter an unerwarteter Stelle auftreten weil Aufrufkonventionen nicht eingehalten werden.

[BenderD]

Wobei das ja eine Sache ist, die mich oft aufregt, dass das System sich wohl aus dem Speicher mehr als den vorgesehenen Bereich nimmt, um damit vermeintliche Leerstellen aufzufüllen.

... das "System" nimmt sich genau soviel, wie Du ihm selber gesagt hast. Wenn Dich das oft aufregt, solltest Du bei der Parameterdefinition etwas mehr Sorgfalt walten lassen.

D*B

[cbe]

Hallo,

vor Urzeiten hatte ich dasselble Problem, ich hatte es so gelöst:

DCL VAR(&USRLBL) TYPE(*CHAR) LEN(275)
DCL VAR(&CURLIB) TYPE(*CHAR) LEN(10)
DCL VAR(&USRLIBL) TYPE(*CHAR) LEN(275)
DCL VAR(&CMD ) TYPE(*CHAR) LEN(800)
DCL VAR(&CMDLEN) TYPE(*DEC) LEN(15 5) VALUE(800)

RTVJOBA USRLIBL(&USRLIBL) CURLIB(&CURLIB)
IF COND(&CURLIB = *NONE) THEN(CHGVAR +
VAR(&CURLIB) VALUE(*CRTDFT))

CHGVAR VAR(&USRLBL) VALUE( +
%SST(&USRLIBL 01 10) !! ' ' !! +
%SST(&USRLIBL 12 10) !! ' ' !! +
%SST(&USRLIBL 23 10) !! ' ' !! +
%SST(&USRLIBL 34 10) !! ' ' !! +
%SST(&USRLIBL 45 10) !! ' ' !! +
%SST(&USRLIBL 56 10) !! ' ' !! +
%SST(&USRLIBL 67 10) !! ' ' !! +
%SST(&USRLIBL 78 10) !! ' ' !! +
%SST(&USRLIBL 89 10) !! ' ' !! +
%SST(&USRLIBL 100 10) !! ' ' !! +
%SST(&USRLIBL 111 10) !! ' ' !! +
%SST(&USRLIBL 122 10) !! ' ' !! +
%SST(&USRLIBL 133 10) !! ' ' !! +
%SST(&USRLIBL 144 10) !! ' ' !! +
%SST(&USRLIBL 155 10) !! ' ' !! +
%SST(&USRLIBL 166 10) !! ' ' !! +
%SST(&USRLIBL 177 10) !! ' ' !! +
%SST(&USRLIBL 188 10) !! ' ' !! +
%SST(&USRLIBL 199 10) !! ' ' !! +
%SST(&USRLIBL 210 10) !! ' ' !! +
%SST(&USRLIBL 221 10) !! ' ' !! +
%SST(&USRLIBL 232 10) !! ' ' !! +
%SST(&USRLIBL 243 10) !! ' ' !! +
%SST(&USRLIBL 254 10) !! ' ' !! +
%SST(&USRLIBL 265 10) )
...
/* alte Libl zurück */
CHGVAR VAR(&CMD) VALUE( +
'CHGLIBL LIBL(' !< &USRLBL !< ') CURLIB(' !< &CURLIB !< ')'
CALL PGM(QCMDEXC) PARM(&CMD &CMDLEN)



Ich muss gestehen, dass ich nicht mehr genau weiß warum...
Und mittlerweile gibt es mehr als 25 Bibliotheken.

Aber vielleicht hilft das?

Gruß, Christian