# DIGITAL TP Web Connector
DIGITAL Database Web Connector
Getting Started

Previous | Contents | Index

## 4.9.3 Local Procedure Execution Environment

When you use the C output adapter on a local stub, STDL processing procedures execute in the caller process in a multithread environment. Before any processing procedures are executed, the initialization procedure executes once in the process. The initialization procedure is not called at process startup but when the first procedure in the processing group is called.

## 4.9.4 C Data Type Support

The C adapter defines the C data type mappings shown in Table 4-4 for the STDL data types.

Table 4-4 Data Type Mapping for C Adapter

STDL Data Type | C Data Type
--- | ---
DATE | char [17]
FLOAT SIZE 4 | float
FLOAT SIZE 8 | double
INTEGER SIZE 1 | char
INTEGER SIZE 2 | short
INTEGER SIZE 4 | int
UNSIGNED INTEGER SIZE 1 | unsigned char
UNSIGNED INTEGER SIZE 2 | unsigned short
UNSIGNED INTEGER SIZE 4 | unsigned int

## 4.9.5 ODBC Data Source Names and IIS

Any ODBC data source name used in a local procedure executing in IIS as part of an Automation server or as part of an ISAPI DLL must be a system data source name. A system data source is visible to all users and to Windows NT services. If a user data source is specified, IIS cannot locate the data source name or the database drivers.

# Chapter 5
Compiling STDL Applications

This chapter presents STDL command line reference and environment information for use with TP Web Connector and Database Web Connector.

# 5.1 Using the STDL Compiler

The ACMSxp `stdl` command invokes the STDL compiler. The STDL compiler translates STDL definitions and specifications contained in the input source file and produces both object code to link with the clients and other outputs to aid source code development.

Synopsis

The `stdl` command syntax is:

    stdl [-cswLMX]

         [-a in_adapter_type:out_adapter_type]

         [-h directory] [-i path]

         [-o directory] [-S include]

         [-u uuid] [-v version] file_specification

Option Flags

-a in_adapter_type:out_adapter_type

Specifies input and output adapters that provide calling interfaces between a client and task or processing procedure.

- Input adapter types:

- async
  Used in Database Web Connector to produce stubs that asynchronously call C processing procedures by the C adapter.
- auto
  Used in TP Web Connector to produce stubs that allow Automation clients web server access to ACMSxp tasks and ACMS tasks by the Automation adapter.
  Used in Database Web Connector to produce stubs that allow Automation clients web server access to local C processing procedures by the Automation adapter.
- c
  Used in TP Web Connector to produce stubs that allow a C client to call ACMSxp tasks, ACMS tasks, and local C processing procedures by the C adapter.
  Used in Database Web Connector to produce stubs that allow a C client to call local C processing procedures by the C adapter.

- Output adapter types:

- acmsda
  Used in TP Web Connector to produce stubs that allow C and Automation clients to call ACMS tasks by the ACMS Desktop adapter.
- c
  Used in Database Web Connector to produce stubs that allow C and Automation clients to call local C processing procedures by the C adapter.
- dce
  Used in TP Web Connector to produce stubs that allow C and Automation clients to call ACMSxp tasks by the DCE RPC adapter.

-c

Generates a C header file. The compiler generates the C header file with the same name as the input source file and a filename extension of `.h`, either into the current working directory or into the directory specified by the `-h` flag.

-h directory

Specifies a directory into which the STDL compiler generates C header files. By default, the compiler generates the C header files in the current working directory.

-i path

Specifies a directory search path for STDL #INCLUDE and #CINCLUDE files. A path argument must be either a legal directory specification or an environment variable. If you specify multiple arguments, separate each by a semicolon (;), and enclose environment variables in percent characters (%). The compiler searches for the #INCLUDE or #CINCLUDE files in the following order:

- Path containing the top-level source file.
- Path specified by the `-i` flag.
- Directories listed in the STDL_INCLUDE_PATH environment variable.

-L

Produces a file that contains a line-numbered source code listing, with error messages inserted directly under each source line containing an error. The compiler creates this file in the current working directory with the same name as the input source file and the `.lis` suffix.

Use the `-S include` flag with this flag to include in the line-numbered source code listing the contents of the files specified in the #INCLUDE and #CINCLUDE directives.

-M

Specifies that the STDL source files use Multivendor Integration Architecture (MIA) syntax. The default is X/Open syntax.

-o directory

Specifies a device and directory into which the compiler generates output `.obj` files. By default, the compiler generates these output files in the current working directory.

-s

Performs only syntax and semantic checks on the input source file. Does not generate any output files. By default, the compiler generates output as directed by other options.

-S include

When used with the `-L` flag, includes in the line-numbered source code listing file the contents of the files in the #INCLUDE and #CINCLUDE directives. If you specify the `-L` flag without the `-S include` flag, the compiler includes only the input source file in the listing file.

-u uuid

