Model 204 — System 1032 — Year 2000
CCA Systems Make Smooth Transition into the New Year by Pam Manolakis
CCA support personnel celebrated the New Year by keeping in close contact with customers throughout the world as we made the transition from 1999 to 2000. A large measure of credit for the successful reports we obtained throughout the weekend must go to the high level of customer preparedness; your intense effort over the last year paved the way for this smooth rollover event.
Favorable reports began to arrive in the Framingham office at about 9:15 p.m. EST and continued from later time zones throughout the night. Some of the quotes are:
"We can confirm that our... systems have been operating normally. No incidents before, during or (so far) after the millennium boundary."; and "have had no operating system or database problems."
Reports of Y2K successes continued to come in throughout New Year’s day, with more European sites reporting systems up and running with positive results of their application testing. North American time zones checked in with great marks as well.
Of the dozens of sites that contacted the support personnel over the weekend, all have reported positive results with their CCA systems:
Happy New Year from all the staff at CCA.
Model 204 — Part II
WebGate Programming
by Mark LaRocca
The first article in this series on WebGate programming in the November 1999 issue of CCAprint described how to define, assign, and display a run-time environment (RTE) variable with WebGate tags. Part II discusses using VBScript to perform similar tasks. (See the Part I article for an illustration of this example.)
Coding using extended server-side VBScript
You can define, assign, concatenate, and delete RTE variables using the following VBScript commands:
Examining the extended VBScript in the example
In the example below, the server-side VBScript is defined by:
<script TYPE=WDBSCRIPT LANGUAGE=VBSCRIPT> ... </script>
TYPE=WDBSCRIPT tells WebGate that this is server-side VBScript to be executed on the Web server.
Next, following the example, to get the RTE variable Variable1 into the VBScript environment and display it, use the wdb.Puts statement:
XVAR1=wdb.GetVar("Variable1") ... wdb.Puts(XVAR1)’print the VB variable
This displays the second "This is a test" on the sample output.
Now, use wdb.SetVar statement to change the RTE variable and wdb.GetVar statement to get the changed variable into the VBScript environment and display it:
wdb.SetVar "Variable1","This is not a test" ’assign new value to the RTE variable XVAR1=wdb.GetVar("Variable1") ’get the changed RTE variable - assign to VB variable wdb.puts(XVAR1)
This displays the third line of output, "This is not a test", on the sample output.
The final output line is coded as follows:
XVAR2="Variable1" ’assign VB variable to RTE the variable name wdb.SetVar XVAR2,"Oh Yes it is" ’assign new value to RTE variable ... <p><BIG><BIG><BIG>##Variable1##</BIG></BIG></BIG></p> <!-- print the changed RTE variable --> <!-- directly from server storage -->
To summarize, first the literal, Variable1, is assigned to the VBScript variable XVAR2. Next, wdb.SetVar defines an RTE variable, called Variable1. In this case, the contents of XVAR2 defines the name Variable1. Finally, Variable1 is displayed outside the VBScript environment to prove that it was changed to "Oh, Yes it is".
The next article in this series will show an example of how to code a database request using WebGate tags and a similar request from within VBScript.
System 1032
Configuring Parallel ODBC Production and Development Environments
By Tym Stegner
Suppose that you want to set up a development environment that parallels your production environment using the same data sources, but using different ODBC servers, so that when you debug the development environment you do not generate hundreds of debug files from the production environment.
You can install the ODBC driver twice into two different ODBC Manager accounts that use different port numbers, as described in the System 1032 ODBC Driver Installation and Reference. Because this configuration uses different ODBC Manager accounts, the development environment does not duplicate the production environment. Furthermore, you must maintain two copies of the ODBC.INI file, and all the S1032ODBC_* logical names are the same between the two installations.
This article describes a single installation, which runs an alternate server for the same installation of ODBC Driver, by modifying one file, creating one file, and executing a configuration file using alternative parameters. This configuration lets the production server use the default port and assigns another port number to the development server within the same ODBC Manager account.
How ODBC Driver server works
The "Overview" on page 1-2 of the System 1032 ODBC Driver Installation and Reference describes at the conceptual level how the flow of queries and updates for an ODBC session work. Let us look at this flow through the command files and logical names used by ODBC Driver.
To set up the ODBC Driver execution environment, logical names must be defined:
S1032_ODBC_V030_node.COM
And the desired TCP/IP port must be configured:
CONFIG_NET_tcpip.COM
Upon a connection request from the ODBC client process to a particular TCP/IP port, the OpenVMS system’s TCP/IP Monitor checks the configuration options for the port. For the default ODBC Driver, the port is configured to execute the command file, S1032ODBC.COM, located at logical name S1032ODBC_LIB.
This command file uses logical names, S1032ODBC_DBGFILES and S1032ODBC_IMAGE, to optionally declare debugging files and define the debug message level, and to then run the ODBC Driver image, S1032ODBC3.EXE:
Creating an alternate S1032ODBC.COM command procedure
By understanding components of the ODBC Driver server environment, you can modify certain files in the ODBC environment to manipulate your debug files.
The following table lists the significant ODBC Driver logical names and command files.
Logical name or command file
Description
The S1032ODBC_LIB logical name points to the following command files:
Command file
The S1032ODBC_IMAGE logical name points to the following command files:
Defining an additional debugging logical name
To differentiate between debugging the production environment and the development environment, you must modify the debugging switch for the development environment.
Add the following line to the S1032_ODBC_V030_node.COM file:
$ DEFINE/SYSTEM S1032ODBC_DBGDVL "FALSE"
The S1032ODBC_DBGDVL logical name enables debug files for the development server, and the original S1032ODBC_DBGFILES logical name continues to be used for the production server.
Modifying S1032ODBC.COM for the alternate server
In addition to modifying the debug logical name, you must modify the file names of the debugging files, to distinguish them from any production debugging files. These file names are defined within the S1032ODBC.COM file; therefore, you need an alternate copy of this file for the development server. The .LOG file is created based on the .COM file name, for example, S1032ODBC_DVL.LOG.
Make the following changes to the S1032ODBC.COM file:
Declaring the alternate server TCP/IP port
The production server environment is defined upon the default Simba TCP/IP port 1583. The development server needs to be defined on an alternate port. The method for doing this is to execute the CONFIG_NET_tcpip.COM file, where tcpip is either UCX or Multinet.
This command procedure is embedded with default information for the production environment. However, you can override this information by specifying parameters on the command line.
Examine the file to determine the user name of the ODBC administrator account. Then, execute the following command from a system-privileged account:
$ @S1032ODBC_LIB:CONFIG_NET_tcpip - _$ <Username> - _$ <Port> - _$ S1032ODBC_LIB:S1032ODBC_DVL.COM
This command configures the development server on the specified port, executing under the specified user name.
Implementation
Now that the development server is set up and configured, all that remains to be done is to define data sources on the client PCs to access the development server port. CCA recommends that you choose data source names that identify these data sources as development data sources.
Now, to enable debugging for the development server, give the following commands on the server node:
$ SET PROCESS/PRIV=SYSNAM $ DEFINE/SYSTEM S1032ODBC_DBGDVL "TRUE" $ SET PROCESS/PRIV=NOSYSNAM
These commands create debugging files only for the development server, because the TCP/IP connection executes the S1032ODBC_DVL.COM file rather than the original S1032ODBC.COM file.
Education Schedule January - March 2000
Model 204
For more information or to register for a class, please call the Framingham, MA office at 508-270-6666
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
