On 9/01/2019 12:46 am, Tony Thigpen wrote:
David,
The BPX_AIO routine just makes the ECB processing a little more
'magic' so that a HLL can use it. I work for one of the TCP/IP vendors
for z/VSE and I actually wrote the back-end side of the AIO processing
API. If you like things more 'magic', go for it. But, remember, the
vendor back-end code has to be more 'general' to handle every
conceivable option the user requests. So, the code-path is a lot
longer than anything you would write.
I prefer 'magic'. I don't want to deal with low level constructs like
ECBs if I can abstract them away into a library routine. A case in point
is Joe's intractable code sample. We have assembler routines which
handle console communication and
hide all the EXTRACT/CIB complexity into a callable service which blocks
and returns a function code depending on the event. It's easy to use and
code path length is a non issue. Dealing with ECB lists in a multi
threaded socket server is something I can't
get my head around. Why would anybody want to do it?
I would disagree with your statement "difficult to use API" when
talking about EZASMI. It's basic use is easy, it's just that there is
a *lot* of bad coding examples out there that people use for both
learning and borrowing code. I especially find many of the
'non-blocking' usage examples a joke while many of the SELECT usage
examples are poorly written.
IMO it is difficult to use. But then again I'm looking at it from
somebody that uses HLLs to write code. I think it's a dreadful API! I
can write a socket server in a couple of hundred lines of C++ code that
handles both standard and SSL sockets. Less if I
use Java. Performance has never been an issue.
Of course, if you want "difficult to use API", just look at the
definition of getaddrinfo()/BPX1GAL. And, that one came out of the
standards group. Very few people understand it, many just 'get it to
work' and leave it at that. Somebody wanted a 'do it all' function and
ended up designing a mess. I feel the same way about the AIO routines
and they also are 'do it all' routines.
Agree with there. getaddrinfo() is the only API I've ever used that
returns a linked list and the parameter list is a mess. But yet again
it's easy to abstract into a class or a function. But I suppose so is
EZASMI although I don't need to.
And, I am happy to agree to disagree on what is 'easiest'. We all have
our own unique experiences and skill-sets.
And I'm happy to agree to disagree. You make some very good points and I
enjoyed the conversation.
Tony Thigpen
David Crayford wrote on 1/8/19 10:51 AM:
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://chromium.googlesource.com/external/apache-portable-runtime/+/refs/heads/master/poll/unix/z_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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