Specifies the default universal unique identification (UUID) for the first processing group specification in the input file that does not have a UUID specified in the STDL syntax. If the input file contains a processing group specification with no UUID specified, this flag is required. The `-u` flag applies only to processing groups that you are compiling, not to processing groups to which the STDL source refers. A UUID value comprises hexadecimal digits (`X`) grouped as follows:

    "XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX"

-v version

Specifies the default version number for any processing group specification in the input file that does not designate a version in the specification syntax. The compiler defaults to assigning a version of 0.0 for any processing group with no syntax-specified version unless you specify a version with the `-v` flag. Version is a decimal literal without a sign. Processing group specifications included for reference only do not require a version number on the command line.

-w

Suppresses warning messages. The default is to display warning messages.

-X

Specifies that the STDL source files contain X/Open syntax.

The STDL compiler defaults to X/Open STDL syntax. To compile Multivendor Integration Architecture (MIA) syntax, use the `-M` flag.

Description

The STDL compiler generates objects that are used in developing processing servers, task servers, and client programs. In addition, the compiler generates adapter objects used for web server access to STDL tasks and local processing procedures. Task compilation is not supported.

The compiler directs output to the current working directory, the directory containing the top-level input source files, or to directories specified by the option flags or by the values set by environment variables.

The input source file designated by `file-specification` must contain either a task group specification (TP Web Connector) or a processing group specification (Database Web Connector).

Use a nonqualified or fully qualified file name as input to the `stdl` command. All files specified with nonqualified names must be in the current working directory. The compiler appends the `.stdl` suffix to the name of the STDL input source file if you omit a suffix in the file specification.

Compilation Output

The STDL compiler generates the following output files based on the contents of the STDL source files and on the flags used during compilation:

- Listing file with a name in the following format:

`source-file-name.lis`

This file contains line-numbered source code statements and a summary report that is generated when you use the `-L` flag.

- C header file with a name in the following format:

`source-file-name.h`

This file is generated when you use the `-c` flag but omit the `-s` flag.
Include this file in any C programs that call ACMSxp tasks, ACMS tasks, or local C processing procedures or refer to STDL data type definitions.

- Adapter stub object with a name in the following format:

`group_in-adapter_out-adapter.obj`

This file uses the name of the task group or processing group (group) and contains the adapter stub object with the adapters specified in the in-adapter and out-adapter arguments with the `-a` flag. (If you specify an asynchronous input adapter, `c` appears in the name, not `async`.)
The compiler generates the adapter stub object if you use the `-a` flag but not the `-s` flag.
Link the adapter stub object as follows:

- With the C client program if the input adapter is `c` or `async` (see Section 4.3)
- With the OLE resource object group_auto.`res` if the input adapter is `auto` (to create an Automation server DLL, see Section 4.4.1)

- OLE resource object with a name in the following format:

`group_adapter.res`

This file uses the name of the task group or processing group (group) and contains a linkable version of an OLE type library.
The compiler generates an OLE resource object if you specify the `-a` flag with an `auto` input adapter.
To create an Automation server DLL, link this OLE resource object with an adapter stub object that includes an Automation adapter (group_`auto`_out-adapter.`obj`). See Section 4.4.1.

- DCE client stub object with a name in the following format:

`group_dce_cstub.obj`

This file contains the DCE client stub for the task group named group.
The compiler generates this file if you specify the `-a` flag with `dce` as the output adapter.
Link the DCE client stub object with a client that uses an adapter stub with a DCE RPC output adapter (that is, the client that calls an ACMSxp task):

- For C clients, see Section 4.3.
- For Automation servers, see Section 4.4.1.

# 5.2 STDL Compiler Environment Setup

To run the STDL compiler, you must register the environment variables needed by the compiler. From a command window, run the `stdl_set_version.bat` batch file from the directory named in the following format:

`install-directory\stdl\bin`

The value install-directory is the device and directory in which you installed the TPware software. For example, if you installed the product in the C:\`tpware` directory, you would type the following:

    C:\tpware\stdl\bin\stdl_set_version.bat

When the STDL development environment is set up, any existing ACMSxp development environment is not available from that command window.

# Chapter 6
Preparing ACMS Applications for Web Access

This chapter describes TP Web Connector components on ACMS systems and explains how the components are used so that PC-based clients, including web clients, can be built to access ACMS applications.

# 6.1 TP Web Connector Components for ACMS Systems

The TP Web Connector kit for ACMS systems includes the following components that together support the generation and use of PC-based client adapters that access ACMS applications:

- DIGITAL ACMS Application Definition Utility (ACMSADU) extension
  Enables ACMSADU to translate an ACMS application into an STDL task group specification.
- DIGITAL ACMS Desktop adapter gateway
  Supports the ACMS RPC between the ACMS Desktop output adapters on the calling system and ACMS systems on the called system (see Chapter 8).

