|
Thanks to those who answered; I still haven't come up with an elegant solution. Unfortunately, it appears the best solution is a subprocedure, although this (admittedly not every pretty) works too: Daar007 pr extpgm('AAR007') D 10 const D 10 C callp aar007('TERMS':q_alpha_10) C eval terms_code = q_alpha_10 The problem is in the calling program: it thinks the 2nd parameter is always 10 bytes but it's not. It appears the calling program takes the full 10 bytes returned (because that's how it's defined) and slaps it into the starting memory address of the 2nd parameter. The fact than P2 is only three bytes is of no concern to the compiler; the extra seven bytes smack whatever field is next to it in memory (which usually is numeric...sigh...). It seems as though what I really want to do (with thanks to B. Cozzi) is set the size of the second parameter (which has the returned data) in the calling program; to do this, I'd have to define parameter 2 as VARYING in both the procedure interface and prototype. Then I'd be able to set the size of P2 to 3 (for example) and the calling program would know to move three bytes from the parameter list control block (?) into my 3-byte variable. Unfortunately, the compiler doesn't like the idea of a fixed-length field passed through a VARYING parameter, and I concur with S. Klement, who observed observation that having all calling programs pass a VARYING field is not ideal. I don't think OPTIONS(*VARSIZE) offers anything. In thinking about this a little more, I could probably write a subprocedure wrapper for the called program; this would allow me to use it as a function, i.e. C eval terms_code = wrapper_aar007('FHTRM') ...and this code is self-documenting. I need to get it into a service program anyway... Well, time to head to the dog pound. Guth-Pup (www.ltl400.com) was two yesterday and he's having his girlfriends over tonight for chicken liver and cream cheese birthday cake. Regards, Reeve
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.