Re: New application using remote databases from RPG program

Evan Harris wrote:

Don't forget that there is maintenance required to make the DDM
files simple to set up.

If you set up the DDM files to operate over TCP you need to set
up Remote Database entries and you also need to be sure you've
got the user authentication entries set up.

Already clarified by Vern, that the DDM does not require anything about RDB to be configured\established. That is true irrespective of the choice of *SNA or *IP used to define the remote location. The *RDB is merely a method of redirection to the chosen addressing [if\when] defined already by the Relational DataBase directory entries, as shown in WRKRDBDIRE 5=Display or DSPRDBDIRE, which show the remote location as LU addressing or IP addressing.

If you use the DDM files via a SNADS connection then you have to
set up the SNADS stuff if it hasn't been done already and that is
not a trivial job. It's not unusual for lot of the SNADS
utilities to have fallen by the wayside over the years in favour
of TELNET and FTP etc so the underlying SNADS stuff that we tend
to take for granted may not be as usable as expected.

Of course if they have an existing SNADS infrastructure then you
are 100% right.

To be clear, no SNA/DS has to be configured\established. It is only the communications underlying the SNA portion that needs to be established; be it over IP or APPC [or ANYNET?]. The DS refers to the "Distribution Services" function built over SNA. At least part of the DS would have to be established for SBMNETJOB & SBMNETMSG via the DDM file, but not for direct access to the [database] data for RLA [Row Level Access file I\O] or OPNQRYF.

In terms of the original question I think I'd want to know how
much data was involved and whether it was practical for the other
machines to extract the required data and transmit it as an
alternative to going out and collecting it.

I think that is something very important that the OP seems to have not responded to. Consider that for all data PULL scenarios there is also the possibility that data PUSH may be an option to consider; implemented possibly by _notification_ [but then, perhaps, why not just pull?] or as a _subscription_ which could be activated by local [to each node] _events_ or possibly even on a _schedule_.

Regards, Chuck