Hi,
maybe someone else also went into this one, so I'm looking for some help here.

I'm working with RDz 8.0.2, Windows 7, 64 Bit. After trying a lot of things I've found the update for RDz and tried out with the new version (8.0.2, no luck).
I've installed RDz 8.0.1 in the RDz UT (running on Linux SuSe 11.3, 64 bit) machine. Everything works fine, except the connection with JMON.

When I start RSED with IVP=IVP, the connection test works perfect:

---

JES Job Monitor test...

---

executed on ADCD -- Tue May 24 10:45:52 EDT 2011
executed by uid=8(STCRSE) gid=1(OMVSGRP)
using /etc/rdz/rsed.envvars

current address space size limit is 1647288320 (1571.0 MB)
maximum address space size limit is 2147483647 (2048.0 MB)

testing JES Job Monitor on port 6715...
hostName=ADCD
hostAddr=10.1.1.2
Waiting for JES Job Monitor response...
ACKNOWLEDGE01v03
Success

When I test the connection with the shell script, everything is fine:

1. fekfivpj

Enter the path to the customized rsed.envvars:
/etc/rdz

executed on ADCD -- Tue May 24 09:48:37 CDT 2011
executed by uid=0(START2) gid=0(SYS1)
using /etc/rdz/rsed.envvars

current address space size limit is 2147483647 (2048.0 MB)
maximum address space size limit is 2147483647 (2048.0 MB)

testing JES Job Monitor on port 6715...
hostName=ADCD
hostAddr=10.1.1.2
Waiting for JES Job Monitor response...
ACKNOWLEDGE01v03à
Success

1. fekfivpj

If a test the connection from the windows machine using telnet, the tcp packets come to the process:

1. netstat -a|grep JMON

JMON 00000050 0.0.0.0..6715 0.0.0.0..0 Listen
JMON 0000007B 10.1.1.2..6715 192.168.178.25..50152 Establsh
#

But when I connect using RDz, I see the zOS Unix Files, the MVS Files, I can start TSO commands but the JES doesn't work. after a while, I get the following error message:
CRRZI9003E Unable to connect to the JES Job Monitor on port ? of host 192.168.178.28.
Message from host: java.net.ConnectException: EDC8127I Connection timed out. (errno2=0x76630291)

Any hint will be very appreciated!

Thank you in advance,

Rodney Krick

Have you ensured that the JMON port is open across your firewall? Have you issued the correct RACF (or equiv.) commands to permit you to look at spool output from RDz?

RDz_John

John,

thank you for your quick answer.
Yes, the port is open, I can connect using telnet. To be sure, I also installed RDz in the Linux box and connected directly to 10.1.1.2 (over the tunnel tap0). The same behavior: everything but JMON connection works fine.
About the RACF: the Job run correctly, I didn't see any error messages in the output. Is there a difference regarding RACF when I connect using RDz and when I start RSED with IVP=IVP? Do you now any further logs I can analyse to narrow the search for the problem?
Thank you in advance,

Rodney

Here some aditional pieces of information. I started wireshark on my linux box and on my windows box. I can see the packages going from Windows over Linux to z/OS. I can see how the TCPIP stacks communicate with each other and exchange the packages:
windows: source 192.168.178.25 destination 192.168.178.28
Linux: source 192.168.178.25 destination 10.1.1.2

So, it doesn't seem to be a network problem. When I first start the connection, I get the following message on SYSLOG:
11.08.12 STC00033 +FEK513W Lock daemon, registration failed, ASID=0031, TCB=008C8A48, USER=IBMUSER

