Re: New application using remote databases from RPG program

[CRPence <CRPbottle@xxxxxxxxx>]

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