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. > > I 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 ???. -- Unix: Some say the learning curve is steep, but you only have to climb it once. -- Karl Lehenbauer Unicode: http://xkcd.com/1726/ Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
