Re: 3000-char CL parm padded with hex zeros

I'm pretty sure this is the first time I've seen the concept of:

The SBMJOB is functionally the same
as CALL QCMD. So what you have is
PGMA > QCMD > PGMB

... and that this causes variable parms to be passed as literals.

#MindBlownHowDidIMissThis ?

Very thankful for this list and all of the expert knowledge from which it
flows!

- Dan

On Tue, Apr 26, 2016 at 10:50 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 4/26/2016 10:33 AM, Dan wrote:

How is it that, after 20+ years on the platform, I don't recall running
into this specific issue

Maybe you were lucky? :-/ I definitely experienced this condition on
System/38 in the 1980s.

(parms defined identically in both the caller and
callee)?

If PGMA were to do a CALL PGMB it would work exactly as you expect. The
issue isn't parameter coordination between PGMA and PGMB, it is
coordination between QCMD and PGMB. The SBMJOB is functionally the same
as CALL QCMD. So what you have is

PGMA > QCMD > PGMB

I typically don't create commands that are not used
interactively, and I'm certain I've passed large parameters like this
before.

We can always pass parameters between programs that we write. When we
interpose SBMJOB, that's a program that someone else wrote, and we can't
effectively pass parameters to it; only literals.