×
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.
First 16 bytes in hex:
00006C28 00006C28 40404040 40404040
The last 8 bytes are still blanks.
The size of the user space before and after the call was 16384 bytes.
To test if the size was an issue I ran this code to trigger the user
space to extend.
ptrExtend = ptrDSPF0100 + DSPF0100.BytesAvail+1;
ExtendChar =' ';
This sets a blank to the location after what is needed by the API.
The required size of my user space to contain the 27688 bytes should be
around 35461.
After the extend code ran the user space size was 49152. More than
enough.
To test, I ran this code to retrieve the data.
QDFRTVFD(DSPF0100 :DSPF0100.BytesAvail :'DSPF0100' :FILE :APIERRORDS);
Again, the API states that the data was returned however no was actually
loaded.
First 16 bytes in hex:
00006C28 00006C28 40404040 40404040
Next I tested your suggestion for the second parm to require a copy.
QDFRTVFD(DSPF0100 :DSPF0100.BytesAvail*1 :'DSPF0100' :FILE
:APIERRORDS);
In this test the data is loaded into the user space.
First 16 bytes in hex:
00006C28 00006C28 0018000F 00000100
I then removed the code to force the extension of the user space and
tested again using the "*1" parm.
Again, the user space was auto-extended and the data was returned.
If find it strange that the location of the input variable would matter
to the QDFRTVFD API for a parameter that the API defines as input. I
think I'll have a PMR opened with IBM to make sure this is the intended
operation of the API.
Chris Hiebert
Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the
author and do not necessarily represent those of the company.
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.