Would someone be willing to share a simple COBOL II ACI server example? I have the EXX copybooks. I’m planning to use it as a shell to call 3rd party software.
TIA,
Dave Love
California Board of Equaliztion
Why wouldn’t you use the RPC server? You can generate a skeleton server subprogram from the workbench and use that to call your 3rd party software.
Are your calls to the 3rd party software synchronous?
Hi Doug, is the COBOL RPC server for the most part more effiecient than a user written COBOL ACI server? We need something cheaper to run on the mainframe than our current batch Natural ACI server that communicates synchronously with this same 3rd party software.
Thanks,
Dave Love
I haven’t seen a direct comparison, so it would be interesting to do one!
Whether the Natural RPC Server would work or not would depend on what your ACI server is doing that is functionally different from an RPC server. An RPC server does synchronous request/reply - receives one message, processes it, sends one reply. ACI servers have the capability to do asynchronous and asymmetric processes (for example, mail box receive-only or zero to many replies to one request, unit of work, etc).
If you are doing synchronous request/reply, then the COBOL RPC Server should be as efficient as any ACI Server doing similar work.
Do keep in mind though: the bulk of the work for any server is usually the application processing (the server subprograms) rather than the server itself.
If you are doing Natural to COBOL (or Assembler or PL/1) calls from your Natural ACI Server, you may want to verify that the linkages are set up correctly to minimize overhead.
@Douglas
Remember that version 8 now has reliable RPC that works really neat with asynchronous calls!
- also for COBOL RPC - worked out of the box when I tried it last summer
Finn
Hi Doug and Dan, thanks for your replies.
Doug, the goal to this experiment is to reduce overhead. I’m hoping the smaller COBOL components will reduce CPU usage when paged in and out by z/OS. Our current client is CICS/Natural/ACI and I desire to keep it that way. Defining ACI clients dynamically is easy where RPC clients require upfront Natparm changes, etc., which is a road I’m/we’re not ready to go down. So, the end product will most likely be a batch COBOL ACI server interfacing with the CICS/Natural/ACI client if provides ample savings over the current process.
As you suggested I followed up with our data center to make available the COBOL RPC server for initial testing. I was planning on comparing the costs for running it against the Natural RPC server. I’ve already used STROBE against a Natural RPC server and it is interesting to see how each component of z/OS is utilized. I’m hoping the COBOL RPC initial tests show enough ROI to continue with the COBOL ACI server experiment.
I’m still in the market for a COBOL ACI version of either the CALC or HELLO server subprogram. All I’m looking for is a working ACI COBOL server interface. I already have COBOL examples calling the 3rd party software. This transaction is syncronous.
Thanks again for your help,
Dave Love
It appears that the examples RPC ACI Bridge examples folder in the EntireX documentation contains ACI server examples of the CALC subprogram in both COBOL and Natural. Problem solved!