The TP Web Connector components on the OpenVMS system (the ACMSADU extension and the ACMS Desktop adapter gateway) reside on systems running ACMS software. The components can be on the same system or on different systems (see Chapter 3).

The extensions in the modified ACMSADU image enable you to translate an ACMS application to an STDL task group specification. TPware extension commands allow you to control the translation. ACMSADU performs the following TPware functions:

- Extracts information about ACMS tasks and records.
- Translates the extracted information to STDL format.
- Writes the translated information in a form that the STDL compiler can read.

Figure 6-1 shows how ACMSADU reads the application, group, task, and record definitions from the Common Data Dictionary (CDD).

Figure 6-1 ACMSADU Translation Model

ACMSADU produces as output an intermediate group file, from which it produces the STDL task group specification, including record definitions and task group headers with records as arguments.

# 6.2 Running the ACMSADU Extension

Translating applications from TDL to STDL requires the following operations:

- Group_task translation (see Section 6.2.1)
- Application_group translation (see Section 6.2.3)
- Record definition translation and conversion (see Section 6.2.7)

You perform these operations with TPware qualifiers for the ACMSADU BUILD GROUP and ACMSADU BUILD APPLICATION commands.

Note Existing parameters and qualifiers for the ACMSADU BUILD GROUP and ACMSADU BUILD APPLICATION commands have not changed from ACMS Version 4.2. Refer to the DIGITAL ACMS for OpenVMS ADU Reference Manual for a listing of existing qualifiers.

Section 6.2.2 describes the actions that occur during group_task translation, and Section 6.2.4 describes the actions that occur during application_group translation.

## 6.2.1 Group_task Translation

Group_task translation produces temporary files containing ACMS task and task group information. Group_task translation must be performed for every ACMS group that comprises an application.

Synopsis

The command syntax is:

`BUILD GROUP acms_group_name [/STDL]`

Description

The acms_group_name parameter refers to the name of the ACMS group.

The /STDL qualifier directs ACMSADU to output task and record information that is used for the final translation to STDL. The output file produced by /STDL has a name in the following format:

`GROUP.WDB`

The .WDB file type indicates the intermediate-format web database file. The BUILD GROUP command writes the file to the default directory (see the DIGITAL ACMS for OpenVMS ADU Reference Manual for information on DEFAULT TASK GROUP FILE).

The /NOSTDL qualifier instructs ACMSADU not to produce the intermediate-format file. The default parameter is /NOSTDL.

## 6.2.2 Actions During Group_task Translation

In the group_task translation operation, ACMSADU produces a file containing intermediate-format group and task information. During group_task translation, ACMSADU performs the following actions:

- Reads information from the CDD.
- Processes the read information.
- Creates the intermediate-format file.

ACMSADU processes the group description and the description of any tasks and records associated with that group. ACMSADU builds descriptions of all records according to the CDD information. Then, ACMSADU creates a description of all tasks in the group along with the names of records used as parameters to those tasks. The intermediate-format file in which ACMSADU writes all this information is used as input to the application_group translation (see Section 6.2.3).

## 6.2.3 Application_group Translation

Application_group translation reads the group names specified in the application from the CDD and translates the intermediate-format group file built from the group_task translation (see Section 6.2.1).

Synopsis

The command syntax is:

`BUILD APPLICATION application_name [/STDL]`

Description

The parameter application_name refers to the name of an ACMS application.

The /STDL qualifier directs the translator during the ADU BUILD APPLICATION to generate STDL code using the intermediate-format group file that was created during the ACMSADU BUILD GROUP compilation. The output is a file with a name in the following format:

`application_name.STDL`

ACMSADU creates an STDL task group specification and writes the output file with the name of the ACMS application to the default directory. (See the DIGITAL ACMS for OpenVMS ADU Reference Manual for information on DEFAULT APPLICATION FILE).

## 6.2.4 Actions During Application_group Translation

If the ACMS group has been translated to an intermediate-format group file (see Section 6.2.2), run the ACMSADU BUILD APPLICATION /STDL command to translate the ACMS application to its equivalent STDL task group specification. ACMSADU accesses the CDD to find the group name and reads application information from the CDD including the group name. Then ACMSADU uses the application name to locate and to read the corresponding group temporary file. Next, ACMSADU processes the internal descriptions of the records and writes them in STDL format with duplicate names removed. See Section 6.2.6 for the restrictions.

After each task name is processed, ACMSADU generates the STDL TASK ARGUMENT statement, which includes the task parameters with an indication as to whether they are input or output. The arguments are as follows:

- A record containing a text field of 256 characters for the selection string as an input argument.
- A record containing a text field of 80 characters for the extended status as an output argument.
- Any argument(s) defined in the TDL task definition, in order.

The resulting file that ACMSADU produces is an STDL task group specification that you use in the next stage of development (see Section 6.2.5). Refer to Section 6.2.6 for information on ACMSADU restrictions.

Previous | Next | Contents | Index