Last Revised: 02/04/1998
This document was developed to assist in the deployment of CA Gen 4.1a applications on Windows NT and Windows 95 workstations. Deployment is the process in which an application, built on a workstation using the CA Gen 4.1a toolset, is moved to another workstation on which the CA Gen 4.1a toolset is not installed. In order to accomplish this deployment, CA Gen runtime files, Microsoft's Visual C++ runtime files, and Registry files need to be copied from the toolset workstation to the deployment workstation. The following information specifies these files and their corresponding directory locations.
Required Deployment Files CA Gen GUI Runtime Files: from CA Gen directory to Deployment directory CDCEX.DLL CSUMGN.DLL CSUN.DLL DCEMG.DLL IEFMBT.DLL MGCFBN.DLL MGDCEN.DLL MQCLX.DLL MQSMG.DLL MQSVX.DLL RTTTRC.CNT RTTTRC.DLL RTTTRC.HLP RTTTRC.LIB SDCEX.DLL TRTRACE.TIP WRC410N.DLL WRE410N.DLL WRF410N.DLL WRG410N.DLL WRGUIN.DLL WRL410N.DLL WRU410N.DLL XFCMN.DLL
CA Gen Codepage File: from CA Gen directory to Deployment directory CODEPAGE.INI
CA Gen Type Libraries: from CA Gen directory to Deployment directory WROA0000.TLB WROF0000.TLB
Microsoft Runtime Files: from Windows System directory (NT: winnt/system32 or W95: windows/system)to Windows System directory MSVCRT10.DLL MSVCRT20.DLL (with MSVC++ 2.0, 4.x, 5.0) MSVCRT40.DLL (with MSVC++ 2.0, 4.x, 5.0) MFC40.DLL (with MSVC++ 2.0, 4.x, 5.0) MFC42.DLL (with MSVC++ 5.0) MSVCRT.DLL (with MSVC++ 5.0) MSVCIRT.DLL (with MSVC++ 5.0) OLEPRO32.DLL (with MSVC++ 5.0) OLEAUT32.DLL (with MS Win 95 or Win NT) SSFM1032.DLL (with Cool:Gen 4.x) MSVCRT10.DLL MSVCRT20.DLL (with MSVC++ 2.0, 4.x, 5.0) MSVCRT40.DLL (with MSVC++ 2.0, 4.x, 5.0) MFC40.DLL (with MSVC++ 2.0, 4.x, 5.0) MFC42.DLL (with MSVC++ 5.0) MSVCRT.DLL (with MSVC++ 5.0) MSVCIRT.DLL (with MSVC++ 5.0) OLEPRO32.DLL (with MSVC++ 5.0) OLEAUT32.DLL (with MS Win 95 or Win NT) SSFM1032.DLL (with Cool:Gen 4.x) MSVCRT10.DLL MSVCRT20.DLL (with MSVC++ 2.0, 4.x, 5.0) MSVCRT40.DLL (with MSVC++ 2.0, 4.x, 5.0) MFC40.DLL (with MSVC++ 2.0, 4.x, 5.0) MFC42.DLL (with MSVC++ 5.0) MSVCRT.DLL (with MSVC++ 5.0) MSVCIRT.DLL (with MSVC++ 5.0) OLEPRO32.DLL (with MSVC++ 5.0) OLEAUT32.DLL (with MS Win 95 or Win NT) SSFM1032.DLL (with Cool:Gen 4.x)
Application Files: from <model>/c directory to Deployment directory <load modulename>.EXE <load modulename>.DLL <load modulename>.SST
Support Files: from <model>/c directory to Deployment directory <load modulename>.HLP <load modulename>.DDE
Registration Files: from CA Gen directory to Deployment directory WROAF.REG from <model>/c directory to Deployment directory <load modulename>.REG
Database Support Files: Database System Runtime Files Oracle sql18win.dll INFORMIX isqlt07c.dll SQL Server ntwdblib.dll with dbmssocn.dll (for TCP/IP)
OCX Files: All OCX controls and OLE servers used in the application have to be installed on the Workstation.
Required Registration Procedure File Path Changes: WROAF.REG and <load modulename>.REG are ASCII files containing location information for the type libraries and application respectively. These files must be adopted to the directory structure on the workstation before being used as input to the registry editor. Both the WROAF.REG and the <load modulename>.REG files contain path names that must be changed to indicate the current directory in which the application is deployed. (ie. if the application was deployed to C:\MYAPP then the paths in WROAF.REG and <load modulename>.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)
Microsoft Tools for Registration: regedit.exe regsvr32.exe Note: regsvr32.exe is provided with the Microsoft C++ compiler and may be shipped with the application.
To register the CA Gen type libraries and applications: regedit.exe wroaf.reg regedit.exe <load modulename>.reg To register the CA Gen OLE server functionality use: regsvr32.exe WRU410N.dll regsvr32.exe OLEPRO32.dll To register the Microsoft Foundation Class use: regsvr32.exe MFC40.dll regsvr32.exe MFC42.dll To register the Sheridan Date Format Functions use: regsvr32.exe SSFM1032.dll To register the OCX controls use: regsvr32.exe <controlfilename>.OCX
Note: If the registration fails due to missing license information, the original installation procedure of the OCX supplier will have to be used.
Required Installation of Support Applications Any applications that have been used to create the contents of an OLE AREA must be installed on the deployment target to get in-place or out-of-place activation. For example, if an Excel spreadsheet is placed in an OLE AREA, on a window, then Excel would have to be installed on the deployment target to activate and edit the OLE AREA contents.
Last Revised: 09/25/1998
This document was developed to assist in the deployment of CA Gen 5 applications on Windows NT and Windows 95 workstations. Deployment is the process in which an application, built on a workstation using the CA Gen 5 toolset, is moved to another workstation on which the CA Gen 5 toolset is not installed. In order to accomplish this deployment, CA Gen runtime files, Microsoft runtime files, and Registry files need to be copied from the toolset workstation to the deployment workstation.
This article contains information on two procedures, the recommended deployment procedure that uses the Cool:Gen 5 Installation CD and a alternate manual procedure. The recommended procedure for deploying the GUI Runtime, Client Manager and Communications Middleware is to use the installation CD on each deployment workstation. We recognize this may not be practical for a large number of workstations. The following is the alternate manual procedure.
The deployment Windows 95 and Windows NT workstations should have the same or later Service Pack as the toolset workstation. Windows 95 files must be deployed only on Windows 95 clients and Windows NT files must be deployed only on Windows NT clients.
Support Files: The support files require one deployment per workstation.
Microsoft Runtime Files for Remote Data Applications (RDA) or Distributed Process Clients (DPC): copy from Windows System directory (NT: winnt/system32 or W95: windows/system) to Windows System directory
ALT.DLL MFC40.DLL MFC42.DLL MSVCIRT.DLL MSVCRT.DLL MSVCRT20.DLL MSVCRT40.DLL SFTTV32.DLL
CA Gen GUI Runtime Files for RDA: copy from CA Gen directory to Deployment directory
CCMIDX.DLL RTTTRC.DLL CDCEX.DLL RTTTRC.LIB CENCX.DLL RTTTRC.CNT CENCX.LIB RTTTRC.HLP CIENCBH.H SDCEX.DLL CODEPAGE.INI SSREGS32.EXE CSU50N.DLL TRSERVER.EXE CSUMG50N.DLL TRTRACE.TIP CTUXWSXN.DLL TUXMG.DLL CTUXXN.DLL WRC500N.DLL DCEMG.DLL WRE500N.DLL ENCMG.DLL WRF500N.DLL IEFMBT.DLL WRG500N.DLL MGCFBN.DLL WRGUIN.DLL MGDCEN.DLL WRL500N.DLL MGTUXN.DLL WROA0000.TLB MQCLX.DLL WROAF.REG MQSMG.DLL WROF0000.TLB MQSVX.DLL WRU500N.DLL NETTRACE.HLP XFCMN.DLL OLEPRO32.DLL
register files
WROAF.REG is an ASCII file containing location information for the type libraries. It contains path names that must be changed to indicate the current directory in which the typelib is deployed. (ie. if the typelib was deployed to C:\MYAPP then the paths in WROAF.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)
regedit.exe wroaf.reg ssregs32.exe WRU500N.DLL
Database Support Files for RDA: The client software from the database vendor must be installed for connectivity to the database server.
CA Gen Client Manager Files for DPC: copy from CA Gen directory to Deployment directory
BROWS50N.EXE IOTCP50N.DLL CCMIDX.DLL MGCFBN.DLL CDCEX.DLL MGDCEN.DLL CENCX.DLL MGTUXN.DLL CENCX.LIB MQCLX.DLL CIDE50N.DLL MQSMG.DLL CIENCBH.H MQSVX.DLL CIF50N.DLL NETTRACE.HLP CMMSG50N.DLL OLEPRO32.DLL CODEPAGE.INI RTTTRC.DLL CSU50N.DLL RTTTRC.LIB CSUMG50N.DLL RTTTRC.CNT CTUXWSXN.DLL RTTTRC.HLP CTUXXN.DLL SDCEX.DLL DCEMG.DLL SSREGS32.EXE DECRE50N.DLL TRSERVER.EXE ENCMG.DLL TRTRACE.TIP IEFCM50N.HLP TUXMG.DLL IEFCM50N.EXE WRC500N.DLL IEFCM50N.ICO WRE500N.DLL IEFCM50N.DLL WRF500N.DLL IEFCMN.INI WRG500N.DLL IEFCMN.SRV WRGUIN.DLL IEFMBT.DLL WRL500N.DLL IO6250N.DLL WROA0000.TLB IONB50N.DLL WROAF.REG IOPP50N.DLL WROF0000.TLB IORSC50N.DLL WRU500N.DLL IORSC50N.LIB XFCMN.DLL
register files
WROAF.REG is an ASCII file containing location information for the type libraries. It contains path names that must be changed to indicate the current directory in which the typelib is deployed. (ie. if the typelib was deployed to C:\MYAPP then the paths in WROAF.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)
regedit.exe wroaf.reg ssregs32.exe WRU500N.DLL
Communications Middleware Files for DPC: copy from CA Gen directory to Deployment directory
xfdcen.dll DCE xfmqin.dll MQSeries xfmqsn.dll MQSeries xfencn.dll Encina xftuxn.dll Tuxedo xftuxwsn.dll Tuxedo
The client software from the communications middleware vendor must be installed for connectivity to the server.
Application Files:Each application requires one deployment per workstation.
Executable and Support Files: copy from <model>/c directory to Deployment directory
<load modulename>.EXE
*.DLL  all DLLs
<load modulename>.SST
<load modulename>.HLP
<load modulename>.DDE
<load modulename>.REG
<load modulename>.REG is an ASCII files containing location information for the application. It contains path names that must be changed to indicate the current directory in which the application is deployed. (ie. if the application was deployed to C:\MYAPP then the paths in <load modulename>.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)
regedit.exe <load modulename>.reg
OCX / OLE Files: All OCX controls and OLE servers used in the application have to be installed on the Workstation. Each requires one deployment per workstation. Refer to the installation instructions from the OCX supplier.
copy from Windows System directory (NT: winnt/system32 or W95: windows/system) to Windows System directory
OLEAUT32.DLL OLEPRO32.DLL
register files
ssregs32.exe OLEPRO32.DLL
Support Application Files:
Any applications that have been used to create the contents of an OLE AREA must be installed on the deployment target to get in-place or out-of-place activation. For example, if an Excel spreadsheet is placed in an OLE AREA on a window, then Excel would have to be installed on the deployment target to activate and edit the OLE AREA contents.
Andy Hebert
This document was developed to assist in the deployment of CA Gen 5.1 applications on Windows NT, Windows 95 & Windows 98 workstations. Deployment is the process in which an application, built on a workstation using the CA Gen 5.1 toolset, is moved to another workstation on which the CA Gen 5.1 toolset is not installed. In order to accomplish this deployment, CA Gen and Microsoft runtime files need to moved to the deployment workstation and the registry on the deployment workstation updated.
The recommended deployment procedure is to use the CA Gen 5.1 Installation CD to install the GUI Runtime, Client Manager and Communications Middleware. We recognize this may not be practical for a large number of workstations. The following is the alternate manual procedure.
NOTE: The deployment workstation should have the same service pack installed as the toolset workstation. Windows NT files must be deployed only on Windows NT clients, Windows 95 files must be deployed only on Windows 95 clients and Windows 98 files must be deployed only on Windows 98 clients.
Support Files:The support files require one deployment per workstation. Some files are listed in multiple packages depending on the options installed.
Microsoft Runtime Files for Remote Data Applications (RDA) or Distributed Process Clients (DPC): Copy from Windows System directory (NT: winnt/system32 or W95/W98: windows/system) to Windows System directory
ATL.DLL CSEINST.DLL COMCTL32.DLL MFC40.DLL MFC42.DLL MSVCIRT.DLL MSVCRT.DLL MSVCRT40.DLL OLEPRO32.DLL ROBOEX32.DLL SFTTV32.DLL
CA Gen GUI Runtime Files for RDA: Copy from CA Gen directory to deployment directory
CFBMO51N.DLL CMCF51N.DLL CMICX51N.DLL CODEPAGE.INI CSU51N.DLL CSUMG51N.DLL CSUVN51N.DLL IEFMBT.DLL OLEPRO32.DLL RTTTRC.CNT RTTTRC.DLL RTTTRC.HLP RTTTRC.LIB TRSERVER.EXE TRTRACE.TIP WRC510N.DLL WRE510N.DLL WRF510N.DLL WRG510N.DLL WRGUIN.DLL WRL510N.DLL WROA0000.TLB WROAF.REG WROF0000.TLB WRU510N.DLL
Register files
WROAF.REG is an ASCII file containing location information for the type libraries. It contains path names that must be changed to indicate the current directory in which the typelib is deployed. (ie. if the typelib was deployed to C:\MYAPP then the paths in WROAF.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)
regedit.exe wroaf.reg regsvr32.exe WRU510N.DLL
Database Support Files for RDA: The client software from the database vendor must be installed for connectivity to the database server.
CA Gen Client Manager Files for DPC: Copy from CA Gen directory to deployment directory
BROWS51N.EXE CFBMO51N.DLL CIDE51N.DLL CIF51N.DLL CMCF51N.DLL CMICX51N.DLL CMMSG51N.DLL CODEPAGE.INI CSU51N.DLL CSUMG51N.DLL CSUVN51N.DLL DECRE51N.DLL IEFCM51N.DLL IEFCM51N.EXE IEFCM51N.HLP IEFCM51N.ICO IEFCMN.INI IEFCMN.SRV IEFMBT.DLL IO6251N.DLL IONB51N.DLL IOPP51N.DLL IORSC51N.DLL IORSC51N.LIB IOTCP51N.DLL OLEPRO32.DLL RTTTRC.CNT RTTTRC.DLL RTTTRC.HLP RTTTRC.LIB TRSERVER.EXE TRTRACE.TIP WRC510N.DLL WRE510N.DLL WRF510N.DLL WRG510N.DLL WRGUIN.DLL WRL510N.DLL WROA0000.TLB WROAF.REG WROF0000.TLB WRU510N.DLL
Register files
WROAF.REG is an ASCII file containing location information for the type libraries. It contains path names that must be changed to indicate the current directory in which the typelib is deployed. (ie. if the typelib was deployed to C:\MYAPP then the paths in WROAF.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)
regedit.exe wroaf.reg
regsvr32.exe WRU510N.DLL
Communications Middleware Files for DPC: Copy from CA Gen directory to deployment directory
DCE DCECF51N.DLL DCECX51N.DLL DCEMG51N.DLL DCEMO51N.DLL DCESX51N.DLL
MQ Series CFBMO51N.DLL MQICF51N.DLL MQSCF51N.DLL MQSCX51N.DLL MQSMG51N.DLL MQSSX51N.DLL
ENCINA DCEMO51N.DLL ENCCF51N.DLL ENCCX51N.DLL ENCMG51N.DLL ENSCF51N.DLL ENSCX51N.DLL ENSSX51N.DLL PPCCF51N.DLL PPCCX51N.DLL PPCMG51N.DLL
TUXEDO TXWCF51N.DLL TXCF51N.DLL TXCX51N.DLL TXWCX51N.DLL TXMG51N.DLL TXMO51N.DLL
TCP CFBMO51N.DLL TCPCF51N.DLL TCPCX51N.DLL TCPMG51N.DLL
The client software from the communications middleware vendor must be installed for connectivity to the server.
Application Files: Each application requires one deployment per workstation.
Executable and Support Files: Copy from <model>/c directory to deployment directory
<load modulename>.EXE
<load modulename>.DLL  all DLLs
CASCADE.DLL
<load modulename>.HLP
<load modulename>.DDE
<load modulename>.REG
Register files
<load modulename>.REG is an ASCII files containing location information for the application. It contains path names that must be changed to indicate the current directory in which the application is deployed. (ie. if the application was deployed to C:\MYAPP then the paths in <load modulename>.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)
regedit.exe <load modulename>.reg
OCX / OLE Files: All OCX controls and OLE servers used in the application have to be installed on the Workstation. Each requires one deployment per workstation. Refer to the installation instructions from the OCX supplier.
Copy from Windows System directory (NT: winnt/system32 or W95/W98: windows/system) to Windows System directory
OLEAUT32.DLL OLEPRO32.DLL
Register files
regsvr32.exe OLEPRO32.DLL
Support Application Files:
Any applications that have been used to create the contents of an OLE AREA must be installed on the deployment target to get in-place or out-of-place activation. For example, if an Excel spreadsheet is placed in an OLE AREA on a window, then Excel would have to be installed on the deployment target to activate and edit the OLE AREA contents.
Last Revised: 03/28/2000
This document was developed to assist in the manual deployment of CA Gen 5.1 Web Client applications. Deployment is the process in which a client application, built on a workstation using the Cool:Gen 5.1 toolset or CSE in conjunction with the Build Tool, is moved to a target execution environment in which CA Gen is not installed. For web clients, the target execution environment is a web server machine. In order to accomplish this deployment, CA Gen and Microsoft runtime files must be manually copied to specific locations on the web server machine. Additionally, the registry of the web server machine must be updated.
To avoid errors associated with manual processes, the recommended deployment procedure is to use the CA Gen 5.1 Installation CD to install the TCP/IP or MQSeries runtime, the CA Gen 5.1 Service Pack 1 CD to install the Web Client Enablement runtime, and the Build Tool to deploy the application to the web server. The Cool:Gen 5.1 Build Tool has been enhanced with new target configuration tokens to automate the deployment of the web server application.
NOTE: The deployment machine should have the same MS Windows service pack as the Cool:Gen toolset workstation. It is also assumed the web server machine is already configured with the required supporting software (i.e. web server and Java servlet engine). Please consult the CA Gen 5.1 Service Pack 1 Technical Requirements for specific product version information.
In order to provide examples in the instructions below, we will assume the web server’s home (default) document directory is c:\inetpub\wwwroot. Modify these instructions according to the document directory structure on your web server machine.
A new directory should be created on the web server machine to hold your application and Cool:Gen runtime files. For our examples, we will use c:\myapp.
Web Server Document Directory Structure
The CA Gen web client application expects to operate in a specific directory structure within your web server’s home document directory.
• In the web server’s home document directory (c:\inetpub\wwwroot), create a new subdirectory using the model’s short name, like c:\inetpub\wwwroot\model
• With the new model subdirectory, create two new subdirectories called “data” and “bitmap”, like c:\inetpub\wwwroot\model\data and c:\inetpub\wwwroot\model\bitmap
• Your directory structure should now look something like
 inetpub ï€ ï€ ï€° wwwroot ï€ ï€ ï€ ï€ ï€° <model short name> ï€ ï€ ï€ ï€ ï€ ï€ ï€° bitmap ï€ ï€ ï€ ï€ ï€ ï€ ï€° data
Supporting Files
Microsoft Runtime Files for Web Client Enablement Clients Copy from Windows System directory to Windows System directory (winnt/system32)
COMCTL32.DLL MFC42.DLL MSVCIRT.DLL MSVCRT.DLL OLEPRO32.DLL
CA Gen Web Client Enablement Runtime Files Copy from CA Gen directory to deployment directory (c:\myapp)
CFBMO51N.DLL CMCF51N.DLL CMICX51N.DLL CODEPAGE.INI COMMCFG.INI CSU51N.DLL CSUMG51N.DLL CSUVN51N.DLL ICG510N.DLL ICF510N.DLL ICE510N.DLL ICU510N.DLL ICL510N.DLL IEFMBT.DLL NETTRACE.HLP OLEPRO32.DLL RTTTIC.DLL RTTTIC.HLP RTTTIC.LIB RTTTRC.CNT RTTTRC.DLL RTTTRC.HLP RTTTRC.LIB SRVLTRT510N.DLL TRSERVER.EXE TRTRACE.TIP WRC510N.DLL WRGUIN.DLL WROA0000.TLB WROAF.REG WROF0000.TLB
Register files
WROAF.REG is an ASCII file containing location information for the Cool:Gen type libraries (WROA0000.TLB and WROF0000.TLB). It contains path names that must be changed to indicate the current directory in which the typelibs are deployed. (In other words, if the typelibs are deployed to C:\MYAPP then the paths in WROAF.REG should be changed to C:\MYAPP instead of the default, which is C:\IEF.) Register the supporting runtimes from the command line with
regedit.exe wroaf.reg regsvr32.exe ICU510N.DLL
Communications Middleware Files for Web Client Enablement Clients Copy from CA Gen directory to deployment directory (c:\myapp)
MQ Series CFBMO51N.DLL MQICF51N.DLL MQSCF51N.DLL MQSCX51N.DLL MQSMG51N.DLL MQSSX51N.DLL
TCP CFBMO51N.DLL TCPCF51N.DLL TCPCX51N.DLL TCPMG51N.DLL
Supporting Files
• Configure client/server communications
The CA Gen client runtime must know how to communicate with the CA Gen application servers. One method is to configure communications parameters before code generation, using the Cool:Gen toolset. This method “hard-codes” the communication parameters into the generated application.
Another method is to use the runtime file commcfg.ini, already copied to your C:\MYAPP directory (see previous section “CA Gen Web Client Enablement Runtime Files”). See “Configuring Web Client Enablement Communications” in the Web Client Enablement Handbook for details on customizing this file.
If using MQ Series, the MQ client software from IBM must be installed and configured for connection to the application server.
Application Files Copy from <model>/html directory on the development machine to web server’s home document directory (c:\inetpub\wwwroot)
*.shtml
Copy from Cool:Gen directory on the development machine to web server’s home document directory (c:\inetpub\wwwroot)
COOLGen_Default.html COOLGen_End.html COOLGen_History.js COOLGen_Make.js COOLGen_pageDn.gif COOLGen_pageLt.gif COOLGen_pageRt.gif COOLGen_pageUp.gif COOLGen_rowDn.gif COOLGen_rowLt.gif COOLGen_rowRt.gif COOLGen_rowUp.gif
Copy from <model>/html directory on the development machine to the new model document directory (c:\inetpub\wwwroot\model)
*.html *.js *.css
Copy from Cool:Gen directory on the development machine to the new model document directory (c:\inetpub\wwwroot\model)
purge.properties
Copy from <model>/bitmap directory on the development machine to the new model bitmap directory (c:\inetpub\wwwroot\model\bitmap)
*.jpg *.gif *.png
Copy from <model>/servlet directory on the development machine to the servlet engine’s servlet home (like c:\jrun\servlets)
*.class
Application Files Copy from <model>/c++ directory on the development machine to deployment directory (c:\myapp)
Copy from Cool:Gen directory on the development machine to deployment directory (c:\myapp)
runtimesupport.jar
Validation.jar
Register files
<load modulename>.REG is an ASCII files containing location information for the web client application. It contains a path name that must be changed to indicate the current directory in which the application is deployed. (In other words, if the application is deployed to C:\MYAPP then the path in <load modulename>.REG should be changed to C:\MYAPP.) Register the application runtimes from the command line with
regedit.exe <load modulename>.reg
Configure environment
Add the following to the System Classpath on the deployment machine: c:\myapp\runtimesupport.jar;c:\myapp\Validation.jar
Add c:\myapp to the System Path on the deployment machine.
Add the following to the servlet engine’s classpath (within Jrun Administrator): c:\myapp\runtimesupport.jar;c:\myapp\Validation.jar
Sample Resulting Web Server Directory Structure
 winnt   system32   … <Microsoft supporting runtime files>  inetpub   wwwroot    <model short name>     bitmap     *.jpq     *.gif     *.png    *.HTML    *.JS    *.CSS    purge.properties   *.SHTML   COOLGen_Default.html   COOLGen_End.html   COOLGen_History.js   COOLGen_Make.js   COOLGen_pageDn.gif   COOLGen_pageLt.gif   COOLGen_pageRt.gif   COOLGen_pageUp.gif   COOLGen_rowDn.gif   COOLGen_rowLt.gif   COOLGen_rowRt.gif   COOLGen_rowUp.gif  jrun   servlets   *.class  myapp  *.dll  *.reg  runtimesupport.jar  Validation.jar  … <Cool:Gen supporting runtime files>
Alan D. Bartholomew Consultant
For most simple cases, you can find the SQL generated by CA Gen by simply searching through your generated C program (i.e. the .sqc file) looking for “EXEC SQL” until you come across the SQL. If the program is more complex with many READ/READ EACH statements then you can use the following method to make sure you are getting to exactly the right SQL statement.
1. Find the action diagram documented as comments in the C program using the following by doing a “find” on “procedure statements.”
Here’s a very simple example of what you’ll find:
/* +→ JAMES 04/06/00 23:19 */ /* ! ENTITY ACTIONS: */ /* ! Entity View p allan */ /* ! id_number */ /* ! */ /* ! PROCEDURE STATEMENTS */ /* ! */ /* 1 ! +⇒READ p allan */ /* 1 ! +> WHEN successful */ /* 1 ! +> WHEN not found */ /* 1 ! +– */ /* +— */
2. Find a key word that will get you to the SQL by doing a “find” on the statement number of the READ statement in the action diagram. CA Gen generates a 10-digit statement number.
num =”nnnnnnnnnn”
For the example above, do a find on:
num = “0000000001”
Here’s a very simple example of what you’ll find:
globdata→psmgr_debug_data.last_statement_num = “0000000001”; f_28();
3. Find the SQL by using the key word on the line below the one you just found.
nnnn(void)
For the example above, do a find on:
f_28(void)
Here’s a very simple example of what you’ll find:
EXEC SQL DECLARE CUR_0000001007_1 CURSOR FOR
SELECT
ALLAN01.ID_NUMBER
FROM
ALLAN ALLAN01
;
static void f_28(void)
NOTE: The SQL is above the line you just found.
1. Find the statement number or the READ EACH you are trying to look for (in this case 15).
15* ! +=>READ EACH (Cursor Hold) p applicant
15* ! ! p appliant_grade
15* ! ! p vacancy_announcement_grade
15* ! ! p vacancy_announcement
15* ! ! SORTED BY ASCENDING p applicant last_name
15* ! ! AND SORTED BY ASCENDING p applicant first_name
15* ! ! AND SORTED BY ASCENDING p applicant middle_name
15* ! ! AND SORTED BY ASCENDING p applicant
2. Do a “find/ Refind” using the 10 digit statement number found above 0000000015. The figure below should be what you are looking for.
COMPUTE LAST-STATEMENT-NUM = 0000000015
MOVE ‘N’ TO READ-EACH-0043647041-ESC-FLAG
PERFORM PARA-0023461916-OPEN THRU PARA-0023461916-OPEN-EXIT
IF SL-23461916 NOT = SUCCEEDS
READ
1.
COMPUTE LAST-STATEMENT-NUM = 0000000012
PERFORM PARA-0000000000-TRACE THRU
PARA-0000000000-TRACE-EXIT
IF TRACE-RET-CD NOT = 8
PERFORM PARA-0158351222 THRU PARA 0158351222-EXIT
EVALUATE SL-158351222
2.
MOVE SUCCEEDS TO SL-23461916 the SQL should be above this.
Sam Glaser Computer Associates, Principal Consultant
In an NT environment, it is possible to register the transaction enabler as an NT Services. This eliminates the need to bring up the funnel and daemon manually each time the server is booted. The registration is done by executing the regte command, followed by the appropriate parameters. In order to get a listing of the parameters, type ‘regte ?’ at a command prompt.
Although it is not specified in the window above, all seven parameters must be separated by a space. The only one of the parameters that you might not recognize is 'instance' - in most cases that is '1' - you are only running one instance per box. To complete the registration process, the developer can
use a command prompt. Type regte 4.11 1 c:\coolgen ……..) or go to start … run and type (coolgen path)\regte 4.11 1 …….)
Both methods will complete the registration process. If you do this on your box, you will see two new entries under NT Services: TE-AD-4.11-1 (asynchronous daemon) and TE-UF-4.11-1 (user funnel). You do not need to reboot after the 'regte' is run. To make this technique more useful, go into the Control Panel… Services and change the startup type of each new entry to automatic. This way, the funnel and daemon start up when the machine is booted.
“Here's one that always annoys me:”
If you've set up the TE on your workstation as services and you start and stop them from the services applet you may want to create a dependency between the funnel and daemon. To do this you need to go into the registry. Be VERY careful. Run regedt32 and go to the HKEY_LOCAL_MACHINE hive (like a folder). Expand to SYSTEM\CurrentControlSet\Services. Look for the user funnel service (something like TE-UF-4.11-1) and select it. You'll want to put the dependency on the funnel which states that when the daemon is stopped also stop the funnel and when the funnel is started also start the daemon. To do this using regedt32:
Select the line for the funnel
Select the menu option Edit and Add Value
Enter in the name “DependOnService” without the quotes, leave the data type as REG_SZ and select OK
Doubleclick on the new entry in the right panel and enter in the value for the daemon as it appears in the key (ex. TE-AD-4.11-1) and select OK
The next time you reboot the dependency will be there.
If you happen to be using regedit instead:
Select the line for the funnel
Select the menu option Edit, New and String Value
Enter in the name “DependOnService” without the quotes in the New Value entry in the right panel
Doubleclick on the new entry in the right panel and enter in the value for the daemon as it appears in the key (ex. TE-AD-4.11-1) in the Value data field and select OK
BP Data is unusable because it does not match the permitted values for the field. This is detected before a database access and is always followed by message 40.
BT Non-numeric data was detected in a numeric field before a database access. This is always
followed by message 45.
CT When the Enforce Data Modeling Constraints option is selected for code generation, checks are generated to ensure that whenever a row is added to the database, all mandatory relationships are created as well. These checks are generated at the exit from the action block that includes the CREATE verb. If any mandatory relationship is missing, the transaction is aborted, and the CT code is set.
DB An error was encountered in the SQL statements. The SQL code and supporting information follows this message.
In a READ qualified by a WHERE clause that uses CURRENT OF views, the view that should be CURRENT has not been read, or has gone out of scope.
A view for an UPDATE has not been populated and locked.
An action block that uses a persistent view was called without the view being populated, and the action block attempted to use the view in a READ, UPDATE, ASSOCIATE, DISASSOCIATE or TRANSFER. One or more of the views in an ASSOCIATE or TRANSFER statement has not been populated
ME When the Enforce Data Modeling Constraints option is selected for code generation, checks are generated to assure that mutually exclusive relationships do not exist in the database. If the constraint is violated, the ME code is set, and the transaction aborts. The generated code ensures that no ASSOCIATE action violates a defined mutually exclusive constraint. If any one member of the mutually exclusive set exists, none of the other members are allowed to exist. The following example illustrates this: A is related to B and to C in a mutually exclusive set. An action block reads A and attempts to ASSOCIATE it to B.
MU Mutually exclusive relationships were found to exist in the database after an ASSOCIATE or TRANSFER. This is only detected if “Enforce Data Modeling Constraints” was selected as a generation option.
OO When the Enforce Data Modeling Constraints option is selected for code generation, checks are generated to enforce one-to-one relationships. If this constraint is violated, the OO code is set, and the transaction aborts. Both ends of the relationship are checked before an ASSOCIATE is permitted. This prevents the foreign keys of several different rows from pointing to the same related row.
Q1, Q2, Q3, Q4 This series of status codes indicates an internal processing error. The error can be caused by several conditions, such as a request for more memory which could not be fulfilled, or so many cascade deletes that the processing could not handle them. Contact support if you receive any of these status codes. Further research will be required to pinpoint the exact cause of the internal processing error.
QD When the Enforce Data Modeling Constraints option is selected for code generation, checks are generated to prevent quiet disassociations. If this constraint is violated, the QD code is set, and the transaction aborts. This constraint concerns the effect of overlaying the value in a foreign key when an ASSOCIATE action is applied to a one-to-many relationship. If the foreign key is populated and no cascade delete logic is performed, the effect is the same as a DISASSOCIATE action. This is called a quiet disassociation because it executes without performing any database integrity checks. The generated code ensures that before an ASSOCIATE action is performed the attribute on which the foreign key is based is null. If not, the association requested must match the one that already exists. The association is said to exist if the value of the foreign key equals the value of the attribute on which it is based. If the foreign key is not null and also not the same value as the requested key, the transaction fails.
RE An error was encountered in the processing of a DELETE or DISASSOCIATE statement. Database referential integrity would be compromised if the statement was permitted.
In a READ qualified by a WHERE clause that uses CURRENT OF views, the view that should be CURRENT has not been read, or has gone out of scope.
A view for an UPDATE has not been populated and locked.
An action block that uses a persistent view was called without the view being populated, and the action block attempted to use the view in a READ, UPDATE, ASSOCIATE, DISASSOCIATE or TRANSFER.
One or more of the views in an ASSOCIATE or TRANSFER statement has not been populated
Lawrence Joseph Barreca USDA National Finance Center, Computer Specialist (Programmer Analyst)
There are many reasons for an -805 DB2 error message. This give a couple of examples on how to research the more common reasons for the error.
Example 1 - DBRM member not bound to the DB2 collection
You just received the error message below (Figure 1). In this first example the error message shows a DBRM token 167B2F34195D9880 for action block PDA_3108U_HOLD_REQUEST. This is the version of the DBRM that is linked into load module PD25. At generation time, CA Gen will generate a DBRM and an NCAL member with the name PDA3108 for this example. The NCAL member is linked into the load module using the PDA3108 action block. The PDA3108 DBRM module is bound to the DB2 collection for this application. For this example the collection id is PODSCCAUDB90.
Our next step is to view the token (Figure 2) in the DB2 package for this member. In this example, we used Platinum tools to view the CONTOKEN for the DBRM. The token in the DB2 packaging shows 1674C76801ED11C8 which, of course, is different from the above.
We can now verify the token in the DBRM that was generated by CA Gen (Figure 3). This can be found by browsing the generated DBRM member. Then display Hexadecimal characters (Command ==⇒ hex on) and turn columns on (Command ==⇒ Cols). In column 25 of the first line is the token for the DBRM module. If this member was used in the DB2 bind, then the token here should match the token in the DB2 packaging.
Conclusion: The error message (Figure 1) shows token 167B2F34195D9880 and it matches the token in the generated DBRM (Figure 3) but does not match the token from the packaging in the DB2 database (Figure 2). Run a bind for the PDA3108 member to the appropriate collection id and the problem is solved. In this example the appropriate collection id is PODSCCAUDB90 shown in Figure 1.
Example 2 - Shared Action Blocks
Ok, you have a load module that worked perfectly ten minutes ago and now you are getting the error message below (Figure 4). In this example the error message shows a DBRM token 167D013A1E2C14F0 for action block PDA3304. This is the version of the DBRM that is linked into load module PD50.
Our next step is to view the token in the DB2 package for this member. The token in the DB2 packaging shows 167B52ED091E53BC (Figure 5) which, of course, is different from the above.
We can now verify the token in the DBRM that was generated by CA Gen (Figure 6). This can be found by browsing the generated DBRM member. Then display Hexadecimal characters (Command ==⇒ hex on) and turn columns on (Command ==⇒ Cols). In column 25 of the first line is the token for the DBRM module. If this member was used in the DB2 bind, then the token here should match the token in the DB2 packaging.
Conclusion: The error message (Figure 4) shows token 167D013A1E2C14F0 and it does not match the token in the generated DBRM (Figure 6) or the token from the packaging in the DB2 database (Figure 5). However, we see that the token in Figure 5 and Figure 6 are the same. This is the result of someone generating a new PDA3304, that is shared among multiple load modules, and binding the PDA3304 DBRM to the DB2 database. Run an install for load module PD50 to link in the latest version of PDA3304 and the problem is solved.
Some of the problem encountered in CA Gen, may it be development time or runtime, may be resolved by following the steps below.
1. Run a consistency check report
The consistency check report tells you if you have any errors in your code. Warnings are okay they will not stop you from generating code, nor give you problems during runtime. Errors are what you have to watch out for.
To run the report:
From the Options menu in the main CA Gen window, select Consistency Check Level and decipher the appropriate level.
In either Analysis or Design menu items, depending on your development phase, Select Check.
2. Browse through the CA Gen toolset Help menu for runtime error codes
The CA Gen toolset Help is very helpful when figuring out runtime error codes. They have a list of error codes that you can look up by categories. Please see figure below.
3. Visit Linkfaqs at http://cool2.sterling.com/support/cses1.htm
Chances are your error has already been encountered by someone else. Linkfaqs is an inquiry system that lets you type in keywords to search for a particular issue. It displays tickets and issues associated with the retrieved data. This is also helpful in finding out if you need to apply PTFs (Program Temporary Fixes) to solve your particular problem.
If you have a file (model, checkout.trn, etc.) that you want to send, the File Upload option on this page is very useful.
In order to use Linkfaqs, you must register on-line. It takes about 2 to 3 days to obtain your password.
4. Call customer support 1.800.246.5151.
Finally when all else fails, give the experts a call. They have a more complete list of problem tickets reported than linkfaqs. They also have staff that can address your problems and even recreate it.
<!-- wikipage stop -->