RE: SBMJOB inserting nulls

Why?

Passing 'ABC blank blank blank blank blank blank blank blank blank blank blank . . . *' is not better than pasing
'ABC blank blank blank blank blank blank blank blank blank blank blank . . .' without the unused '*'.
Of cause _coding_ for that '*' forces you to be sure that it's on the 101'st position but it's easier _not_ to code for this.


Another thing:
It was said previously in this thread that the padded bytes were 'unpredictable', and this is probably also what the manual tells. My experience is however that it _can_ be predicted (there might be an exception if you pass a parameter _from_ a program that is already an entry parameter _to_ the same program): All parameters are placed in a single consequtive string somewhere in the P.A.G. In case they are alphameric literals shorter than 64 (CALL pgm PARM('abc')) the parameter occupies 64 bytes while numeric literals occupies 8 bytes (packed 15.5). All non-litterals occupies only the minimum numbers of bytes that they need. Then, all the CALL command does is to pass _pointers_ to somewhere in this string. Is this useful? Yes, you can use it to hack the parameter interface in program that you have no source for. For example replace a QSYS program (temporary!!!) whith this program of your own:
PGM PARM(&P1 &P2 ... &Pn)
DCL &P1 *CHAR 256
DCL &P2 *CHAR 256
.
.
DCL &Pn *CHAR 256
DMPCLPGM
ENDPGM
You'll see that &P2 is the same as &P1, except that first n bytes from &P1 are cut off from &P2. Then you know that first parameter has the length of n bytes.

Henrik
www.hkrebs.dk