RE: CL Parm issue

> -----Original Message-----
> From: Don Fisher
> 
> Trouble is that if I SBMJOB CMD(CALL PGM(CLPGM) PARM('FOO
> ') the job log shows the command as CALL PGM(CLPGM) PARM('FOO')
> 
> Similarly, if I SBMJOB CMD(CALL CLPGM PARM(&50CHARVAR) where 50CHARVAR

> is "FOO", the job log shows CALL PGM(CLPGM) PARM('FOO').
> 
> These two things are counter intuitive and can be fixed without 
> needing to read my mind.


Don,

It sounds to me like your issue is with the fact that trailing blanks
are being stripped from the parameter values.

In order to understand why this is happening it helps to remind oneself
that the CALL embedded within a SBMJOB is processed as a command, not
some HLL OpCode. Now, consider a few valid ways to express a CALL
command:

Call Pgm(FooPgm) Parm(  'CharFoo   ' 0123456789.00000 'FooChar  '  )
Call Pgm(FooPgm) Parm(  CharFoo      0123456789.00000    FooChar    )
Call Pgm(FooPgm) Parm(CharFoo 0123456789.00000 FooChar)
Call Pgm(FooPgm) Parm(CharFoo   FooChar)

As you can see, the command processing program needs to interpret the
number of parameters being passed, and their respective data
types/lengths. Accordingly, it needs to make  certain assumptions.

Clearly, parameters are assumed to be delimited by a space. But in the
case of multiple spaces, and no apostrophes enclosing the constants,
which space do you choose? Take the second example above; should that be
interpreted as:

1. '   CharFoo   '
2. '   CharFoo '
3. '   CharFoo'

And what about the forth example? Is that:

1. 'CharFoo  '
2. 'FooChar'

-or-

1. 'CharFoo'
2. '  FooChar'

One effective way to get around these types of problems is to strip
leading and trailing blanks from all parameter values not enclosed
within apostrophes. This is the method IBM has chosen, and as long as
you know the rules, you get the best of both worlds; simplicity of use,
and adequate functionality.

If your needs are more sophisticated, such as embedding a dynamic call
within a SBMJOB command executed from a program using variables as
parameter values, then you may --at times-- need to be more explicit in
your request of the system by constructing the call command at runtime,
and passing it to SBMJOB using the RQSDTA parameter.

I hope it's now clearer why some of us don't consider the present
situation "broken". Could it have been done better? Perhaps, but most
things can be improved with the benefit of hindsight. What's important
now is that such is the design, and "fixing" it would likely involve
breaking a lot of existing code, and would most assuredly involve other
trade-offs that might not be any better than the ones we already have.

Regards,

John Taylor