> The company I work for now has a policy of not allowing the use of > assembler for any new code which is understandable.
> Understandable, but not necessarily a good decision. > Who is going to want to maintain that code in 5, 10, 15 years time? Who is going to want to maintain a complicate program in some other language instead of a simple program in assembler? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of David Crayford <dcrayf...@gmail.com> Sent: Tuesday, January 8, 2019 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Concurrent Server Task Dispatch issue multitasking issue Tony, The company I work for now has a policy of not allowing the use of assembler for any new code which is understandable. Who is going to want to maintain that code in 5, 10, 15 years time? WRT throughput, select based socket servers on distributed systems have been considered an anti-pattern for many years now and have been mostly replaced by asynchronous I/O servers using APIs like epoll, kqueue or I/O completion ports. On z/OS we have AIO which has an API in C or the z/OS UNIX assembler callable services (BPX1AIO, BPX4AIO). It's secret sauce but you can work out how to emulate epoll by checking out how the Apache Portable Runtime does it [1]. Unfortunately, BPX1AIO only works for sockets which is why some modern ports of popular software like the z/OS port of Node.js continue to use poll because they require event notification for message queues in the event loop. I would argue that if it's good enough for the Apache HTTP server for z/OS it's probably better than rolling your own using EZASMI and all the complexity that comes with a difficult to use API. I know that many IBM TCP servers like IMS connect use BPX*AIO. [1] https://secure-web.cisco.com/1IF6FkUURP_Ml3SpGNgnqt5H4PJrxc4QZ6ug2Pf8svQWZmKx8I8MgQg0r6xVh_dW0whqvz56rXnbSBqyY_yc9OwiblWQ3p6WgqAhpHX_kXQQSQvEoykgQOncSkYOw6dubO0tg2lE9U58INv0JC4_1RDbIXFUfBCd2sOg9S5IQ2QU_J0j_T0GkG71olqVBOuELgUlMZfsZAuwA6G8rzsMxItNft6mZQo2HdGBuWnNL29ulkpp1Hn0t_ZgZaJbxa0iqoJtooNivdd0O6Q50vgZJwDf16yRG6znJF7TJlOICgzV89_MgoAJYZvjLn4ViuXShr0iTLpv0NcJPKmV28RUHQZozcYp9TyVFRMNgzF5MHgnp087RxOqIQ3iak46XP1YYXiVM0fuasUR2D1xaC5N5Q2TKt0DmsusLwONlu4NqyQWoSURbE-uGznnS3cSHW-fs/https%3A%2F%2Fchromium.googlesource.com%2Fexternal%2Fapache-portable-runtime%2F%2B%2Frefs%2Fheads%2Fmaster%2Fpoll%2Funix%2Fz_asio.c. On 8/01/2019 9:47 pm, Tony Thigpen wrote: > David, > > 1) Using EZASMI does not require the use of ECBs, but it does give you > some additional useful options that are not available from other > interfaces. And, if someone is writting in assembler, why not use the > macros vs. calling eithere EZASOKET or Unix services. > > 2) Using ECBs is much cleaner than using SELECTs and/or non-blocking > processes. In fact, the SELECT call is really just an ECB wait process > for those that are in a HLL without ECBs or just don't want to manage > the ECBs themselves. Remember, the whole 'socket interface' process > was designed by a bunch of C programmers on a Unix system. And they > don't really have ECBs but were instead working with 'semaphores'. > (Similar, but not the same.) Using your own ECBs in Assembler has a > lot less overhead than using SELECT. Though-put suffers under SELECT > processing. > > 3) I wrote the ATLS Proxy processor for z/VSE. It started out as a > multi-task, SELECT based process. It's now a single-task, multi-thread > ECB based process. The SELECT processing was killing the performance. > The GIVESOCKET/TAKESOCKET process was also hurting. (The TLS overhead > of a CONNECT/ACCEPT was already high and the GIVE/TAKE just made it > worse.) > > It boils down to: For simple though, the HLL interface is 'OK', but > just like the AT&T commercials, are you ok with 'Just OK'? > > Tony Thigpen > > David Crayford wrote on 1/8/19 5:36 AM: >> I'm wondering why anybody would choose to write a TCP server using >> EZASMI macros as opposed to the UNIX callable assembler services? >> It's so much easier and no need to deal with all those tricky ECBs. >> In fact why not just use a high level language? >> >> On 8/01/2019 4:32 am, Tony Harminc wrote: >>> On Sun, 6 Jan 2019 at 15:29, Seymour J Metz <sme...@gmu.edu> wrote: >>> >>>> Second, MODIFY is not the only type of CIB, If the COMM ECB is >>>> posted then you need to process and delete the CIB, regardless of >>>> type, and regardless of whether you recognize the text of a MODIFY. >>>> The types I would expect to see are START, MODIFY and STOP. I >>>> would do a WTO for any CIB my code didn't recognize, but you still >>>> need to delete it. >>> I agree with you, of course, but I'm not sure that that's fundamental >>> to the reported problem.The symptom for failing to delete the CIB >>> would be that the next MODIFY (or STOP or anything else) command would >>> get an IEE342I MODIFY REJECTED-TASK BUSY. (To say nothing of a hard >>> loop.) Joe hasn't told us how his MODIFYs are mostly "not working", >>> nor if all of them that he has issued are "valid" in that his code >>> understands them. >>> >>> I am more suspicious of mixing async (are they really all async?) >>> EZASMI calls with WAITs in the same maintask flow of control. Is there >>> any reason for a Givesocket to be async? (For that matter is there any >>> reason for Takesocket or indeed any of the worker task's socket calls >>> to be async?) >>> >>> In the enlarged but still incomplete code snippet posted, the WAIT >>> after the SELECTX is commented out. SELECTX isn't going to WAIT on the >>> Comm ECB, so who does? >>> >>> Joe, if you want serious help with this, please post something that >>> can actually be assembled and run. >>> >>> Tony H. >>> >>> ---------------------------------------------------------------------- >>> 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 >> >> > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
