RE: Getting DDM to work through an SSH tunnel -- MIDRANGE-L

The CHGJOB LOG(4 0 *SECLVL) command is right there at the top of the included job log. (I added LOGCLPGM(*YES) and ran it again, but it didn't change the job log.)

There are no other messages between the echo of the SBMRMTCMD command and the CPE3425 message. I checked the QSYSOPR message queue and it just shows this job's CPF9162 escape message. I also checked the QSYSOPR message queue for the system at the remote end of the SSH tunnel and there is nothing there.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKee
Sent: Monday, July 04, 2011 7:07 PM
To: Midrange Systems Technical Discussion
Subject: RE: Getting DDM to work through an SSH tunnel

was message level set, as in MSGLVL(4 0 *SECLVL) LOGCLPGM(*YES)

Thee has to be something before CPE3425, but the message level is keeping it out of the job log. Also look at QSYSOPR. Might be something there that was auto replied to.

John McKee

-----Original message-----
From: "Douthat, Trent A" trent.douthat@xxxxxxxxxxx

Date: Mon, 04 Jul 2011 18:55:59 -0500
To: Midrange Systems Technical Discussion midrange-l@xxxxxxxxxxxx
Subject: RE: Getting DDM to work through an SSH tunnel

The CPE3425 message is the very first message after the SBMRMTCMD.

Here are the message details from pressing F9 on the message help screen:
Message ID . . . . . . : CPE3425 Severity . . . . . . . : 10
Date sent . . . . . . : 07/04/11 Time sent . . . . . . : 14:31:59
Message type . . . . . : Diagnostic

From . . . . . . . . . : AISTAD1 CCSID . . . . . . . . : 65535

From program . . . . . . . . . : QRWXDLL

From library . . . . . . . . : QSYS
From module . . . . . . . . : QRWXDLL
From procedure . . . . . . . : SndErrnoMsg__FPc
From statement . . . . . . . : 13

To program . . . . . . . . . . : QRWXDLL
To library . . . . . . . . . : QSYS
To module . . . . . . . . . : QRWXDLL
To procedure . . . . . . . . : SndErrnoMsg__FPc
To statement . . . . . . . . : 13

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKee
Sent: Monday, July 04, 2011 5:57 PM
To: Midrange Systems Technical Discussion
Subject: RE: Getting DDM to work through an SSH tunnel

What was in the joblog before the CPE3425, and what was on the second level help for THAT message?

Might even be multiple messages listed that are involved. Thus, the reference to the job log in CPE3425.

John McKee

-----Original message-----
From: "Douthat, Trent A" trent.douthat@xxxxxxxxxxx
Date: Mon, 04 Jul 2011 14:51:08 -0500
To: Midrange Systems Technical Discussion midrange-l@xxxxxxxxxxxx
Subject: RE: Getting DDM to work through an SSH tunnel

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.

--
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.

--
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.

--
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.

--
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.