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



This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Simon:

Thanks for the info.  I should have know this, or at least remembered it
from all the past discussions on midrange-l on APIs.  This is exactly what I
needed to know and it works fine, and should work even when the length of
the data returned by the API changes.

Dave

-----Original Message-----
From: Simon Coulter [mailto:shc@flybynight.com.au]
Sent: Tuesday, July 16, 2002 8:06 PM
To: midrange-l@midrange.com
Subject: Re: QUSRSPLA and operating system upgrade



Hello David,

You wrote:
>Does anyone have a good example of using QUSRSPLA - one that works even
>after OS upgrades.  We just upgraded to V5R1 and have a few programs that
>call QUSRSPLA and they bombed because the length of the variable being
>passed was not long enough now.

That's not how it should work.  All the APIs that fill a receiver variable
work the same way.  They only fill as much space as you give them.  They
all expect a minimum length of 8 bytes formatted as two 4-byte integers.
The first integer is how much data the API actually provided, the second
integer is how much data they could have given **IF** you had provided
enough space.  As long as the receiver is at least 8 bytes long the API
will function without error.  If you provide less than 8 bytes you will
receive CPF3C24.

I checked the API documentation and I didn't see a message ID that
indicated the behaviour you describe.  What exception message did you
receive?

If QUSRSPLA is generating an exception as a direct result of the upgrade
(and not some coding error on your part that has been working by luck)
then you should open a PMR with IBM.

The whole point of using APIs is that they are upwardly compatible so code
I write using an API at, say, 420 will work from then on regardless of any
additional information that may become available.  If I want the new
information then I must update the structure which maps the receiver
variable (otherwise I won't know how to interpret the extra data) and
recompile but if I don't care about the new information then my program
will continue to run.  The documentation for receiver variable states:

"The receiver variable that receives the information requested. You can
 specify the size of the area to be smaller than the format requested as
 long as you specify the length parameter correctly. As a result, the API
 returns only the data the area can hold. "

>It was easy to fix them and the error message even told us what the new
>length should be but there should be a way to automatically determine the
>length needed and dynamically allocate the variable.  I'm not seeing
>anything in the manuals that helps.

It's not in the manuals because it is a standard method.  The IBM
programmers who supply the examples would reasonably expect any other
programmer to be able to solve this and would consider it so basic as to
not require explaining.  The method is:

Call the API with an 8-byte receiver, allocate as much space as the
Bytes-Available field says the API could return, call the API again using
the allocated space as the receiver.  This technique has been discussed
previously so search the archives.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
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 ...


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.