=============================================================================

    Notice:
    Copyright 1992 By William F. Slater, III
    Permission is hereby granted to copy and distribute this material
    so long as due credit for the authorship is given.

    This material was previously submitted to PARADOX INFORMANT for editing,
    adding of artwork layout, and publication.  The finished material was
    published in three installments in PARADOX INFORMANT in February, March,
    and April 1992.  If there are any questions, please contact the author at
    719-260-2018 (work) or 719-495-0726 - or - Mitchell Koulouris, publisher,
    PARADOX INFORMANT at 916-686-6610.


==============================================================================



                         PARADOX SQL LINK for Rdb/VMS

    PARADOX SQL LINK - WHAT IS IT?

    PARADOX SQL LINK is a PC product which was designed by BORLAND to give
    PARADOX users access to SQL-based relational database servers.
    Using the PARADOX SQL LINK a PARADOX user can have the familiar,
    versatile "front end" of PARADOX, and harness the power and other
    standard relational database management system features of Rdb/VMS.

    WHY WOULD A PARADOX USER WANT TO ACCESS AN Rdb/VMS DATABASE ON A VAX?

    Rdb/VMS is considered by many experts to be the most flexible and
    formidable relational database management system which runs on the VAX.
    Some of the pluses of using Rdb/VMS include: performance, backup
    capabilities, security, data integrity, triggers, primary and foreign key
    support, interoperability with DB2 and ORACLE, dynamic file size
    allocation, multi-file support, multi-user access, the industry's best
    implementation of the two-phase commit protocol in a transaction
    processing context, and rollback and recovery.  In addition to all
    of these advantages, Rdb/VMS runtime licenses are bundled with VAX/VMS
    licenses.

    CORPORATE DATA RESIDES IN Rdb/VMS DATABASES - IT'S PARADOX ACCESSIBLE

    In today's highly competitive data processing environment, many MIS
    departments which use VAX systems either are using Rdb/VMS databases
    or are considering a migration to Rdb/VMS, so these cases there is or
    will be a growing amount of corporate data stored in Rdb/VMS databases.
    With the use of PARADOX and PARADOX SQL LINK, PC users access this data.
    Using these software products, users can access data directly through
    screens in PARADOX turn-key application systems, or the data can be
    brought down directly to the PC for reporting, graphing, analysis,
    etc.  Data can also be uploaded in the form of tables, either adding
    entire new tables to an Rdb/VMS schema file and/or updating existing
    records, inserting records, and deleting records in tables which
    already exist in the Rdb/VMS schema file.

    CONSIDERING Rdb/VMS?  THERE ARE THREE TYPES OF Rdb/VMS LICENSES

    If your company has a VAX cluster, you may be interested to find that
    Digital has three forms of Rdb/VMS Licenses:  Development, Interactive,
    and Runtime.  It is quite typical to have Runtime Rdb/VMS Licenses on
    every node of a VAX cluster, except one or two nodes which may be
    running with either Development or Interactive copies of Rdb/VMS.
    Development or Interactive Rdb/VMS is required so changes can be
    made by a Database Administrator to the structure of an Rdb/VMS
    database for database definition, tuning purposes, database utilities,
    etc. and for RDB/VMS application development.  What makes this type
    of configuration particularly attractive for most companies is that
    Digital doesn't charge for Rdb/VMS Runtime Licenses.  If you purchase
    the VAX/VMS software license for a VAX machine, you can get a Rdb/VMS
    Runtime for FREE.  This makes using Rdb/VMS particularly cost effective
    when you consider the licensing schemes of other large software vendors
    which make relational database software for the VAX.

    WHY WOULD AN Rdb/VMS USER BE INTERESTED IN PARADOX?

    PARADOX is a very powerful PC-based relational database manager.
    Since 1985, PARADOX has been giving PC users one of the most easy-to-use,
    versatile PC interfaces on the market to create and manage databases,
    generate reports, create screen forms, generate queries using Query By
    Example (QBE) syntax, and create graphs (a feature added in 1989).
    PARADOX permits any and all of these functions through a simple user
    menu, or by writing scripts and procedures using the feature rich
    PARADOX Application Language (PAL) to develop turn-key systems.  Indeed,
    by using PARADOX and PARADOX SQL LINK, the Rdb user has an extremely
    powerful and flexible front end which performs well in client/server
    mode, as well as providing a method for importing data into the
    PC for all kinds or reports, graphs, analysis, etc. using PARADOX.

    DIGITAL PEOPLE AND CUSTOMERS WILL BE INTERESTED IN PARADOX SQL LINK

    For Digital customer base, the most interesting flavor of the PARADOX
    SQL LINK product is the one which permits access of data in Rdb/VMS
    databases through DECnet and SQL Services.

    THERE ARE OTHER "FLAVORS" OF PARADOX SQL LINK

    The remainder of this article deals with using PARADOX and PARADOX
    SQL LINK with Rdb/VMS on a VAX.  It is acknowledged that other flavors
    of PARADOX SQL LINK will access data under MS SQL SERVER, SYBASE,
    ORACLE, and a few other database servers, but for the sake of providing
    information to Digital customers this article will deal strictly with
    the flavor of PARADOX SQL LINK which operates exclusively with Rdb/VMS.

    THE FACTS HERE SUPPLEMENT PREVIOUS ARTICLES BY TANDOWSKI AND WRIGHT

    This article is meant to supplement the series of three PARADOX
    SQL LINK articles, "The ABC's of PARADOX SQL LINK", by Ben Tandowski
    and Drew Wright, which appeared in the PARADOX INFORMANT magazine from
    August through October 1991.  Therefore, I will try to refrain from
    repeating most of the information that was covered in those articles.

    When attempting to understand some of the technical aspects of these
    three products: PARADOX, PARADOX SQL LINK, and Rdb/VMS, it is sometimes
    difficult to comprehend these terms necessary to describe how these
    environments work together.  A glossary has been provided to aid in
    the understanding of these terms and concepts.


   Note:  Terms marked with an asterisk (*) are taken from the
          "Digital Dictionary" copyright 1984, 1986 by Digital
          Equipment Corporation.

          Terms marked with two asterisks (**) are taken from the
          "PARADOX SQL LINK User's Guide" copyright 1990 by Borland
          International.

          Terms marked with three asterisks (***) are taken from
          "Rdb/VMS - A Comprehensive Guide" by Lillian Hobbs and
          Ken England, copyright 1991 by Digital Press

          Terms marked with four asterisks (****) are taken from
          "PARADOX - PAL Users Guide - PARADOX Application Language"
          copyright 1988 by Borland International.



                       PARADOX SQL LINK User Glossary

   ACLs                Access control lists.  One of the methods used to
                       implement security and control access to file
                       structures, directory structures, Rdb tables, etc.
                       in the VAX/VMS environment.  VAX/VMS has ACLs, and
                       so does Rdb/VMS.  The ACLs under Rdb/VMS are more
                       restrictive than ACLs under VAX/VMS and they can
                       be applied at the schema, table and column level.

   client **           In client/server architecture, the client software
                       (residing on the workstation) sends requests from
                       the workstation to the server for processing and
                       displays the results of those requests back on the
                       workstation.

   client/server
   architecture **     In this environment, database management tasks are
                       divided between client or "front end" software,
                       which resides on the user workstations, and the
                       server or "back end" software, which resides on a
                       dedicated database server or file server.  Data is
                       accessed by the client, then it is processed,
                       stored and managed on the server.

   cluster             An arrangement of VAX computers, whereby two or more
                       nodes can share computer peripherals such as disk
                       space.

   commit              A commit is the action in a transaction processing
                       environment in which the changes which are being
                       made to the database are finalized and permanently
                       written to the database.  A transaction, once
                       committed cannot be rolled back.  In an Rdb/VMS
                       transaction, a commit will not only permanently
                       write the changes into the database, but it will
                       also close the database cursor that is presently
                       being used in accessing the Rdb/VMS database.

   constraints         Rules that can be applied to columns and tables
                       to insure data integrity.  Constraints are normally
                       defined by a database administrator.

   database
   administrator (DBA) The person responsible for implementing the logical
                       design of an Rdb database into a physical design.
                       Other responsibilities include security, database
                       maintenance, database performance tuning, capacity
                       planning, database modification, backups, providing
                       technical assistance and database access guidelines
                       to application developers, and any other activity which
                       is related to the operation of Rdb/VMS.

   database server **  SQL database servers directly manage the database
                       including such tasks as processing requests,
                       storing data, managing concurrent data access,
                       and providing data security and integrity.

   DECnet *            The Digital software facility that enables a user
                       to access information on a remote computer via
                       telecommunications lines.  DECnet permits
                       communication signals to flow between PCs and
                       VAXs.  It also allows communications with several
                       other types of computers.

   download            The act of transmitting data in the form of
                       one or more records from a remote table to an
                       PARADOX Answer table on the client workstation.

   nft                 Network File Transfer.  A special PC-based utility
                       used under DECnet which permits easy copying of files
                       back and forth between PC and VAX and between VAX and
                       PC.  Translations of file format between VAX and PC
                       format are automatically performed.  An MS-DOS ASCII
                       test file on the PC will be perfectly readable, at
                       least that is to say that all the print readable
                       characters will be readable.

    node               A term used by Digital to designate a single CPU.
                       A node can be a single, standalone unit, or it can
                       participate in a cluster.  A node can also be a PC
                       which is defined to a cluster as a workstation which
                       can communicate through DECnet with other nodes on
                       a cluster.

    PAL                PARADOX Application Language is a set of standard,
                       structured programming instructions which is
                       especially suited to handling relational PARADOX
                       relational database access.  It allows the PAL
                       developer to create scripts which speed up the
                       execution of PARADOX functions.  Note that PAL
                       scripts are interpreted instead of compiled.

   PAL procedure       All the PAL code which exists between a PROC
                       and ENDPROC statement.  Procedures are usually
                       developed to handle specific tasks (functions),
                       which would otherwise be handled by the repetitive
                       use of PAL code.  Procedures are usually used
                       not only because they simplify the PAL scripts
                       or procedures that use them, but also because
                       they cause PARADOX to parse the PAL code and
                       generate object code which will execute faster
                       than standard PAL scripts.  Note that all PAL
                       procedures are contained in script files, but not
                       all script files are procedures.

   PAL procedure       A special library file where PAL procedures get
   Library             written into as they are being parsed and converted
                       into object code by PARADOX.  There can be as few as
                       one and as many as 300 procedures in a PAL
                       procedure library.  Note that when a PARADOX turn-key
                       application system is distributed, only one script
                       is necessary to start the system, and it is not
                       necessary to distribute PAL source, if the procedures
                       have been written into a PAL procedure library.

   PAL SQL extensions  The SQL-like PAL language features and the
                       actual SQL commands that were implemented into
                       PAL in release 3.5 of PARADOX to enable the
                       PAL developer to create applications which can
                       interface with and use the capabilities of SQL-
                       based database servers.

   PARADOX main menu   The main menu which lists the various major modes
                       and operations that the PARADOX user can use to
                       provide any of several major functions for use
                       with relational tables in the PARADOX environment.
                       Curly braces ( { } ) are used to designate the
                       PARADOX menu options which need to be followed to
                       accomplish a specified task from the menu.

   PARADOX             A full-featured PC 4GL database manager which
                       permits rapid prototyping and application
                       development.  Features such as a versatile
                       screen forms editor, a report editor, an
                       Query By Example tool, relational database
                       capabilities, and a script language processor
                       make it a powerful "front end" to a database
                       server.

   PARADOX SQL LINK    The Borland PARADOX add-in product, which works with
                       PARADOX to provide access to SQL-based database
                       servers.  It permits the following operations on
                       tables which are residing on the database server:
                       querying using SQL, querying using QBE, adding tables
                       to the remote database schema, deleting tables,
                       adding local tables to remote tables, creating
                       remote tables on the server, adding records to remote
                       tables, modifying records in remote tables, and
                       deleting records in remote tables.  It also permits
                       the creation and management of metadata in PARADOX
                       replica dictionaries, translation of QBE syntax
                       to SQL statements, using SQL statements interactively in
                       an SQL editor, setting special database communication
                       configurations, such as commit, rollback, set trans-
                       actions, etc., and establishing or disconnecting
                       the communications from PARADOX on the PC to the
                       database server communications program.

    process *          The basic entity scheduled by the system software
                       that provides the context in which an image
                       executes.  A process consists of an address space
                       and both hardware and software context.

    QBE  ****          Query By Example, PARADOX's non-procedural query
                       language that lets a user ask questions about data
                       by providing examples of answers you are looking
                       for.  The mechanism of providing these examples is
                       a query form structure which follows the table
                       structure of the table being queried.

   Rdb Schema file     The file which has a .RDB extension, which contains
                       the relational file structure, and some or all of
                       data in an Rdb/VMS database.

   Rdb/VMS             Digital's relational database management system which
                       features some of the most advanced and comprehensive
                       capabilities of any relational DBMS in the world.

   Rdb/VMS
   Management
   Utility  ***        A DCL-based Rdb/VMS utility that allows that database
                       administrator to manage the database.


   remote table        The term that PARADOX uses when referencing a
                       table on a database server.

   remote user         The person who accesses a VAX from another
                       platform through DECnet.

   replica table **    A local table that tells PARADOX where to locate
                       a remote table and how to work with the data in it.
                       A replica contains structural information about
                       the remote table and information that PARADOX uses
                       to connect to the database server.

   replica dictionary  The PARADOX table which is created when a database
                       server is initially accessed to describe the
                       structure of all tables defined by the server
                       schema file, and to map replica table structures
                       to their counterparts on the server.  It is in the
                       replica dictionary that discrepancies between
                       the server tables and the replica tables get
                       resolved.  Such discrepancies include numeric
                       data type differences, field name differences,
                       and table naming differences.

   rollback            The ability to restore a table to its original
                       state before a transaction was first started.
                       Most transactions (except COPY, CREATE, and
                       DELETE table commands can be "rolled back" before
                       a commit takes place.


   SQL                 The Structured Query Language, which has become a
                       standard for accessing relational databases.

   SQL Services        A client/server product that allows application
                       programs running on various types of computers to
                       access DIGITAL Standard Relational Interface (DRSI)
                       compliant databases using the dynamic interface to
                       VAX SQL, an implementation of the industry-standard
                       SQL (Structured Query Language).

   SQLSRV$PROXY.DAT    The SQL Services proxy data definition file in
                       which SQL Services usernames are defined to SQL
                       Services.  Adding the usernames to this file is
                       what permits the communications access to occur
                       between SQL Services and PARADOX SQL LINK.

   transaction **      A process or logical unit of work comprised of
                       one or more database operations.

   triggers            Specially defined switches that operate when some
                       predefined event occurs.  These can be used to
                       enforce the business rules of a company at the
                       database level.  Triggers are normally defined by
                       a database administrator.

   UIC                 The user identification code, which VAX/VMS uses
                       to uniquely identify a username.  Rdb/VMS uses the
                       UIC to control levels of access and protection
                       in the access control list (ACL).

   upload              The act of transmitting data in the form of
                       one or more records from a PARADOX table to
                       a database server.

   username            The name that a VAX/VMS user types on a terminal
                       in order to log in to a system.

    VAX  *             A computer made by Digital Equipment Corporation.
                       VAX is a high-performance, multi-programming computer
                       system based on a 32-bit architecture.  VAX stands
                       for Virtual Address Extension.

   VAX/VMS             Virtual Address Extension/Virtual Memory System. The
                       official designation of Digital's most popular
                       operating system with runs on the VAX.

_____________________________________________________________________________

PARADOX SQL LINK for Rdb/VMS - WHAT IT IS NOT

    So that there will not be any misconceptions about the capabilities of
    PARADOX SQL LINK, below is a list of functions that it will not do.

       PARADOX SQL LINK for Rdb/VMS Does Not Have the Capability To:
                                    --------

       1.  Allow creation or deletion of an Rdb schema database file.

       2.  Permit the definition of Rdb ACL security on an Rdb database

       3.  Permit the definition of Rdb/VMS database constraints and triggers
           at any level in an Rdb/VMS database.


    PARADOX SQL LINK IS NOT A Substitute For An Rdb/VMS Development License
    Or An Rdb/VMS DBA License.


      Note - these facts must be understood before you begin to use PARADOX
      SQL LINK with Rdb/VMS.  Some users have been under the false impression
      that by getting PARADOX SQL LINK, they can circumvent the basic
      requirement to obtain an Rdb/VMS Development License or an Interactive
      license.  Using PARADOX SQL LINK will not replace the need to obtain
      at least one of these type of Rdb/VMS licenses.  Rdb/VMS runtime
      licenses are, of course, free, as stated earlier in this series of
      articles.


    WHAT YOU NEED TO GET STARTED USING PARADOX SQL LINK WITH Rdb/VMS

        A.  Make sure your IBM compatible PC has:

            1.  a network card (for DECnet connections) and a network cable

            2.  PARADOX 3.5 already installed

            3.  PARADOX SQL LINK for Rdb/VMS vers. 1.0 or greater (Note:
                many users will have accidentally bought the PARADOX SQL
                LINK which operates with other SQL server databases.  Be
                sure you buy the correct flavor of PARADOX SQL LINK.)

            4.  DECnet DOS 2.1 or greater, or PATHWORKS. (DECnet has better
                performance.)

            5.  About 4.5 MB of hard disk space for software.
                PARADOX requires 3.0 MB, and PARADOX SQL LINK requires 1.5
                MB of hard disk space.

            6.  At least 1MB of memory, 2MB - 4MB
                is highly recommended.

            7.  MS-DOS 3.3 or greater

            8.  Additional hard drive space for Rdb table
                downloads ( a fast hard drive is desirable )

            9.  A 80286, 80386, or 80486 processor (a fast 80386
                or 80486 is recommended)

        NOTES ABOUT THE INSTALLATION OF PARADOX SQL LINK ON THE PC:

            1.  The PARADOX SQL LINK product should be installed in the
                same directory as PARADOX 3.5.  This is usually the \PDOX35
                directory on one of the PC hard drives.

            2.  Installing the PARADOX SQL LINK product is a "one way
                install".  By this, I mean that there is no uninstall
                capability.  The only was to get it removed from the
                \PDOX35 directory once it is installed, is to erase all
                files from both PARADOX and PARADOX SQL LINK and reinstall
                PARADOX by itself.  The reason for this is that the
                PARADOX SQL LINK product adds some files into the \PDOX35
                directory which overwrite existing PARADOX files.  In
                order to return PARADOX to its "pre-PARADOX SQL LINK"
                state, a total reinstall is required.  This fact has not
                documented anywhere else.

            3.  If you should for some reason, desire to erase all the
                files in the \PDOX35  directory, then it would be a great
                idea to copy your PARADOX.CFG file off somewhere to
                preserve the current configuration settings that were
                present before the PARADOX SQL LINK install.  Then when
                the reinstall of PARADOX has been completed, you can
                quickly return the configuration to its former state by
                copying the PARADOX.CFG file back into the \PDOX35
                directory.

        B.  VAX Requirements:

            1.  Any VAX which runs VAX/VMS

                Note: If a MicroVAX or VAX 3100 is used, a minimum of
                a two disk drive configuration is strongly recommended
                for performance reasons.

            2.  VMS 5.3 or greater

            3.  Rdb/VMS 3.1B or greater

            4.  DECnet must be currently running

            5.  Connection to the PC network card

            6.  SQL Services process currently running

            7.  A username account set up for the remote user

            8.  An Rdb database to connect to and retrieve
                records from, copy tables to, or to operate
                with in client/server mode.


    HOW TO PURCHASE PARADOX AND PARADOX SQL LINK - PRICING/ORDERING INFORMATION

    Both PARADOX and PARADOX SQL LINK may be ordered from BORLAND.  The
    pricing for single volume orders are as follows:

                                             Suggested
                         Product             List Price
                  ----------------------     ----------
                  PARADOX V. 3.5               $795
                  PARADOX SQL LINK             $495
                  PARADOX V. 3.5 Netpack       $999
                  (for 5 users)

      (Note: Discount software retailers can routinely beat these prices.)


    VAX/VMS SYSTEM MANAGEMENT NEEDS

    Getting access to a VAX requires some efforts of a VAX system manager,
    someone who knows the VMS operating system and is directly responsible
    for the software configuration of the system.  This person is usually
    known as the VAX System Manager or System Administrator.  From this
    person, you will need to request the following:

        USERNAME ACCOUNT

        A username account must be added for the user who will be using
        PARADOX SQL LINK to connect with an Rdb/VMS schema file.  A
        password will be assigned to the username.  It is advisable to
        do your first VAX signon on a terminal connected to the VAX system.
        Why?  Two reasons, 1) you will determine that you definitely have
        a VAX/VMS username account and 2) VAX/VMS requires that each time
        a new user is added to the system or a password is redefined by
        the System Manager, the password must be changed by the affected
        user the very first time they login after the new username
        definition or password change.

        MAKE SURE THE SQL SERVICES PROCESS IS RUNNING

        If an attempt is made to run PARADOX SQL LINK when the SQL Services
        process is not presently running under VAX/VMS, the user will see
        this message, "Network Connection Error".  This is a signal to the
        user to get the SQL Services process started under VAX/VMS.

        WHAT IS SQL SERVICES?

        A client/server product that allows application programs running
        on various types of computers to access DIGITAL Standard Relational
        Interface (DRSI) compliant databases using the dynamic interface to
        VAX SQL, an implementation of the industry-standard SQL.

        HOW TO CHECK TO SEE IF SQL SERVICES IS RUNNING ON THE VAX

        Since using the PARADOX SQL LINK product requires that the SQL
        Services process be currently  running on the VAX node that you
        plan to connect with, you will want to determine if this process
        is running by typing this command on the VAX: $ SHOW SYSTEM.  This
        command will cause a list of every process which is currently in
        running in the system.  If a process named SQL$SERVER is running,
        then that is the SQL Services process.

        HOW TO START THE SQL SERVICES PROCESS IF IT IS NOT CURRENTLY
        RUNNING

        The DCL command procedure (SQLSRV$STARTUP.COM) which starts up the
        SQL Services process is found under the SYS$STARTUP logical
        directory name.  Note that SYSPRIV privileges will probably be
        required to execute this procedure.  If you don't have SYSPRIV
        privileges, get the VMS System Manager to perform this task for you.
        To successfully start the SQL Services process, enter these commands:

                             $ SET DEF SYS$STARTUP
                             $ @SQLSRV$STARTUP


        Note that if your site is running Rdb/VMS 4.0 or greater, there
        will probably have to some modifications made to the SQL SERVICES
        file called SQLSRV$PROXY.DAT which is located under the SYS$STARTUP
        directory.  The steps to modify the SQLSRV$PROXY.DAT file are shown
        below along with a sample SQLSRV$PROXY.DAT file.


           1.  Make sure you have SYSPRIV permissions or else have your
               VMS System Manager perform these tasks.

           2.  Do a SET DEF SYS$STARTUP to point you at the directory where
               the necessary SQL SERVICES files are located.

           3.  Edit the SQLSRV$PROXY.DAT file to contain the following
               information:

               The Syntax:

               ADD/PROXY remote_nodename::remote_username local_username

               An example of an actual SQLSRV$PROXY.DAT file under
               SYS$STARTUP:

                       add/proxy bartls::slater slater
                       add/proxy bartls::kahn_p kahn_p
                       add/proxy bartls::koulouris_m koulouris_m
                       add/proxy bartls::coffey_j coffey_j
                       add/proxy bartls::zenreich zenreich
                       add/proxy bartls::wing wing
                       add/proxy bartls::munns munns
                       add/proxy bartls::koski koski
                       add/proxy bartls::system system


           4.  After the edit, use the SQLSRV$SHUTDOWN.COM file to shut
               down the SQL$SERVICES process in the system.  It is better to
               wait until after hours to make sure no one will be using the
               SQL$SERVICES process.

                            $ @SQLSRV$SHUTDOWN

           5.  After the shutdown procedure is successful, use the
               SQLSRV$STARTUP procedure to restart the SQL SERVICES
               process.   When SQL$SERVICES restarts, the new
               SQLSRV$PROXY.DAT parameters will then take effect at
               that time.

                            $ @SQLSRV$STARTUP


        CREATE A TEST Rdb/VMS DATABASE

        To begin using PARADOX SQL LINK the new user may want to start
        with the sample application which is shipped with the product.
        When this application is used, or if any other testing operations
        are done where tables may be copied up to the Rdb schema file,
        changed or deleted, on the VAX, it may be advisable to start with a
        "test" Rdb schema file until the new PARADOX SQL LINK user is totally
        confident with using PARADOX SQL LINK.

        WHY CREATE A TEST Rdb/VMS DATABASE?

        When the connection has been made to an Rdb/VMS schema, PARADOX
        SQL LINK will permit a user to treat Rdb tables as if they are
        PARADOX tables.  This means that Rdb tables can be deleted, emptied,
        modified, and copied to.  It also means that it would be possible
        to perform an unintentional destructive update to an existing Rdb
        table by emptying the table, modifying it, or copying a local
        PARADOX table into it.  Rdb tables can be protected by enforcing
        the security feature known as Access Control Lists (ACLs), however,
        it should not be assumed that security has been implemented to the
        fullest extent until confirming this with your site Rdb database
        administrator.  To be safe, until a new  user becomes proficient at
        using PARADOX SQL LINK it is advisable to use a test Rdb database.

        HOW TO CREATE A TEST Rdb/VMS DATABASE USING VAX SQL

        You must have an Rdb/VMS Development license or Interactive license
        in order to run the VAX SQL product which will permit the definition
        of a Rdb schema files.  Shown below are the VAX SQL statements needed
        to create a most basic Rdb schema database file:  (Note the use of
        semicolons to terminate an SQL statement)

                           $ SQL

                           SQL>  create schema filename test;
                           SQL>  create table dummy
                           cont>     ( dummy_file  char(1) );
                           SQL>  commit;
                           SQL>  show table;
                           SQL>  exit



        GETTING STARTED WITH PARADOX SQL LINK AND Rdb/VMS

        MAKING THE CONNECTION


            1.  Make sure the SQL Services process is executing on the VAX.

            2.  Make sure you have a DECnet card and software on your PC.

            3.  Start PARADOX

            4.  Do a {Tools} {More} {Directory} to see what directory is
                the current default directory.  It should be C:\PDOX35.
                If not, at this time set the directory to C:\PDOX35.

            5.  To get an Rdb database connection do this:

                  {Script} {Play} C:\PDOX35\SQLSETUP {Enter}

  [Screen S02 Goes Here...]


                Then select {Automatic} from the SQL menu to start the
                login process.

                Press [F2] to select the Rdb/VMS connection setting from the
                SQL Connection List Screen.  It will be the only setting on
                the list.

  [Screen S03 Goes Here...]

                Then you must provide signon information in the connection
                screen that appears:


                           REMOTE USER      :  ______________

                           REMOTE PASSWORD  :  ______________

                           REMOTE NODENAME  :  ______________

                           SCHEMA NAME      :  ______________


  [Screen S04 or S05 Goes Here...]

                Fill in the appropriate information and press the [F2] key.
                If you did everything correctly, a message in the lower
                right part of the screen will indicate:  "Rdb/VMS 3.1"
                (Even if you are really running with 4.01).

            6.  In the C:\PDOX35 directory, there will be a PAL script file
                called SQLSETUP.  If not you did not install PARADOX SQL
                LINK correctly.  Do a {Script} {Play} {SQLSETUP}.  This
                will execute the SQL SETUP program under PARADOX/PARADOX
                SQL LINK.

            7.  Select the {Automatic} to automatically build the PARADOX
                Replica Dictionary.  This is a PARADOX database which will
                mirror the Rdb schema and show a one to one equivalence
                between what the Rdb data definitions look like and the
                PARADOX data definitions that it gets translated to.
                PARADOX will ask you for an eight character name for this
                Replica Dictionary.  I suggest something which reminds you
                of the Rdb schema name that PARADOX SQL LINK is accessing
                so you will be able to keep track of it.

            8.  The first part of the Replica Dictionary creation process
                after PARADOX SQL LINK access the Rdb schema, is for
                PARADOX SQL LINK to provide a list of every table in the
                Rdb schema.  At that time, the user may de-select those
                tables that are not desired for access by PARADOX SQL LINK.
                The de-selection process is done using the [Space Bar].
                After the list of tables looks the way you want it, press
                [F2] to perform the table structure selections and continue
                building the Replica Dictionary.

  [Screen S06 Goes Here...]

            9.  The second part of the Replica Dictionary creation process
                is to permit the user to review and define different numeric
                data types where a possible conflict could exist.  Usually,
                there will not be a problem, unless several different numeric
                data types were used in the Rdb schema.  It should be okay to
                press [F2] to complete the Replica Dictionary creation process.

  [Screen S07 Goes Here...]

           10.  After the Replica Dictionary has been successfully created,
                PARADOX will build a Replica table for each Rdb data table
                selected during the Replica Dictionary creation process.
                A Replica table is a strange table under PARADOX.  It
                consists of a PARADOX table structure which mirrors its
                "big brother" Rdb table, but it contains NO data.  To get
                data from the VAX Rdb database, select the {Ask} feature
                from the PARADOX main menu, and cursor over to a replica
                table name.  When you press the [Enter] key, PARADOX will
                put up a Query By Example (QBE) framework onto the workspace
                which mirrors exactly the structure of the Replica Table.
                Use the [F1] key if you require help, but unless it is a
                huge Rdb table (i.e. a large number of records), do an
                [Alt] [F6] to accomplish the placement of a +check mark
                in every field.  When you have filled out the QBE query form
                press [F2] to execute the query.  The result will be a data
                access request generated from PARADOX on the PC to SQL
                Services on the VAX.  It will then retrieve the desired
                records out the corresponding remote table under Rdb/VMS
                and send these records down to the PC in PARADOX to be
                copied into the Answer table.

  [Screen S08 Goes Here...]
  [Screen S09 Goes Here...]
  [Screen S10 Goes Here...]
  [Screen S11 Goes Here...]

        THREE TYPES OF CLIENT/SERVER OPERATION

        The PARADOX SQL LINK product combines with PARADOX and Rdb to give
        the user three types CLIENT/SERVER of operation:

        A.  Download - a user performs a Query By Example in
            interactive "native" PARADOX, on a  "replica" table and
            the result is an "Answer" table which is on the PC.  This
            "Answer" table can be copied or renamed to another table
            name.

        B.  Upload   - a user can copy tables up to the VAX through
            the VAX SQL Services facility and PARADOX SQL LINK, that
            PARADOX table which is getting written to the VAX disk
            drive, gets written out in the form of an Rdb/VMS table.
            This means that the Rdb file is modified to include the
            structure of the new table being added, and the records to
            populate that table with data.  While Rdb triggers and
            constraints are not placed on the newly created table,
            if a unique key field exists on the PARADOX table, then
            that key is duplicated in the Rdb file.  Note that any table
            which is copied up to the Rdb/VMS schema will show that
            it was created by a UIC of [____,SQL$SERVICES].  The blank
            will be some other software product name, which may be set
            by some other software installation.  In the case of the site
            where these tests were made, DECPLAN was the software product
            which was in place of the blank.

  [Screen S12 Goes Here...]

        C.  Turn-Key Application  - In this type, the SQL extensions to
            PARADOX Application Language (PAL), make it possible for
            a user to pull Rdb records into a screen form under PARADOX
            on the PC, massage the data in the record, then write the
            record back out to the Rdb data table.  It is also possible to
            add and delete records in client server mode.  Note that in
            order to operate in this mode, it is necessary to develop a
            PARADOX application which includes PAL procedures which
            utilize the PAL SQL extensions to perform SQL operations on
            the remote table.   To effect this type of development, the
            user must work closely with a PARADOX programmer who
            understands the new concepts of accessing an SQL database
            server using the PAL SQL extensions.


   VI.  Getting the Sample Client/Server Application Installed
        and Started

        The sample application which is packaged with PARADOX SQL LINK
        is a customer order tracking system.  When installed properly,
        this application will nicely demonstrate the capabilities of
        PARADOX, PARADOX SQL LINK, and Rdb/VMS working together to provide a
        client/server system.

        Installation Notes for the SQL Sample Application

            1.  Start the PARADOX SQL LINK, and connect Rdb/VMS.  You must be
                connected in order to successfully perform the SQL sample
                application.

                    On the PC:

                           C:\> cd \PDOX35

                           C:\PDOX35>  PARADOX

                           {Script} {Play} {SQLSETUP}

                  Then select {Automatic} from the SQL menu to start the
                  login process.

                            (gives you the signon screen)


                          REMOTE USER      :  ______________

                          REMOTE PASSWORD  :  ______________

                          REMOTE NODENAME  :  ______________

                          SCHEMA NAME      :  ______________


                   (Fill in the signon information and press [F2]


            2.  Make sure the sample application has been copied into
                the \PDOX35\SQLSAMP directory on the PC by using the PARADOX
                SQL LINK installation program which is on disk 1 of the
                PARADOX SQL LINK product disks.

            3.  Use the {Tools} {More} {Directory} commands to set the
                current directory to be \PDOX35\SQLSAMP

            4.  Execute the INSTSQL script, {Script} {Play} {INSTSQL} , which
                will build the procedure library and create/load remote
                tables.  Note that this installation script can only be
                executed once with each Rdb schema that you connect to.  Why?
                Because the INSTSQL script has been coded to check if
                these tables already exist in the schema database file.  If
                they do exist, an error message will be displayed and the
                program will stop executing and force an exit.  You can, of
                course, get around this by either deleting the tables from
                the Rdb schema file (using PARADOX or VAX SQL), or you can
                try this install activity to another schema, where the
                install has not been done yet.  Note that since the
                installation of the sample SQL application also creates
                replica tables, if you are attempting a re-install to recover
                from previously mishandled procedures, you may need to
                delete them using the PARADOX SQL LINK menu {Tools} {SQL}
                {ReplicaTools} {Delete} {table_name} {Ok} .

            5.  After the INSTSQL script has been successfully executed, you
                may then start the application using the STARTAPP script, the
                main driver script.  To do so, make sure you are pointed into
                the \PDOX35\SQLSAMP directory, then {Script} {Play}
                {Startapp} .  Remember as you experiment with PARADOX SQL
                LINK that the changes and deletions you make are permanent,
                so be careful not to delete or change anything that you would
                not want to be permanently changed.

        Running the Client/Server Application

            Note that each time a user wishes to execute the sample
            application, the SQL connection process will have to occur.

            The sample application is a fine example of what a PARADOX SQL
            LINK user can expect to experience when running a turn-key system
            which is PC-based but interfaces directly with Rdb/VMS on a VAX.
            Although the user's screens and keyboard will have the look and
            feel of the same PC they have always been used to, the user will
            indeed be interfacing with a very powerful relational database
            management system on the VAX.

            To become familiar with the capabilities of the sample
            application, the user should try the following capabilities of
            the sample application:

                           1.  Add records

                           2.  Delete Records

                           3.  Modify Records

                           4.  Execute Queries

                           5.  Run Reports


     POSSIBLE USES OF PARADOX SQL LINK

         A.  Downloading data from Rdb/VMS to PARADOX

         B.  Uploading data from PARADOX to Rdb/VMS

         C.  Client/server, turn-key system access

         D.  Get Rdb/VMS data into PARADOX format for easy import to
             QUATTRO PRO.  One the data is in QUATTRO PRO format, if
             it is in tabular format, it can be easily graphed and turned
             into presentation quality graphics.

         E.  Database Administration Uses:

     PARADOX SQL LINK - The DBA's Friend

     Among the many uses provided by the combination of PARADOX, PARADOX
     SQL LINK and Rdb/VMS together, are operations by which a database
     administrator can really become more productive and to better manage an
     Rdb/VMS database.  These include:

          1)  The rapid creation of a DBA table which contains the name of
              every table which is defined in an Rdb schema file and
              easily modifying this table with other fields and data
              which will permit a more automated method of managing the
              DBA details of the database.  (See Appendix 2)

          2)  Using the table described above with PARADOX report writer
              to have PARADOX rapidly generate hundreds of lines of SQL
              schema DML code in seconds.  This includes schema code for
              defining storage areas, maps, and indexes.  (See Appendix 3)

          3)  Rapid creation and modification of Rdb table structures.

          4)  Using PARADOX SQL LINK to create and populate tables into
              a test Rdb database by copying PARADOX tables up to an Rdb
              schema file on a VAX.

          5)  "Quickie" database conversions using two different copies of
              PARADOX SQL LINK.  Here's how this would work:

              A.  One PC with a very large hard drive.

              B.  One copy of PARADOX, installed into two different
                  directories on the same PC.

              C.  Get two copies of PARADOX SQL LINK (one version for
                  Rdb/VMS and one version for ORACLE) install one in one
                  PARADOX directory and the other in the other PARADOX
                  directory.

              D.  Get access to two different databases on a VAX. You may
                  have to coordinate this with two different DBA's
                  Example:  ORACLE and Rdb/VMS.

              E.  Use the ORACLE version of PARADOX SQL LINK to connect to
                  ORACLE.  Download a table to a directory using the QBE
                  feature of PARADOX.  Rename the Answer table.  Disconnect
                  from ORACLE.

              F.  Use the Rdb/VMS version of PARADOX SQL LINK to connect an
                  Rdb database schema file.   Use PARADOX to copy the newly
                  downloaded table that came from ORACLE directly into the
                  Rdb schema file.  You have just completed a simple major
                  database conversion.



         COMMON PROBLEMS WHICH PREVENT CONNECTION TO Rdb/VMS FROM PARADOX
         SQL LINK

         1.  SQLSRV$PROXY.DAT may be incorrect - verify with VAX System
             Manager.

         2.  SQL Services process not running (Network Connection Error) - see
             your VAX System Manager.

         3.  Incorrect specification of Rdb/VMS schema file in the PARADOX
             SQL LINK Connection Screen - check your typing.

         4.  No authorization to access a given Rdb schema file - see DBA



        POTENTIAL PROBLEMS AFTER YOU START USING PARADOX SQL LINK

        A.  DATA SECURITY

        With the new ease of Rdb data access from PARADOX, comes the
        responsibility to care for the data once it has been written in
        PARADOX database format, and possibility that data can be
        easily stolen from a company.  This is a particularly sensitive
        topic because it addresses on a concept that few managers have
        a firm grasp on:  The concept that data can be transferred easily
        between PC and VAX.  Previously, managers have thought of data
        security in a purely PC or purely VAX context.  The lead time to
        required to understand these data transfer concepts and to implement
        sufficient data security policies which embrace this new technology
        is the window during which corporate data in Rdb databases will have
        the highest vulnerability in terms of theft.

        B.  SETTING UP ACLs FOR DIFFERENT TYPES OF ACCESS UNDER Rdb/VMS

        Any table which is copied up to the Rdb/VMS schema will
        show that it was created by a UIC of [____,SQL$SERVICES].  The
        blank will be some other software product name, which may be set
        by some other software installation.  In the case of the site
        where these tests were made, DECPLAN was the software product
        which was in place of the blank.

        When you copy a PARADOX table up to the VAX into Rdb/VMS, the user
        who has all the ACL is UIC [______,SQL$SERVICES].  The ______ may
        be a product that has modified SQL$SERVICES during installation.
        At our site, the ______ is DECPLAN.  You may verify this by running
        interactive SQL.  Be sure to ASSIGN the value of SQL$DATABASE to
        the Rdb schema file which you are using with PARADOX SQL LINK.
        Then type this command to see the ACL on that table which was
        copied up from PARADOX:  SHOW PROTECTION ON table_name

        Below is the Rdb/VMS ACL on a table I uploaded to an Rdb schema file
        from PARADOX SQL LINK: (Note that Rdb/VMS placed the ACL statements
        on this table at the time it was created when it was uploaded into an
        Rdb database schema.

         $ SQL

          SQL> SHOW PROTECTION ON VEMP;
          Protection on Table VEMP

         (IDENTIFIER=[DECPLAN,SQLSRV$SERVE],ACCESS=SELECT+INSERT+UPDATE+
          DELETE+SHOW+CREATETAB+ALTER+DROP+DBCTRL+OPERATOR+DBADM+REFERENCES+
          SECURITY+DISTRIBTRAN)

         (IDENTIFIER=[*,*],ACCESS=NONE)

         EXIT

        Personally, I think this is weird, because of the username/password
        requirement of signing on to get started.  And, this is certainly
        a security aspect that will require attention BEFORE your system
        goes into production.


        C.  EDUCATION OF THE END USER ABOUT PC HARD DRIVE SPACE REQUIRED

        End users must be educated about the amount of space that will be
        required to download Rdb tables.  Generally speaking, a user can
        easily fill a typical PC hard drive by executing a query which
        would retrieve all the records in a large Rdb table.  If the PC's
        hard drive, fills up, an error message will be displayed, the query
        will be aborted, and all the time invested in waiting for the query
        to complete will be lost.  This could amount to several hours, so it
        pays to be sure that there is enough space on the PC.


        D.  EDUCATION OF AN END USER ABOUT THE CONCEPT OF COPYING PARADOX
            TABLES DIRECTLY INTO AN Rdb SCHEMA FILE ON THE VAX.

        Modification of an Rdb database could be a destructive process if a
        if a production table values are replaced by a PARADOX table that
        is being uploaded.  For this reason, a user with the capability to
        copy PARADOX tables into an Rdb schema as an Rdb table must be
        trained to act responsible when working with PARADOX SQL LINK.

        E.  REPLICA DICTIONARY MANAGEMENT

        When a user first accesses an Rdb schema file on the VAX using
        PARADOX SQL LINK, a Replica Dictionary in the form of a PARADOX
        table on the PC.  When copying PARADOX tables up to a Rdb schema
        file, PARADOX SQL LINK will sometimes force the renaming of a table
        before it can be copied into an Rdb schema.  This is because there
        could a naming conflict between the Rdb table and the local
        PARADOX table.  The user can force PARADOX SQL LINK to perform
        an update by going into the menu and selecting the {Automatic}
        feature and re-establishing the connection to the Rdb schema file.
        Some users may consider it a inconvenient, but PARADOX SQL LINK will
        rebuild the Replica Dictionary each time a new access is made to an
        Rdb schema file.

         F.  INACCURATE NUMERIC DATA TYPE TRANSLATIONS

        PARADOX SQL LINK shows good judgement most of the time when making
        translations between Rdb/VMS and PARADOX datatypes, however,
        occasionally there will be an incorrect numeric data type chosen
        when data is getting translated.  PARADOX SQL LINK will pause while
        the Replica Dictionary is being created with a list of fields that
        it is not sure about.  The user will have the capability to change
        numeric data types in that screen.  See Appendix 1 for PARADOX to
        Rdb/VMS data type equivalences.

        G.  DIFFICULTIES IN DEALING WITH FIELD NAME RESTRICTIONS

        Any PARADOX application designer with a penchant for naming
        fields with imbedded blanks will get into trouble when
        attempting to upload such a table to Rdb.  Rdb does not
        allow imbedded blanks in field names.  It is best to substitute
        the ASCII "_" (underscore character) in place of blanks in
        the field names using {Modify} {Restructure} {table_name} before
        you perform a local table upload to Rdb.  See Appendix 1 for
        guidelines on field names in PARADOX and Rdb/VMS.

        H.  DIFFICULTIES IN DEALING WITH TABLE NAME RESTRICTIONS

        Due to PARADOX and MS-DOS limitations, PARADOX restricts the names
        of tables and replica tables to be eight characters.  Rdb/VMS will
        permit table names of up to 31 characters in length, with letters,
        dollar signs, numbers, and/ ASCII underscores in the name.  If a
        user is used to dealing with long table names, the eight character
        limitation in PARADOX may be considered a real limitation.


        I.  COMMUNICATIONS PROBLEMS OR PC PROBLEMS CAN NEGATIVELY IMPACT
            A DATA TRANSMISSION AND CAUSE A FAILURE TO OCCUR

        When data is being transferred in either direction, to the PC
        from the VAX or from the PC to the VAX, it should be understood
        by the user that the communications link which is performing the
        data transfer is fragile and can be interrupted by actions that can
        stop the successful formation of data tables at whichever end is the
        receiver of the data.

        J.  TABLE LOCKING WHEN AN INTERACTIVE SQL USER IS ATTACHED
            TO THE SAME Rdb DATABASE FILE AS A PARADOX SQL LINK USER

        There is a strange table locking problem that occurs when two
        different users are accessing the same table of the same Rdb schema
        file.  It is actually not a problem at all but a feature of Rdb/VMS
        degree three locking feature,  First I will describe the environment,
        then the symptoms then the workarounds:

        ENVIRONMENT:

        VAX
        VAX/VMS 5.4
        Rdb/VMS 4.0
        Rdb Schema file containing tables uploaded by PARADOX SQL LINK
        SQL Services
        VAX SQL
        DECnet
        VT320 terminal
        PC (DECstation 316)
        PARADOX 3.5
        PARADOX SQL LINK 1.0
        A client/server application written in PAL with SQL extensions
          (the SQL Sample Application which is shipped with PARADOX SQL
            LINK)
        User accessing an Rdb schema file for the client/server access from
          the PC using PARADOX and PARADOX SQL LINK.  He is running the
          Sample SQL application which is shipped with the PARADOX SQL
          LINK.  He is attempting to add a new customer record into the
          server Rdb database.
        A second user accessing an Rdb schema file in interactive VAX SQL
          from the VT320 terminal.  This user executes the following SQL
          statement:  SELECT NAME FROM CUSTOMER;

        SYMPTOMS:

        The PARADOX user's terminal access appears to wait and wait and
          wait.  This would hang forever if you let it.

        The second user is able to retrieve any and all columns and/or
          entire records from the table with no delays.

        WHAT HAPPENED TO THE PARADOX USER?

        The second user who was using the VAX SQL access to the table
          caused a lock to be placed on the table.

        WORKAROUNDS:

        It turns out that this locking "problem" is actually a "feature"
        of Rdb/VMS.  In the words of an engineer I discussed the problem
        with: "This locking is needed to guarantee degree three locking
        consistency... this occurs because Rdb suspects that sequential
        access may be desired because there is no index on the table."

        To get around this there are two easy workarounds:

        A)  Create an index on the table, and access the table using the
            index.

        B)  At the beginning of the VAX SQL session, the user should
            use an explicit DECLARE statement:

                    DECLARE TRANSACTION READ ONLY RESERVING
                        table_name FOR SHARED READ;


