ADABAS 7.0 / Natural 8.3 / Natural 9.0 (NaturalONE)
Is it possible to access ADABAS in the cloud with Natural over the network? In other words, how can Natural communicate with ADABAS if these two components are not installed on the same server? If this is possible, how is the data secured (encrypted)?
ADABAS Communication across physical boundaries requires the add-on Entire Net-Work.
Entire Net-Work secures data on the wire via (Open)SSL.
Another method is to use the Adabas ADATCP(s) interface (requires Entire Net-Work license). This interface allows Natural running on a different node to access Adabas (on-prem or in the Cloud) via TCP/IP communication which can be encrypted if you also use Adabas Encryption for Linux solution.
Hi Wolfgang, hi Luciano,
thanks for the quick responses. Do you have experience if the performance will be reduced if Adabas and Natural are not on the same server?
With kind regards,
Vincent Schoone
I’ve worked with customers using Adabas / Natural in the cloud with Adabas and Natural on separate servers, with response time and batch performance comparable to or better than they had on the mainframe. In one case, no Natural ran on the Adabas server and batch performance was very good.
Key to performance was to minimize network latency, so minimal distance and network hops/firewalls are very important, along with the usual requirement for high speed disk availability.
You could also consider using Multifetch to fine tune the performance on session level and statement level.
Hi Eli,
do you have a good documentation that explains what exactly Multifetch is and how it works?
Best regards,
Vincent
Hello,
Try to use this page
Accessing Data in an Adabas Database (softwareag.com)
You can read manuals but here is simple overview:
Multifetch is an option in an ADABAS call to return multiple records in a single call. The purpose is to reduce number of ADABAS calls and thus speed up the application in elapsed time.
NATURAL has an option on FIND and READ statements e.g. READ MULTI-FETCH OF n , where n is the number of records you want retrieved. The processing of these records in NATURAL loops is transparent. I personally recommend n to be some number 20 or less. This reduces number of calls by 95%, increasing it more provides diminishing returns but risks issues with larger buffers. Note you cannot use this if you are updating the same records you just retrieved, however you could do a GET SAME and UPDATE…
Great feature IMHO.
P.S. If you are using it online for lists I recommend n to be same as number of records on the screen.
Eugene (Gene) Miklovich
ADABAS/NATURAL Systems Support and DBA
Cell: 916-202-7047
Normal Hours: 8am-4pm E.T.
Please call or text if assistance needed outside these hours.
I agree with @Eugene.Miklovich that this is a powerful statement.
Multi fetch is also available on HISTOGRAM statements.
One warning: do not use multi fetch to get few records. Example: do not use multi fetch to retrieve one record. It will waste time and resources retrieving multiple records in one call when only one record is wanted or needed.
Somewhere there is a formula to determine the best n value to use. It’s too complicated for me. The size of the view used is one of the factors. The smaller the view (buffer) the bigger n should or could be.
If the process is not going to read/find/hist large numbers of records, work out a reasonable guess how many records will be retrieved each time the read/find/hist is invoked. If you know that 99% of the time the logic will retrieve five records, make use 5.
If you expect the number of records to go into six figures and it is a frequent process, do some bench mark tests of a bare-bones program (containing only the IO statement) to try different values. The more frequent and/or important the process, the more bench marks are justified.
If nothing else, follow @Eugene.Miklovich suggestion and keep it to 20 or less.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.