RE: Parameters Stepping on each other

Ganesh,

The best way is to learn Command Definition "language". Which is a CL-like
script that includes CL prompting, but the SEU type is CMD. This source, when
compiled, will allow you to call the program and "define" the parameter
attributes so that the parameters are passed correctly. This has been on this
architecture since the beginning (that is since 1981) and has been widely used
throughout the system. 

-Bob Cozzi
www.iSeriesTV.com
iPod your industry news instead of reading it.
Coming July 18, 2006
Ask your friends to tune into iSeriesTV.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Ganesh Chandrasekaran
Sent: Tuesday, June 27, 2006 9:42 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Parameters Stepping on each other

Hi Eric,
              Your suggestion sounds to be new. Can you give more details 
on this?  How can you make use of *CMD object to over come this parameter 
issue.

Regards,
Ganesh.C
________________________________________________________________________________
_
C.Ganesh, Sr.Software Engineer, L&T Infotech Ltd., Chennai. 
Ph:044-22535737 (Dir) // Mob: 94444-63300



"DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
27-06-06 07:36 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Parameters Stepping on each other






Any call with parameters will be affected by this parsing issue.  Again, 
I'll reiterate that with a *CMD object, there is never any confusion by 
the system as to the size and type of parameter data.  I can't understand 
why this remedy is never adopted, but whenever this topic comes up, the 
solution taken is nearly always one of the workarounds.  Is there some 
problem with *CMD objects that I don't know about?

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Fleming, Greg (ED)
Sent: Tuesday, June 27, 2006 6:46 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Parameters Stepping on each other


Thanks Tom,

I think we'll be OK, since the last field is a single character, and
will always have a value. 

Another thought was to skip the CL altogether and use QCMDEXC to submit
the job from the RPG service program that normally calls the CL.  I
wasn't sure if that might not have the same problem as the CL.  I'll
probably test that when I get a spare moment. 

Greg

|-----Original Message-----
|From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
|On Behalf Of qsrvbas@xxxxxxxxxxxx
|Sent: Monday, June 26, 2006 7:13 PM
|To: rpg400-l@xxxxxxxxxxxx
|Subject: RE: Parameters Stepping on each other
|
|rpg400-l-request@xxxxxxxxxxxx wrote:
|
|>   4. RE: Parameters Stepping on each other (Fleming, Greg (ED))
|>
|>And thanks to all who responded, as well.  Since, in this case, the CL
|>program is being called from another RPG procedure, I think we'll just
|>put the parms in a datastructure and pass it through the CL to the
final
|>RPG program.  I think that should avoid the problem...
|
|Greg:
|
|Be aware that, if you continue to use the CMD() parm, this will still
|exhibit the same problem although it will be isolated to trailing
blanks
|for the structure itself rather than trailing blanks for individual
*CHAR
|parms.
|
|If the last field in the struct _never_ has trailing blanks, all will
be
|fine. But...
|
|Tom Liotta
|
|--