______________________________________________________________________________
                                   Conclusion

          -  Powerful Client/Server Solution

          -  Easy User Access to Rdb Data

          -  Powerful, Sophisticated, Programmerless Operations

          -  Feels Like PARADOX, Yet It Unleashes The Power on Rdb/VMS

          -  Permits Turnkey System Development On The Client (PC)

          -  Fun to Use

     -----------------------
     The PARADOX SQL LINK product provides PC users and programmers alike
     a product for accessing relational databases on powerful midframe and
     mainframe computers.  Until now, data in Rdb databases was not that
     easily accesssable from the PC.  Now, using PARADOX users and developers
     can develop programmer-less ways to access data and report on it.
     The creative Rdb DBA can use methods which are outlined here to become
     more productive than ever before.  And the turn-key systems which can
     be developed using PARADOX, PARADOX SQL LINK and Rdb/VMS will
     revolutionize the concept of client/server between the PC and the
     VAX.  Personally, I find working with PARADOX, PARADOX SQL LINK and
     Rdb/VMS to be very exciting, and I hope that I have the priviledge
     of working with this product set for a long, long time.


   ___________________________________________________________________________
      References

         "The ABC's of Using PARADOX SQL LINK", a series of three
          articles by Ben Tandowski & Drew Wright published in the
          PARADOX INFORMANT magazine, Aug., Sept., Oct. 1991

          "Multi-Table Forms and SQL LINK", a presentation by Martin
          W. Rudy to the Second International PARADOX User's Conference,
          April 1991.

          PC World PARADOX 3.5 Power Programming Techniques, by Gregory
          B. Salcedo and Martin W. Rudy, pp 385 - 460, published by IDG
          Books Worldwide Inc., 1990.

          PARADOX SQL LINK User's Guide, by Borland International, 1990.

          "PARADOX - PAL Users Guide - PARADOX Application Language"
          copyright 1988 by Borland International.

          "Digital Dictionary" copyright 1984, 1986 by Digital
          Equipment Corporation.

          "Rdb/VMS - A Comprehensive Guide" by Lillian Hobbs and
          Ken England, copyright 1991 by Digital Press


