|
SBMJOB CMD(CALL PGM(VHAMBERGO/TEST) PARM('36 characters45678901234567890123456 '))
There are 4 spaces at the end, after the final "6".Now here is the debug display - the non-hex display looks as if there are all blanks, but this is not the case. But there are 5 blanks after the final "6". It is possible that 4 are what I passed in, the other being what happened to be in memory.
midrange.com
> EVAL &rcvvar
&RCVVAR = '36 characters45678901234567890123456 '
> EVAL &rcvvar:x
00000 F3F64083 88819981 83A38599 A2F4F5F6 - 36 characters456
00010 F7F8F9F0 F1F2F3F4 F5F6F7F8 F9F0F1F2 - 7890123456789012
00020 F3F4F5F6 40404040 40000000 00000000 - 3456 .......
00030 0000.... ........ ........ ........ - ................
> ATTR &rcvvar
TYPE = FIXED LENGTH STRING, LENGTH = 50 BYTES
Now I submitted it with RQSDTA, as
SBMJOB rqsdta('CALL PGM(VHAMBERGO/TEST) PARM(''36
characters45678901234567890123456 '')')
again with 9 spaces after the final "6". I get almost the same result - this time with 10 spaces after the final "6".
> EVAL &rcvvar:x
00000 F3F64083 88819981 83A38599 A2F4F5F6 - 36 characters456
00010 F7F8F9F0 F1F2F3F4 F5F6F7F8 F9F0F1F2 - 7890123456789012
00020 F3F4F5F6 40404040 40404040 40400000 - 3456 ..
00030 0000.... ........ ........ ........ - ................
So it appears that their IS a space in memory
after my parameter, or the system is not
stripping spaces but actually adding 1. I don't
believe the latter, although the next examples suggest this is true.
I also ran it with 4 blanks after the "6", got the same thing as with CMD.Now I changed the program also to have a packed 7,2 parameter. When passing in the same string (with 9 trailing spaces), the character parameter had all those spaces, plus the bytes from the packed parameter at the end. So things are behaving the same, as far as I can see, as they do from a command line. Here's an example, using digits that will actually show up in the first parameter:
SBMJOB cmd(CALL PGM(VHAMBERGO/TEST) PARM('36 characters45678901234567890123456 ' x'9876545F'))
with these results in debug - note the "junk" at the end of &rcvvar, that matches the packed parameter. But it appears after the blanks. And the blanks are not stripped. And this was using the CMD form.
> EVAL &dec7p2
&DEC7P2 = 98765.45
> EVAL &char50
&CHAR50 = '36 characters45678901234567890123456 qÎè¬'
> EVAL &char50:x
00000 F3F64083 88819981 83A38599 A2F4F5F6 - 36 characters456
00010 F7F8F9F0 F1F2F3F4 F5F6F7F8 F9F0F1F2 - 7890123456789012
00020 F3F4F5F6 40404040 40404040 40409876 - 3456 qÎ
00030 545F.... ........ ........ ........ - è¬..............
Does this fit your experience? This is on a V5R2 box, I think.
Regards
Vern
At 10:07 PM 11/15/2005, you wrote:
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 -- Tom Liotta The PowerTech Group, Inc. 19426 68th Avenue South Kent, WA 98032 Phone 253-872-7788 x313 Fax 253-872-7904 http://www.powertech.com __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp -- 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
