Re: SQLNet vs Two-task link problems

In article <1995Oct5.120525.23759_at_hrbicf>,

   mmm_at_icf.hrb.com (MAX M. MAGLIARO) wrote:
>I am running Oracle 7.0.16 on a DEC Alpha under OpenVMS 6.1.
>
>I have SQLNet installed, and it works fine (meaning I can connect
>using SQLPlus, see my tables, etc).
>
>Now... here's the dilemma. I have a ProFORTRAN application, which
>I linked WITHOUT the two-task option (the "T" flag on the
>LNPROFOR command). When I run it on the server, it works fine. It
>connects to my database.

that was your mistake. i think you need the S option; it's the shared library image that contains the sqlnet connect string detector.

>
>Now... I want to be able to run that same application on remote
>client machines. So... I linked WITH the two-task option. Lo and
>behold, it will not connect to Oracle, even when I run it
>on the server machine. The oracle username/password I use is
>the same in both cases (XDI/XDI_at_SCOTTY, if you want to know).
>SCOTTY is defined in the TNSNAMES.ORA file, etc. And I can
>connect using SQLPlus using this exact same username and password.

because you are probably running the normal sharable image server, not a two-task server.

>
>By the way, I have linked this exact same application at other sites
>running Oracle 7.0.16 and it works fine, which leads me to conclude
>that something about Oracle at my site is simply not configured right.

well, the default link mode can be set during oracle install on VMS. your site prep during the latest install may have goofed up the default connect mode. the default should be S. or the oracle engine may have been linked without the sqlnet v2 libraries.

>
>I get an ORA-06400, which is a SQLNet error, when my application
>tries to CONNECT.
>
>Question 1: What on Earth has the two-task link option got to do with
> SQLNet? I thought the two-task option just linked without
> the sharable image (i.e., it pulls the library references
> right into the final executable .EXE file so that it
> is portable and can run without the sharable image being
> installed).

the old 2-task idea uses interprocess memory instead of the network to talk to a local server. you get hooked into sqlnet v1 if the connect string is not recognized. 2-task doesn't have the hook to v2.

>Question 2: I called Oracle support (why I bother, I will never know).
> They said that ORA-06400 is a SQLNet version 1 error.
> But I am not using version 1. I don't even have
> the version 1 drivers built on my machine. Is this really
> a version 1 error?

yes. most everything in the 6000 range is sqlnet v1.

>Question 3: Oracle support told me that 6400 means I have no default host
> string defined, but they couldn't tell what I should set it
 to.
> Why do I need one? I told it XDI/XDI_at_SCOTTY. Doesn't it
> just look up "SCOTTY" in my TNSNAMES.ORA file? It's defined
> in there, with the nodename, the protocol (DECNET), the
> SID, etc. I tried defining ORA_DFLT_HOSTSTR as "2:", but
> that didn't help.

because the mode you linked in doesn't recognize v2 connect strings.

>Question 4: While we are on the subject, what is the syntax and allowable
> values for ORA_DFLT_HOSTSTR? I have asked three (count 'em,
 3!)
> different technical support people at Oracle what these
> values mean and the only answer I have ever gotten is,
> "I dunno, but '2:' is what makes it work."

it is the same as a normal connect string which occurs after the "_at_" sign. so if the default connect string is "t:blah" then a signon of scott/tiger connects to blah via tcp/ip. if you have sqlnet v2 linked into the shared image. if not, and v1 is in the image, you will have error messages.

>Question 5: My LISTENER.ORA file specifies the file SRV2.COM as the
> command file to run for incoming connection requests.

that's nice, but it doesn't mean that the instance is communicating with it right now.

on vms you have to build the oracle engine with all the v2 sqlnet libraries, stipulate which connect type is the default, and preferably IMHO use shared libraries for your application links.

Dave Mausner, Sr. Consultant, Braun Technology Group, Chicago. Received on Sat Oct 07 1995 - 00:00:00 CET