According to V9.6 release notes ATTACH SERVICES component of the kernel in zOS EntireX Broker will be retired in the future (sometime after 9.6). So what upgrade path do customers have that are using this now, in particular to startup ACI servers. Do they now have to write their own?

Here is the snippet:
Features to be Dropped in Future Versions
The following features and platforms are not planned to be supported in future versions.

Broker Services
Broker Services have been partially retired since EntireX version 8.0. They will be fully retired with the next version of EntireX. This affects in particular the following components:

Broker Services WebSphere MQ Support
Retired since version 8.0. There will be no direct replacement for the Broker Services WebSphere MQ support. However, WebSphere MQ is supported with the EntireX WebSphere MQ RPC Server and the EntireX WebSphere MQ Listener. For scenarios using the Broker Services WebSphere MQ support, both of these might be a more modern and easier-to-use alternative.

Broker Services APPC Adapter
Retired since version 8.0. There was no replacement for the Broker Services APPC Adapter. We recommend using the standard EntireX functionality in the future. Possible migration paths can vary and should be determined based on your projects.

Broker Services Attach Service
There will be no replacement for the Broker Services Attach Service. Most of the RPC server implementations support multiple worker models for load balancing purposes. See for example Scenario Worker Models under CICS | Batch. For Natural RPC servers, the Natural RPC Server front-end provides similar functionality.

Hallo Eugene,

Broker Services will be fully retired with EntireX 9.7 in October 2014. This includes the ATTACH SERVICES.

For ACI servers, there is no replacement for the ATTACH SERVICES within EntireX.
EntireX 9.6 (and the ATTACH SERVICES) is still supported on

• z/OS 1.13: till 2016-09-30
• z/OS 2.1: till 2017-04-30

Kind regards,
Juergen

Like Eugene, I am keen to know how other people are facing up to the removal of Attach Services. What solutions are they adopting?
I am looking for a solution that will accommodate both conversational and non conversational applications. Reading the manual it seems to give us two possibilities (from what I can see) - RPC and Cobol under CICS. For us Cobol is something we are trying not to use and we do not want an RPC solution so any other ideas? How are you doing it?

What are you using Attach Services for, specifically? Are you using it to start batch servers, CICS servers…? Would starting the severs on a schedule via a console operations tool (job scheduler, lights-out management tool,…) suffice? Is your server load quite variable that starting (and stopping) servers is a requirement?

The facilities of EntireX Broker that support Attach Services are not being retired. The ACI functions are in use by the various provided servers (such as the various RPC Servers) and are documented. Writing an attach server can be done in any language that can call EntireX ACI functions, including Natural, and resembles a conventional ACI server in some ways. The attach server needs someway to start the server function in response to a specific return code from EntireX Broker - the simplest is often to submit JCL to the internal reader that will start the requested server. Another possibility is subtasking (which admittedly gets a bit trickier to do, even with Natural’s support via CMTASK), particularly with CICS servers. For Linux/Unix/Windows applications (which never had Attach Services), server processes can be spawned with native operating system facilities. The Java based RPC Servers use Java thread running processes to run as many server instances as requested.

Note that the started server can be of any type - conversational, non-conversational, UOW, RPC, ACI - whatever (really, it doesn’t even have to start an EntireX server, but that would be somewhat pointless).

Please elaborate on your use cases and we’ll see if the community can offer some creative suggestions!

I will split our workload into 3.
For batch we have developed an application that sends a trigger to OPC to start a batch job when requested. We should be okay with that. That should not change.
For non conversational - we use attach services to trigger the server as an asynchronous CICS transaction that invokes the Natural program to receive the data as soon as the data has been put in the persistent store.
For conversational - we use attach services to trigger the server (running under CICS) as soon as one is requested.
The aim is for us to have a real time environment so we can provide customers with the latest information. Our work load can therefore be variable and go from 0 to 100’s of conversations very quickly - at all times of the day.
For the non conversational aspect an attach manager written in Natural could be the way forward. I would need to read more to see how we get several servers running at the exactly the same time. Or is there a better approach?
The conversational approach will need thinking about. Cobol / Assembler has been mentioned but at our site neither is seen as ‘strategic’ and so any solution utilizing these languages would not be first on the list.
For conversational I think any solution has to be CICS or RPC and it must have the ability to start between 1 and x of the same servers at exactly the same time.

I think people may look for an equivalent tool for z/OS like the one that is retiring.

Where you – when requested by Broker - with parameters can specify which server to start, min and max, etc. Where you don’t have to create code yourselves (Natural or whatever) to make an attach server.

Similar to Attach Manager on Open Systems (exxatm).

Are you currently using the Attach Manager on z/OS?

I’m not clear on where the type of server (conversational/non-conversational) impacts the startup. The attach manager receives a code from EntireX indicating that there was a request for a server of interest (specified by the class/server/service trinity) and none available to service that request. It is up to the attach manager program to then take action to start a server. That server does the usual register and receive (and optionally shuts down after processing the receive).

For CICS, you should be able to use the EntireX RPC Server - you need to have a CICS transaction that is going to start the server (whether it is Natural, un-Natural, ACI or RPC).

Currently we are not using the Attach Manager on z/OS although we have worked with external suppliers to help them setup attach managers, so we know how they work.
Your thoughts confirm what I thought. We must explore the CICS RPC server route. It is not a route we want to go down but looks like we have no option. I suppose we are just frustrated that an essential part of the software which we relied on has been taken away. Who knows, maybe when we implement the new solution I may be converted.
Once we get there I will post how we did it on here.