_____________________________________________________________________________
                                   APPENDIX 1

              Data type, field name, equivalences between Rdb/VMS and
              PARADOX


         Table 1

         Valid Data Types - Equivalence between PARADOX and Rdb/VMS
        ͻ
         PARADOX *             Rdb/VMS **                             
        ______________________________________________________________
         Type  Description     Type                Description       
                                                                     
          A   alphanumeric  VARCHAR          varying length character
                                                                     
          S   short number  SMALLINT         small integer           
                                                                     
          $   currency      DOUBLE PRECISION 64-bit floating point   
                                            number 53 digit precision
          N   numeric       DOUBLE PRECISION                         
                                                                     
          D   date          DATE             64-bit VAX standard     
                                             absolute date data type 
        ͼ

          *   PARADOX PAL User's Guide
              By BORLAND, 1990

          **  VAX Rdb/VMS - SQL Reference Guide
              By Digital Equipment Corporation, 1989



         Table 2

         Field Naming Rules ++
        ͸ͻ
         Rule               PARADOX             Rdb/VMS              
        _____________________________________________________________
                                                                     
         Max Length         25                  31                   
                                                                     
         Valid Characters   All except ",[,],   Letters, digits,     
                            {,},(,),-,>          $, or _             
                                                                     
         Must begin with    Any valid character Any valid character  
        ͼ

          ++  PARADOX SQL LINK - Connecting to VAX Rdb/VMS
              By BORLAND International, 1990


                                   APPENDIX 2

              Creating a DBA Table For an Rdb Schema Using PARADOX,
              PARADOX SQL LINK, Rdb/VMS, VAX SQL, DECnet, and NETWORK
              FILE TRANSFER.


         1.  On the VAX use the ASSIGN DCL statement to define the
             SQL$DATABASE logical.

             $ ASSIGN complete_path_and_Rdb_file_name SQL$DATABASE

             example:

             $ ASSIGN user3:[slater.trim]cms_train.rdb SQL$DATABASE

         2.  $ SQL invokes interactive SQL on the VAX

         3.  SET OUT TABLIST.LOG directs output into a file.

         4.  SHOW TABLE to get table names for a file.

           SHOW TABLE

           User tables in schema with pathname SYS$COMMON:[CDDPLUS]CMS_TRAIN;1
                COUNTRY
                DBA
                DBA_TAB
                ENTER
                FIRST_DEMO
                KCR
                KCRTEST
                KCRTEST2
                KCRTEST3
                KCRTEST4
                KCRTEST5
                ORG
                PETER_Z
                PLANET
                STAFF
                TRIM_COL_VIEW                   A view.
                TRIM_DATA_TYPES
                TRIM_DICT_FIELD
                TRIM_DICT_TABLE                 A view.
                TRIM_DICT_TEXT
                TRIM_INDEX_VIEW                 A view.
                TRIM_MENU_ITEM
                TRIM_TABLE_VIEW                 A view.
                V2FACT03
                V2MKTTAB
                V2PERTAB
                V2PRODNW
                V2PRODTB
                VBENE
                VDEPNDNT
                VDEPT
                VEMP
                VSH
                VSHCODE
                VSHPLACE
                WFSDEMO1


         4.  SHOW TABLE to get table names for a file.

         5.  Copy TABLIST.LOG file to PC using the DECnet's Network
             File Transfer facility.

             example:

             C:\> NFT
                            NFT - Network File Transfer v.4.028

             NFT> copy cooler"slater password"::user3:[slater.trim]tablist.log
                  c:\wfs\tablist.log

  [Screen S13 Goes Here...]


         6.  After the file transfer from the VAX to the PC, use an
             editor program to delete the leading spaces between the
             lefthand margin and the beginning of where the table name
             strings start.  In other words, make the table names flush
             with column position 1 in the left hand margin.  Also,
             delet any other lines in the tablist.log file which does not
             contain a table name.  This editting step will insure that
             good table names are loaded into the PARADOX table which this
             ASCII file will be imported to.

         7.  Use PARADOX menu to import data into a PARADOX data table.

             {Tools} {ExportImport} {Import} {Ascii} {Text}

             Filename: {TABLIST.LOG}

             Table:    {DBATABLE}

  [Screen S14 Goes Here...]

         8.  Use PARADOX, {Modify} {Restucture} Table: {DBATABLE} to add
             additional fields to this table and to change the name and the
             fieldsize of the field call "Text" to a field called "Table_Name"
             with a picture of A30.

                     Field Name                 Field Type
                     -------------------------  ----------
                     Area_No                    N*
                     Table_Name                 A30
                     No_Of_Indexes              S
                     Rdb_Schema_Name            A25
                     File_Name                  A20
                     Volume                     A12
                     Path                       A45

  [Screen S15 Goes Here...]
  [Screen S16 Goes Here...]
  [Screen S17 Goes Here...]

          9.  Use PARADOX SQL LINK to copy this newly created DBA table from
              the PC to the VAX into the same Rdb schema file which used to
              provide table names.  Note that PARADOX will request a new
              table name.  You may use something like "DBA_TAB".


         10.  After the table has been copied into the Rdb schema file on
              the VAX, use VAX SQL to inspect the structure and the contents
              of the newly created DBA table.  Before starting the SQL
              commands, be sure that your SQL$DATABASE logical has been
              assigned.

                      $ SQL

                      SHOW TABLE DBA_TAB

                      Columns for table DBA_TAB:
                      Column Name                     Data Type        Domain
                      -----------                     ---------        ------
                      AREA_NO                         DOUBLE PRECISION
                      TABLE_NAME                      VARCHAR(35)
                      NO_OF_INDEXES                   SMALLINT
                      RDB_SCHEMA_NAME                 VARCHAR(25)
                      FILE_NAME                       VARCHAR(20)
                      VOLUME                          VARCHAR(12)
                      PATH                            VARCHAR(45)

                      Table constraints for DBA_TAB:
                      No constraints found

                      Constraints referencing table DBA_TAB:
                      No constraints found

                      Indexes on table DBA_TAB:
                      No indexes found

                      Storage Map for table DBA_TAB:
                      No Storage Map found

                      Triggers on table DBA_TAB:
                      No triggers found
                      ________________________________________________________

                      SELECT TABLE_NAME FROM DBA_TAB;
                       TABLE_NAME
                       COUNTRY
                       DBA
                       ENTER
                       FIRST_DEMO
                       KCR
                       KCRTEST
                       KCRTEST2
                       KCRTEST3
                       KCRTEST4
                       KCRTEST5
                       ORG
                       PETER_Z
                       PLANET
                       STAFF
                       V2FACT03
                       V2MKTTAB
                       V2PERTAB
                       V2PRODNW
                       V2PRODTB
                       VBENE
                       VDEPNDNT
                       VDEPT
                       VEMP
                       VSH
                       VSHCODE
                       VSHPLACE
                       WFSDEMO1
                      27 rows selected
                      EXIT


        _________________________________________________________________________
                                      APPENDIX 3

              Creating a SQL schema DML files for making an Rdb database
              into a multi-file database using PARADOX report writer, PARADOX
              SQL LINK, Rdb/VMS, VAX SQL, DECnet, and NETWORK FILE TRANSFER.

         1.  On the VAX use the ASSIGN DCL statement to define the
             SQL$DATABASE logical.

             $ ASSIGN complete_path_and_Rdb_file_name SQL$DATABASE

             example:

             $ ASSIGN user3:[slater.trim]cms_train.rdb SQL$DATABASE

         2.  $ SQL invokes interactive SQL on the VAX

         3.  SET OUT TABLIST.LOG directs output into a file.

         4.  SHOW TABLE to get table names for a file.

           SHOW TABLE

           User tables in schema with pathname SYS$COMMON:[CDDPLUS]CMS_TRAIN;1
                COUNTRY
                DBA
                DBA_TAB
                ENTER
                FIRST_DEMO
                KCR
                KCRTEST
                KCRTEST2
                KCRTEST3
                KCRTEST4
                KCRTEST5
                ORG
                PETER_Z
                PLANET
                STAFF
                TRIM_COL_VIEW                   A view.
                TRIM_DATA_TYPES
                TRIM_DICT_FIELD
                TRIM_DICT_TABLE                 A view.
                TRIM_DICT_TEXT
                TRIM_INDEX_VIEW                 A view.
                TRIM_MENU_ITEM
                TRIM_TABLE_VIEW                 A view.
                V2FACT03
                V2MKTTAB
                V2PERTAB
                V2PRODNW
                V2PRODTB
                VBENE
                VDEPNDNT
                VDEPT
                VEMP
                VSH
                VSHCODE
                VSHPLACE
                WFSDEMO1


         4.  SHOW TABLE to get table names for a file.

         5.  Copy TABLIST.LOG file to PC using the DECnet's Network
             File Transfer facility.

             example:

             C:\  NFT

                         Network File Transfer V 4.0

             NFT> copy cooler"slater password"::user3:[slater.trim]tablist.log
                  c:\wfs\tablist.log


         6.  After the file transfer from the VAX to the PC, use an
             editor program to delete the leading spaces between the
             lefthand margin and the beginning of where the table name
             strings start.  In other words, make the table names flush
             with column position 1 in the left hand margin.  Also,
             delete any other lines in the tablist.log file which does not
             contain a table name.  This editting step will insure that
             good table names are loaded into the PARADOX table which this
             ASCII file will be imported to.

         7.  Use PARADOX menu to import data into a PARADOX data table.

             {Tools} {ExportImport} {Import} {Ascii} {Text}

             Filename: {TABLIST.LOG}

             Table:    {DBATABLE}


         8.  Use PARADOX, {Modify} {Restucture} Table: {DBATABLE} to add
             additional fields to this table and to change the name and the
             field size of the field call "Text" to a field called "Table_Name"
             with a picture of A30.

                     Field Name                 Field Type
                     -------------------------  ----------
                     Area_No                    N*
                     Table_Name                 A30
                     No_Of_Indexes              S
                     Rdb_Schema_Name            A25
                     File_Name                  A20
                     Volume                     A12
                     Path                       A45


         9.  Using good database analysis techniques, design your database
             physical layout to reflect the design that will give you the
             best possible performance.  Then determine the syntax of schema
             code that will be required to generate this design.  Note that
             while PARADOX report writer cannot write every bit of the schema
             code, it can write the repetitious items which account for about
             90% of the code syntax.

        10.  Once you have determined the syntax of the schema code, use the
             PARADOX report writer to set up a model of the schema code you
             want for storage areas.  Be sure to place a table_name field in
             the report so PARADOX will plug it in each time it prints out a
             schema entry.  After designing a report to do this, then use
             PARADOX report writer to do a schema map code syntax file, and
             another report to do the schema index code syntax file.

  [Screen S18 Goes Here...]
  [Screen S19 Goes Here...]

        11.  Use PARADOX to execute each of these report definitions files,
             and send each output to a different ASCII text file.

        12.  Using the Network File Transfer program, copy these three files
             up to the VAX.  Change the file extension on each one to be
             ".SQL".  This is so VAX SQL will be able to execute each SQL
             command file identified by the .SQL extension.

             Example:

                      $ RENAME CREAAREA.TXT CREAAREA.SQL
                      $ RENAME CREAMAPS.TXT CREAMAPS.SQL
                      $ RENAME CREANDXS.TXT CREANDXS.SQL

        13.  Use the ASSIGN statement to assign the SQL$DATABASE logical to
             the Rdb schema file which is being operated on.

             $ ASSIGN complete_path_and_Rdb_file_name SQL$DATABASE

             example:

             $ ASSIGN user3:[slater.trim]cms_train.rdb SQL$DATABASE

        14.  Use VAX SQL to execute each of these files.  Using the "@"
             will cause VAX SQL to execute an .SQL command file.

             Logon to the VAX

             $ SQL

             SQL> SET VERIFY
             SQL> SET OUT STOR_AREA.LOG
             SQL> @CREAAREA

             Note repeat the SET OUT and the @CREAMAPS to create the
             storage maps.  You should execute a database load program
             or load PARADOX data into it before building the indexes.
             After the database data has been loaded, create the indexes
             by doing the same steps listed above for the CREANDXS.SQL
             syntax file.


        Shown below is the schema DML code for defining storage areas. Note
        that the PARADOX report writer tool was used to generate this and
        that the actual table names came from the PARADOX DBA table for this
        Rdb schema file that is on the VAX.  It was also used to generate the
        schema map definitions which follow this section of schema code.


                  create storage area COUNTRY_AREA
                         filename db_area_:COUNTRY_AREA
                         snapshot filename db_area_:COUNTRY_AREA;

                  create storage area COUNTRY01_IX_AREA
                    filename db_area__01_IX:COUNTRY01_IX_AREA
                    snapshot filename db_area_:COUNTRY01_IX_AREA;

                  create storage area DBA_AREA
                         filename db_area_:DBA_AREA
                         snapshot filename db_area_:DBA_AREA;

                  create storage area DBA01_IX_AREA
                    filename db_area__01_IX:DBA01_IX_AREA
                    snapshot filename db_area_:DBA01_IX_AREA;

                  create storage area ENTER_AREA
                         filename db_area_:ENTER_AREA
                         snapshot filename db_area_:ENTER_AREA;

                  create storage area ENTER01_IX_AREA
                    filename db_area__01_IX:ENTER01_IX_AREA
                    snapshot filename db_area_:ENTER01_IX_AREA;

                  create storage area FIRST_DEMO_AREA
                         filename db_area_:FIRST_DEMO_AREA
                         snapshot filename db_area_:FIRST_DEMO_AREA;

                  create storage area FIRST_DEMO01_IX_AREA
                    filename db_area__01_IX:FIRST_DEMO01_IX_AREA
                    snapshot filename db_area_:FIRST_DEMO01_IX_AREA;

                  create storage area KCR_AREA
                         filename db_area_:KCR_AREA
                         snapshot filename db_area_:KCR_AREA;

                  create storage area KCR01_IX_AREA
                    filename db_area__01_IX:KCR01_IX_AREA
                    snapshot filename db_area_:KCR01_IX_AREA;


   Shown below is the schema DML code for defining storage maps for multi-
   file Rdb database schemas.

                  create storage map COUNTRY_MAP
                         for COUNTRY
                         disable compression
                         store in COUNTRY_AREA;

                  create storage map DBA_MAP
                         for DBA
                         disable compression
                         store in DBA_AREA;

                  create storage map ENTER_MAP
                         for ENTER
                         disable compression
                         store in ENTER_AREA;

                  create storage map FIRST_DEMO_MAP
                         for FIRST_DEMO
                         disable compression
                         store in FIRST_DEMO_AREA;

                  create storage map KCR_MAP
                         for KCR
                         disable compression
                         store in KCR_AREA;



