|
Gene, >Here's a case where the command line fails to pad blanks to 32 >bytes. I >call the QSYRGFN API on V4R4 like this from the command line >to register a >30-character function named XYZ: > >CALL QSYRGFN PARM('XYZ' >X'00000002000000100000000100000001F3404040000000100000000200000 >001F1404040' >X'00000000') >This creates a function named 'XYZ' + X'00' + 26 blanks. Huh? > Why did the >command line insert a trailing null after 'Z'? Is this a >feature? This is what you would expect, given that the API specs say the first parm is 32 long. Most of the time we see this when using the API's that request a qualified object name, say for instance the Index API's. It's my understanding that this is a sort of memory overrun, and the API takes 30 bytes of the stack regardless. The data you see after the XYZ is or should be junk from the stack (where the parms are located) and should most times match the data in the following parms you supplied. In ILE/RPG, you get the same symptoms and results if you declare the entry parms bigger than you actually supply on the command line when you call the ILE/RPG pgm - and you do see the over run into the other parms. > Now I >call the QSYRGFN API like this from the command line and >explicitly pad the >first parameter to 32 blanks: > >CALL QSYRGFN PARM('XYZ ' >X'00000002000000100000000100000001F3404040000000100000000200000 >001F1404040' >X'00000000') > >This creates a function named 'XYZ' + 27 blanks, as I >expected. Somehow >the QSYRGFN API can determine whether the command line caller typed a >3-character string or a 32-character string in parameter one. The API doesn't 'determine anything. In this case when it read the 32 bytes of the stack frame, there was 32 bytes to read. >Can an MI >program determine this information, too? I think not, otherwise the docs for the system API's wouldn't state that the parms be padded to the requested length. For parms that are truly variable in length, in all the cases I've seen, you also have to provide the length of the variable length parm too. Hope this helps, --phil +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.com +---
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.