RE: Finding the length of a passed parameter

That's not a bad idea. 

Thanks,


Albert York                          


        -----Original Message-----
        From:   Booth Martin [SMTP:Booth@xxxxxxxxxxxx]
        Sent:   Thursday, September 18, 2003 12:49 PM
        To:     midrange-l@xxxxxxxxxxxx
        Subject:        RE: Finding the length of a passed parameter

        Albert, if you can deal with the calling program(s) then can you
define one
        parm of max length? 
         
        If you can make your shop standard be one parm in all called
programs then
        you can define an external data structure for each set of programs
so that
        you have one huge parm that is always the same length, and the
content is
        always consistent because both the called and calling programs use
the same
        externally defined data structure? 
         
        (sometimes a cat can be skinned in another way?)
         
        ---------------------------------------------------------
        Booth Martin http://www.MartinVT.com
        Booth@xxxxxxxxxxxx
        ---------------------------------------------------------
         
        -------Original Message-------
         
        From: Midrange Systems Technical Discussion
        Date: Thursday, September 18, 2003 11:50:24
        To: 'Midrange Systems Technical Discussion'
        Subject: RE: Finding the length of a passed parameter
         
        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.