Sharing Data Between Systems

Sometimes, the data we want is on a different System i platform. We could transfer the data using a number of different techniques, such as:

·         FTP

·         A combination of save and restore commands

·         Send Net Object (SNDNETOBJ)

However, these techniques physically move the data, creating copies of the same information on the different systems. And we all know what happens next - the information becomes "out of sync" as updates are made to the data on one system and not on the other.

Here's a technique that can be used to share low-level amounts of data. The data will reside on one system, but it can be accessed by both that system and other systems. All it takes is a little configuration and Distributed Data Management (DDM).

DDM is a protocol that enables SNA-based communication. DDM is most commonly thought of for file sharing, but it can also be used for data areas and data queues. I'll describe how to configure data areas and data queues to utilize DDM and include a couple short examples of accessing data on a different system. I won't get into the configuration of DDM itself; I'll assume you already have a DDM environment that links two or more System i platforms.

Data areas and data queues are similar. They both store information in an unformatted state - there's no concept of records and fields as there is in a file. Commands can be used to display or change the contents of a data area, while performing the same actions on a data queue requires the use of an API call. A big difference is size - a data area can only be a maximum of 2,000 bytes, while a data queue can accommodate entries up to 64,512 bytes. They're both used for the same type of processing - relatively small amounts of information, especially information that may be accessed by several programs. For instance, this could be an invoice number, where an order-entry program would access the data area or data queue, retrieve and increment the invoice number, use the invoice number for the new order, and then put the updated invoice number back in the data area or data queue.

First, let's look at data areas and the command used to create one. Since I'm going to access this data area from two systems, I'll designate one system as the remote system (REMOTESYS) and the other as the local system (LOCALSYS). Sitting at a terminal on the remote system, I'll create a character-based data area (MRDTASRC) with this command:

CRTDTAARA DTAARA(MICHAEL/MRDTASRC)
     TYPE(*CHAR)
     LEN(50)
     TEXT('Source Data Area')

I'll then sign on to my local system - the system from which I'll access the contents of this data area. The command to create the DDM-based data area on the local system is:

CRTDTAARA DTAARA(MICHAEL/MRDTADST)
     TYPE(*DDM)
     RMTDTAARA(MICHAEL/MRDTASRC)
     RMTLOCNAME(REMOTESYS)
     TEXT('Destination Data Area')

Note the different parameters. I specified "*DDM" for the Data Area Type (TYPE) parameter. This means the data area I'm creating (MRDTADST) is a DDM "link" to a data area on a different system. The Remote Data Area (RMTDTAARA) parameter has a value of MICHAEL/MRDTASRC. This indicates that the actual data area to be accessed is a remote data area. And the system that contains the remote data area is specified in the Remote Location Name (RMTLOCNAME) parameter - I've specified REMOTESYS, the name of the remote system.


Once I've created the data areas, I can access the remote data area (MRDTASRC) from the local system. Here are a couple quick CL programs to test this out:

PGM
DCL    VAR(&MYVAR) TYPE(*CHAR) LEN(50)
DCL    VAR(&MSG) TYPE(*CHAR) LEN(125)
/* Change it...                  */
CHGVAR   VAR(&MYVAR) VALUE('12345')
CHGVAR   VAR(&MSG) VALUE('Setting the data area to' *BCAT &MYVAR)
SNDPGMMSG MSG(&MSG)
CHGDTAARA DTAARA(MICHAEL/MRDTADST) VALUE(&MYVAR)
ENDPGM

This program will change the remote data area to a new value ('12345'), and send the user a message. I get this message:

Setting the data area to 12345

Now I know the remote data area has been changed. Here's a program to retrieve the data from the remote data area:

PGM
DCL    VAR(&MYVAR) TYPE(*CHAR) LEN(50)
DCL    VAR(&MSG) TYPE(*CHAR) LEN(125)
/* Retrieve it...                 */
RTVDTAARA DTAARA(MICHAEL/MRDTADST) RTNVAR(&MYVAR)
CHGVAR VAR(&MSG) VALUE('And the data area contains' *BCAT &MYVAR)
SNDPGMMSG MSG(&MSG)
ENDPGM

