On 8/09/2016 8:10 PM, John McKown wrote:
On Thu, Sep 8, 2016 at 3:24 AM, David Crayford <[email protected]> wrote:
On 8/09/2016 2:51 PM, Salva Carrasco wrote:
Thanks, Joe.
After a quick look to the doc, I think:
- amode 64. Ouch!!
- blocking, non-blocking. I would prefeer an ECB mode.
This is for big data analytics right? So AMODE 64 makes sense. The
interface is a callable service so it's HLL friendly so compiling in AMODE
64 is no problem. IMO, it looks good.
Why do you want an ECB mode, so you can use timers? The API looks like it
uses ENFREQ ACTION=LISTEN which doesn't use ECBs.
I'd prefer it mainly so that I can shut down cleanly via a MODIFY or STOP
operator command. I.e. go into a loop which basically does a WAIT on one of
two ECBs: the async IFAMGET one; or the CIB one. Of course one can, sort
of, emulate this by putting the IFAMGET in a loop in a subtask and have
that subtask do a POST of the ECB. Then, during shutdown, simply DETACH the
subtask TCB which will terminate/abend the IFAMGET. I am just glancing
over this and don't see specifically yes or no as to whether the parent
task could do a IFAMDSC while the IFAMGET is blocked. I would guess so due
to an IFAMGET response code of RC 0x04 RSN 0x0405 on the IFAMDSC which I
think will cause the IFAMGET to get RC 0x04 RSN 0x0406. If this latter will
work, that would accomplish, with some minor complexity, the equivalent of
an asynchronous IFAMGET. I _hate_ the idea of "polling".
One possible plus of this subtask implementation is that one could
architect it so that only the subtask needs to be AMODE(64) and it could
just stay in that AMODE, letting the parent task do all the other work when
POSTed by the subtask in whatever AMODE it needs (hopefully 31 in most
cases). I'm not too sure about things in an LE environment, if the main
code is in C. But, most likely, the subtask code will need to be written in
HLASM anyway, no? And there would likely be no need for that code to be LE
enabled.
All good points. I think I could do the equivalent of attaching
subtasks in C/C++ wih POSIX pthreads. One that listens for a __console()
shutdown
and another collector thread. If I receive a shutdown I can
pthead_cancel() the collector and use handlers registered in
pthread_cancel_push() to cleanup
and process any pending data.
look forward to having a play with it...
This is a nice facility. I might get permission to see about using it on a
friend's system (IBM Dallas Innovation Center). It would be an
"interesting" (may you live in interesting times) way to distribute z/OS
SMF data to off-host locations via TCPIP. Or <grinning>, put it in a UNIX
file; or a DB2 table; or ???.
Agreed. I seems like it's designed for sending data off-host to logging
platforms like Splunk, ELK, Spark or Spark on z/OS.
The tricky bit is keeping up with the ring buffer while sending stuff
over TCP. Big buffers! I suppose a good design would be to use non-blocking
sockets and maybe a backlog queue? I wonder how it would work with slow
round trip protocols like HTTP. Looks fantastic for broadcast protocols
like websockets.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