_________________________________________________________________________
                                  APPENDIX 4


                   An Rdb DBA Tool For the PARADOX SQL LINK User

       One of the best tools that the Rdb DBA has at their disposal is the
       RMU utility.  There are several options under RMU including options
       to /ALTER, /ANALYZE, /BACKUP, /COPY_DATABASE, /DUMP, /MONITOR,
       /MOVE_AREA, /RECOVER, /RESOLVE, /RESTORE, /SHOW, /UNLOAD, and /VERIFY.
       The new PARADOX SQL LINK user who is just becoming familiar with the
       VAX and Rdb environment can log onto the VAX while the PARADOX SQL
       LINK connection to Rdb is being used, execute the RMU/SHOW STATISTICS
       rdb_file_name command, and graphically observe these I/O operations
       taking place against the Rdb schema file which is being accessed
       from PARADOX SQL LINK on the PC.  There are several options under this
       single RMU utility command which enable a PARADOX SQL LINK user to
       quickly understand the I/O impacts that PARADOX SQL LINK is having on
       an Rdb database.  In addition to these options, everything that is
       shown on a VAX terminal screen can be easily printed into a disk file
       which can be printed or copied somewhere, like down to a PC for
       including into a report.

       The following screens depict the actual I/O activity during an
       activity session using PARADOX, PARADOX SQL LINK and Rdb/VMS.  Each
       time the "W" key was pressed while using the RMU/SHOW STATISTICS
       command, a screen was printed into a VAX file called RMU.SCR;#.  As
       many users already know, the VMS operating system will cause new
       versions to be written of the same file name, and VMS will be careful
       to avoid overwriting file names because a version number uniquely
       identifies a file.  Each time another file of the same name is about
       to be written to the same disk directory, VMS will increment the
       highest used version number of the file by the same name and attach it
       to the filename.  For example, first RMU.SCR;1 would be written to
       disk, then RMU.SCR;2, then RMU.SCR;3, and so on.


       Note: the following screens and the software which produced them are
       copyright 1991, Digital Equipment Corporation.

