Communication failures

[Exit16W]

Two types of failures:

First:  arsmaint -v -I ARSDBASE -r results in:
ARS1106E Connection cannot be established for the >ARSDBASE< server

arsdb commands successfully loaded the tables using the same id. 
Is there a way to generate a log file?  Adding -1 <<log file name >> did not work like it does for arsdb.
How can you test communication?


Second:
I installed the On Demand Windoze 32 bit Client; same version client as the server on zOS.
Attempting to connect to the ARSSOCKD server.
 Server set to the Instance Name; Host and IP Port set accordingly; userid and password - tested serveral IDs.
 The port opened by ARSSOCKD is active in TCPIP.
 I ran a TCPIP component trace - the data is not readable therefore, can't read what's coming back form the mainframe to the client.
 Is there any test for the client connectivity?
 Are the userid & password used for loggin in ESM (ACF2) userids or are they stored in DB2?
 

[Exit16W]

#2 is now working - after defining users via the admin client.  Good thing some post here from years ago mentioned about the ADMIN id.  The use of this ID to get the ball rolling wasn't in the RedBook.

#1
ARS1106E Connection cannot be established   - would be nice if there was a trace function

[jeffs42885]

Again, not familiar with Z/OS but-

Turn on ARSSOCKD trace. I had to do this with a PMR

[Exit16W]

Thanks for the tip.  Will turn that trace on and see if I get anything via the arsxml command.

One other update:
Late last night, I compiled, binded and executed the ODBC IVPs with smashing success - I saw this as a step to take in a previous thread.
arsdb -trs -i Instance_Name, arsdb -u -I Instance_Name, arssyscr -l, arssyscr -a, arssyscr -m all worked.
How can I verify that all tabespaces were created?
Can ars.cfg values influence whether or not a successful conneciton will be made for the arsxml commands to load the IVPs?

[Exit16W]

ODBC tracing shows that the arsxml command does not use odbc.
I consistently get trace data from arsdb commands.
I opened a PMR.

FYI:
Regarding tracing, this is how I turned it on by editing the ODBC client file:
cat /etc/ars/cli.ini
[COMMON]
APPLTRACE=1
APPLTRACEFILENAME=/tmp/ars/tracefile.trc
DIAGTRACE
MVSDEFAULTSSID=DSN
[DSN]
PLANNAME=DSNACLI

I didn't have much success with capturing trace data using modules DSNAOTRC, DSNAOTRX (copied from SDSNLOAD and SDSNLOD2 to USS).  Formatting the trace records in the dump returned 0 records.  If anyone knows how to capture data using these utilities, I'd appreciate it.

[Exit16W]

Resolved:
arsxml, arsload use tcpip.
-h was was to the quad four IP address. 
there must be a  problem with the resolver since the DNS name can't be used.
traces for arsload using -1 and -2 ALL=15 showed the tcpip socket never getting created.
initially I used a port of my choosing.  After seening the trace, arsload was attempting to use default port 1445.
setting ars.ini to the default port, bouncing the server and using -h a.b.c.d got arsload and arsxml to successfully build the IP connection and run.
I haven't tested yet, but setting port parms in arsload.cfg and ars.ini might be one way of get the issue encountered, but I'm leaving the server at this point on the default port.

[Ed_Arnold]

Exit - what does your ars.ini look like?

For comparison, here's part of one of my ars.ini files:

?@SRV@_ARCH900?                       
HOST=mvs222                           
PROTOCOL=2                             
PORT=1448                             
SRVR_INSTANCE=ARS900DB                 
SRVR_INSTANCE_OWNER=ARSSERV3           
SRVR_OD_CFG=/etc/ars/V900/ars900.cfg   
SRVR_SM_CFG=/etc/ars/V900/ars900.cache
SRVR_FLAGS_SECURITY_EXIT=1             
SRVR_FLAGS_FORCE_SECURITY=0           
SRVR_FLAGS_FOLDER_APPLGRP_EXIT=0       
                                       
?@SRV@_ARCH850?                       
HOST=mvs222                           
PROTOCOL=2                             
PORT=1447                             
SRVR_INSTANCE=ARS850DB                 
SRVR_INSTANCE_OWNER=ARSSERV2           
SRVR_OD_CFG=/etc/ars/V850/ars850.cfg   
SRVR_SM_CFG=/etc/ars/V850/ars850.cache
SRVR_FLAGS_SECURITY_EXIT=1             
SRVR_FLAGS_FORCE_SECURITY=0           
SRVR_FLAGS_FOLDER_APPLGRP_EXIT=0     

Then when I run my jobs the -h parm is -h ARCH900 or -h ARCH850
Ed

[Exit16W]

[@SRV@_ARSDBASE]
HOST=MVSTECH
PROTOCOL=2
PORT=1445
DIRECTORY=/ars
SRVR_INSTANCE=ARSDBASE
SRVR_INSTANCE_OWNER=ARSADMIN
SRVR_OD_CFG=/usr/lpp/ars/V9R0M0/config/ars.cfg
SRVR_SM_CFG=/usr/lpp/ars/V9R0M0/config/ars.cache
SRVR_FLAGS_SECURITY_EXIT=0
SRVR_FLAGS_FOLDER_APPLGRP_EXIT=0
SRVR_FLAGS_DOCUMENT_EXIT=0
SRVR_FLAGS_SQL_QUERY_EXIT=0
SRVR_FLAGS_FORCE_SECURITY=0

In the trace I could see issues with the tcpip resolver getting the resolution of mvstech.  I'm not going to be able to fix that anythime soon.
The quick fix that worked was use
-h
ip.quad.four.address

After making this change, a trace showed the IP socket created using the quad address.


FYI:  You can eliminate the ?@ and ? characters by changing 3270 emulation translation language to 1047 (Latin).  Then you'll get brackets (like me)

[Ed_Arnold]

> DIRECTORY=/ars

I think that parm is obsolete...I checked and the last time I used it was in a V7 test system.

Do you know why you have it?   

Ed

[Exit16W]

No intelligent answer to the question -
  so I removed it.
For sure, it wasn't in the RedBook example.

[Ed_Arnold]

The quick fix that worked was use
-h
ip.quad.four.address

After making this change, a trace showed the IP socket created using the quad address.

FYI - I believe that will only work if you're using the default port, but obviously you're good for now.

Ed