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 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.
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.
And, I am happy to agree to disagree on what is 'easiest'. We all have
our own unique experiences and skill-sets.
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