______________________________________________________________________________

Node: BARTLS           Rdb/VMS V4.0A  Performance Monitor   24-DEC-1991 16:14:40
                             Summary IO Statistics
                For Database: USER3:[SLATER.TRIM]CMS_TRAIN.RDB;1
--------------------------------------------------------------------------------


statistic......... max. cur.          10        20        30        40        50
name.............. rate rate +---------+---------+---------+---------+---------+
                             |         |         |         |         |         |
transactions          0    0 |         |         |         |         |         |
verb successes       43   43 +---------+---------+---------+---------+--*      |
verb failures         6    6 +-----*   |         |         |         |         |
                             |         |         |         |         |         |
data file reads      13    6 +-----*   |         |         |         |         |
data file writes      0    0 |         |         |         |         |         |
RUJ file reads        0    0 |         |         |         |         |         |
RUJ file writes       0    0 |         |         |         |         |         |
AIJ file writes       0    0 |         |         |         |         |         |
root file reads       5    0 |         |         |         |         |         |
root file writes      1    0 |         |         |         |         |         |
                             +---------+---------+---------+---------+---------+

--------------------------------------------------------------------------------
Display_menu Exit Help Numbers Options Reset Set_rate Time_plot Write_screen

_____________________________________________________________________________

   This screen is what is produced when the user selects the Summary IO
   Statistics - Graphics option from the Display Menu.


