× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This is only true Jose _if_ the call is made from the command line (including in this context QCMDEXC). It is a well documented and explainable phenomena. It is the same issue as numerics always being defined as 15,5 packed when entered on a commend line.

The best way to cure it (if indeed a cure is needed) is to use a command interface where the true length of the parms can be defined.

The best bets cure is to understand the problem and program for it correctly.

As to your “cure” it seems to me to be a lot more work to no purpose and if adding an extra parm “works” it has to be coincidental. I can only speculate that by adding a parm you are getting the temporary storage for both parms being defined consecutively and therefor you might effectively have a 64 character area. But that only works if the expected parm has a max length of 64 chars or less. I suspect this “cure” would not work if the expected parm had a length of 100.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Oct 12, 2016, at 12:45 PM, Jose Perez <joseenocperez.jp@xxxxxxxxx> wrote:

Peter be aware that when you pass a parm greater than 32 characters through
a CL, this parm get garbage when it is receive in the RPG programm the best
way to send a parm greater than 32 in a CLLE is declaring one extra parm
after the long length parm which length is equal 1 and pass this parm as
empty, besides CLLE has a var definition type *PTR for pointer.



On Fri, Oct 7, 2016 at 5:48 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 07-Oct-2016 15:32 -0500, Peter Dow wrote:

On 10/7/2016 1:01 PM, CRPence wrote:

You can effect nearly identical to what TEMPLATE provides, using
BASED, as shown here. Note that the QUALIFIED keyword is *not*
required to be specified; although unqualified references will be
problematic if the basing pointer is not set correctly; oddly, I
do not get a MCH3601 on v6r1


See **Note** at bottom of my message for correction for the above claim.

[but I do on v5r3, and msg CPF8E17
when EVAL @MODE {<ed> with the debugger}] when the basing pointer
is initialized to *NULL as shown, and instead get INCORROUT UNPRED
(UR) results -- but the code shown here sets the pointer to the
address of the by-reference-pointer *immediately* upon entry:

d ptrToData s * inz(*NULL)
d @PARMS e DS extname(OB0050PR)
d based(ptrToData)

d OB0050AN pi
d @RETURNCODE 2A
d @CALLER 10A
d PARMS likeds(@PARMS)

/free
ptrToData = %addr(PARMS) ;

// The following, if un-commented, are function equivalents:
// if parms.@mode = 'B' ;
// if @MODE = 'B' ;

Thus, for the same reason those two predicates are the /same/, the
SQL can be written as shown here, thus avoiding a qualified name
that would prevent the pre-compiler from functioning as desired:

UPDATE myTable SET myColumn = :@MODE WHERE ...


Interesting that the compiler doesn't complain about the unqualified
name.


There is no requirement to use qualified names in the mainline code,
because the QUALIFIED keyword was not specified on the @PARMS DS. Thus
essentially, the programmer has made a contract with the RPG run-time, that
the program[mer] will ensure the basing address will be properly set for
that DS.

If the pointer were set to some valid data but not the *ENTRY
parameter, which field would the compiler use when the field
reference is unqualified?


The qualified references are assuredly accessing the data for the field,
as defined by `*entry->the_field`. That is how they are known to the
run-time. So, no worries about them; seems that is already understood, but
stated for other readers of the archives.

However the unqualified references to those [sub]fields of @PARMS would
access the data defined by `ptrToData->the_field`. Such a reference would
offer-up\present whatever data was at the corresponding offset of
`the_field` within the DS, to the offset within the memory as defined by
the starting\base address of the basing pointer `ptrToData`. These
unqualified field references merely provide a window onto whatever storage
is addressed by the basing pointer; thus outside of the control of RPG
run-time, and the onus on the programmer to set that address
appropriately. So there really is just *one field* defining the storage
and data-type for each of the subfields, but two possible basing pointers;
either the *entry address [which is always used for the qualified
references, as assured by the compiler for the run-time], or the ptrToData
address [which is used for the unqualified references, for which the
programmer needs to establish\set an appropriate address].

And that is why I was shocked, that on v6r1, when the basing pointer was
not set [having been left initialized to *NULL, thus the effect should have
been a x2401 exception; i.e. mch3601] when making the unqualified
reference, the result was an unpredictable reference [but at least v5r3
exhibited the expected mch3601].
**Note** **Note** However I since went back and checked, to find that I
had been mistaken; of my own stupidity, both for expecting to see the
English text "pointer not set" whilst I was working on a *non-English*
system, and a monitor suppressing the error. *Oops* I mistakenly thought
I had seen a message for the failing EVAL in the joblog, but it was in
fact, the expected MCH3601 -- I know, I know, if I review the *spooled*
joblog, not the active joblog! Anyhow, I had coded a monitor in my program
to ignore the pointer-not-set condition because that had allowed me to test
both variations [pass-by-reference of a pointer or pass-by-reference of the
typed-data] in just one program, by having the CL make the two distinct
invocations successively.

--
Regards, Chuck


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.