My company is preparing to use Adabas Cluster, but we still have Cobol using Adabas Native SQL. According to the manual, Adabas Native SQL is not supported on cluster, because the product is not prepared to call X48.
I have some questions:
Is there any plan to Adabas Native SQL to support Cluster environment (and Adabas Cluster)? If so, could you please tell me the date planned to the product be available?
If there is no plan to use Adabas Native SQL on Cluster environment, do you have any idea how to solve it? Suppose that I have several Cobol using Native SQL, what would be your suggestion?
I have Cobol DB2 calling Cobol Adabas (SQL) and then calling Cobol DB2 and finally Cobol Adabas SQL, how I can do to keep the same user from the first called (Adabas SQL) to the second called (Adabas SQL), if I change Cobol Adabas Native SQL to Natural programs? How does Adabas know that the user is the same from the first called if I have an update transaction?
Is there any way to call x48 on Cobol direct calls? If so, it could be another solution instead of Natural programs. Could you give me an example how to call x48?
Please tell me the manual and the page of the manual you refer to, so that we can correct any misleading information.
The fact that Adabas Native SQL is not prepared to do x48 calls, does not imply that it is not supported on Cluster Services.
Cluster Services is transparent to application programs.
Most applications running with Cluster Services do not use x48 calls.
This rather means that Adabas Native SQL does not fully support Parallel CICSPLEX and that ADABAS Native SQL transactions have a so called CICS affinity.
As long as a user remains assigned to the same CICS address space during an Adabas session your Native SQL application will work under Cluster Services.
Problems will only arise if a user is switched to a different CICS address space of the same CICSPLEX between terminal I/O interaction while an update or read transaction is open in Adabas.
Also note that CICSPLEX will do this only in rare “emergency” situations, for example when a CICS comes down.
And again this is likely to matter only if the user doing a terminal I/O is dispatched onto a different LPAR, which CICSPLEX is even less likely to do.
I am not sure which page or manual I’ve seen it before, but the case is Adabas Native SQL is not supported on Cluster environment as it should be.
You are right when you said when you have affinity, Adabas Native will work, however, I cannot explain to CIO, and manager that I use SYSPLEX to have high availability, but for the applications written in Cobol Native I will need to use in only one CICS address space.
I think you word this a little bit too pessimistic.
You can run Adabas Native in a CICSPLEX with more than one CICS.
The main objective of SYSPLEX is to keep the system alive in case of failure of a single component, but not necessarily user transactions. Of course users running on an unaffected system component should not be affected by a failure somewhere else.
CICSPLEX will normally not change the CICS a user is assigned to.
When you run Adabas Native SQL, the worst what will happen is that users at terminal I/O, but being in an Adabas session and assigned to a CICS, which fails, will be routed to a different CICS. Without X48, they may still receive a response code and be backed-out, but the system remains up and running and all can proceed without delay and this affects only Native SQL users assigned to the failing CICS. Please note, that when an Adabas nucleus fails in a cluster all user sessions with open READ or Update transactions with this failing nucleus would receive a response code anyway, even those doing X48 calls.
This is in no way a contradiction of what SYSPLEX high availability is supposed to accomplish.
The important objective of SYSPLEX is that the system remains up and usable. To let user transactions survive is at best a secondary objective.