_____________________________________________________________________________

Node: BARTLS           Rdb/VMS V4.0A  Performance Monitor   24-DEC-1991 16:23:56
                             Summary IO Statistics
                For Database: USER3:[SLATER.TRIM]CMS_TRAIN.RDB;1
--------------------------------------------------------------------------------


statistic.........      rate.per.second.........     total...     average..
name..............      max.     cur.     avg...     count...     per.trans

transactions               0        0        0.0            9           1.0
verb successes            43        0        2.0         1649         183.2
verb failures              6        0        0.1           78           8.7

data file reads           21        0        0.5          398          44.2
data file writes           0        0        0.0            0           0.0
RUJ file reads             0        0        0.0            0           0.0
RUJ file writes            0        0        0.0            0           0.0
AIJ file writes            0        0        0.0            0           0.0
root file reads            5        0        0.0           20           2.2
root file writes           1        0        0.0            6           0.7


--------------------------------------------------------------------------------
Display_menu Exit Graph Help Options Reset Set_rate Time_plot Write_screen

_____________________________________________________________________________

   This screen is what is produced when the user selects the Summary IO
   Statistics option from the Display Menu.


_____________________________________________________________________________

Node: BARTLS           Rdb/VMS V4.0A  Performance Monitor   24-DEC-1991 16:26:16
                             Summary IO Statistics
                For Database: USER3:[SLATER.TRIM]CMS_TRAIN.RDB;1
