|
On Jul 5, 2018, at 3:40 PM, mlazarus <mlazarus@xxxxxxxxxxxx> wrote:
It would be really nice if at least CL had the ability to prototype. A major bonus would be the ability for CL to be able to utilize prototypes from RPG source, so we wouldn't need to have parallel protoypes. It could pull the source type and know what format it's in or I would be willing to specify FORMAT(*RPGLE) on the INCLUDE statement, if that's a problem. Or allow FORMAT(*AUTO).
-mark
On 7/5/2018 11:57 AM, Jon Paris wrote:
No - that is basically the scenario I was referencing Mark. A length/decimals mis-match between the command definition and the expected parms is the problem area.--
It is one of the reasons why I always insist on a program's prototype being included along with the PI so that the proto can be validated, Sadly because protos are RPG only that kind of defence mechanism has limited utility.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Jul 5, 2018, at 11:37 AM, mlazarus<mlazarus@xxxxxxxxxxxx> wrote:
Hi Jon,
"For that matter even using a command interface doesn't completely rule out the potential for a problem." Can you elaborate on that? Is it only when the parm defined in the command is shorter than the parm defined in the program? Or are there other scenarios that can introduce issues?
-mark
On 7/5/2018 11:13 AM, Jon Paris wrote:
Can't really be changed though Rob can it.--
There is no information stored in a program that tells the OS what size (or indeed data type) a parameter is. The kind of problem the OP is experiencing can even occur on regular program calls if no steps are taken to make sure either that the parms are padded out to the correct length (Const on prototype) or that the called program determines the length. For that matter even using a command interface doesn't completely rule out the potential for a problem.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Jul 5, 2018, at 7:33 AM, Rob Berendt<rob@xxxxxxxxx> wrote:
If, however, you still want IBM to change this you can try submitting a
RFE (Request For Enhancement) at
https://www.ibm.com/developerworks/rfe/?BRAND_ID=352
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Erwin Donker"<erwin.donker@xxxxxxxxxx>
To: "midrange-l@xxxxxxxxxxxx (midrange-l@xxxxxxxxxxxx)"
<midrange-l@xxxxxxxxxxxx>
Date: 07/05/2018 04:04 AM
Subject: CL parameters over 32 length
Sent by: "MIDRANGE-L"<midrange-l-bounces@xxxxxxxxxxxx>
Hi,
We have a CL program that uses 3 input parameters. The first parameter is
*CHAR length 50, the second parameter is *CHAR length 44 and the third
parameter is *CHAR length 512.
When this CL program is called with values that are smaller than the
parameter length (for instance 23 characters for the first parameter), we
have noticed that the value of the second parameter gets added tot he
first, starting at position 33.
I have searched the internet and have found that this behaviour is
intentional. From what I understand, *CHAR parameters are padded with
blanks up to 32 characters. Whatever was in memory after position 32
becomes part of the value of the first parameter.
I have also found several suggestions as workaround fort his issue, som y
question is nota bout how I can solve this problem. What I really don't
understand is why this CL program has worked for months without any
problems and then suddenly starts showing this behaviour. The program has
not been changed, the calling program has not been changed. We did apply
PTF's but this was 1 week before the CL program started showing this
behaviour so I don't think the PTF's are causing this. So basically what I
want to know is, why does using CL parameters over 32 characters sometimes
work, and sometimes not?
Another question out of curiosity, this "problem" has been around at least
since 1998 and probably much longer (1998 was the oldest information I
found online). I see many people having issues with this, so why has IBM
never changed this?
Erwin Donker
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD
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.
midrange.com
