Hi, I need to be able to obtain FDT’s, read physical with multi-fetch, get & update database records, ALL using direct calls with ACBX to handle Adabas 8 features like LA and gt 32k record buffer size, and am having serious issues with building a prototype to prove that this is possible within our infrastructure.
Surfing around, current indications are that USR1043N is the recommended route over CMADA and CALL ‘ADABAS’ directly, but for the life of me, I cannot get my Natural prototype to use USR1043 with my ACBX data structures and return anything constructive.
According to text member USR1043T, only the CL command is possible using ACBX. Surely this is not the case?
Also if USR1043 can be used for other Adabas commands as other documentation leads one to think, then how does the specification of the following standard interface with USR1043 allow for the ABD’s of the format, record, etc buffers?
So you would have to resort to calling (for example) an Assembler program issuing the direct calls, which, otoh, is discouraged because it would break Natural’s transaction integrity.
Let’s see if you really need to issue direct calls yourself
For reading in the “extended” FDTs you will probably really need to, but here it would be no problem calling an external subroutine as there are no transaction issues.
Read physical with multi-fetch, however, IS possible from Natural - what verrsion are we talking about ?
Hi Wolfgang, I’m aware that Natural can do the read physical with multi-fetch, but as my requirement is that the code will only be aware of which db file to read at execution time, it will have to be done using direct reads, with the parms set up at execution time.
I’m really disappointed that I cannot use the ACBX features with a direct call in Natural (which is my language of choice).
Do you know why this is not actually possible? It doesn’t make sense to me…?
Hi Steve, that’s a good suggestion but there are hundreds of files involved, and with more constantly being added to the list, also with FDT’s constantly changing, that’s why I’ve chosen to do it with direct calls, to extract the latest FDT and to apply it to whichever db file is requested…
It can be done, just not using Natural unfortunately!
Hi Steve, yup, had already considered dynamically created code, but thought that the direct call solution was the better of the options available. Besides I think that dynamically created code would scare the socks off most people I work with
Natural supports Adabas 8 features - it’s USR1043N that’s the problem.
I have done something similar. My requirement was to extract records from one data base and load them into another. Of course the FDTs of the two files would not match due to constant asynchronous updates (think Production vs Development), so I needed to generate the field list dynamically.
Direct calls and FDTs are a pain to use, so I did it all in Natural. To do that I needed to ensure that DDMs were kept in synch with the FDTs. What simplified the process was that a single program “model” (an extract/load) defined all my requirements. I suspect your situation allows the same.
I created a working program for a single file. From that I created a template by replacing code with unique tags, for example view name, source DBID, and target DBID. The template was saved in a Natural library as a Program source.
My utility read the template from FUSER and replaced the embedded tags as appropriate. The selected DDMs were read from environment-specific Predict instances to prepare a field list which was inserted at the appropriate place in the template. Once the template was prepared, a RUN command was issued. I never saved the updated source because the field lists could not be trusted for future executions.
User exits were used to read the template, access Predict, and set the run-time DBIDs.
I think you would find this easier than using Natural’s dynamic source approach. Yes, it’s still code generation, but the template can be reviewed (and understood) by any programmer, and the ‘run’ version could be listed for the sockless faint of heart.
Hi guys, am using L2 direct calls using ACBX from COBOL, but am having issues with making the L2 multi-fetch work… I need to understand the data returned in the multifetch buffer so that I can use it properly, extracting the relevant record data from the record buffer.
Have taken a look at the manuals and defined the multi-fetch buffer accordingly:
10 MB-BUFF-NO-OF-ELEMENTS PIC S9(8) COMP.
10 MB-BUFF-RDE PIC X(16) OCCURS 10 TIMES
INDEXED BY MB-BUFF-IDX.
with each occurrence of the RDE being moved into this structure…
05 WS-RDE PIC X(16).
05 FILLER REDEFINES WS-RDE.
10 WS-RDE-LEN PIC 9(8) COMP.
10 WS-RDE-RC PIC 9(8) COMP.
10 WS-RDE-ISN PIC 9(8) COMP.
10 FILLER PIC X(4).
… so that I can work with it. The L2 exec RC=0 and the rec buffer has the correct data of the prescribed no. of recs, but the problem is that the info described by the multi-fetch buffer is rather odd… do you have suggestions as to what is wrong - I suspect something to do with the format of the variables, but don’t know what exactly?
MB NO OF ELEMENTS: 1077952576
RDE(1):
LEN: 1077952576
RC : 1077952576
ISN: 1077952576
RDE(2):
LEN: 1077952576
RC : 1077952576
ISN: 1077952576…and so on, all the same!
Hi Marbod, thanks for the tip, you’re correct, it seems as though the content of all the RDE’s in the multi-fetch buffer are spaces, with the RDE count set to 7795…?
My L2 worked perfectly before setting up multi-fetch…!
The L2 is now executed with cmd option 1 specified as ‘M’ which implies that multi-fetch is on.
The format buffer doesn’t change for multi-fetching, so remains at 6 bytes, requesting only 2 fields.
The length of the record buffer required for a single record was 47, so to test multi-fetching of 3 records at a time, this is spec’d for the L2 as 141.
The multi-fetch buffer is defined as 4+ (16x3) = 52.
Have also spec’d multi-fetch factor of 3 in ACBXISL, and also 0 allowing Adabas to work out optimum no. of recs to return dependent on buffer sizes, and get the same results both ways.
The L2 with multi-fetch exec RC=00 and the record buffer is filled with the 3 records, format as I expect from the format buffer.
The problem is that the resultant multi-fetch buffer is not giving me what I need to be able to interpret the record buffer and work with it, viz. individual ISN’s and record lengths, to extract each record out of the record buffer and process it individually.
According to the manuals, I’m expecting a RDE count (4bytes), followed by multiple RDE’s (16bytes each), 1 for each record returned in the record buffer. But all I ever get is a RDE count of 7795 and RDE’s filled with spaces - irrespective of how I manipulate the buffers lengths etc.
