Thank you for the valid criticism. Of course, I should have thought to include more details of the error message. I've included them below, but they don't seem particularly helpful.
From what I've read, the CPE3425 error message is pretty generic. I know that the tunnel will accept network connections, because I've done a TELNET to the same port and I can see the connection on the remote system on the NETSTAT *CNN screen. There is a connection on port 22 where it enters the remote system's end of the tunnel, and then there is a connection from 127.0.0.1 to port 446 where it connects to the DDM server coming out of the tunnel. The State field on the NETSTAT screen says "Established". Unfortunately, the iSeries TELNET client just hangs and doesn't show any headers from the DDM server being returned through the tunnel.
I also tried to make a connection using ssh in the PASE environment to see if the remote DDM server might return any headers or error messages but it just hangs: ssh -T aistad1@localhost -p 21001. I can see the connection via NETSTAT on the local server, but the remote server doesn't show any connection when I try ssh.
If I don't get any suggestions in the next few hours, I'll probably use RPG to call the TCP/IP APIs to see what kind of raw responses I'm getting through the tunnel.
Here's the job log with SBMRMTCMD attempt:
200 - CHGJOB LOG(4 0 *SECLVL)
300 - DLTF FILE(QTEMP/TEMPDDMF)
Object TEMPDDMF in QTEMP type *FILE not found.
500 - CRTDDMF FILE(QTEMP/TEMPDDMF) RMTFILE(LIBRARY/FILE)
RMTLOCNAME('127.0.0.1' *IP) PORT(21001)
Ownership of object TEMPDDMF in QTEMP type *FILE changed.
File TEMPDDMF created in library QTEMP.
700 - SBMRMTCMD CMD(WRKSPLF) DDMFILE(QTEMP/TEMPDDMF)
A remote host refused an attempted connect operation.
DDM TCP/IP communications error occurred on connect() to Application
Server.
Cannot establish DDM connection with remote system.
Function check. CPF9162 unmonitored by TADTUNTEST at statement 0000000700,
instruction X'0000'.
CPF9162 received by procedure TADTUNTEST. (C D I R)
When I hit help on the first-error message, I get this:
Message ID . . . . . . : CPE3425 Severity . . . . . . . : 10
Message type . . . . . : Diagnostic
Date sent . . . . . . : 07/04/11 Time sent . . . . . . : 14:31:59
Message . . . . : A remote host refused an attempted connect operation.
When I hit 'help' on the second-error message, I get this:
Message ID . . . . . . : CPD3E34 Severity . . . . . . . : 40
Message type . . . . . : Diagnostic
Date sent . . . . . . : 07/04/11 Time sent . . . . . . : 14:31:59
Message . . . . : DDM TCP/IP communications error occurred on connect() to
Application Server.
Cause . . . . . : Error code (errno) 3425 was received while processing the
connect() to Application Server function for DRDA/DDM TCP/IP communications.
Recovery . . . : See any previously listed message(s) to determine the
cause of the error; if necessary, correct the error and issue the request
again.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, July 04, 2011 11:50 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Getting DDM to work through an SSH tunnel
On 03-Jul-2011 14:24 , Douthat, Trent A wrote:
<<SNIP>>
When I actually attempt to use the DDM file, I get an error like so:
SBMRMTCMD CMD(WRKSPLF) DDMFILE(QTEMP/TEMPDDMF) Cannot establish DDM
connection with remote system.
<<SNIP>>
Ignoring SSH, concentrating only on the above snippet showing a failing request to [further] describe the problem, I offer FWiW:
The first level message text of an error following a request message is not a generally worthwhile and appropriate means to [further] describe a problem. Presumably the quoted message text is from the message identifier CPF9162 for which the second level text suggests to "See previously listed message &1". Both the message identifier and the replacement text for &1 probably would have been included if the text had been copied either from a spooled joblog taken with filtering level
LOG(4 0 *SECLVL) or F6=Print [after F1=Help]; though with either, the previous logged message(s) still could just as easily have been omitted.
Presenting the full second-level details from the spooled joblog including the request message up to and including the final [exception] message preceding the next request, is generally the more worthwhile text to provide to describe a failure. From such a spooled joblog with second-level text included, the message identifiers, the context of the messages, and the message replacement data would all be available for further review.
Of course having suggested that, there was no attempt to imply that just having that [missing] data become available would surely provide anyone with the necessary details to enable them to assist [beyond the other details already provided, though snipped in the quoted text]. But surely the more complete error details would be better than just some first-level message text copied and pasted from an interactive joblog [which apparently had not even expanded the message view with the use of F10=Include detailed messages].
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
