On 20 March 2015 at 08:02, Robin Atwood <[email protected]> wrote: > David - > Thank you very much, your explanation has been most helpful. So my choices > are: > 1. Code a lot of wrappers so the C code can call the EZASMI macros > 2. Change the ASM code to use BPX* calls > > The amount of coding is probably about the same but choice 2 is preferable > because we have a lot more customers using server 1.
There are a couple of other reasons to prefer (2). If you contemplate using AT-TLS on your connections at some point, there are cases where AT-TLS calls return a return code and a reason code, where the return code is not unique and requires the reason code to disambiguate it. While EZASMI does support AT-TLS, it offers no mechanism to return a reason code for any operation, and IBM appears to have no plans to rectify this. The BPX* calls all have provision to return a reason code. [In passing, the return codes from EZASMI and BPX* socket calls are different (!) That is, the symbolic RC names like EAGAIN or ETIMEDOUT are consistent, but the numeric values are different. Well maybe that doesn't matter, but if you want to retrieve error message text from a table or system service, you need to have them right.] It's not obvious to me that, even if you wrote wrappers for EZASMI in a C environment, LE would properly support the environment required for EZASMI calls. I am aware of no specific problems, but it's the kind of "why would anyone want to do that?" issue that might easily be dismissed if you run into a problem. For that matter it's not clear to me that IBM will continue the EZASMI interface indefinitely. It's clearly being maintained for compatibility reasons, but as demand drops they could just say "as of release nnn you must convert". And if you believe the picture in the Sockets API book http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSLTBW_2.1.0/com.ibm.zos.v2r1.hala001/socketlib.htm#socketlib__apirel you can see that the EZASMI interface is just a front end to the BPX* code in any case, so presumably it performs better. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
