home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!munnari.oz.au!yoyo.aarnet.edu.au!arnie.systems.sa.gov.au!roads.sa.gov.au!walsh
- From: walsh@roads.sa.gov.au
- Newsgroups: comp.databases
- Subject: Re: Paradox SQL-link with VMS???
- Message-ID: <1992Jul29.155856.51@roads.sa.gov.au>
- Date: 29 Jul 92 15:58:56 GMT
- References: <1992Jul24.134420.3159@otago.ac.nz>
- Organization: DEPARTMENT of ROAD TRANSPORT
- Lines: 138
-
- In article <1992Jul24.134420.3159@otago.ac.nz>, unitelmc@otago.ac.nz writes:
- > Hi there
- >
- > We are looking to use Paradox SQL-link to connect our PC database system to our
- > VAX system to access Rdb/VMS data. What I have not been able to find out (even
- > from our local Borland agent) is what you need in your PC to be able to talk
- > over DECNET, and what happens at the VAX end:
- > * Does the SQL-link run SQL on the VAX for you?
- > * Do you have to have some other product as well ?
- >
- > If anyone has experience using Paradox SQL-link in a VMS envirnment I would be
- > very interested in hearing how it really works! Please E-mail to me direct.
- >
-
- Hi back.
- Well, we had the same problem with BORLAND and it took around 4 weeks to get it
- operating sucessfully due to the PROXY problems (using PARADOX V3.5 to RDB/VMS
- V4.0). It seems to go OK once the right things are done, although we have
- decided to wait for the windows version to appear b4 we so anything with it. A
- quick summary of what I think is needed/happens follows (it may not necessarily
- be true):
-
- 1. You need RDB/VMS installed and started
- 2. You need SQL installed and started
- - the install could be part of the RDB install, depending on your version
- 3. You will need to stop SQL Services and edit your parameter files (once only)
- (a) SYS$COMMON:[SYS$STARTUP]SQLSRV$CONFIG.DAT and
- (b) SYS$COMMON:[SYS$STARTUP]SQLSRV$PROXY.DAT
- so that they have correct parameters. Particularly (b). A copy of our files
- is attached below. This was our major barrier to our successful running and
- you will have to tinker with them a bit before they'll go for you since SQL
- LINK only wants to know about old RDB V3.1 type connects. beware.
- 4. Start up SQL services again for new params to take effect. Starting this
- defines object 81 in the volatile decnet database so that an incoming decnet
- request to this object will stoke up the correct procedure. That is
- essentially what paradox SQL link does - put out a decnet request for this
- object to be stoked up so that it can `talk sql' back and forward to the
- sql services program. This is real hairy stuff as it seems to define more
- created server processes as `pseudo-batch-jobs'. I don't know why. You'll
- sometimes see jobs running on a queue which i'm sure doesn't exist. Anyway,
- it works.
- 5. Do all sorts of nasty things to the PC to ensure that there are enough
- NCP MAX LINKS for the decnet links (we use 20), etc.
- 6. Do all sorts of nasy things with SQL LINK to ensure PARADOX will use it.
-
- Best of luck to you, Dave.
-
-
- SYS$COMMON:[SYS$STARTUP]SQLSRV$CONFIG.DAT
-
- -- ----------------------------------------------------------
- -- ----------------------------------------------------------
- -- S Q L / S E R V I C E S
- -- C O N F I G U R A T I O N F I L E
- -- ----------------------------------------------------------
- -- INTRODUCTION
- -- ----------------------------------------------------------
- -- This SQLSRV$CONFIG.DAT file contains parameters used at
- -- system startup time to configure execution server processes
- -- in the process pool. Once Rdb/VMS is installed, the processes
- -- in the pool are available to execute client API requests.
- -- After installing Rdb/VMS, you can alter this configuration
- -- file to suit application requirements at your site.
- -- ----------------------------------------------------------
- -- CONTENTS OF THIS FILE
- -- ----------------------------------------------------------
- -- This configuration file contains two sets of parameters:
- -- o The first set defines a GENERIC class of
- -- execution server processes.
- -- o The second set defines a DATABASE class of
- -- execution server process.
- -- The second database class definition is commented out. The
- -- installation procedure cannot create database class servers
- -- at system startup because SQL/Services does not know what
- -- databases your applications require. The database class
- -- definition is provided as an example.
- -- ----------------------------------------------------------
- -- "GENERIC" CLASS DEFINITION
- -- ----------------------------------------------------------
- -- The execution servers in the generic server class are
- -- general-purpose server processes that the communication server
- -- assigns by default to execute API requests. Execution servers
- -- in this class are not pre-attached to a database as they are
- -- with the database class of execution servers.
- --
- -- You can define only one generic server class in a configuration
- -- file; however, you can define multiple execution servers in the
- -- generic class process pool. A generic class definition follows:
- --
- -- *** The MAX parameter below was changed from 2 to 100 by DCW on 7/8/91
- -- *** The IDLE parameter below was changed from 3 to 1 by DCW on 2/3/92
- --
- -- ----------------------------------------------------------
- TYPE "GENERIC"
- MIN 0
- MAX 100
- IDLE 1
- -- ----------------------------------------------------------
- -- "DATABASE" CLASS DEFINITION
- -- ----------------------------------------------------------
- -- The database class of execution server processes differs from
- -- the generic class of execution servers in several ways. First,
- -- the database servers are pre-attached to a database. Second,
- -- the attach is made through a single user name as Rdb/VMS
- -- requires when binds to databases occur.
- --
- -- You can define multiple database classes in the configuration
- -- file. Each database server class can contain multiple execution
- -- server processes. A database class definition follows:
- -- ----------------------------------------------------------
- -- TYPE "PERSONNEL"
- -- USER "BARNEY"
- -- EXECUTE "DECLARE SCHEMA FILENAME SQLDB$PERSONNEL"
- -- IDENT "SUPERVISOR"
- -- MIN 1
- -- MAX 3
- -- IDLE 1800
- -- ----------------------------------------------------------
- -- ----------------------------------------------------------
-
- SYS$COMMON:[SYS$STARTUP]SQLSRV$PROXY.DAT
-
- -- proxy file
- --
- -- add/proxy nodename::username localname
- -- '*' valid for the nodename and username
- add/proxy DEVPC7::walsh walsh
- add/proxy DEVPC7::* walsh
- add/proxy *::walsh walsh
-
- +---------------------------------------------------------+
- | Dave Walsh, Dept. of Road Transport, South Australia. |
- +---------------------------------------------------------+
- | Email: walsh@sysdev.roads.sa.gov.au |
- | Post : Dept. of Road Transport, Information Technology, |
- | PO Box 1, Walkerville, South Australia, 5081. |
- | Phone: +61 8 343 2559 Fax: +61 8 343 2768 |
- +---------------------------------------------------------+
-