“data definitions” and “data” disagree.

, , , ,
1

We have a project where Event Replicator could be an option replicating from Adabas on z/OS to Adabas on Windows.

But the problem is that the data definitions on target are defined as “big chunks

2

Hello Mogens,

Currently, the Reptor does not allow “editing” of field contents.

For an Adabas to Adabas replication the Reptor issues Adabas direct calls to the Windows database which recognizes the source architecture and encoding. This means that Alpha fields are translated from EBCDIC to Windows codepage.

If some Alpha fields are redefined having binary or other numeric fields a schematic EBCDIC to ASCII conversion would make the contents useless on the target.

NV field option
To avoid conversion with these redefined fields Adabas has the NV field option which is specified with the field definition. Such fields will not be EBCDIC/ASCII converted. Using such a field in a subscription will leave the contents intact.

However, an application expecting numeric contents at a fixed location in such a redefined Alpha field would have to be able to interpret mainframe formatted data (byte swapped binary, Unpacked number in EBCDIC).

Subscription Exit
If it is too difficult to do this in the application, there is a possibility of writing a subscription exit that can change the field contents to the form expected by the application.

The alternative to using a subscription exit would be working with MQ/Broker and a target that reads the subscription data from a message queue, reformats the data in the alpha fields and stores the data into the Windows Adabas database.

Kind regards,
Marbod

3

Hi Marbod,

Thank you for your detailed answer.

The ‘NV’ option must assigned to the source fields in the Adabas FDT, right?

  • what consequences may it have for other programs access to this file?
  • can it be applied dynamically or do you have to unload/decompress/compress/load?

I looked briefly at “Subscription Exit

4

Hello Mogens,

since Reptor is running on mainframe it would send the data in the database encoding to the Windows database and codepage conversion would be done on Windows. That means that Adabas on Windows would have the NV field option set. This could be made different to the source database.

The NV option’s only difference for users with different encoding: such fields will not be converted - but the normal ASCII blank compression at the end of the field will be done in the target database.

Currently, NV option cannot be changed in loaded file. This may perhaps be possible in the next version on MF (ADADBS change field) and OpenSystems.

Concerning the Subscription Exit:

  1. initialstate data always passes through subscriptions
  2. the exit gets the data as defined by the subscription format not the compressed record.
  3. the dbid and file number of the originating database is given. No information on the target database/file number - there could be more than one.

Kind regards,
Marbod

5

Hi Marbod,

Just to be sure; the NV option is not necessary at the source Adabas but just at the target Adabas?

6

Hello Mogens,
to be precise, you can avoid setting the NV option on the source file when the subscription does not convert the alpha (or Wide) characters.

If you see keywords such as SACODE or SWCODE and SARC then you probably have conversion which will hurt the redefined binary content in non-NV alpha fields:

ADARPD SUBSCRIPTION NAME=EMPLOYEE                 
ADARPD  SACODE=819,SWCODE=4091,SARC=9             
ADARPD  SDESTINATION='OUT1'                       
ADARPD  SFILE=11,SFDBID=10006                     
ADARPD  SFBAI='AA,AC,AD,AE,AH,8,U,AL,AN,AM,AO,AP.'

Kind regards,
Marbod

7

Hi Marbod,

But if only want to “turn off” conversion on selected fields in the file I need to assign NV on these fields it the FDT of the source Adabas, right?