× 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.



Albert,

Why not prototype the PLIST and use keyword VARYING. The first two bytes would 
pass the actual length of the data value passed.

Or am I mistaken here?

Regards,
Carel Teijgeler.

*********** REPLY SEPARATOR  ***********

On 18-9-03 at 9:44 York, Albert wrote:

>Thanks Scott. 
>
>As always, you have left a broad swath of enlightenment in your wake. :-)
>
>For reasons I won't go into, I don't want to add a field for length.
>However, I can prefix the data with a type code, which will tell me what I
>need to know.
>
>
>Albert York                          
>
>
>
>       -----Original Message-----
>       From:   Scott Klement [SMTP:klemscot@xxxxxxxxxxxx]
>       Sent:   Thursday, September 18, 2003 9:26 AM
>       To:     Midrange Systems Technical Discussion
>       Subject:        RE: Finding the length of a passed parameter
>
>       >
>       > However, I am writing a program which will accept a variable
>number of
>       > parameters of different length. I can easily find out how many
>parameters
>       > were passed but I am looking for a way to find out how long each
>one is. In
>       > my program I can allow for the maximum length and subscript as
>needed.
>       >
>
>       The programs are, in a way, talking to each other when they send
>       parameters.   One program is telling the next program "I'm passing 3
>       parameters, and they are (address) (address) (address)"
>
>       Programs don't tell each other the lengths.  They also don't tell
>each
>       other the data types.   They just give a number of parameters and an
>       address in memory.  That's it.
>
>       Therefore there's no way to retrieve the length, aside from having
>the
>       calling program pass that length as an additional parameter.
>That's why
>       APIs frequently will have both "data" and "length" parameters.
>QCMDEXC
>       is a simple example, the first parm is the command, the second is
>the
>       length.
>
>       Now, IBM could enhance the operating system... perhaps adding a new
>       parameter to the call command such as SNDLEN(*YES) to tell the call
>to
>       send the lengths of each parameter.   But, each program that wanted
>to
>       use it would have to be changed to specify that SNDLEN(*YES).  It
>couldn't
>       be changed universally without breaking backwards compatibility.
>       Of course, all this would really do is add "hidden" parameters that
>       contain the length of each of the "visible" parameters.
>
>       Since you'd have to change the calling program anyway, you may as
>well
>       just add parameters containing the lengths.   That way, you can
>solve
>       your problems today.
>
>       Hope that helps you understand (even if it doesn't solve your
>problem)
>
>       _______________________________________________
>       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.
>_______________________________________________
>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 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.