Re: SBMJOB inserting nulls -- MIDRANGE-L

Dan, this is known behavior ever since the beginning (of the 38 & 400, that is). IBM knows of the problem because it is by design. Here are a couple bits from the CL Programming manual:

When you use the CALL command, character string constants of 32 bytes or less are always passed with a length of 32 bytes. If the string is longer than 32, you must specify the exact number of bytes, and pass exactly that number.

If a CL program might be called using a CALL command that has not been compiled (an interactive CALL command or through the SBMJOB command), the decimal parameters (*DEC) should be declared with LEN(15 5), and the character parameters (*CHAR) should be declared LEN(32) or less in the receiving program.

In your first case, that could happen if you did not have exactly (maybe at least) 34 characters, including trailing blanks. The values after 32 are unpredictable. The second case is exactly as described above. The actual bytes from position 33 and on may or may not be x'00' = they can be anything, actually.

This is one very good reason to use a command, as Rob suggests. With commands, the full length of the variable is padded with blanks and will always work.

HTH

Vern

At 07:49 AM 2/19/2003 -0600, you wrote:

A fellow developer submitted this question to IBM and was told
they know of a problem.  Anyone else experience this:

While testing V5R2, I discovered when a parm 34 characters
long is used in the SBMJOB command and the last characters
blank (Hex value '40'), the submitted program receives the
last character corrupted with a hex value of '00'.

If an 80 character parm containing an 'X' in positions 1-3
is submitted, all characters after position 33 will have a
hex value of '00' when received.

I verified the parms in both programs are the same length and
type.

If the same program is called instead of submitted the parm
is passed correctly.

Parm in the SBMJOB command:
         Value in Hexadecimal
         * . . . + . . . . 1 . . . . + . . . . 2 . . . . +
'XXX  '  E7E7E740404040404040404040404040404040404040404040
    +26  404040404040404040

Parm as received by the submitted program:
         Value in Hexadecimal
         * . . . + . . . . 1 . . . . + . . . . 2 . . . . +
'XXX  '  E7E7E740404040404040404040404040404040404040404040
    +26  404040404040404000

Has anyone else had this problem?  Is there a PTF to fix
this?

Dan Rasch - because if the human species concentrated on the really
important things in life, there would be a shortage of fishing poles!
IBM Certified twice....... but still a couple PTFs away from Nirvana.

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.