From: walsh@roads.sa.gov.au
Newsgroups: comp.databases
Subject: Re: Paradox SQL-link with VMS???
Date: 29 Jul 92 15:58:56 GMT
Organization: DEPARTMENT of ROAD TRANSPORT

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 |
+---------------------------------------------------------+