--------------------------------------------------------------------------------
                                  transactions

Maximum rate = 1             Current rate = 0             Average rate = 0.0
Total count = 10                               Average per transaction = 1.0

         +---------+---------+---------+---------+---------+---------+---------+
 46+     |         |         |         |         |         |         |         |
 41-45   |         |         |         |         |         |         |         |
 36-40   |         |         |         |         |         |         |         |
 31-35   |         |         |         |         |         |         |         |
 26-30   |         |         |         |         |         |         |         |
 21-25   |         |         |         |         |         |         |         |
 16-20   |         |         |         |         |         |         |         |
 11-15   |         |         |         |         |         |         |         |
  6-10   |         |         |         |         |         |         |         |
  1-5    |         *         |         |         |         |         |         |
         +---------+---------+---------+---------+---------+---------+---------+
                        Sample interval is 1.00 seconds
--------------------------------------------------------------------------------
Display_menu Exit Help Reset Set_rate Write_screen

_____________________________________________________________________________

   This screen is what is produced when the user selects the Summary IO
   Statistics - Tranactions - Graph option from the Display Menu.


_____________________________________________________________________________

Node: BARTLS           Rdb/VMS V4.0A  Performance Monitor   24-DEC-1991 16:27:16
                             Transaction Durations
                For Database: USER3:[SLATER.TRIM]CMS_TRAIN.RDB;1
