On Mon, 15 Aug 2022 at 15:26, Kirk Wolf <[email protected]> wrote: > IMO, If you are going down the path of writing C/C++ for z/OS of much > significance, you will likely need to write some assembler routines that > you can call from C/C++. Just bite the bullet and figure out the calling > conventions (XPLINK?) and you will be glad in the long run.
Yup - thanks. This is a 20+ year old code base that runs on z/OS and Windows with conditional compilation. It already uses a number of z/OS callable services, including RACF ones. I'm just trying to make it a bit more z/OS-friendly in the way it interacts with end-users and operations people. Part of this is issuing messages with the expected z/OS level of accuracy and particularity (don't laugh...), rather then the "Oops - something went wrong" that we see from Google and Microsoft et al. So it's not a matter of writing brand new C/C++ code for z/OS. If we *were* writing new z/OS code I'm pretty sure we'd be looking at the Open XL C/C++ compiler with its newfangled bells and whistles, 64-bit-only code, and so on. Our current code has run with LE and its baggage for a long time, and isn't likely to change. The compiler inlining support is another option that often good, but in > many cases it can be tricky because you have to carefully declare all of > the register clobbers, not to mention the crazy syntax and symantics of > __asm. > I've tried asking IBM over the years to provide something that's a lot more like the PL/X GENERATE statement for C, i.e. that doesn't try to cram assembler into C syntax. Of course that's for Metal C where the compiler is generating assembler statements anyway. I seem to be crying in the wilderness on this one. Tony H. On Mon, Aug 15, 2022, at 1:17 PM, Tony Harminc wrote: > > Marginally related to my previous question - I'd like to do a TESTAUTH > from > > C/C++ code, and refuse to run if I'm not APF authorized. I'm not > proposing > > to actual use the result for any sort of my own security testing, but > just > > to know if calling a C/C++ library function that is documented to require > > APF (or better) is likely to fail so I can tell the user early. > > > > I don't see a C library function to do this. The TESTAUTH expansion is > > tiny, and I could use __ASM(...), but it's perhaps neater to just test > > JSCBAUTH directly in C code. Yes, I realize TESTAUTH is more than just > > testing that one bit, but I think it's true that if that bit is off (and > > I'm not in supervisor state or system key, which I won't be), then a > > TESTAUTH would fail, and that's all I want to know. > > > > Oddly enough, there *is* a library function that appears to test for the > > Program Controlled state. Well, maybe not - it's __must_stay_clean() > which > > tests for the "must not lose Program Controlled" status, so not quite the > > same. > > > > What's the best approach? > > > > Tony H. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
