Re: DDM file between v7r3 and v5r4 -- MIDRANGE-L

Thanks Steve, good thinking!

It looks like the problem is that when the job on the v5r4 system tries to open the target of the DDM file, it gets confused because the target is the DDM file created by the SQL CREATE ALIAS, which refers to the local system:

Message . . . . :   Remote location *LOCAL for program device DDMDEVICE was
   not found.
Cause . . . . . :   One of the following occurred:
     -- The remote location was not defined.
     -- Not enough time was allowed to find the remote location.
     -- The combination of remote location *LOCAL, device *LOC, location *LOC,
   and remote network ID *LOC is not correct.
Recovery . . . :   Do one of the following and try the request again:
     --If the remote location was not defined, create the device description
   for the remote location or add the remote location to advanced peer-to-peer
   networking (APPN).
     -- If not enough time was allowed to find the remote location, increase
   the time specified in the WAITFILE parameter on the Change Intersystem
   Communications Function File (CHGICFF) command or the Override Intersystem
   Communications Functions File (OVRICFF) command to allow the system to wait
   longer to find the remote location.
     -- If the combination of remote location *LOCAL, device *LOC, location
   *LOC, and remote network ID *LOC is not correct, use the Work with
   Configuration Status (WRKCFGSTS) command to select the correct combination.

I'm not sure what to do about that. SQL seems to have no problem with it -- it manages to open the alias and return data.

On 12/24/2019 4:34 AM, Steve McKay wrote:

The CPI9200 message will tell you the job name/user/number of the QUSRWRK
job servicing this request on the target system - do you see any helpful
messages in that job?

Thanks,

Steve McKay
(205) 585-8424
samckay1@xxxxxxxxx

On Tue, Dec 24, 2019 at 5:29 AM Peter Dow <petercdow@xxxxxxxxx> wrote:

Yes, we're successfully using simpler DDM files (PF -> PF) in a
production application.

On 12/23/2019 2:34 PM, Steve McKay wrote:

Do the DDM attributes match between both systems?

Is the DDM server stated on both?

On Mon, Dec 23, 2019 at 5:09 PM Peter Dow <petercdow@xxxxxxxxx> wrote:

This involves two machines, one running v7r3, the other v5r4.

I was trying to determine if I can have an RPGLE program on v7r3 read a
SQL ALIAS table that points to a remote table.

On v5r4 there's a multi-member file of which I only want a particular
member. So on that machine, I created an alias:

CREATE ALIAS mylib/myAlias for mylib/myFile (myMbr)

On v7r3,

CREATE ALIAS mylib/myFile FOR rmtv5r4/mylib/myAlias

So far so good. On v7r3, a "SELECT * FROM mylib/myFile" returns the
records from myMbr on the remote v5r4 machine.

I wrote RPGLE program TESTALIAS on v7r3 which reads the first record
from myFile, displays the key fields, then ends. The first issue was it
wouldn't compile because it couldn't get the external field definitions
from myFile. So I copied the file definition from v5r4 to v7r3 as
myDefn and used that in the EXTDESC key field on the file spec. That
got it compiled.

Here's the fun part. When I ran it I got some errors:

CALL TESTALIAS
[CPI9160] Database connection started over TCP/IP.
[CPI9200] DDM object SYSCDEP1 in UTLIB uses remote object

UTLIB/SYSCDEM1.

[CPF9162] Cannot establish DDM connection with remote system.
Cause . . . . . : An error occurred during distributed data
management (DDM)
initialization while attempting to establish a connection at the
remote
location OCAL 0000.
Recovery . . . : See previously listed message CPF4364. Correct
the errors
and then try the request again. If message CPD3E34 is listed,
see the
message listed before it for meaning of error code.

The "Recovery" is interesting because there is no "previously listed
message CPF4364". However,
the "Cause" hints at the problem with "remote location OCAL 0000."

Has anyone seenanything like this?

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com