--------------------------------------------------------------------------------
Transaction rate (per second):   current = 0          average = 0.0
Transaction duration (seconds):  average = 8.4        95th pctile = 99999.9

             Scaled distribution of transaction lengths (in seconds)
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+---+
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |   |
|   *|*   *    |    |    |    ***  |    *    |    |    |    *    |    |    **  |
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+---+
0....1....2....3....4....5....6....7....8....9....10...11...12...13...14...15+++
                      (Vertical scale is 1 transaction per row)
--------------------------------------------------------------------------------
Display_menu Exit Help Options Reset Set_rate Write_screen

_____________________________________________________________________________

   This screen is what is produced when the user selects the Transaction
   Duration option from the Display Menu.


_____________________________________________________________________________

Node: BARTLS           Rdb/VMS V4.0A  Performance Monitor   24-DEC-1991 16:27:49
                          IO Stall Time (seconds x100)
                For Database: USER3:[SLATER.TRIM]CMS_TRAIN.RDB;1
--------------------------------------------------------------------------------

statistic.........      rate.per.second.........     total...     average..
name..............      max.     cur.     avg...     count...     per.trans

root read time             9        0        0.0           37           3.7
root write time            6        0        0.0           19           1.9

data read time            63        0        1.2         1318         131.8
data write time           21        0        0.0           52           5.2
data extend time           0        0        0.0            0           0.0

RUJ read time              7        0        0.0           14           1.4
RUJ write time             6        0        0.0           21           2.1
RUJ extend time           31        0        0.0           53           5.3

AIJ write time             0        0        0.0            0           0.0
AIJ extend time            0        0        0.0            0           0.0

--------------------------------------------------------------------------------
Display_menu Exit Graph Help Options Reset Set_rate Time_plot Write_screen

______________________________________________________________________________

   This screen is what is produced when the user selects the IO Stall
   Time option from the Display Menu.
_____________________________________________________________________________


                           The End  

-----------------------------------------------------------------------------


                                  Credits

    MS-DOS and MS SQL Server are registered trademarks of MicroSoft
       Corporation.

    DB2 is a registered trademark of IBM Corporation

    ORACLE is a registered trademark of ORACLE Corporation

    PARADOX, PARADOX SQL LINK, and QUATTRO PRO are registered trademark
       of BORLAND International

    DECnet, VAX SQL, SQL SERVICES, VAX, Rdb, Rdb/VMS, Network File Transfer,
       and RMU are registered trademarks of Digital Equipment Corporation

    Multi-Edit is a registered trademark of American Cybernetics Corp.

    PAL-EDIT is a registered trademark of Kallista, Inc.

-----------------------------------------------------------------------------
 <FF>
                           Digital Equipment Corporation
                             DB/TP/EU Symposium - 1992

                 Using PARADOX and PARADOX SQL LINK with Rdb/VMS

                        PARADOX and PARADOX SQL LINK Resources

          -  Texts

          PC World PARADOX 3.5 Power Programming Techniques, by Gregory
          B. Salcedo and Martin W. Rudy, pp 385 - 460, published by IDG
          Books Worldwide Inc., 1990.

          PAL By Example: The PARADOX Programmer's Guide, Second Ed. by Alan
          Zenreich and James Kocis.  Published by Scott-Foresman, 1991.

          PARADOX SQL LINK User's Guide, by Borland International, 1990.

          "PARADOX - PAL Users Guide - PARADOX Application Language"
          copyright 1988 by Borland International.

          -  Periodicals

         "The ABC's of Using PARADOX SQL LINK", a series of three
          articles by Ben Tandowski & Drew Wright published in the
          PARADOX INFORMANT magazine, Aug., Sept., Oct. 1991.

         "Paradox Users Can Now Access Rdb Data", an article in Digital's
         Rdb World journal, by William F. Slater, III, Jan. 1992 issue,
         Vol. 1, No. 1.

         "SQL LINK With Rdb/VMS", a series of three articles by William
         F. Slater, III to be published in PARADOX INFORMANT magazine,
         Feb., Mar, and Apr. 1992.


          -  Digital's PARADOX Notes Conference At TYFYS::PARADOX,
               moderated by William F. Slater, III and James Finnerty

          -  CompuServe - GO BORDB - Section 16 (William Slater, 70530,1016)

          -  Professional Training

             >   Borland International    Scotts Valley, California
             >   Kallista, Inc            Chicago, Illinois
             >   SoftBite International   Addison, Illinois

----------------------------------------------------------------------------
    Biographical Sketch:

    William F. Slater, III is a software specialist in the Digital Equipment
    Corporation Center for Migration Services, Colorado Springs, CO, a
    PARADOX user for four years, chairman of the Database/Spreadsheet
    SIG in the Colorado Springs PC User's Group, and the moderator of the
    Digital PARADOX Notes Conference.  He has almost 15 years of
    professional computer career experience.  He enjoys talking computers,
    software, writing technical articles about software, and helping people 
    in technical subjects.  When he is not working with computers, he teaches 
    computers to teenagers in an Explorer Post, plays folk and bluegrass 
    music, does photography, and coaches Judo students.  He may be contacted 
    at (719) 495-0726 till midnight Mountain Time.  
   ===========================================================================

