We need to remove a sub system (Natural program & Adabas files) to another mainframe. However some Adabas file (which Natural programs refer to) will remain in the current mainframe as they are used by other subsystems.
My question is how the Natural programs moved to other mainframe can access the Adabas files which will continue to stay at current Mainframe ?
The interaction needs to be real time as it is happening now.
Please suggest if any solution available to resolve such problem ?
You seriously need to consider the reasons why you are being asked to move this subsystem before settling on an integration strategy. Why carve out this subsystem if you are going to consider the remote database an integral part of your application?
If your application only needs read-access to the data, perhaps you would be better served with a replicated copy of the file(s). See Event Replicator or Entire Transaction Propagator for your solution there.
You could also loosely integrate by making service calls to get your remote data. See SOA Gateway, EntireX or other possible products to enable this.
Only after you can explain the reasons you are making this change and the planned roadmap for your systems can you choose the most appropriate integration strategy. Otherwise, you risk succeeding at your project but not fulfilling the objectives as to why you did it.
Thanks for your reply. Indeed craving out a sub system to other mainframe is not a standard process. But we are in a situation where the core processing (happening in the subsystem) would be outsourced, where as the rest of the processing (other subsystems) will continue to be inhouse.
The subsystem is closely integrated with rest of the subsystem and does real time access to data in other subsystem ADABAs files in both read and write mode and vice versa. We are looking at cheapest solution without impacting on performance.
I understand having different support groups maintaining different sets of code, but I am not sure what is gained by separating the code to different mainframes if you are going to have the data read and updated on the original mainframe. You are still directly affecting the company’s data. It seems the move to carve out the subsystem is for appearances only with no real separation occurring. It’s a lot of work for nothing if you can still update data directly from your own partition.
If the issue is a difference between outsourced developers and in-house developers, it’s best to just make sure everything is detailed contractually and then perhaps set up different application libraries, providing appropriate library access to the sets / groups of users and linking the files with READ or UPDATE links as appropriate. This allows the outsourced developers to protect their code and data from the in-house developers and vice versa without making it overly complex.
The applications are tightly integrated, and there is no need to move the code to another platform if there is no plan to change the fact that these will remain tightly integrated. Only if you were planning to make the applications much more loosely integrated would it begin to make sense moving the subsystem to another partition.