In z/OS 1.7, the EntireX needs to be migrated from v-721 to v-732. Concurrently ADABAS will be migrated from v-742 to v-744.
EntireX-732 comes with WAL812 libraries and ADASVC version-8. The ADABAS-744 comes with ADASVC version-7. To migrate EntireX from 721 to 732, following are the queries.
Which ADASVC should be installed ? From WAL812 or ADA744.
Which WAL libraries should be used in the Broker? WAL812 of EXX732 or WAL744 of ADABAS-744?
OR implement two-way SVC communication by intializing the SVC-ID table with two separate SVC installation.
For EntireX internal functions e.g. EXX Security, RACF RACroute…the ADASVC installed from WAL812 libraries can be used.
While for ADABAS the ADASVC installed from ADABAS-744 LOAD libraries can be used.
Note:- The client has ADABAS/NATURAL where the Natural-RPC is using TCP/IP stack i.e. SAGTOKEN (stub BKIMBTSO). Not the NATETB23 for SVC.
The suggestions are
Use “one-way communication” i.e. only 1 ADASVC installation.
Use ADASVC v-8 (we are also testing ADABAS-812, so the SVC-8 is already implemented, which can be used for EntireX + ADA744, since it is downward compatible).
Use ADASVC from ADABAS.LOAD. Because the WAL libraries are provided mainly for the non-ADABAS customer.
with EXX73, you can run without any SVC. EntireX Security runs in the same kernel as the Broker - no SVC involved. If the applications are all using TCP/IP, then you don’t actually need the NET (SVC) transport.
if you decide to install the NET transport anyways, then I suggest using Adabas 8 as it provides the larger message area (up to 2gb) than Adabas 7 (up to 32k). Generally the SVC is faster and requires less CPU for local communication than TCP/IP, but I haven’t benchmarked Adabas 8 yet and these timings do vary with installation options and OS versions.
I recommend using the WAL libraries provided with EXX for Broker, even if you have Adabas installed.
If EXX73 can run without any SVC, then why the ADASVC (earlier version of EXX it was ADASVC5) is provided to be coded in Broker attribute.
Let’s assume a typical scenario, where the NET transport is used, then can the secured Broker communicate with Natural RPC server + ADABAS having a SVC communication?
Is it a good idea to have an exclusive SVC installation for EntireX, with its own subsystem which will be separate from ADABAS SVC which is used for COM-PLETE, ADASQL, NATURAL? But this will have 2 different type of SVC (SVC-7 & 8). OR else, we need to use WAL812 libraries to install SVC-8 for ADABAS-7.4.4. But SAG always recommends to use ADABAS.LOAD instead of WAL.LOAD for ADABAS cross memory services.
If you are using EntireX Security and want to use the Trusted User feature, you will need to use the SVC. TCP/IP communcations cannot use the Trusted User feature. All communication types can use EntireX Security by passing the appropriate user id and password and using the appropriate Broker stubs (depending on the version of EntireX and ACI being used).
I don’t know why you would use a different SVC if the components need to communicate with each other. If you are using Natural/Natural RPC to communicate with Adabas and EntireX, they need to be on the same SVC. I don’t think there is a configuration option for Natural with Adabas and EntireX to use different SVC’s.
The ADALNK (ADALNC, to be precise) is located within COM-PLETE, and not at the ‘user level’, and driven by COM-PLETE, the application calls a COM-PLETE function rather than ADALNK directly.
We are not planning to use the “Trusted User-id” feature.
What we are trying to achieve here is the independence between Adabas Cross-Memory Services used to access Adabas databases and Adabas Cross-Memory Services used for EntireX Communicator.
Moreover EXX732 with WAL812 has SVC:type-8, whereas we are still on ADABAS-744 version with SVC:type-7. If we install the SVC from WAL812, we can use this SVC in the BROKER attribute, which is downward compatible with SVC:type-7 of ADA744.