Running this program produces this message:

And the data area contains 12345

Now I know the program accessed the remote data area.

The same concepts and techniques are used for data queues. Here's the command to create a data queue on the remote system:

CRTDTAQ DTAQ(MICHAEL/MRDTAQSRC)
    MAXLEN(100)
    TEXT('Source Data Queue')

Nothing special - just a 100-byte-long character-based data queue.

Here's the command to create the DDM-based data queue on the local system:

CRTDTAQ DTAQ(MICHAEL/MRDTAQDST)
    TYPE(*DDM)
    RMTDTAQ(MICHAEL/MRDTAQSRC)
    RMTLOCNAME(REMOTESYS)
    TEXT('Destination Data Queue')

Again, the Data Queue Type (TYPE), Remote Data Queue (RMTDTAQ) and Remote Location Name (RMTLOCNAME) parameters identify the data queue, the library where it resides and the remote system.

Here are two CL programs to test out the data-queue connectivity. The first is a program to send information from the local system to the remote system:

PGM
DCL    VAR(&MYDTAQVAR) TYPE(*CHAR) LEN(100)
DCL    VAR(&Msg) TYPE(*CHAR) LEN(125)
/* Send/Retrieve DtaQ Variables.         */
DCL    VAR(&DTAQNAM) TYPE(*CHAR) LEN(10) VALUE('MRDTAQDST')
DCL    VAR(&DTAQLIB) TYPE(*CHAR) LEN(10) VALUE('MICHAEL')
DCL    VAR(&DTAQSIZ) TYPE(*DEC) LEN(5 0) VALUE(100)
DCL    VAR(&DTAQWAT) TYPE(*DEC) LEN(5 0) VALUE(1)
/* Change it...                 */
CHGVAR   VAR(&MYDTAQVAR) VALUE('99999')
CHGVAR   VAR(&MSG) VALUE('Setting the message to' *BCAT &MYDTAQVAR)
SNDPGMMSG MSG(&MSG)
/* Send it...                   */
CHGVAR VAR(&DTAQSIZ) VALUE(100)
CALL PGM(QSNDDTAQ) PARM(&DTAQNAM &DTAQLIB &DTAQSIZ &MYDTAQVAR)
ENDPGM

And second is the program to retrieve the contents of the remote system's data queue:

PGM
DCL    VAR(&MYDTAQVAR) TYPE(*CHAR) LEN(100)
DCL    VAR(&MSG) TYPE(*CHAR) LEN(125)
/* Send/Retrieve DtaQ Variables.         */
DCL    VAR(&DTAQNAM) TYPE(*CHAR) LEN(10) VALUE('MRDTAQDST')
DCL    VAR(&DTAQLIB) TYPE(*CHAR) LEN(10) VALUE('MICHAEL')
DCL    VAR(&DTAQSIZ) TYPE(*DEC) LEN(5 0) VALUE(100)
DCL    VAR(&DTAQWAT) TYPE(*DEC) LEN(5 0) VALUE(1)
/* Retrieve DtaQ Value.              */
CALL    PGM(QRCVDTAQ) PARM(&DTAQNAM &DTAQLIB &DTAQSIZ &MYDTAQVAR &DTAQWAT)
CHGVAR   VAR(&MSG) VALUE('And the message is' *BCAT &MYDTAQVAR) SNDPGMMSG MSG(&MSG)
ENDPGM

The data-queue programs are a bit longer than the data-area programs, but they're not any more complex.

Sharing information between systems is easy with DDM-based data areas and data queues. There are no synchronization issues since data isn't copied between systems. Standard commands such as Change Data Area (CHGDTAARA) and Retrieve Data Area (RTVDTAARA), and standard API calls such as Send to Data Queue (QSNDDTAQ) and Receive from Data Queue (QRCVDTAQ) are used. Use these techniques when you need to access information on remote systems.