After that (I don't know if they relate to each other), I see a "bad tcp" message in wireshark.

Can someone give a hint, where I could look for the error?

Thank you in advance!

Rodney

I believe I found the root of the problem, I am still looking for one solution. I've read all the traces from wireshark again and found a strange IP adress. This IP adress (192.168.252.167) was in the old TCPPARMS. By running makesite I probably forgot to set the correct HLQ, and I believe because of this some packages got the wrong IP adress and were lost.
So, I checked the file again, rerun makesite and re-ipl the whole machine. I'm still getting the same problem, the wrong address is still beeing used. I would appreciate if someone can point me here to a "quick" solution. How can I get rid of that? Did I forget to run something?
I'll read the manuals and come back here between the chapters...

Thank you for your help!

I believe the registration message means that the DNS name that the machine identifies itself as conflicts with what DNS lookup finds. Try assigning a new name to the system and/or place the DNS name of the system in a local hosts file (via a resolver) and force DNS to search the LOCAL file before using the DNS server. See the config guide http://publibfp.dhe.ibm.com/epubs/pdf/c1472811.pdf section on TCPIP.

Thanks, d. I started my configuration over again, there were some strange things going on and I could not find the reason why. Now I'll install the SMP/E and try it again. I hope it will work now :-)

Rodney,

I have installed RDz and seeing the same issue. RSE, USS are connected, but not JMON. What was the issue that you uncovered?

A couple of things.

Sometimes the DNS gets confused and won't allow the Lock Daemon to register, after which things go south. Check to make sure your TCPIP DATA file has a valid value set for NSINTERADDR. This can be a DNS hostname or IP address, but it must be reachable on your network. You can comment out NSINTERADDR if you don't have access to a DNS. You can also use the LOOKUP parameter to set the order that the resolver uses to resolve DNS requests. LOCAL uses the local host file, DNS uses a DNS server.

Once you get this message about the Lock Daemon cleared up, the job monitor should work, however, the Job Monitor uses RACF to secure access to JES resources. Check out the topic on Defining JES Command Security on p. 119 of the Host Customization Guide - SC23-7658-05 and issue the RACF commands appropriate for your system.

RDzJohn

Thanks for the response John.

We went through the TCPIP.DATA member, and it seems right. And I am pretty sure we followed the RACF setup for JES according to the steps in the RDzUT Guide, as well as the RDz Host Config guide.

One thing we noticed missing was the message below although we are sure the syntax matches the documentation exactly.
EZZ0401I SYNTAX ERROR IN FILE: 'USER.TCPPARMS(TCPDATA)' ON LINE: 53 AT:'TCPIPJOBNAME'
EZZ0324I UNRECOGNIZED STATEMENT TCPIPJOBNAME FOUND ON LINE 53
EZZ0324I UNRECOGNIZED STATEMENT NSINTERADDR FOUND ON LINE 143

Also changed settings to get DNS settings from a local hosts file.

So far still no luck.

I'm working with Dhimant, and we checked these. We have a local host table (/etc/ipnodes), and we can ping the DNS servers. We find this in the rsecomm.log file for the /var/rdz/logs/IBMUSER folder

Thu Jul 21 22:38:16 EDT 2011 ERROR FFSServerImpl: java.net.SocketTimeoutException: connect timed out java.net.SocketTimeoutException: connect timed out at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:352) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:214) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:201) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378) at java.net.Socket.connect(Socket.java:537) at com.ibm.ftt.rse.mvs.server.filesystem.impl.FFSServerImpl.sendCommandToLockDaemon(FFSServerImpl.java:408) at com.ibm.ftt.rse.mvs.server.filesystem.impl.FFSServerImpl.registerLockDaemon(FFSServerImpl.java:320) at com.ibm.ftt.rse.mvs.server.filesystem.impl.FFSServerImpl.connect(FFSServerImpl.java:298) at com.ibm.ftt.rse.mvs.server.miners.MVSFileSystemMiner.connect(MVSFileSystemMiner.java:667) at com.ibm.ftt.rse.mvs.server.miners.MVSFileSystemMiner.handleConnect(MVSFileSystemMiner.java:650) at com.ibm.ftt.rse.mvs.server.miners.MVSFileSystemMiner.internalHandleCommand(MVSFileSystemMiner.java:451) at com.ibm.ftt.rse.mvs.server.miners.MVSFileSystemMiner.handleCommand(MVSFileSystemMiner.java:360) at org.eclipse.dstore.core.miners.Miner.command(Miner.java:303) at org.eclipse.dstore.core.miners.Miner.handle(Miner.java:221) at org.eclipse.dstore.core.model.Handler.run(Handler.java:135) --------------------------------------------------------------- Thu Jul 21 22:42:22 EDT 2011 ERROR JMConnection: java.net.ConnectException: EDC8127I Connection timed out. (errno2=0x76630291) java.net.ConnectException: EDC8127I Connection timed out. (errno2=0x76630291) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:352) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:214) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:201) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378) at java.net.Socket.connect(Socket.java:537) at java.net.Socket.connect(Socket.java:487) at java.net.Socket.<init>(Socket.java:384) at java.net.Socket.<init>(Socket.java:198) at com.ibm.etools.zos.jes.miners.JMConnection.connect(JMConnection.java:160) at com.ibm.etools.zos.jes.miners.JMConnectionProcessor.connect(JMConnectionProcessor.java:127) at com.ibm.etools.zos.jes.miners.JESMiner.handleConnect(JESMiner.java:197) at com.ibm.etools.zos.jes.miners.JESMiner.internalHandleCommand(JESMiner.java:115) at com.ibm.etools.zos.jes.miners.JESMiner.handleCommand(JESMiner.java:90) at org.eclipse.dstore.core.miners.Miner.command(Miner.java:303) at org.eclipse.dstore.core.miners.Miner.handle(Miner.java:221) at org.eclipse.dstore.core.model.Handler.run(Handler.java:135)

