RE: RE: SBMJOB is trimming the tailing blanks

[qsrvbas@xxxxxxxxxxxx]

midrange-l-request@xxxxxxxxxxxx wrote:

>   2. RE: RE: SBMJOB is trimming the tailing blanks (Vernon Hamberg)
>
>This has been the way things work for over 20 years, I don't see it 
>changing soon. One major issue, as I understand it, is that 
>parameters are passed to programs by reference. (Procedures can be a 
>different story, I believe.) That being the case, how do you know how 
>much memory is to be used at each pointer that is passed? Certain 
>assumptions have been established - 32 characters for strings, 15,5 
>packed for numbers.

Vern:

In general, true, except that 20 years ago the SBMJOB command didn't have the 
CMD() parm at all, IIRC. IBM added it in late version 1 or early version 2 of 
OS/400 in order to make things "easier" for us. The big issues back then were 
getting all of your embedded quotes and packed values lined up properly. 
Embedded quotes were asked about as often back then as the *CHAR(32) is today.

Even today, if you reserve the space in a quoted string parameter in your 
RQSDTA(), the 32-char default length isn't needed -- you will get actual 
length. I suspect that a quoted string gets parsed out of the request message 
based on the number of bytes between the quotes with no reformatting and placed 
into some memory location. The amount of allocated memory becomes that actual 
length and trailing blanks are preserved.

But when the CMD() parm is used, the parser truncates trailing spaces as it 
builds RQSDTA() during execution of the command, before the request message is 
ever sent to the jobq. When it later gets parsed out of the request message 
from the jobq, the trailing blanks are already gone. The truncation happens 
within SBMJOB itself.

Unfortunately, there's no similar way around the *DEC(15 5) problem. If you 
don't convert to hex yourself or plan for (15 5), you better have a *CMD or 
expect garbage.

Tom Liotta