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

> message: 4
> date: Wed, 19 Feb 2003 10:19:51 -0500
> from: "Metz, Zak" <Zak_Metz@xxxxxx>
> subject: RE: SBMJOB inserting nulls
> 
> Vern described the problem you're seeing exactly. Now I'd like to share
> a little trick to help you get around it when you simply must pass more
> than 32 bytes on a call.
> 
> In the calling program, define the variable to be passed to the called
> program one byte longer than necessary and put an "*" or something in
> the LAST byte. For example, if I want to pass 100 bytes, I define it as
> 101 and put "*" in position 101 on the sending side. The receiving side
> defines the variable as 100 bytes, ignores the extra byte, and
> everybody's happy. 
>