length limitation to a character parm?
Kuojen Chiang
Bill Wragg
Hi
PARM1 at 70 is more than acceptable. I constantly use 100 byte parms. The
limitation is the max length of RPG, of course it depends on your version
that you are using.
RPG/400 max length is 256 for character fields. We are running V3R2
Bill Wragg, Systems Consultant
World Class Information Systems
Kuojen Chiang wrote in message ...
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
David Welden
The main thing to watch out for with long character fields is that
right-padding with spaces is not done consistently if the field is over 32
in length. If your content does not fill the field, garbage characters may
end up padding the field on the right. In your example, the contents of
PARM2 will probably end up in PARM1 following the last non-blank character.
If you need a field with a length greater than 32, you must ensure that all
characters are filled in. I usually handle this by making the field one
character longer than needed, and place some character such as "." in the
final character.
Bill Wraggnospam.com> <wr...@merck.comnospam.com>> wrote in article
<6dkfu5$q46$1...@merck.com>...
: Hi
:
OSITim
>The main thing to watch out for with long character fields is that
>right-padding with spaces is not done consistently if the field is over 32
>in length. If your content does not fill the field, garbage characters may
>end up padding the field on the right. In your example, the contents of
>PARM2 will probably end up in PARM1 following the last non-blank character.
>
>If you need a field with a length greater than 32, you must ensure that all
>characters are filled in. I usually handle this by making the field one
>character longer than needed, and place some character such as "." in the
>final character.
This is not entirely accurate, the 32 character limitation, only applies when
you use the CALL command on a command line to pass parameters to a program.
When a HLL program calls another program, a pointer to the string is passed to
the sub-program. If the string declared in the main program is declared shorter
than the string in the sub-program, then the extra characters in the
sub-program may actually overrun some other storage from the main program. Any
modifcation to the string by the sub-program could yield "unpredicatable
results".
On the other hand, the sub-program declares the string as shorter than what is
passed, the subprogram will not have any problems but it won't be able to
address all the positions in the string.
While strings may be limited to 256 in RPG/400, Data structures are not and can
be passed as a parameter.
Bradley V. Stone
This is not entirely accurate, either. Calling a program with a
character parameter (in a CL lets say) greater that 32 character could
very likely end up with garbage in the trailing character, even in the
parameter on the receiving program is declared the same size, type,
etc.
It's happened to me, and other, many times before.
Bradley V. Stone
bvs...@usa.net
http://prairie.lakes.com/~bvstone/
1992 Yamaha FJ1200
1969 Suzuki T250
"People train don't run out of Wicheta... Lesn' your a hog, or a cattle. People train runs out of Stubville."
tho...@inorbit.com
Kuojen:
Your final statement "Like 33?" is telling. Can you supply an exact example of
how the parameter is created and used on the CALL statement? If the CALL
happens at a command line or the parameter is a CL literal value or any of a
number of possibilities, you'll run into possible problems.
By default, every *CHAR parameter passed from CL has a minimum 32 character
length. Up to 32 is always padded with blanks even if you only pass a single
character. Over 32, the parameter has a default declared length of whatever
the length of the literal is. If you issue the following:
===> call pgm(ABC) parm('12345678901234567890')
and receive it into a character variable declared as longer than 32 positions,
there will be no padding at the rightmost end. Whatever was in memory after
position 32 becomes part of the value of the received argument. Positions 21
through 32 should be blank, but the rest? Who knows? (Actually, you CAN make
some predictions, but that's irrelevant.)
If you supply some precise examples of the CALL, corrections can be given.
Tom Liotta
In article <OlHtE86...@upnetnews02.moswest.msn.net>,
"Kuojen Chiang" <kch...@email.msn.com> wrote:
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_0007_01BD4786.12877960
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Does anybody know of any limitation to the length of a character parm to =
> an RPG program, for example...
>
> *ENTRY PLIST
> PARM PARM1 70=20
> PARM PARM2 6
>
> PARM1 is 70 character string, PARM2 is 6 character string. Can I do =
> this? Or is there any limitation to the length of a parm? Like.... 33 =
> characters?
>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Njal Fisketjon (Njål Fisketjøn)
>Hi
>
>PARM1 at 70 is more than acceptable. I constantly use 100 byte parms. The
>limitation is the max length of RPG, of course it depends on your version
>that you are using.
>
>RPG/400 max length is 256 for character fields. We are running V3R2
>
If you need more you can use arrays (up to 9999 times 256 bytes) or data structures (up to 32K ?)
Njål Fisketjøn
e-mail: nfis...@hesgrp.com
http://www.robin.no/~nfisketj
Paul Nicolay
Hi Bradley,
I used to work on a project were every I/O was handled by a specific
program. So in order to read/write something, a program needed to call
this routine with the record buffer (was always bigger than 32 bytes). In
case it would give garbage as you stated, this project shouldn't have
worked... however it did !
Regards,
Paul
___________________
Bradley V. Stone <bvs...@usa.net> wrote in article
<34fe2a1d....@news.lakes.com>...
>
> This is not entirely accurate, either. Calling a program with a
> character parameter (in a CL lets say) greater that 32 character could
> very likely end up with garbage in the trailing character, even in the
> parameter on the receiving program is declared the same size, type,
> etc.
>
> It's happened to me, and other, many times before.
>
> Bradley V. Stone
> bvs...@usa.net
> http://prairie.lakes.com/~bvstone/
> 1992 Yamaha FJ1200
> 1969 Suzuki T250
> "People train don't run out of Wicheta... Lesn' your a hog, or a cattle.
People train runs out of Stubville."
>
Joep Beckeringh
Depends on how the program is called. There is no problem if it is called
from another program using variables for the parameters (using the correct
definitions, of course). The padding happens when it is called using
literals, mostly when used from the command line.
Joep Beckeringh
David Welden heeft geschreven in bericht
<01bd47b6$94c99220$5b15...@weldend.cappcare.com>...
OSITim
>This is not entirely accurate, either. Calling a program with a
>character parameter (in a CL lets say) greater that 32 character could
>very likely end up with garbage in the trailing character, even in the
>parameter on the receiving program is declared the same size, type,
>etc.
>
>It's happened to me, and other, many times before.
>
>Bradley V. Stone
>bvs...@usa.net
Do you have a specific example of what you are describing? What you are
describing has never happened to me or to anyone else I know. And also runs
contrary to any discussion of parameter passing I have seen in any of the HLL
manuals.
jo...@oanet.com
In article <19980305163...@ladder02.news.aol.com>,
osi...@aol.com says...
Parameters can be passed and received as follows:
Character string constants of 32 bytes or less are always passed with a
length of 32 bytes (padded on the right with blanks). If a character
constant is longer than 32 bytes, the whole length of the constant is
passed. If the parameter is defined to contain more than 32 bytes, the
calling program must pass a constant that contains exactly that number of
bytes. Constants longer than 32 characters are not padded to the length
expected by the receiving program.
Regards,
John Zivkovic
OSITim
That's character CONSTANTS, now how about CL variables? Everyone is in
agreement about how CL handles string literals.
Bradley V. Stone
On 5 Mar 1998 16:37:15 GMT, osi...@aol.com (OSITim) wrote:
>>This is not entirely accurate, either. Calling a program with a
>>character parameter (in a CL lets say) greater that 32 character could
>>very likely end up with garbage in the trailing character, even in the
>>parameter on the receiving program is declared the same size, type,
>>etc.
>>
>>It's happened to me, and other, many times before.
>>
>>Bradley V. Stone
>>bvs...@usa.net
>
>Do you have a specific example of what you are describing? What you are
>describing has never happened to me or to anyone else I know. And also runs
>contrary to any discussion of parameter passing I have seen in any of the HLL
>manuals.
>
>
It's not only happened to me, but others as well. It was just being
discussed on the MC forum a few weeks ago as well. I think it might
have had more to do with submitting a job than calling one.
Bradley V. Stone
bvs...@usa.net
http://prairie.lakes.com/~bvstone/
1992 Yamaha FJ1200
1969 Suzuki T250
"Seinfeld's van! SEINFELD'S VAN!"
Tony Smithurst
Last time this happened to us, we declared one byte longer than necessary
and placed an asterisk '*' in the last (additional) position to force the
full length to be passed. It worked for us.
Tony Smithurst
jo...@oanet.com wrote in message ...
>In article <19980305163...@ladder02.news.aol.com>,
>osi...@aol.com says...
>> >This is not entirely accurate, either. Calling a program with a
>> >character parameter (in a CL lets say) greater that 32 character could
>> >very likely end up with garbage in the trailing character, even in the
>> >parameter on the receiving program is declared the same size, type,
>> >etc.
>> >
>> >It's happened to me, and other, many times before.
>> >
>> >Bradley V. Stone
>> >bvs...@usa.net
>>
>> Do you have a specific example of what you are describing? What you are
>> describing has never happened to me or to anyone else I know. And also
runs
>> contrary to any discussion of parameter passing I have seen in any of the
HLL
>> manuals.
>
>
Jeff Johnson
Bradley V. Stone wrote in message <34ff83b8...@news.lakes.com>...
>It's not only happened to me, but others as well. It was just being
>discussed on the MC forum a few weeks ago as well. I think it might
>have had more to do with submitting a job than calling one.
The problem is with using CALL from the command line as opposed to within a
program. And when submitting a job, the submitted CALL is treated as if it
were typed at a command line.
jo...@oanet.com
In article <19980305233...@ladder03.news.aol.com>,
osi...@aol.com says...
> That's character CONSTANTS, now how about CL variables? Everyone is in
> agreement about how CL handles string literals.
>
My apologies. I misunderstood the original claim.
I've only seen two situations where this can happen with CL variables:
1) Obviously, when the calling program defines the passed parameter
smaller than the receiving program expects it.
2) The gotcha - when the CALL is placed in a SBMJOB command. In this case
the parameter is treated as a constant.
I have never seen this happen between two programs in a simple CALL when
the parameters have been declared correctly.
John.
tho...@inorbit.com
Bradley:
Biggest problem in this area most people have when submitting jobs is using
the CMD() parameter instead of RQSDTA(). When IBM added CMD() to SBMJOB (in
v1r2?), its purpose was poorly understood, as well as its proper use.
Unfortunately, it's so relatively easy that it quickly took over.
Tom Liotta
In article <34ff83b8...@news.lakes.com>,
bvs...@usa.net (Bradley V. Stone) wrote:
>
[ etc. ]
> >
> It's not only happened to me, but others as well. It was just being
> discussed on the MC forum a few weeks ago as well. I think it might
> have had more to do with submitting a job than calling one.
>
> Bradley V. Stone
> bvs...@usa.net
> http://prairie.lakes.com/~bvstone/
> 1992 Yamaha FJ1200
> 1969 Suzuki T250
> "Seinfeld's van! SEINFELD'S VAN!"
>
tho...@inorbit.com
Jeff:
Not precisely true. There're two ways to specify the command to be submitted
with SBMJOB. Using the CMD() parameter tends to simulate a command line entry
most closely because parameters are evaluated through the command prompter
before the request data is built -- trailing blanks get truncated for example.
You have more precise control if you specify the request data directly through
the RQSDTA() parameter.
People tend to use CMD() to substitute CL variables directly into CALL
PARM()s. This eliminates any enclosing quotes, thereby removing any way for
the command prompter to determine the correct length of the parameter.
*CATing the CL variable into RQSDTA() allows you to place surrounding quotes
and preserve the length. It also allows you to pass digits-only character
values from a CL variable correctly.
Tom Liotta
In article <34ffb...@news9.kcdata.com>,
"Jeff Johnson" <pawp...@com.geocities> wrote:
>
>
> Bradley V. Stone wrote in message <34ff83b8...@news.lakes.com>...
>
> >It's not only happened to me, but others as well. It was just being
> >discussed on the MC forum a few weeks ago as well. I think it might
> >have had more to do with submitting a job than calling one.
>
> The problem is with using CALL from the command line as opposed to within a
> program. And when submitting a job, the submitted CALL is treated as if it
> were typed at a command line.
>
>