We can ping the host name of the zos. In the /etc/ipnodes file, we set it to the loopback address. Is there a document or diagram that shows how the communication flows, and over what ports?

We finally have ours working. The solution appears to be that we needed solid DNS resolution. After adding the /etc/ipnodes and changing adding a static entry for the IP of the zOS. The key here is that you need to restart RSED, LOCKD, and JMON after making any such changes. We did not see any difference until we did that. But as soon as we made the host name changes, we had the TCPIP verification (fekfivpt) working, which was giving us fits earlier. Only after restarting the tasks did they work.

You definitely need good DNS name resolution - see my post above. Consider using the RESOLVER as described on p.17 of the RDz-UT Config guide - SC14-7281-01. Because z/OS and USS use different methods to resolve DNS requests, using the RESOLVER greatly simplifies the process by consolidating all DNS request configuration in one place. I always configure my systems with a RESOLVER and I highly recommend you do the same.

RDzJohn

 

Even though this is an old thread, it helped to find the cause of a connection failure with message FEK513W Lock daemon, registration failed after we applied some changes to our local DNS.

In the config guide http://publibfp.dhe.ibm.com/epubs/pdf/c1472811.pdf section on TCPIP, I found the following note which I had not noticed before:

If you choose a HOSTNAME or DOMAINORIGIN arbitrarily, be sure that the DOMAINORIGIN is not a real domain name or that the combination of the HOSTNAME and DOMAINORIGIN does not constitute an existing DNS name. Use the Linux ping or nslookup commands to ensure that your choice of names is not found by your DNS server. Identifying your computer as another computer, or as a member of an existing but incorrect domain, may cause problems that are unusual and difficult to diagnose, like timeouts, pauses, and connection failures in many areas, including 3270 connections and Developer for System z. Some systems, including components of Developer for System z, require that z/OS can locate itself by name.

I was not aware of that, and I assume that if no IP address is returned from the DNS, the local IP is used as a fallback. We changed HOSTNAME to a non-existing name, the it worked. Probably the hostname must not return the IP address used from outside the Linux which RDTE runs on. An alternative could probably be to use the SEARCH option to obtain the local IP address before asking the DNS.

Maybe this can help someone else, too.