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