I'm glad to hear that you got it working, Gary.
For those of you playing along at home, a little exposition on DH+ "Remote Link Addressing".
When a message needs to transit between separate DH+ networks, the mechanism used to differentiate between the DH+ networks is the "Link ID".
The nomenclature is a little obscure; nimodo pointed out that it's labeled the "Passthru Link ID" in RSLogix 500 Channel 1 Configuration. "Link" is just a word left over from the distant past when DH+ was called "Peer Communication Link" (PCL). "Subnet", "Segment", and "Network Number" all have different connotations, so "Link ID" is the term we'll use.
The most popular way to connect multiple DH+ networks together today is a little gem called the 1756-DHRIO. It is a two-port module that fits in a ControlLogix chassis and one of it's primary duties is to bridge DH+ messages.
If you have just one 1756-DHRIO that is running both channels as DH+, this is a relatively simple task. In the "Routing Table" configuration for the 1756-DHRIO (configured using an applet within RSLinx) you configure a Link ID for each DH+ Channel on the module. The easiest settings are Link ID 2 for Channel A, and Link ID 3 for Channel B.
Now you have to go back to all of those DH+ nodes on each separate DH+ network (a.k.a. "link") and configure their Link ID to match the DHRIO channel to which they are attached.
A "Remote Message" from a controller on one network to a controller on the other network needs the Remote Link ID and the Remote Node Number. Once the message arrives as the DHRIO module, it routes it to the channel that matches the Remote Link ID in the message.
This is a simplified example; the DHRIO can do a lot more. For example, you can define a route that goes through a complex Rockwell CIP network path (over Ethernet, over ControlNet, through the woods to Grandmother's house, and to another DHRIO) and define a Link ID for that whole path. The DHRIO will encapsulate your Remote DH+ Message (which contains just a destination node and Link ID) and hustle it over that CIP path, with the MSG block in the originating controller being none the wiser.