Re: COBOL IN SRB Mode (Was Un-authorized caller)
Our current server-side JavaScript (SSJS) engine is based on SpiderMonkey. This is the version that we zIIP enabled. Note, however, that since SM was never conceived as running in a System z environment, it's certainly *not* a typical SM distribution. Our prior version (which many customers still use, and we support) was a proprietary code base (lightening fast, but we ultimately decided that we are in the integration business not the language business). We have other code bases running in-house (on System z), but we are always wrestling with finding the best intersection between availability technologies and real customer integration requirements. To us, the JS engine is simply the foundation to build zOS and CICS integration solutions. As a result, we tend to think that the real value is in library of JS objects that have been created over the last decade which allow customers to interact with zOS and/or CICS apps and data sources. Russ Teubner HostBridge Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL IN SRB Mode (Was Un-authorized caller)
Hi John, Your comment is wise: Just because you can do something doesn't mean it's worth doing. This is a great summary of our quest to zIIP enable a bit of our COBOL code. Of course, this also means you have to do your homework because it may just turn out that, in some cases, it's *definitely* worth it. A System z ISV in this day and age can't afford to miss those cases (at least that's my philosophy). For example, zIIP enabling our core HostBridge products, Base and JSE (our CICS-based JavaScript Engine), was a no-brainer Likewise with HB Socket Support (zIIP-enabled EZASOKET alternative). On the other hand, our COBOL/BMS utility transactions??? Not so much. I must add that this break-even assessment is a moving target because zOS processor switching overhead seems to be trending down (and our own code paths are getting shorter). Note also that the model of the System z hardware makes a big difference. If the GPs are knee-capped relative to the zIIPs, the GP savings and potential improvement in throughput are staggering in some cases. Russ Teubner HostBridge Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL IN SRB Mode (Was Un-authorized caller)
Hello all, The conversation on this topic is very interesting. As an ISV licensed for the zIIP API, we have played around with all sorts of possibilities. While our LEASM and C/C++ code runs on zIIP (and even inside CICS), earlier this year I was intrigued with COBOL. While we don't have much COBOL in our products, we do have a bit and so we researched it. Just to take this discussion of the theoretical realm, consider the following output (both HBZIQSRB and HBZICOB were run on a zIIP): 20130928 201457.334405 HBZIQSRB CEEPIPI CALL,CALL_SUB_ADDR_NOCHK2 20130928 201457.334938 HBZICOBENTRY 20130928 201457.342362 HBZICOBHello World from COBOL! 20130928 201457.342364 HBZICOBEXIT 20130928 201457.342367 HBZIQSRB CEEPIPI RETURN,CALL_SUB_ADDR_NOCHK2 Now... to make that small bit of magic happen, three big aspects had to be considered: (1) LE PIPI enclave management, (2) how the COBOL prolog determines it's view of reality (and the state/status of the LE enclave) when it receives control, and (3) how your program orchestrates (or games) LE and COBOL to make it all hang together. As a result of writing this bit of infrastructure, I would offer the following observation: The conceptual/theoretical discussions related to zIIP enablement and SRB authorization are interesting. However, the practical realities of getting LE and COBOL to work in this environment are a WHOLE different matter. It's certainly not impossible, but it should be approached with great care. Russ Teubner HostBridge Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
zAAP's are indeed used by Java code running on a TCB. However, to my knowledge, it does not follow that: With zAAP on zIIP, they must be using SRB's. IBM determines the rules in this regard. To me (as both an ISV and System z developer), IBM allowing more code to run on specialty engines is a VERY good thing. It continues the controlled reduction in the cost of System z ownership. As a side benefit, it has also promoted innovation within the ISV community. For example, by zIIP enabling our integration products, some of our customers were able to deploy very cost effective solutions that would not have been possible otherwise. This has allowed them to expand their System z workload. I don't think customers mind using (and paying for) high-value MIPS for high-value apps. However, everything else (e.g., integration and plumbing) should be run on specialty engines (within the bounds of IBM's rules). Russ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zIIP simulation
I will go on record as being another zIIP-enabled vendor (like those who have already opined) for which PROJECTCPU is worthless. When CICS starts and our product initializes, we look to see if a zIIPs are available. If not, we don't worry about marking the enclave SRB as zIIP elidgeble. If fact, there's an option to not even run it under an Enclave SRB. This approach holds true for the following products: HB Base, HB JavaScript Engine, HB Socket Support. HB BPIC (Batch Programs Inside CICS) doesn't exploit zIIP. Russ Teubner HostBridge Technology www.hostbridge.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using zIIP engine
Hi Don, I concur with Sam. Scheduling work as an Enclave SRB is necessary, but not sufficient. You must also use an IBM licensed API to define/manage the Enclave's zIIP eligibility. The API is part of the materials that IBM may license to ISVs. More to the point of your question... As part of our zIIP-enablement RD we compared the cost of: (a) frequently starting Enclave SRBs, and (b) using a persistent Enclave SRB in conjunction with MVS Suspend/Resume services. We actually ended up using both techniques in our product (although in different situations). Russ Teubner HostBridge -Original Message- From: Sam Siegel [mailto:s...@pscsi.net] Sent: Tuesday, October 16, 2012 9:15 AM Subject: Re: Using zIIP engine Don - contact IBM partner world. You need to sign a license and confidentiality agreement to obtain documentation needed to run on a zIIP. License is only available to ISV devs. ,ot to in-house commercial cust. Sam --Original Message-- From: Donald Likens Sender: IBM Mainframe Discussion List To: IBM-MAIN@LISTSERV.UA.EDU ReplyTo: IBM Mainframe Discussion List Subject: Using zIIP engine Sent: Oct 16, 2012 7:09 AM I am upgrading my product to use the zIIP engine. It is my understanding that to do this I must schedule an enclave SRB. I am confused here. WLM is involved and there seems to be more to this. Can anyone explain? My only purpose in using the zIIP is to reduce the GP CPU usage, so I plan on issuing a dependent enclave SRB and wait for it to finish. Does anyone have any gotchas to share? I know this is contrary to SRB designed but would it be more efficient to have one preemptable SRB running forever and use wait and post to control or simply schedule the SRB and wait for it to complete? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Sent from my Verizon Wireless BlackBerry -- 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
