jimoibm
commented
3 years ago What was the error you got in the stored procedure call?
Open dkornacki-cutco opened 3 years ago
jimoibm
commented
3 years ago What was the error you got in the stored procedure call?
alanseiden
commented
2 years ago @dkornacki-cutco It seems you are reading uninitialized memory from after the API return data ends. I think this particular API is too dynamic and complex to access using XMLSERVICE directly for your needs. I'd suggest writing an RPG program that calls the API, then calling the RPG program from XMLSERVICE.
The end of your output looks like this:
kadler
commented
2 years ago Yeah, this is one of the shortcomings of XMLSERVICE. It works very well for scalar and record-oriented data, but variable length unstructured data is harder for it to deal with because it is declarative not imperative. XMLSERVICE has no way to declare something like "there's a blob of data and at this offset contains a number of keys and at this offset is an array whose length is the previous value I just mentioned and each of these array entries contains an offset to a template header; loop over each of these template headers and if the template header field says it's this kind of data, do this but if it's this kind of data do that..." It would probably be easier to just say return the whole blob of data in binary and then use Python's built-in EBCDIC support along with struct to read the data out. Of course XML doesn't play nicely with binary data, so you'd need to set hex=on to return the data hex-encoded (base64 would be way more efficient, but it's what we've got).
I'm sure if Tony were still working on it, he could give you some kind of way to do this, but I suspect it'd be brittle and rely on the offsets being fixed (which you should never assume) and using the "hole" type to ignore gaps in the output structure.
Originally I wrote the itoolkit for Python equivalent to use system API QESRSRVA to retrieve service attributes. I debugged to the point the the stored procedure is called and just directly called it.
There seems to be an issue where the maximum records returned from the iPLUG stored procedures is 4 of 3000 length each.
I have tested this with ODBC through itoolkit and JDBC through Run SQL Scripts utility. Drivers have been updated to current versions from ACS packages. I've tried both stateless and stateful (IPC) methods. User profile is setup with CCSID 37.
Here is the call:
For reference, here is the original itoolkit build:
Edit: It seems that the parameters do not align correctly so I will try to remap lengths appropriately (though RPG style from C style conversions seem to be correct after multiple takes). However, I believe there may still be an indirect bug. Just taking a wild guess but there may be some kind of overflow issue where more checking of sizes needs to happen. I may take a crack at debugging the RPG at some point.