From: Vilim Zaksek on
Finally i have solved the problem.
The tnsnames.ora was located on a network drive (which is the standard
location in this company) and that seemed to be the reason why the remote
session could not find it.
I copied the file to my local HD and changed the registry entry to the new
location. Now it works.

Thanks for the ideas and approaches!

Vilim


On Fri, 30 Oct 2009 04:53:46 -0400, Vilim Zaksek
<vilim.zaksek(a)STERIA-MUMMERT.DE> wrote:

>Hi,
>
>I have already checked the SAS invocation, it's excactly the same with the
>same config and auotoexec.
>I have also compared the options of the interactive windows session and the
>remote windows session. They are exactly the same, exept for the DMR option,
>which indicates the batch session.
>
>But I have found out something else: I thought that the reomte session reads
>the tnsnames.ora like the interactive session does. The error message
>indicates that the information for the connection to oracle is there and
>that there is some problem communicating with the listener. But that is not
>the case. I have used the fully qualified name (the server name:
>xxxxx.yyy.zzz.com) to name the connection in the tnsnames.ora. The remote
>session was never able to read the tnsnames.ora, but tried to connect to the
>server where the oracle db is located, because the server name was in the
>libname statement (libname oralib oracle path='xxxxx.yyy.zzz.com'...).
>I found that out by looking into the sqlnet.log. There I have seen that the
>standard port for oracle listeners is trying to be accessed, but I have a
>different port in the tnsnames.ora. To confirm this, I have renamed the
>connection in the tnsnames.ora to "myora" and have tried that in the libname
>statement (libname oralib oracle path='myora'...). Now I have the following
>error message: "ORACLE connection error: ORA-12154: TNS:could not resolve
>service name."
>Now I have to find a way to let my remote session know where the
>tnsnames.ora is located, or to include all neccesary information in the
>libname statement.
>
>The location of the tnsnames.ora is already known in my windows registry as
>TNS_ADM. I have also put that parameter ino my config, but without any
>positive effect.
>
>Any ideas?
>
>
>On Thu, 29 Oct 2009 10:31:49 -0400, Michael Raithel
><michaelraithel(a)WESTAT.COM> wrote:
>
>>Dear SAS-L-ers,
>>
>>Vilim Zaksek posted the following interesting problem:
>>
>>>
>>> i have an oracle db running on a unix system and i can access it easyly
>>> from
>>> my local SAS windows session, for example with this libname statement:
>>>
>>> libname oralib oracle path=mypath
>>> user=&user password=&pwd
>>> schema=&schema ;
>>>
>>> I can also establish a remote session from z/OS on the same Windows PC
>>> with
>>> the same options (exept the DMR option). I have a spawner running on
>>> that
>>> Windows PC, and the connection works fine.
>>>
>>> The problem is: I need to combine these two things, and it doesn't seem
>>> to
>>> work. The libname statement for the oracle db, which works fine when it
>>> is
>>> executed in the interactive PC session, will not work if the session is
>>> invoked remotely from z/OS. The error message is: "ERROR: ORACLE
>>> connection
>>> error: ORA-12541: TNS:no listener.". The listener is running, because i
>>> can
>>> connect to oracle immediately after the error occurs from an
>>> interactive
>>> windows session.
>>> I have tried to allocate the oralib with a rsubmit libname statement,
>>> with a
>>> remote libname statement, with an autocall macro that was stored on the
>>> PC
>>> and invoked inside a rsubmit and even with the libname statement in the
>>> autoexec file that is executed when the remote session starts. All with
>>> the
>>> same error message.
>>> There must be a significant difference between using the oracle libname
>>> engine in an interactive and in a remote session, and I cand find it.
>>>
>>> Every hint is appreciated!
>>>
>>> PS: I have no SAS on the unix box, and no SAS access to oracle on z/OS.
>>> That
>>> is the reason why I have to take this approach.
>>>
>>Vilim, very intriguing, odd, and, of course, very aggravating for you!
>>
>>Here is my idea: Perhaps there is a difference between the SAS you run
>when invoking interactive SAS on your desktop and the SAS you are invoking
>through the spawner. So, if I were in your sandals, I would:
>>
>>1. Check my SAS shortcut on my desktop to see which config file, autoexec
>file, and SAS exec it is using.
>>
>>2. Check the SAS config, autoexec files, and SAS exec that are used by the
>spawner.
>>
>>3. Make note of any differences, and change the files in #2, accordingly.
>>
>>Try, again, to logon to z/OS, remote to your PC, and then access Oracle.
>>
>>So, will this work? Only time and your efforts will tell! Give it a shot
>and let the list know if there is any merit in this proposed solution.
>>
>>Vilim, best of luck in all of your SAS endeavors!
>>
>>
>>I hope that this suggestion proves helpful now, and in the future!
>>
>>Of course, all of these opinions and insights are my own, and do not
>reflect those of my organization or my associates. All SAS code and/or
>methodologies specified in this posting are for illustrative purposes only
>and no warranty is stated or implied as to their accuracy or applicability.
>People deciding to use information in this posting do so at their own risk.
>>
>>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>Michael A. Raithel
>>"The man who wrote the book on performance"
>>E-mail: MichaelRaithel(a)westat.com
>>
>>Author: Tuning SAS Applications in the MVS Environment
>>
>>Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second
>Edition
>>http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172
>>
>>Author: The Complete Guide to SAS Indexes
>>http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409
>>
>>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>I'm gonna keep my head on straight up and steady on,
>>I just hope it's not too late... - Steady On, by Shawn Colvin
>>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++