Re: Direct branch entry to ICSF routines
>Could you share why it matters to you if there is a linkage stack entry (whether before or after getting to the "true routine", even if my guess is right about what you think of as the "true routines")? Performance. That doesn't provide much insight. What the callable services stub and the service do is generally the business of the stub and the service. For all I know, there is a BAKR on the front end and the target routine relies on being able to extract caller information from the linkage stack. It remains up to a caller to meet the interface requirements. Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
I really like ICSF (having worked on it for over 25 years), but I will say this right now: address-space-switch PCs are not cheap. Trying to shave a handful of instructions to call ICSF is not going to save enough cycles (or elapsed time) to be worthwhile. As Colin points out, storage management will help quite a bit usually. I would suggest that you focus on your application and find the hot spots in it first and see if the pain of trying to rework your crypto calls is worth it. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Colin Paice Sent: Sunday, January 14, 2024 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Direct branch entry to ICSF routines Is this to reduce the elapsed time, or that you are doing this a million times a second and want to save CPU? I expect any elapsed time impact is going to be at the sub microsecond level. I would have thought that there are other areas which you might address which might give you a bigger improvement. When I worked for IBM on a z/OS product, we had lots of PC requests. These never really showed up as hot spots. We got improvements from better storage management (avoid getmains/freemains) data arrangement and alignment (and on a 4KB page boundary), elimination of thread interaction at the cache block level Colin On Sun, 14 Jan 2024 at 17:13, Binyamin Dissen wrote: > On Sun, 14 Jan 2024 15:57:47 + Peter Relson > <056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: > > :>Binyamin wrote does that means that the CSFDLL functions do > not create a :>linkage stack entry before calling the true > routines/ :>Could you share why it matters to you if there is a > linkage stack entry (whether before or after getting to the "true > routine", even if my guess is right about what you think of as the > "true routines")? > > Performance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
Is this to reduce the elapsed time, or that you are doing this a million times a second and want to save CPU? I expect any elapsed time impact is going to be at the sub microsecond level. I would have thought that there are other areas which you might address which might give you a bigger improvement. When I worked for IBM on a z/OS product, we had lots of PC requests. These never really showed up as hot spots. We got improvements from better storage management (avoid getmains/freemains) data arrangement and alignment (and on a 4KB page boundary), elimination of thread interaction at the cache block level Colin On Sun, 14 Jan 2024 at 17:13, Binyamin Dissen wrote: > On Sun, 14 Jan 2024 15:57:47 + Peter Relson > <056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: > > :>Binyamin wrote does that means that the CSFDLL functions do not > create a > :>linkage stack entry before calling the true routines/ > :>Could you share why it matters to you if there is a linkage stack entry > (whether before or after getting to the "true routine", even if my guess is > right about what you think of as the "true routines")? > > Performance. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
On Sun, 14 Jan 2024 15:57:47 + Peter Relson <056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: :>Binyamin wrote does that means that the CSFDLL functions do not create a :>linkage stack entry before calling the true routines/ :>Could you share why it matters to you if there is a linkage stack entry (whether before or after getting to the "true routine", even if my guess is right about what you think of as the "true routines")? Performance. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
Binyamin wrote does that means that the CSFDLL functions do not create a linkage stack entry before calling the true routines/ Could you share why it matters to you if there is a linkage stack entry (whether before or after getting to the "true routine", even if my guess is right about what you think of as the "true routines")? Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
Out of curiosity, does that means that the CSFDLL functions do not create a linkage stack entry before calling the true routines/ On Fri, 12 Jan 2024 14:23:54 + Eric D Rossman wrote: :>There is no documentation because this is not a supported interface. It has been suggested in passing but has never been put forward as an official requirement. :>All LE-capable applications have access to the CSFDLLxx (where xx is 31,3X,64) libraries and the csfbext.h C/C++ header to call directly :>All non-LE applications have the CSN* and CSN*6 (plus CSF*/CSF*6) assembler stubs. :>Eric Rossman :>ICSF Architect :>-Original Message- :>From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen :>Sent: Friday, January 12, 2024 3:26 AM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: [EXTERNAL] Direct branch entry to ICSF routines :>I have been looking but I have not yet found the explicit doc that shows how to call ICSF routines via the CSFCCVT. :>Looking at a few of the stub routines I see that they create a linkage stack entry and then call the real routine via CSFCCVT but the labels in the CSFCCVT are not obviously related to the name of the stub routine. :>I am expecting to find something like for the name/token routines, where the stub can be used but the direct entry is also documented. :>Further research shows that the several routine that I am interested all branch to the same EP, but the stub loads a different value into R0. Don't ask me why there aren't a list of equated values for the various functions and a parameter with the function code. At any rate, high level language routines cannot set R0 but assembler routines certainly can. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
Tony Harminc wrote: > IBM has been quite mixed in its documentation for the various > "new" callable services that ship with stub routines. Perhaps IBM as a whole but ICSF has documented our interfaces in the same way for at least 20 years. > there is no requirement ... to re-bind with new stubs upon > every z/OS release. Correct. ICSF's stubs (and LE interfaces) are forward compatible, so once you BIND (or link), you don't need to do it again, in general. > I find the whole "bind it with a stub" scheme causes all > kinds of packaging issues For non-LE, I agree with you. > and IMHO IBM should just document > all the calls (as UNIX and RACF do) and perhaps even provide > their own CSRCALL-type macro. As much as I think it's a good idea, it's not very high on our list because there's not been much demand and, as far I know, there has never been a formal requirement for this. Eric Rossman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
On Fri, 12 Jan 2024 at 09:24, Eric D Rossman wrote: > There is no documentation because this is not a supported interface. It > has been suggested in passing but has never been put forward as an official > requirement. > > All LE-capable applications have access to the CSFDLLxx (where xx is > 31,3X,64) libraries and the csfbext.h C/C++ header to call directly > > All non-LE applications have the CSN* and CSN*6 (plus CSF*/CSF*6) > assembler stubs. > > Eric Rossman > ICSF Architect > IBM has been quite mixed in its documentation for the various "new" callable services that ship with stub routines. UNIX and RACF document the offsets and calling procedures, and some others (Unicode services) sort of mention it but don't have a table of routines:offsets. IBM explicitly or implicitly supports using these offsets in that there is no requirement (and it would be unreasonable to have one) to re-bind with new stubs upon every z/OS release. Many years ago I wrote a macro I called BPXCALL that knew how to invoke any of the UNIX CSRs by name. Later I extended it to support RACF and then Unicode services and a few other handy things, and renamed it to CSRCALL. It's my former employer's, so I can't post it here, but it's certainly not difficult to write one. For the UNIX version I was able to cut from the book into the macro. I used some of the HLASM features to make the generated call code look nice, e.g. it generates (once) and then uses a symbol for every routine it calls so you don't see a bunch of undocumented numeric offsets starting from the CVT amd ending in a BASR. I find the whole "bind it with a stub" scheme causes all kinds of packaging issues, and IMHO IBM should just document all the calls (as UNIX and RACF do) and perhaps even provide their own CSRCALL-type macro. Tony H. -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Binyamin Dissen > Sent: Friday, January 12, 2024 3:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Direct branch entry to ICSF routines > > I have been looking but I have not yet found the explicit doc that shows > how to call ICSF routines via the CSFCCVT. > > Looking at a few of the stub routines I see that they create a linkage > stack entry and then call the real routine via CSFCCVT but the labels in > the CSFCCVT are not obviously related to the name of the stub routine. > > I am expecting to find something like for the name/token routines, where > the stub can be used but the direct entry is also documented. > > Further research shows that the several routine that I am interested all > branch to the same EP, but the stub loads a different value into R0. Don't > ask me why there aren't a list of equated values for the various functions > and a parameter with the function code. At any rate, high level language > routines cannot set R0 but assembler routines certainly can. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
There is no documentation because this is not a supported interface. It has been suggested in passing but has never been put forward as an official requirement. All LE-capable applications have access to the CSFDLLxx (where xx is 31,3X,64) libraries and the csfbext.h C/C++ header to call directly All non-LE applications have the CSN* and CSN*6 (plus CSF*/CSF*6) assembler stubs. Eric Rossman ICSF Architect -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Friday, January 12, 2024 3:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Direct branch entry to ICSF routines I have been looking but I have not yet found the explicit doc that shows how to call ICSF routines via the CSFCCVT. Looking at a few of the stub routines I see that they create a linkage stack entry and then call the real routine via CSFCCVT but the labels in the CSFCCVT are not obviously related to the name of the stub routine. I am expecting to find something like for the name/token routines, where the stub can be used but the direct entry is also documented. Further research shows that the several routine that I am interested all branch to the same EP, but the stub loads a different value into R0. Don't ask me why there aren't a list of equated values for the various functions and a parameter with the function code. At any rate, high level language routines cannot set R0 but assembler routines certainly can. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Direct branch entry to ICSF routines
I have been looking but I have not yet found the explicit doc that shows how to call ICSF routines via the CSFCCVT. Looking at a few of the stub routines I see that they create a linkage stack entry and then call the real routine via CSFCCVT but the labels in the CSFCCVT are not obviously related to the name of the stub routine. I am expecting to find something like for the name/token routines, where the stub can be used but the direct entry is also documented. Further research shows that the several routine that I am interested all branch to the same EP, but the stub loads a different value into R0. Don't ask me why there aren't a list of equated values for the various functions and a parameter with the function code. At any rate, high level language routines cannot set R0 but assembler routines certainly can. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Direct branch entry to ICSF routines
I have been looking but I have not yet found the explicit doc that shows how to call ICSF routines via the CSFCCVT. Looking at a few of the stub routines I see that they create a linkage stack entry and then call the real routine via CSFCCVT but the labels in the CSFCCVT are not obviously related to the name of the stub routine. I am expecting to find something like for the name/token routines, where the stub can be used but the direct entry is also documented. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
