|
If the address of a VARYING variable is passed, then the address starting with the length-bytes will be passed by default. But as Scott pointed out yesterday in another thread, %addr(varname:*data) overrides that. Maybe that is what you meant?
++
Dennis
++
The cardiologist' s diet:
-- If it tastes good spit it out.
Bravely sent from my Galaxy tablet phone.
++
Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:
Another thought - the use of a pointer to get the data part of a
varying-length variable. That shouldn't be necessary, IMO.
I don't know all the circumstances when using varying-length variables
with APIs. Seems to me that sometimes you can just pass them, and the
data received by the API does not include the length bytes. Other times
those bytes are included.
Maybe someone can clarify this. I've run into both in my own code, just
don't remember the details.
Thanks
Vern
On 6/20/2012 7:58 AM, Vern Hamberg wrote:
Using QCMDEXC for a CALL is downright silly. Not just for what you
mention, but also that character literals will be really messed up if
the parameter is longer than 32 characters.
What is worse is that the QCMDEXC is not prototyped.
Let's see - what else? Limiting the command length to 2048 - and not
even USING the return code.
How much better to do something so simple as callp(e) cmdexc(cmd :
%len(%trim(cmd))); and check %error() if needed. Or use monitor: around
the execution.
where cmdexc is the internal name for a prototype with the optional 3rd
parameter for QCMDEXC.
Too much fun, Birgitta!
Vern
On 6/20/2012 7:26 AM, Birgitta Hauser wrote:
Nothing is wrong with RPGIV...
But why bother to build with the call command, passing this string to a
sub-procedure which itself calls QCMDEXC API to execute the call?
Why not calling it directly with the RPG command CALL or CALLP?
And if he wants to mimic the system procedure to call a program, why not
executing it directly?
And why an internal procedure, instead of having an external one (which
indeed exists!) to execute an CL command?
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Paul Nelson
Gesendet: Wednesday, 20.6 2012 13:40
An: 'Midrange Systems Technical Discussion'
Betreff: RE: How to call a RPG program from a RPG program?
What's wrong with RPGIV?
Paul Nelson
Cell 708-670-6978
Office 512-392-2577
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Birgitta Hauser
Sent: Wednesday, June 20, 2012 12:12 AM
To: 'Midrange Systems Technical Discussion'
Subject: How to call a RPG program from a RPG program?
A new way to call a RPG program from a different RPG program!
I found the following code snippet this morning in a program written in
April 2012!!!
Both programs are written in RPGIV!!!
Aaaaaaaaaarrrrrrgh!
D DW_System PR 10i 0
d cmd 2048 varying value
D dsallpf ds qualified
D fil 10A
D lib 10A
...
/Free
dw_system('CALL PGM(DSYUNIQUE) PARM('''+
dsallpf.fil+''' '''+
dsallpf.lib+''' ''0'')');
...
/End-Free
P DW_System B
*
D DW_System PI 10i 0
d cmd 2048 varying value
d cmdval s 2046 based(cmdval_p)
*_____________________________________________
c eval cmdval_p=%addr(cmd)+2
c eval cmdlen=%len(cmd)
c call 'QCMDEXC' 50
c parm cmdval
c parm cmdlen 15 5
c 50 return -1
c return 0
P DW_System e
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
--
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.
midrange.com
