![]() |
![]() |
e-docs > Tuxedo > Using Tuxedo ATMI on Windows > Using the Visual C++ IDE To Develop BEA Tuxedo ATMI Applications |
Using Tuxedo ATMI on Windows
|
Using the Visual C++ IDE To Develop BEA Tuxedo ATMI Applications
The following sections describe how to develop ATMI application clients and/or servers in the Microsoft Visual C++ Integrated Development Environment (msdev) on a Windows 98, Windows XP, or Windows 2000 system:
Before You Start
Because BEA Tuxedo ATMI client but not server components can be installed on Windows 98 or Windows XP, you can use the Microsoft Visual C++ IDE on these platforms to develop only ATMI application clients. In contrast, because both BEA Tuxedo ATMI client and server components can be installed on Windows 2000, you can use the Microsoft Visual C++ IDE on the Windows 2000 platform to develop both ATMI application clients and servers.
Using Development Tools
BEA Tuxedo ATMI integrates into the Microsoft Visual C++ IDE (msdev) and emulates the functionality of msdev when integration is not possible. This integration makes it easier for you to develop BEA Tuxedo ATMI applications for 16-bit and 32-bit Windows operating systems.
The coding required to create BEA Tuxedo ATMI service requests, send requests, set up conversational connections, and get replies is fundamentally the same in both UNIX and Windows 2000 environments. BuildTuxedo and TUXDEV are tools that help you in your development environment.
Using the buildserver and buildclient Commands
Both the buildclient() and buildserver() commands are available to Windows 2000 but not to Windows 98 or XP. Only the buildclient() command is available to Windows 98 or XP, meaning that only Tuxedo application clients can be built on a Windows 98 or Windows XP system. For more information about the build commands, see buildclient(1)and buildserver(1)in BEA Tuxedo Command Reference.
There are differences between how the options to the buildclient() and buildserver() commands work on non-integrated development environments and on integrated development environments, as indicated in the following table.
To modify the build environment in an integrated development environment, follow these steps:
Note: CC and CFLAGS are no longer needed.
To specify the library and include paths in an integrated development environment, follow these steps:
Adding BuildTuxedo to the MSDEV Tools Menu
To add BuildTuxedo to the MSDEV Tools menu, follow these steps:
Figure 3-1 Tools Page in the Customize Window
BuildTuxedo is now part of the MSDEV Tools menu.
Creating BEA Tuxedo ATMI Project Files
BuildTuxedo maintains a separate project file in the current directory for each BEA Tuxedo ATMI application using it. When BuildTuxedo begins, it searches for a valid project file in the current directory. If one is found, the various dialog controls are set to the values stored in the file and the dialog is displayed. The title bar displays the following information:
BuildTuxedo project_name
Because your BuildTuxedo project is closely associated with the msdev project in the current directory, BuildTuxedo also searches for two other files:
If BuildTuxedo cannot find either of these files, it displays a warning and/or fails to activate. If the directory contains multiple BuildTuxedo project files, or multiple msdev project files or make files, menu items that contain appropriate target names are added to the System menu.
To save the current project file, select OK or Apply. To cancel any changes that you make to the project file or any file maintained by the BEA Tuxedo system, click Cancel or Esc.
Setting Up Your Environment
Before you can build your BEA Tuxedo ATMI application in an IDE, you must set the following fundamental parameters in your environment:
To provide this information, access the BuildTuxedo project_name dialog box in the msdev GUI.
Specifying the Build Type, Header File, and Filename
To specify the build type, header file, and filename, follow these steps:
Figure 3-2 Build Page
Note: Windows 98 or XP users can select only Workstation Client type.
The Initialization and Cleanup options allow you to override the default init/exit functions by specifying valid function names. The Entry Point option allows you to specify the name of the function generated by BuildTuxedo. After specifying its name, you can call the function from anywhere in the application.
How BuildTuxedo Uses the Header File
In the header file, BuildTuxedo adds the necessary pragma statements to build the current BEA Tuxedo ATMI project correctly. BuildTuxedo opens the file specified in the Header File field of the Build page, if the file is present; otherwise, it creates a new one. A section starting with:
//Begin Tuxedo Section*****DO NOT EDIT*****
and ending with:
//End Tuxedo Section
designates the area in the header file in which pragma statements are written. This area is maintained by BuildTuxedo. If BuildTuxedo does not locate this section in the file, it appends it to the end of the header file. Because all other text within the file remains unchanged, you can specify stdafx.h as the header file.
Note: If your project is new, and you select OK or Apply, you must select Files into Project from the MSDEV Insert menu. You then add the file generated by BuildTuxedo to the current project. You need to do this only for a new project or when you change the name of the C/C++ output file.
Specifying Function and Service Names
Select the Services tab to display the Services page, in which you specify function and service names.
Figure 3-3 Services Page
In the Services page, two lists are used to maintain the service dispatch table:
Note: To scroll up and down either list, use the arrow keys.
Generally, the service and the function that performs the service are represented by the same name. For example, function x performs service x. In some cases, the function may have a different name from the service it performs. For example, in one case, function abc performs services x, y, and z. In another case, the service name may not be known until run time.
You must specify any function associated with a service when you build the server. For any function associated with a service, you must specify the service, the appropriate prototype, a C linkage, a void return, and a single TPSVCINFO pointer parameter. To specify a function to which a service name can be mapped, you must add the function to the Function Name list. This information is required for the service dispatch table.
Note: If you are using the buildserver(1)command, you can provide this information with the -s option. For more information about the -s option, see Programming a BEA Tuxedo ATMI Application Using C or Programming a BEA Tuxedo ATMI Application Using COBOL.
To add or edit names on the Function Names list, follow these steps:
Specifying a Resource Manager
To specify a resource manager, follow these steps:
Figure 3-4 Resources Page
Note: The Tuxedo Resource Manager field contains a list of BEA Tuxedo resource managers available on the system, as defined in the %TUXDIR%\udataobj\RM file. If the file is not present, a default (NONE) is displayed.
Debugging a BEA Tuxedo ATMI Server Application
You should use the following procedure only if you have built the ATMI server application using the Debug configuration for your project.
To debug a server that has not been booted, follow these steps.
Note: To debug a server that is already running, type msdev -p nnn at any Windows 2000 command prompt, replacing nnn with the server's process ID (represented by a decimal number).
Developing an ATMI Application Using the Command Line Instead of the Visual C++ IDE GUI
If you must develop a BEA Tuxedo ATMI application using the command line instead of the Microsoft Visual C++ IDE GUI, use the buildserver(1)and buildclient(1)commands. To do this, specify the compiler and link options necessary to build a BEA Tuxedo ATMI application. For information about using these tools, see the following documents:
To build a debug version of your ATMI application using buildserver or buildclient, you must compile all source files with the /Zi and /Od options. The /Zi option enables debugging; the /Od option disables optimization. In addition, you may need to define the _DEBUG preprocessor directive. To complete the process, indicate the link option as follows:
-l"/link/debug:full /debugtype:both"
Using the Tuxdev Application
To install the Tuxdev application, follow these steps:
Note: To create a hot key for a tool, put an ampersand (&) before any letter in the tool name. This enables you to invoke the tool at any time simply by typing that letter.
Using the BEA Tuxedo ATMI Editors
Two editors are available in this environment: the FML Table Editor and the VIEW Table Editor. The user interface for both editors is similar to a workbook in which you can work on multiple views (that is, documents) simultaneously. You can also edit multiple files of various types at the same time. Both editors are similar to a Microsoft Excel spreadsheet:
Using the FML Table Editor
To invoke the FML Table Editor, follow these steps:
Figure 3-6 FML Table Editor
As shown in the preceding figure, the FML Table Editor contains five columns—Name, Number, Type, Flag, and Comment—and an unlimited number of rows.
The following table describes the purpose of each column in the FML Table Editor.
You can open new (unnamed) FML tables. A blank grid is created for the table named FML Tablex, where x is a value tracked by the MDI and incremented by one each time a new table is created. You can specify a name if and when the table is saved. You can also open an existing text file for editing. Unless otherwise specified, files are saved in the directory in which the file was opened in tabbed delimited format, with .fml appended to the end of the filename when applicable. You can compile this file to produce either a 16-bit or 32-bit FML header file. Using the VIEW Table Editor To invoke the VIEW Table Editor, follow these steps:
Figure 3-7 VIEW Table Editor
As shown in the preceding figure, the VIEW Table Editor contains seven columns— CName, FBName, Type, Count, Flag, Size, and Null—and an unlimited number of rows.
You can enter comments in the CName column, as long as the required pound sign (#) is shown at the beginning of each comment. Blank lines are also allowed. When a CName entry is not preceded by a pound sign and is not NULL, the line is assumed to be an active table entry.
The following table describes the purpose of each column in the VIEW Table Editor.
Note: You must specify the following information to denote the start and end of the view information:
VIEW table_name
.
.
.
END
The information must appear in the CName column in a row by itself. You can enter multiple views within the same file, provided that each table entry is preceded by VIEW table_name and followed by END.
You can open new (unnamed) view files in which a blank grid is created for the view, Viewx, where x is a value tracked by the MDI and incremented by one each time you create a new view. You can specify a name if and when you save the view file. You can also edit an existing view file (either text or binary). Unless otherwise specified, files are saved in the directory in which the file was opened in tabbed delimited format, with .v appended to the filename when applicable. You can compile this file to produce either 16- or 32-bit binary VIEW and header files.
Working in Multiple Documents Simultaneously
The MDI, as part of the basic framework, provides a multiple-document architecture in which you can open documents and views, regardless of type, at the same time. Examples of this design are msdev, Excel, and Word. In BEA Tuxedo terms, you can open x number of FML tables and y number of VIEW Table files at any time, and then use any one of them. Each document looks and feels like a workbook that contains tabs for each open document.
How the Editors Validate Entries
The following table describes the information that is validated in each column of the FML Table Editor.
The following table describes the information that is validated in each column of the VIEW Table Editor.
See Also
For information about the BEA Tuxedo ATMI, see the following documents:
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |