Tips and Tricks Guide

COOL:GEN DEVELOPERS TIPS AND TRICKS
Scott D. Lanouette & Allan James G. Rubio
The palest ink is better than the best memory
GETTING TO KNOW GEN................................................................................................................................. 7 NUMBER 1 TIPSAVE OFTEN! ................................................................................................................................9 COOL:GEN MODEL DIRECTORY STRUCTURE.......................................................................................................10 IMPORTANT MODEL FILES......................................................................................................................................11 DATA FILES 11 TRANSACTION FILES 12 PDX FILES 13 DNX FILES 13 MODEL INFORMATION.............................................................................................................................................13 MODEL REPORTS.....................................................................................................................................................14 COOL:GEN MODEL PATHS......................................................................................................................................15 WINDOW DESIGN TIPS.................................................................................................................................... 17 FIELD DESIGN LIST..................................................................................................................................................19 SPECIAL ACTIONS FOR MENU ITEMS.....................................................................................................................20 GETTING RID OF HELP AND WINDOW MENU ITEMS ...........................................................................................21 RESIZING LISTBOX COLUMNS.................................................................................................................................21 THE SELECTION CHARACTER.................................................................................................................................22 WINDOW MAPPING..................................................................................................................................................24 SPECIFYING COMMANDS.........................................................................................................................................25 IMPORTING BITMAPS TO THE MODEL DIRECTORY...............................................................................................27 DIFFERENT BITMAP STATES....................................................................................................................................28 VIDEO PROPERTIES..................................................................................................................................................29 POSITIONING WINDOW OBJECTS............................................................................................................................29 TABBING SEQUENCE................................................................................................................................................31 DESIGNING WITH GRID ON OR OFF........................................................................................................................31 RABBIT TESTOOPS, RAPID TEST........................................................................................................................32 ACTION DIAGRAMMING TIPS...................................................................................................................... 35 OPEN WINDOW LIST PUSH BUTTON.......................................................................................................................37 ACTION BLOCK SYNTHESIS.....................................................................................................................................37 TIREVENT..............................................................................................................................................................38 ADDING OBJECTS COMMON TO A BUSINESS SYSTEM...........................................................................................40 CAN I USE THIS FUNCTION?....................................................................................................................................41 DETERMINE WHERE AN ACTION BLOCK IS USED..................................................................................................41 VIEW MATCHING: DATA PASSING..........................................................................................................................42 VIEW NEIGHBORS....................................................................................................................................................44 READ EACH PROPERTIES.....................................................................................................................................44 DOUBLE-CLICK OF BRACKETS IN AN ACTION DIAGRAM......................................................................................45 KEYPRESS EVENT.....................................................................................................................................................45 CHANGED EVENT.....................................................................................................................................................46 CUSTOMIZING THE POP-UP MENU(S).....................................................................................................................47 SINGLE ADD VS. MULTIPLE ADD............................................................................................................................48 CONVERTING NUMBER TO TEXT AND TEXT TO NUMBER.....................................................................................48
EVENT LOCATOR.....................................................................................................................................................48 DIALOG FLOW DESIGN............................................................................................................................................50 OTHER TIPS..............................................................................................................................................................51 CLIENT DEPLOYMENT TOPICS.................................................................................................................... 53 DEPLOYMENT ARCHITECTURE................................................................................................................................55 DEFAULTW.ICO 56 BUILD TOOL PARAMETERS: THE WIN32ITM.TGT FILE 56 DIALOG FLOW TRANCODE AND CLEAR SCREEN TRANCODE 57 EXPAND ALL VIEWS 59 REGISTRATION OF COOL:GEN FUNCTIONS............................................................................................................61 INSIDE THE WROAF.REG FILE..................................................................................................................................61 HOW TO CHECK WHATS REGISTERED.................................................................................................................61 WHAT TO DO WHEN USING OLE/OCX CONTROLS.............................................................................................62 TIMESTAMP OF LOAD MODULE EXECUTABLES.....................................................................................................63 ASSOCIATING AN EAB STUB WITH THE DESIRED EXTERNAL CODE...................................................................64 IMPORTANT FILES TO DEPLOY AFTER GENERATION...........................................................................................64 INSIDE THE LOAD MODULE.REG FILE....................................................................................................................65 SUBSETTING TOPICS....................................................................................................................................... 67 NON-SEAMLESS CHECKOUT....................................................................................................................................69 CHECKOUT SUBSET..................................................................................................................................................70 UPDATE WITH OR WITHOUT CHECKIN..................................................................................................................71 RESEND LAST UPDATE.............................................................................................................................................72 VERIFY LAST UPDATE.............................................................................................................................................73 COMPARING UPDATE VS. RESEND VS. VERIFY......................................................................................................74 GENERATE NEW MODEL.........................................................................................................................................75 CONCURRENCY MATRIX..........................................................................................................................................76 PROTECTION CONFLICT TABLE..............................................................................................................................77 WHERE TO GET HELP..................................................................................................................................... 79 FUNCTION KEY F1...................................................................................................................................................81 ELECTRONIC BOOKS / INFORMATION BASE...........................................................................................................82 TECHNICAL LIBRARY...............................................................................................................................................83 APPENDIX........................................................................................................................................................... 85 DEPLOYMENT OF COOL:GEN 4.1A APPLICATIONS ON WINDOWS NT AND WINDOWS 95..................................87 DEPLOYMENT OF COOL:GEN 5 CLIENT APPLICATIONS ON WINDOWS NT AND WINDOWS 95.........................91 DEPLOYMENT OF COOL:GEN 5.1 CLIENT APPLICATIONS ON WINDOWS NT, WINDOWS 95 & WINDOWS 98..95 DEPLOYMENT OF COOL:GEN 5.1 WEB CLIENT APPLICATIONS ON A WINDOWS NT WEB SERVER...............101 FINDING SQL IN C AND COBOL PROGRAMS........................................................................................................108 FINDING SQL IN A C PROGRAM 108 FINDING SQL IN COBOL 109
REGISTERING THE TE AS A SERVICE - REGTE WITHIN A COMMAND PROMPT................................................112 DATABASE STATUS ERROR CODES.......................................................................................................................114 RESOLVING DB2 805 ERRORS ............................................................................................................................116 STEPS IN SOLVING COOL:GEN ERRORS...............................................................................................................122
Getting to Know Gen 1
7 | Cool:Gen Developers Tips and Tricks
Number 1 TipSave Often!

Nothing is more frustrating than losing hours or even days worth of work. In or to avoid losing hours of valuable work time, remember to save often! To save your model, click on the disk icon anywhere within the toolset, or hit the (Ctrl + V) keys on the keyboard. It is, however, not even advisable to have days worth of work. As a general guideline, updates to the model must be made at least once a day. You never know what might happen.
CTRL + V for Victory
Cool:Gen Model Directory Structure
Figure 1.1 below shows the basic Cool:Gen model directory structure.
Every time you create a model or checkout a subset, the basic folders BITMAP, C, OLE, COBOL, and DDL are automatically created for you. These folders are the location of your generated files. For example, if you are generating and compiling in C++ all your source code and executables will be placed in the C folder of your models directory. The COM and JAVA folders shown in Figure 1.1 are created when the respective proxy types are selected for generation.
Figure 1.1
In Figure 1.2, the Local name that you specify here will be the same name of the main model directory with an .ief extension. Cool:Gen can only read model names that have .ief extensions. The name of your model can be no more than eight characters in length.
Figure 1. 2 10 | Cool:Gen Developers Tips and Tricks
The bitmap folder is where Cool:Gen points to when locating your bitmap images during window design. Figure 2 below shows the image and the message that are displayed when the images that you used during window design are not in the bitmap folder. Remember that when you get unhappy faces, you just need to check your bitmap folder. (please see bitmaps in Unit 2 Window Design
Tips)
Figure 2
Important Model files
The following files mentioned below are files found in the models.ief root directory.
some of the files are described below.
The significance of
Data Files
There are four data files that make-up the entire Cool:Gen model. These files can transferred to another workstation or another .ief directory and it would still be a valid working model.
IEF0000.DAT, GLOBAL DATA FILE
Contains key information about the model: global variables such as long model name, subset name, and software version.
IEF1200.DAT, MAIN DATA FILE
Contains model objects, properties, associations, and memory management tables.
IEF0700.DAT, DESCRIPTION FILE
Contains all textual descriptions of the objects contained in the IEF1200.DAT file.
IEF2511.DAT, ACTIVITY FILE
Contains all the changes to the model such as add, delete, or modify object This file is the basis for the update.trn file which is used to update the model on the encyclopedia. The size of this file may influence when an update of the encyclopedia should be performed.
How to Improve Performance

To improve the performance of automatic check-in and check-out, select the file transfer option (found on the workstation toolset; select Options, then Encyclopedia Communications). If your model is large or transactions have been frequent, update often. Periodically, check in your model to reduce the size of files and reduce fragmentation in storage. Failure to check in periodically can eventually result in a fatal error when you try to check in a model. The error occurs when the IEF1200.DAT file exceeds its maximum record count. The accompanying message is: "Memory error: No more record structures available.'' You can also improve performance by lessening contention. Do this by checking in changes on a regular, daily basis. You may wish to designate times for check-ins, check-outs, and other maintenance. Refer to the concurrence matrix for encyclopedia operations that can and cannot run concurrently.
source: Cool:Gen Electronic Books Transaction Files

checkout.trn
The checkout.trn contains all the objects and information necessary to create a subset or a model on your workstation. The size of this file varies depending on how many objects were specified in your subset definition and included during expansion. Caution: The checkout.trn can be checked out anytime and may seem to be an active model. Always check the model retrieval status report. (please see model reports in this unit)
update.trn
The update.trn file contains all changes that have been made to the model since last checkout. It is usually wise to create this .trn file and upload it to the encyclopedia at least every other day. To play it safe, always send an update at the end of the day or whenever you have done a substantial amount of work. This file will be sent to the encyclopedia to update the model. When uploading changes, the user has the option of updating with checkin or updating without checkin. Regardless of which option is chosen, the update.trn file is what will be sent to the encyclopedia.
verify.trn
The verify.trn contains information about the status of the model in the encyclopedia. It brings in a report of what objects have been added. Once an update has been performed, no further modification should be done until a verify has been made. This will cause the workstation model to become out of sync with the encyclopedia on the host. If an update with checkin was selected from the model/encyclopedia option the workstation, the file will set the workstation model to read-only.
PDX Files
PDX are your Protection Downgrade report files. These are used by the model for displaying the model retrieval status reports. These files are Important in determining what type of downgrades occurred during checkout. The format can be read only when you go into the reports menu item in the Cool:Gen toolset. (please see model reports in this unit) It has the following format: mmddhhmm.PDX
DNX Files
DNX are your Duplicate Name report files. These files are used by the model to display the status of a successful checkin. The format can be read only when you go into the reports menu item in the Cool:Gen toolset. (please see model reports in unit) It has the following format: mmddhhmm.DNX
Model Information
By selecting Model Info from the main Cool:Gen window, the developer can view important
information about the subset located on the workstation. It tells you the location of your model and the local name. It indicates the status of your model whether its checked-in, checked-out, or even whether it had failed an update. It also indicates the maximum number of objects you can create in this subset. Unless you do a HUGE amount of work, this number will not be exceeded.
Figure 3 13 | Cool:Gen Developers Tips and Tricks
Model Reports
Each time a subset is checked out or an update of the encyclopedia is performed, a report is created.
It will show any conflicts or errors that may have occurred during the check-out or update process. To open the Reports window, click Model Reports on the main Cool:Gen window. The list of reports on the workstation can then be accessed by selecting File Open from the Reports window.
Figure 4
Whenever you do a checkin, Cool:Gen creates a report for you based on the date and time the action was done. If a checkin was executed, you will see an Encyclopedia Update Status report. On the other hand if a checkout was executed, you will see a Model Retrieval Status report. It is very important to review the reports. When you do a checkout, make sure that the timestamp of the report matches when you did the checkout. This is important for non-seamless checkout because you could be using a checkout.trn that is 30 days old and not the current one you just checked out.
Cool:Gen Model Paths
The Paths pop-up window lets you define subdirectories to read from or write to when storing files
regarding data, output, models, record, and work. It is launched by click on Options Paths on the main Cool:Gen window.
Data: Specifies where the Cool:Gen executable is stored along with associated read-only files. Output: Specifies a path for files you want to save outside of Cool:Gen. Models: Specifies a path for the subdirectory in which Cool:Gen stores and accesses all files that
define or relate to specific models.
Work: Specifies the subdirectory in which Cool:Gen stores and accesses temporary work files.
Window Design Tips 2
Field Design List
The field design list is an excellent way to see the state of all of the export views in the procedure.
Figure 5
The character to the left of the attribute tells the developer how (or if) the field is being utilized by the current window/dialog box.
*
d h
The attribute has already been placed on the window. The properties have been defined for the attribute, but the field has not been placed. The developer can define an attribute by clicking the PROPerties push button or by double clicking on the attribute. The attribute is hidden. The field may have been placed on a window and later removed, but the mapping still exists.
If the attribute is not coupled with one of the three characters above, then its properties have not been defined for use by the current window or dialog box. Attributes which are defined (d) can be used to manipulate disable logic within a window or dialog box. Take the situation illustrated below in Figure 6.1. The field out_return_needed ief supplied flag is defined to the window, but not placed anywhere on it.
Figure 6.1
When setting up the disable logic for the OK button on the dialog box POC Detail, that flag is available for selection by the developer.
Figure 6 . 2
This eliminates the need to place fields outside the barriers of the window (widen a window, place a field on the edge, and return the widow to its original size) in order to provide an alternate means of disabling a field or control.
Special Actions for Menu Items
When defining an item that is part of a menu structure, the developer has some additional options that
are not available when defining other controls.
Figure 7
The special actions Cut, Copy, and Paste can be used in association with menu items only. As Figure 7 shows, Cool:Gen takes advantage of the clipboard within the operating system to perform this function.
Getting Rid of Help and Window Menu Items
Performing this task is as easy as clicking a checkbox.
The trouble here is knowing where to find it. Click on Menu Design within the Window Design Tool, and highlight the top line Main Menu Bar. Clicking on the PROPerties button will open the Menu Properties Box. It contains the checkbox which needs to be turned off in order to prevent the Window and Help options from being generated.
Figure 8
As illustrated above, the user can also change the Foreground Color, Background Color, and Font Size of the menu within the Menu Properties box.
Resizing Listbox Columns
Once a list box is placed on a window, the developer can adjust the width of the columns.
This is done by placing the cursor over the column divider line until a double arrow appears. Figure 9 shows a double-headed arrow in between the columns status and date-entered. From there, it is a simple click and drag procedure.
Figure 9
There are a couple of simple, yet very important, things to remember when resizing list box columns: Even though the edit pattern characters are not running into the next column, this does not mean that user entered data will automatically fit in the space provided. Font size and the specific width of each character in the font must be considered before determining the proper column size. Resizing list box columns will affect how the data lines up with its associated column header prompt. The headers must be moved independently their position does not change when a column width is adjusted.
The Selection Character
In order to associate a export group view with the list box control, the group view must contain a
selection character. When setting up the properties of a list box, the developer can specify which field will act as the selection character by highlighting the desired field and clicking the PROPerties button as shown in Figure 10. This action will open the List Box Field Properties Box and the developer must then check the selection indicator field at the bottom of the dialog box.
Figure 10
After the checkbox is checked and the window is closed, the field designated as the selection character will have a d next to it. This means that the field has been defined, but will not be placed on the window. For more information, see FIELD DESIGN VIEW LIST earlier in this section of the guide. Each list box must have a selection character if it is to work properly. The selection character is what Cool:Gen uses to determine if a row within a list box has been selected. The developer can see how this is done within the TRACE facility (discussed later on in this guide). If a row in a list box is highlighted, the selection character for that row will contain an *. By cycling through the members of a group view within TRACE, the developer can see which row has been selected. Note: If a list box supports Extended Selection, selection character fields might at times contain a + or a -. By allowing extended selection, the developer gives the user the ability to select multiple rows by holding down the shift or control keys while clicking on items within the list box. The + is used to indicate the last row selected in the list box when extended selection is utilized. Likewise, the - is used to show the last field being unselected using this method.
Selection Character Values

BLANK
untouched row in the view is not highlighted at all highlighted, row selected currently highlighted row clicked (unhighlighted) unhighlighted row clicked unhighlighted top row in viewable list Item is the highlighted top row in viewable list Row is hidden via FILTER or listbox view Row is added and highlighted (applies to enterable listboxes and enterable dropdowns
* + < >
H A
Window Mapping
Mapping is the process of assigning Import Views to Export Views.
For a given Window or Dialog box, the developer can see which fields are mapped by clicking on DesignMapping within the Window Design tool.
Figure 11
The view mapping dialog box, Figure 11, illustrates which export views will be moved to which import views after each execution of the procedure. This passing of views happens once the flow through a procedure is complete and control is passed to the Window Manager. The developer does not have to go into the view mapping dialog box if both an import and export view were assigned to a window field at the time it was placed. However, it is always a good idea to double check the mapping once the design of a window or dialog box is complete. Improper mapping will result in data being lost and/or placed in the wrong fields at runtime. CAUTION: ADDING AN ATTRIBUTE VIEW AFTER IT HAS BEEN MAPPED WILL NOT AUTOMOATICALLY MAP IT. BE SURE TO CHECK YOUR MAPPING EVERYTIME YOU ADD A VIEW. The biggest problem with not mapping is losing a variable's value. For example, you need to map exports to imports as a holding area when travelling between the window and its associated procedure. If you do not map a flag, for example, then flow to the window, when you come back into the procedure, the flag will be blank. The reason you do window mapping is to retain attribute values when cycling between the window/dialog boxes and their associated procedure. Also, if you want to place an attribute on a window, you place export attributes (of course), then those exports get passed back into the PROCEDURE AS IMPORTS TO CAPTURE WHAT THE USER ENTERS OR CHANGES ON THE WINDOW. SO, TWO REASONS to map: (1) retain "working" attribute values and (2) communicate with the window.
Mary Russell
Computer Associates Principal Consultant
Specifying Commands
Setting a command within Cool:Gen serves multiple functions and can be done in a variety of places
with a given model. The manner in which a command is set determines what affect it will have when the application is executed. Command is (command value): When a command is set in this fashion, its purpose is to request an action to be taken by the current procedure, or to request action when passed to a separate procedure. It is added as its own statement within an action diagram. When a command is set in this fashion, the developer may interrogate the special attribute command within an action diagram by using a such statements as CASE, IF, or WHILE.
Figure 12.1
Associating a command with an event: A command can be associated with an event action so that when the event is triggered, the special attribute command is set. This is done by clicking on the Commands button within the Event Processing window as shown in Figure 12.2. When a command is set in this fashion, it may be interrogated within an action diagram by using such statements as CASE, IF, or WHILE.
Figure 12.2
Associating a command with a push button or menu item: When a command is associated with a push button or menu item, the special attribute command is not set, and therefore DOES NOT have the same effect as the command set in the event action. The specified value will not show up when attempting to interrogate the command attribute within an action diagram. The command is set by clicking on the Cmds button in the properties window for the push button or menu item.
Figure 12.3
The main reason to set a command in this fashion is to allow for the enabling and disabling of the item within an action diagram using the GUI statements ENABLE and DISABLE. In the case of a menu item, it also allows the developer to utilize the MARK and UNMARK GUI statements, Figure 12.4.
Figure 12.4
Importing Bitmaps to the Model Directory
Utilizing Bitmaps on widows will help spice up the appearance of any application.
By replacing the standard push button text with a bitmap, the developer can help reinforce the action associated with that particular control. In either case, if the developer wishes to utilize a bitmap, it must first be imported before it can be placed within the application. This is done through the bitmap management window, Figure 13.1. It can be access through both the push button properties window as well as the picture properties window.
Figure 13.1
In the example above, no bitmaps have been imported. To import a bitmap, browse to the location where the bitmap is located (or type the path directly into Import/Export File box). Once the location is entered into the Import/Export file box, press the import button. The bitmap you specified will be listed in the Installed Bitmap box and is now available for placement on a window.
Figure 13.2
It is possible to import multiple bitmaps at once. This is done by inserting path name/*.bmp as shown above. Click Import, and all of the bitmaps in the specified directory will be available for selection. When a bitmap is imported, a .PPM (PORTABLE PICTURE MAP) file will be created in the bitmap subdirectory underneath the {model name}.ief directory. It is the existence of this .PPM file which allows the developer to select it for placement on a window. Note: When a bitmap is used for the face of a push button, the button text entered in the push button properties box still plays a role at runtime. When the user places the cursor over the push button within
the application, the push button text will pop up in the form of context sensitive help. This helps make the application more user friendly.
Different Bitmap States
The Cool:Gen toolset will accommodate 4 bitmap states: enabled, disabled, pushed, and focused.
The number of states utilized at runtime is determined by the value of the Number of Pictures filled on the Push Button Properties dialog box. The example below, Figure 14.1, is only utilizing two states.
Figure 14.1
The Number of Pictures specified is interpreted as follows:
1: 2: 3:
The entire image is to represent the enabled state. Operating system defaults are to be used for the disabled state, the pushed state, and the focused state. The top half of the bitmap is to represent the enabled state and the bottom half is to represent the disabled state. Operating system defaults are to be used for the pushed state and the focused state. The top third of the bitmap is to represent the enabled state, the middle third is to represent the disabled state, and the bottom third is to represent the pushed state. The operating system default for focused is to be used for the focused state.
4:
The top fourth of the bitmap is to represent the enabled state, the second fourth is to represent the disabled state, the third fourth is to represent the pushed state, and the bottom fourth is to represent the focused state.
NOTE: When specifying multiple states, make sure the bitmap file contains the same number of versions of the picture to be placed on the button. The following bitmap was used for the OK button in the previous example, Figure 14.1.
Figure 14.2
Video Properties
The video properties option allow the developer to control the appearance of all fields and control on a
window or dialog box. The object selected at the time the menu option is chosen will determine how the changes cascade down. For example, if the window selected and the developer changes the font, the fonts of all prompts, fields, and push buttons will be changed. (The exception is the menu structure. Menu properties must be set separately) However, if a single entry field is selected, only that field will display in the newly chosen font. The video properties box is accessed via the detail menu within the window design tool.
Figure 15
As illustrated above in Figure 15, foreground color, background color, and font settings can be controlled through the video properties box.
Positioning Window Objects
Proper positioning of window objects is essential when attempting to create a uniform look throughout
a given application. Objects can be moved in three ways: Click and Drag: Right click and hold the item to be moved, drag it to its desired location, and release EditMove: Highlight the item to be moved and click editmove on the Window Design menu. A cross hair will appear over the selected item. Drag (dont click yet!) the item to the desired location and then click to release the cursors hold on it. Field Positioning dialog box: By selecting Position from the Edit menu item within the Window Design tool, the developer can line up objects on a window, position them relative to each other, and position them relative to the window itself. This will open the Field Positioning dialog box, Figure 16.
Figure 16
The two options under Move will place the selected items relative to the entire window, and are available when single or multiple items are selected. The Default Size and Arrange prompts against the fields options are also available independent of the number of selected items. All other options are available only when multiple items are selected; they involve moving items relative to each other. When multiple items are selected, Cool:Gen uses the first item as the anchor, and subsequently selected items are placed relative to the anchored item.
Tabbing Sequence
By setting the sequence on a window or dialog box, the developer can specify the order in which the
cursor moves from control to control when the tab key is pressed. The tool will automatically determine a sequence for you, but it often must be altered once fields are moved around during the window design process. The default sequence will flow left to right, top to bottom based on where the individual controls were originally placed. This order can be modified by clicking on Detail Sequencing within the Window Design tool. This will open the Control Sequencing dialog box, Figure 17.
Figure 17
In order to change the default sequencing, highlight the field you wish to move and click Move. Next, click on the field or control you want the highlighted field to be after in the new sequence order. The selected field will then appear in its new place in the sequence order. Clicking on Transform will reorder the controls to the default sequence.
Designing with Grid On or Off
The Window Grid is another tool available to the developer to aid in the placing of objects on a window.
To display the Grid Definition, click Options Grid within the Window Design Tool, Figure 18. The Information group box displays characteristics about the font being used. These settings are not controlled by Cool:Gen they are set at the operating system level. The Horizontal and Vertical coordinate boxes allow the developer to set the distance between grid lines. The figures measure distance in a device independent presentation unit of measure.
The Show Grid check box determines if the grid is visible to the developer within the Window Design tool. The grid is never visible to the user at runtime.
Figure 18
The Snap Windows to Grid checkbox will force the developer to place all fields and controls along a grid line. It also restricts the sizing of objects, ensuring that all corners will fall on a grid coordinate point. This helps to ensure that fields and controls are lined up properly with one another. The Show Coordinates checkbox controls whether or not a highlighted objects coordinates, height, and width will appear in the title bar of the Window Design tool.
Rabbit TestOops, Rapid Test
Did you know that when you resize the Cool:Gen Testing Tool dialog box that there is a rabbit head
rolling around and his tongue sticking out. The previous version of Cool:Gen, the race car, Figure 19, used to be a rabbit. It was so-called probably because of rabbit testing which sounds similar to rapid testing. It was not only later on that it was changed to a race car. But the rabbit still lives. Next time you are in Window design, go to Modethen Test. Resize the Cool:Gen testing tool and you will see the rabbits head rolling around and, as always, sticking out his tongue at you.
Figure 19
Action Diagramming Tips 3

Open Window List Push Button
The open window list push button is an effective way to track the number of Cool:Gen windows you
have open at any given time. The push button appears on top of most of windows in the toolset, Figure 20.1.
Figure 20.1
Clicking on this button will launch a dialog box, Figure 20.2, which shows all open windows. This certainly is not that useful if you only have a couple of windows open, but its effectiveness increases with the number of active windows. The developer can click on an item within the list and click the Show button, and the selected window will maximize and become active.
Figure 20.2
Action Block Synthesis
Selecting Action Block Synthesis from the Action Diagramming Tool displays a series of pop-up
windows. These windows let you to automatically generate (100% code) detailed process logic based on the constraints set in the data model. The developer can choose to generate logic based on one of the five basic entity actions: Read, Create, Update, Delete, and List.
Figure 21
This dialog box, Figure 21, can be accessed by clicking on GenerateAction Block Synthesis within a Process Action Diagram (PAD). Action Block Synthesis is very useful as a starting point in creating the action blocks that perform your systems basic database functions. In fact, it is advisable to start with this action block and trim the unnecessary code afterwards. Non-display procedures also have an automation technique that you could use. This is called Procedure Synthesis.
TIREVENT
A TIREVENT is a special external action block used to trigger user defined events in your client
procedure. Although it looks like a normal EAB stub, it is PRE-DEFINED to the Cool:Gen runtime components, and therefore does not have to be compiled outside of the toolset. These are the precise steps that must be followed in order to successfully utilize this type of event.
1.
Create a new action block and name it Tirevent. The action block should have one import view a work view of IEF supplied command. The only line of code should be one defining the action block as external.
Figure 22.1
2. Create a user defined event, Figure 22.2.
Although not required, the best practice here is to associate the user defined event with the main window. Act as though you were going to create an open event on the procedures main window. Give the event a unique Event Type. It is the event type, NOT the Action Name, that will be used when the event is called.
Figure 22.2
3. Call the newly created user defined event, Figure 22.3.
In the main procedure, create a temp view like the import view in the Tirevent stub, and set that view equal to the unique event type from the previous step.
Figure 22.3 Important: The code you placed within the event will be queued for execution. It is not executed in
place like a normal action block call. The Tirevent will be executed once control is passed back to the window manager.
Adding Objects Common to a Business System
The phrase, There is more than one way to do that is applicable throughout the toolset.
The Business System Defaults window is an area where this phrase is proven to be true. Within this window, the developer can perform such tasks as adding exit states and commands, and setting up default function keys attributes, edit patterns, and delimiters. The interfaces should be familiar. For example, the dialog box to create and exit state in the Business System Defaults window is the same one used when adding an exit state from within an action diagram. All of these options can be accessed by clicking on the Detail menu option, Figure 23.
Figure 23
Can I Use this Function?
There are a number of functions within Cool:Gen which will not work in the mainframe environment.
A developer can tell which ones these are by pulling up Help within the toolset and looking up the function in question. However, there is an easier way. Functions which appear in all lower case (ex. concat) can be used, while those appearing in mixed case (ex. DateTime) can not, Figure 24.
Figure 24
Determine Where an Action Block is used
The main purpose of the Action Block Usage tool (Figure 25) is to display where an action block is
used in the model. The tool identifies action blocks connected to other action blocks, processes, and procedure steps through the USE command. In addition, the tool identifies all of the procedure steps that call a selected procedure step with the PROCEDURE STEP USE statement. In the figure below, the circled action block is being called by three other action blocks.
Figure 25
From the action block usage tool, the developer can perform a variety of functions on any of the PADS or PRADS which appear in the result set. The tool can be accessed from the main Cool:Gen window under the Design menu.
View Matching: Data Passing
View Matching is one of the most important concepts in Cool:Gen.
It determines which data is passed from one action block to another. View Matching must be done as part of a USE, PROCEUDRE STEP USE, and USING statement. In these three cases, the View Matching interface is the same. There is a dialog box, for the imports and a dialog box for the exports. The trick to view matching is to look at the CALLING and a CALLED action block as a ROUNDTRIP process. Just imagine that both your starting and ending point is always the workstation (client). Let us look at an example and Figure 26. Sample procedure use statement: In this example Server Procedure B is being called by Client Procedure A in an event action. EVENT ACTION call_server_procedure_b USE server procedure b (procedure step) WHICH IMPORTS: Entity View e_main view a TO Entity View i_main view a WHICH EXPORTS: Entity View e_main view b FROM Entity View e_main view b
The same procedure step use statement: USE server_procedure_b (procedure step) server_procedure_b is the name of the action block or procedure you called.
WHICH IMPORTS:
Entity View e_calling view a TO Entity View i_called view a
WHICH IMPORTS: This mean that you are SENDING whatever is in e_calling view a TO the i_called view a of the action block you called . The view to the right of TO is always the view of the called action block
WHICH EXPORTS: This means that e_main view b is RECEIVING data FROM e_main view b of the action block you called. The action block you called is exporting back data you requested. The view to the right of FROM is always the view of the called action block.
WHICH EXPORTS:
Entity View e_main view b FROM Entity View e_main view b
Figure 26 43 | Cool:Gen Developers Tips and Tricks
View Neighbors
The View Neighbors option within Dialog Design is very useful for systems that have multiple procedures. To take advantage of this feature, highlight a procedure and click on View Neighbors.
Figure 27
In the above example, the procedure HQ Employee Maintenance is highlighted. After selecting Neighbors from the menu, only those procedures which flow to or from HQ Employee Maintenance will appear in the Dialog Design window. All other procedures within the system will be hidden from view.
READ EACH Properties

The READ EACH Properties pop-up window lets you specify properties common to all database management systems supported by Cool:Gen. In addition, you can set characteristics unique to a DBMS by selecting a tab at the top of the dialog box. The dialog box (Figure 28), can be accessed by highlighting a read each statement within an action diagram and clicking and clicking Detail Properties, or by double-clicking on the READ EACH statement.
Figure 28
Double-Click of Brackets in an Action Diagram
Double clicking on a bracket, regardless of the statement type, is a neat shortcut to use in order to
select the contents within the bracket. Simply double click on the vertical line designating the left bracket border. The entire contents of the bracket will be highlighted, making Copy, Move, and Delete of multiple lines easier. This technique works for database statements, condition statements, events, and almost any other statement bracket that exists within the toolset. The only exception to this is the outermost bracket of an action block or procedure. If you double click even with the view definition at the top of the action block, the contents of the action diagram will not get selected. However, all contents of the action diagram will be highlighted if that double click occurs on the bracket at a point even with or below the first action diagram statement.
Keypress Event
The Keypress event is the most unique event in the toolset.
It is triggered much like a change event, but in the case of a keypress event, the code is executed each time a character is entered into a given field. What makes the keypress event unique is the ability given to the developer to trap the keystroke entered by the user. When a keypress event is created, a special view structure is added to the exports of the action block. By interrogating this export view, the developer can trap each stroke and control whether or not it is actually displayed in the entry field on the screen. Figure 29 describes how each of the keystroke view members is used in this process. Notice that all of the attributes in the keypress work view are followed by a 3. This is because multiple keypress events exist within this business system. Each time a keypress event is added within a business system, a unique set of attributes are created.
Figure 29
Changed Event
The Changed Event is a fairly common event, but it has one characteristic that makes it worthy of
inclusion in this guide. By double clicking on any event in an action diagram, the developer can view the Event Action dialog box.
Figure 30
When an event is created, the Import to Export radio button is always set to Default . For all other types of events, default means that import views are automatically moved to export views after the event is executed. The Changed Event is the exception - the views remain as they were before the event logic was executed. There is a reason for this deviation from the norm for this event type. Based on certain conditions, the prior value in the field should be displayed instead of what was entered. For example, a default value may be displayed in an entry field. If the user makes an incorrect entry, the default value should remain displayed, not the entry that was made. The developer can override the default value by choosing one of the other options in the Import to Export radio button group. The most common course of action is to change the selection to ALWAYS MOVE. If the default selection is not changed to ALWAYS MOVE, then the data entered in an entry field will not be automatically redisplayed.
Customizing the Pop-Up Menu(s)
The Customize Pop Up Menu (Figure 31) option allows developers to select the commands they want
to show, as well as set the order in which the commands appear on pop-up menus. This option is available on any window where a click of the right mouse button opens an in place menu within the diagram. The dialog box can be opened by clicking on Options Customize Pop Up Menu.
Figure 31
To prevent an item from being displayed, highlight that item and click the Hide button. The word Hide will then appear next to the menu item in the Command Menu Hierarchy box. To promote an item (make it appear one level higher in the menu structure), highlight the item an click the Promote button. The item will then appear in the Pop Up Menu Order box, and the word Promote will appear next to the menu item in the Command Menu Hierarchy box. To make a hidden item visible again or to demote a promoted item, highlight the item in the Command and Menu Hierarchy box and click Clear.
NOTE: Menu customization is done on a diagram level. This means that if you change the Action Diagram pop up menu, the pop up menu launched within the Window Design tool will remain unchanged.
Single Add vs. Multiple Add
Located under Options on the main Cool:Gen window, the selection of Single or Multiple Adds
determines how the toolset behaves when adding objects via a pop-up window. Selecting Single Add causes the pop-up window to appear only until one add is complete. When the OK pushbutton is pressed, the primary window is displayed. Selecting Multiple Adds causes the pop-up windows from which you are adding objects to remain displayed until the Cancel pushbutton is pressed. This enables the developer to add items repeatedly, without initiating the pop-up window each time.
Converting Number to Text and Text to Number
Cool:Gen provides the developer with a variety of functions that perform data type conversion.
Two of these functions are textnum and numtext. The textnum function converts a numeric value into a text string and the numtext function converts a text string into a numeric value. The important thing to remember about both of these functions is that the numeric portion of the function bases its conversion on a field length of 15. This means that when using the numtext function, the receiving field must be at least 15 characters in length to ensure that no data is lost. If the target field is smaller than 15, the field is zero-filled to 15 characters and only the leftmost characters are displayed. For example, assume that the numeric field CHARSTRING = "1234" and TEXTSTRING is 15 characters long. Consider the statement: SET TEXTSTRING = NUMTEXT(CHARSTRING) In this example, the value of TEXTSTRING would be 000000000001234. If CHARSTRING were only 12 characters in length, the value of TEXTSTRING would be 000000000001. The same type of logic applies to the textnum function. The target field must be at least 15 characters long to ensure that nothing is truncated in the conversion. In both cases, the developer can utilize the substr function to help control the values and field lengths returned.
Event Locator
The Event Locator button (Figure 32.1) is a very useful tool when attempting to navigate an action
diagram which contains many events.
Figure 32.1
When the button is pressed, the locate event dialog box will open (Figure 32.2), showing all of the events contained in the current action diagram. By highlighting one of the events and clicking the Show button, the developer can jump to the top of that event within the action diagram code.
Figure 32.2
Dialog Flow Design
When in the Dialog Design Diagram, the combination key, CTRL + I [zoom in], comes in handy when you cannot read the entire procedure name. After pressing this, you will able to see and tell which procedure are the clients and which are the servers.
Sheila E. Ratcliff
USDA National Finance Center Computer Specialist (Programmer Analyst)
Other Tips
Notes in action diagrams: This point can not be stressed enough. It is good practice to place a note
at the top of each PAD that contains a description of what the program does, and the person who developed it. This note can also serve as a change log, making maintenance easier for all the members of the development team. Notes should also be used within the body of the code. Here, a developer can explain why they designed something they way they did, as well as explain logic that may not be that easy to follow. It might seem like a little time consuming at first, but it sure does save time in the long run! Always use notes whenever you code. The next person looking at your code will thank you for it. Setting up Mandatory relationships: Within the data model, each relationship is defined as mandatory or optional. As expected, the decision on how each relationship is defined is based on the customers business rules. However, it is important to consider archiving strategy during initial design. If the customer wishes to offload data after a certain period of time, the mandatory relationships that conformed to the business rules might end up making the implementation of an archiving strategy much more difficult. Consider enforcing mandatory relationships within the client code. The same thing can be said for enforcing restrictive delete rules in the data model. The fewer client procedures which maintain data for a given entity, the more beneficial client enforcement of business rules is to a development staff. Utilizing the proxies: It is a good idea to make all of the import views on the server procedures optional. Why? Well, it is much more efficient to include required field logic on the client side. Otherwise, the server must send the required field error messages back across the data line, slowing down response time, and increasing the amount of time before an eventual successful transaction is processed.
Client Deployment Topics 4

Deployment Architecture
Pre-Generation
Checkout Subset Check out client procedures with Read protection, Full Expansion, System test
Generation
Select All (highlight) window manager By highlighting all window manager modules you can be sure that everything will be expanded for generation in the next step. View expand all, NOT expand Clicking on expand will only expand to the procedure step level. Expand all will always expand to the action block level. Play it safe, always choose EXPAND ALL Generation Defaults Check target environment. If generating for only one environment do this set it, save it , and forget it. Trace ON / OFF Select appropriate option for your release phase. You may not want to turn trace on for production releases, as generating with trace on will create larger dlls. Generate Code Selected Select GenerateCode Selected Try to be selective when generating code. This may save you time.
Post-Generation
Move Files to the application directory load module.dll load module.sst load module.exe load module.ocx load module.reg load module.hlp Change Path of load module.reg file This path should point to wherever the load module executable is located.
Delete contents of C/DDL directory Delete old files instead of overlaying and empty recycle bin. Not deleting files may sometimes cause generation problems as well as space problems. Check OLE directory and OCX file Make sure ole file is in the models ole directory and is registered in its original path.
Include the defaultw.ico Add your customized icon file in the Cool:Gen directory.
Register Files OCX DLL REG other runtime files Include Special files You may want to create/include special files that automate the registration process; help in deployment; etc.
Check Build Tool settings Check and Set build tool parameters.
Check elp Files Make sure that necessary help files needed to generate help are setup.
DEFAULTW.ICO
The defaultw.ico is the icon file for your applications generated windows.
It is the image that you see on the task bar when you minimize your application window. This .ico file resides wherever your Cool:Gen directory is located. You can replace this default icon with your shops icon. That way, your icon will automatically be associated with the systems windows each time the code is generated. Following this practice will eliminate the need to change any icons in your window design settings. You can see the difference in Figure 33 below.
Your Icon Here
Cool:Gen Default Icon
Figure 33
Build Tool Parameters: The Win32itm.tgt File

LOC.EXTERNAL_LIB c:\models\extrn
This is the directory where Cool:Gen expects to find the external code [stub] used in the model during link time. If the stub is not in this location, you will receive this type of error during the link step of the build: fatal error LNK1120: unresolved externals
OPT.IEF_BITMAP
z:\iefmodel\win\bitmaps
The IEF_BITMAP environment variable set within the operating system specifies where the bitmap directory is located. If there is no IEF_BITMAP environment variable, the token OPT.IEF_BITMAP is used. If OPT.IEF_BITMAP is not enabled within the build tool (default), then the build tool looks in the models bitmap subdirectory. If this directory doesnt exist, the module's source directory is used. If the bitmaps are not in the specified location, you will receive this type of error during link: error RC2135 : file not found: .\..\BITMAP\<bitmap name>
OPT.BUILD_SRC
YES
GUI applications require DBMS specific startup files (stubs). If OPT.BUILD_SRC is set to YES, the build process will copy the DBMS specific stub source to the build directory and precompile, compile,
and link the stub. Otherwise, the DBMS specific stub executable will be copied into the build directory and renamed to {Load module}.EXE. If this option is set to yes, the generated window manager resource file is also bound with the {Load module}.EXE to provide the executable with the application icons. Valid values are [YES | NO]. This token is disabled and the default value is set to NO. (please see timestamp of load module executables in this unit)
Dialog Flow Trancode and Clear Screen Trancode

Clear Screen Transaction Code
There is one transaction code for every screen or non-screen transaction. It allows the user to execute the load module from a blank screen by entering the transaction code. If you want the user to be able to execute the transaction from a blank screen, then you must define a transaction code. If not (such as for server transactions), there is no need to define the transaction code a dialog flow trancode will suffice. The trancode must be defined to the teleprocessing monitor (e.g. CICS, IMS, Transaction Enabler) by the System Administrator in addition to defining it to Cool:Gen.
Dialog Flow Trancode

There is one dialog flow trancode for every screen, server, or non-screen transaction. Each screen/nonscreen must have the same value for its trancode and its dialog flow trancode. The Cool:Gen dialog flow trancode is internal to the Cool:Gen-generated application it is not defined to the teleprocessing monitor.
Figure 34
Q: A:
How does the application know what window to execute first if they are all packaged in one big load module? By appending the desired TRANCODE at the end of the executable parameter c:\usdanfc\nfcapps\pods.exe <trancode>
The trancode would be the code entered during packaging of load modules. Remember that each client procedure step is assigned a trancode. Other parameters could be added to the path as shown below: c:\usdanfc\nfcapps\ <load modulename.exe> <trancode> <command> <command> could be up to 80 characters. The value of the last parameter will be in the Cool:Gen special attributes. You can then use this value after entering the procedure.
Carol Marie Cooper

Computer Associates Consultant
Expand All Views
When generating, whether it may be window code or cooperative code, ALWAYS select VIEW
EXPAND ALL when expanding load modules (Figure 35). Expand would just give you the procedure step level. Expand All will expand all the way down to the action block level. If you dont properly expand you may get an error stating that it cannot find the components the load module needs to successfully build.
Figure 35
How To Verify Cool:Gen Environment Variables
RememberMS SQL Server wouldn't work and we had to compare the environment variables? Remember how we wish we could print it out? Well, I found out how. Go to the Start menu and select Windows NT Diagnostics under Administrative Tools (Common). It will bring up different tabs and select the one for Environment. Then at the bottom of the window, there's the Print PB. You can even print to a file
Catherina Fuh
Computer Associates Consultant
Registration of Cool:Gen Functions
When functions (i.e. SetVisible, BackgroundColor, etc.) are not working properly, for instance objects
you want to be invisible are visible and the colors are not changing, try reregistering the Cool:Gen .reg files that deal with the Cool:Gen function and application libraries.
To reregister the Cool:Gen Functions 1. 2. 3. 4. Register the WROAF.REG file Register the WRU410n.dll (version 4.1) Register the OLEPRO32.dll Register the RTT.REG
Inside the wroaf.reg File
The wroaf.reg contains pointers to two important type libraries.

WROF0000.TLB (function library)
WROA0000.tlb (application library) and
REGEDIT
HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3} = COOL:Gen Application Interface Type Library HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3}\4.0 = COOL:Gen Application Library HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3}\4.0\0\win32 = c:\coolgen\WROA0000.TLB HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3}\4.0\HELPDIR = c:\ief HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED} = COOL:Gen Functions Interface Type Library HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED}\4.0 = COOL:Gen Functions Library HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED}\4.0\0\win32 = c:\coolgen\WROF0000.TLB HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED}\4.0\HELPDIR = c:\ief
How to Check Whats Registered

In order to check what is registered, open the ActiveX Control Test Container (Figure 36) that comes with Microsoft C++. In the main window, click on File Register Controls to view the control registry. You can even register and unregister files using this utility.
Figure 36
What to Do When Using OLE/OCX Controls
Unfortunately, the ocx controls added to the model during design time are not stored as object files on
the encyclopedia. Therefore, like bitmap files, they have to be manually managed. When opening the model that uses ocx controls, make sure that the ocx file is in the models OLE directory. It must be in the same path as it was when the control was added during the initial design of the window. Otherwise, the pointer to this file may be lost and will become invalid in your action diagram statement. The OCX file and SST file must be moved to the directory where the dlls are deployed. The SST file is used by your ole/ocx control to access/manipulate the control. This must be placed in a non-read only directory (local or network), otherwise your ole/ocx will cease to function. With Cool:Gen 5.0 and higher, the SST file is going to be packaged with the executable file, and therefore does not need to be deployed.
Timestamp of Load Module Executables
Have you ever wondered why your executables program date and time stamps do not change?
The systems load module.exe files are actually just renames of the database stubs that you selected during generation. If you have DB2 as your target database, Cool:Gen will grab the stubdb2n.exe file and rename it to the name you have assigned to your load module during construction. This stub contains specific database scripts (start, stop, commit) for the database you are using. This is only useful if you have an online application using a local database. Please see build tool setup section for more information on OPT.BUILD_SRC parameter.
stubdb2n.exe stubinfn.exe stuboran.exe stubs95n.exe stubsybn.exe stubxdbn.exe
27KB 64KB 25KB 28KB 82KB 28KB
8/4/97 8/4/97 8/4/97 8/4/97 8/4/97 8/4/97
6:43 AM 6:43 AM 6:43 AM 6:43 AM 6:43 AM 6:43 AM
In [Cool:Gen] 5.1, some of the default settings have changed from 4.1a. One of the default settings is the OPT.BUILD_SRC in the NT build tool setup. With the default setting of NO, the client executables generated will not have a current timestamp and it will not pickup the defaultw.ico for the icon. To get around this, all you have to do is change the setting in the IT setup [win32itm.tgt] file to YES. This does create a little more work when compiling and building executables, but if you need a custom icon and an accurate timestamp on the executable it is worth the extra work.
David McGrady
MIS Analyst III Information Resources, Lowe's Companies, Inc.
Associating an EAB Stub with the Desired External Code
If your system utilizes external action blocks, Cool:Gen needs to know which EAB stubs go with which
external programs. To create this association, go into the construction ... generation and pull up the type of code you being used.
Figure 37
If your system utilizes EABs, the stub will appear in the generation list. If you double click on the stub, and action block properties dialog box will appear (Figure 37). The source name is the name that was used when the external library was built.
Important Files to Deploy After Generation

LOAD MODULE.EXE ONLY MOVE ONCE LOAD MODULE.DLL LOAD MODULE.REG LOAD MODULE.SST MOVE ALL THE TIME ONLY MOVE ONCE MOVE ALL THE TIME
LOAD MODULE.OCX
ONLY MOVE ONCE
Inside the Load Module.reg File
The load module.reg file contains the path information for all your executables.
When this file is registered, the path inside this file, figure 38, will be the path stored in the registry.
HKEY_CLASSES_ROOT\CLSID\{D74E6110-AFD9-11D2-B291-000000000000} = Composer (Ver 4.0) HKEY_CLASSES_ROOT\CLSID\{D74E6110-AFD9-11D2-B291-000000000000}\LocalServer32 = C:\USDANFC\NFCAPPS\PDL0.exe /Embedded HKEY_CLASSES_ROOT\CLSID\{D74E6110-AFD9-11D2-B291-000000000000}\ProgID = PDL0.Composer.Application.1

...
Figure 38
Subsetting Topics 5
Non-seamless Checkout
When performing a non-seamless checkout, insert a * for both model name and subset name (Figure 39). The asterisk denotes wildcard substitution for the specific names. This is especially helpful when you do not know the model and subset name. The local name is required to determine the directory location of your checkout.trn. This method is much less painful than opening the checkout.trn file using notepad to find the model and subset name.
Figure 39
Checkout Subset
Workstation
3 Model
Encyclopedia Check Out a Model
Mainframe
c:\models\<local name>.ief\
CHECKOUT.TRN IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT mmddhhmm.PDX Model Retrieval Status Report (Protection Downgrade Report) Header
1
FTP NFxxx.IEF.TRAN %IEFDOWN
Encyclopedia Model
binary format
Steps (1,2,3, etc) are what you do for manual upload/download. Seamless is kicked off at the workstation and then performs all of the other steps.
Update With or Without Checkin
Workstation
1 Model
Encyclopedia Update and Checkin Model or Update But Do Not Check In
Mainframe
UPDATE.TRN without checkin reset to write IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT Header
binary format
FTP
3
NFxxx.IEF.TRAN NFxxx.IEF.MSG S
Encyclopedia Model %IEFU P
VERIFY.TRN mmddhhmm.DN X Encyclopedia Update Status Report (Duplicate Name Report)
FT P binary
format
Model Encyclopedia Verify Last Update
Only changes are sent to the Encyclopedia -- not your entire subset.
Resend Last Update
Workstation
1 Model
Encyclopedia Resend Last Update
Mainframe
UPDATE.TRN without checkin reset to write IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT *.DNX Encyclopedia Update Status Report (Duplicate Name Report) Header
binary format
FTP
3
NFxxx.IEF.TRAN NFxxx.IEF.MSG S
Encyclopedia Model %IEFU P
4
VERIFY.TRN
FT P binary
format
Only changes are sent to the Encyclopedia -- not your entire subset.
Verify Last Update
Workstation
without checkin reset to write IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT *.DNX VERIFY.TRN
Mainframe
Encyclopedia Model
1
binary format
FT P
NFxxx.IEF.MSGS
Encyclopedia Update Status Report (Duplicate Name Report)

Comparing Update vs. Resend vs. Verify
UPDATE/GENERATE NEW MODEL

UPDATE.TRN without checkin reset to write IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT *.DNX Header FTP FTP IEF.TRAN IEF.MSGS %IEFUP Encyclopedia Model
VERIFY.TRN
RESEND LAST UPDATE

without checkin reset to write IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT *.DNX
UPDATE.TRN Header FTP IEF.TRAN %IEFUP
Encyclopedia Model
VERIFY.TRN
FTP
IEF.MSGS Encyclopedia Model
VERIFY
without checkin reset to write
IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT
FTP
*.DNX VERIFY.TRN IEF.MSGS Encyclopedia Update Status Report (Duplicate Name Report) 74 | Cool:Gen Developers Tips and Tricks
Generate New Model
Workstation
1 Model
Encyclopedia Generate New Model
Mainframe
UPDATE.TRN IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT Header
binary format
FTP
3
NFxxx.IEF.TRA N NFxxx.IEF.MSGS
Encyclopedia Model %IEFUP
mmddhhmm.DN VERIFY.TRN X Encyclopedia Update Status Report (Duplicate Name Report)
4 FTP
binary format
Your entire subset is sent to the Encyclopedia and new model is created.
Concurrency Matrix
Y = THE TWO OPERATIONS CAN RUN CONCURRENTLY U = the operations can run concurrently if the subset names are different. blank = the operations cannot run concurrently
UPLOAD SUBSET OVERRIDE SUBSET RENAME SUBSET DELETE SUBSET COPY SUBSET CODEGEN RENAME MODEL DELETE MODEL PI IMPORT CRE MDL FROM SUBSET (DST) COPY MODEL (SRC) COPY MODEL (DST) TRIAL MERGE (ALL) MERGE OLD (DOM) MERGE OLD (SUB) MERGE NEW (BOTH) MERGE NEW (NEW) MODEL RESTORE REV ENG IMPORT MIGRATION (DST) ADOPTION (SRC) OBJECT RENAME OBJECT DELETE ADOPTION (DST) REPORTS Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y DOWNLOAD SUBSET CRE MDL FROM SUBSET (SRC) MIGRATION (SRC) MODEL BACKUP CONVERSION Y Y Y Y Y PI EXPORT Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y ESF EPORT Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
DOWNLOAD SUBSET UPLOAD SUBSET OVERRIDE SUBSET RENAME SUBSET DELETE SUBSET COPY SUBSET CRE MDL FROM SUBSET (SRC) CRE MDL FROM SUBSET (DST) CODEGEN RENAME MODEL DELETE MODEL COPY MODEL (SRC) COPY MODEL (DST) OBJECT RENAME OBJECT DELETE MIGRATION (SRC) MIGRATION (DST) ADOPTION (SRC) ADOPTION (DST) MODEL BACKUP MODEL RESTORE TRIAL MERGE (ALL) MERGE OLD (DOM) MERGE OLD (SUB) MERGE NEW (BOTH) MERGE NEW (NEW) PI IMPORT REV ENG IMPORT PI EXPORT ESF EXPORT REPORTS CONVERSION INTELLIGENT REGEN PACKAGING
U U U U U U Y U U U U U
U U U U U U U Y
U U U U U U U Y
U U U U U U U Y
U U U U U U U Y
U U U U U U Y
Y Y Y Y Y Y Y
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Y Y Y Y Y Y Y Y Y Y Y
Y Y Y Y Y Y Y
Y Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y
Y Y
Y Y
Y Y
Y Y
Y Y
Y Y
Y Y
Y Y
Y Y Y
Y Y Y Y
Y Y Y Y
Y Y Y Y
Y Y Y Y
Y Y Y
Y Y Y
Y Y Y
Y Y Y
Y Y Y
Y Y Y
Y Y Y
Y Y Y
Y Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y
Y Y Y Y Y Y Y
Y Y Y Y Y Y Y Y Y
Y Y Y Y Y Y Y
Y Y Y Y Y Y Y
Y Y Y Y Y
Y Y Y Y Y
Subset ALL = the entire model Note: This matrix shows only the concurrency matrix enforced by the Host Encyclopedia. Other types of contention, such as that caused by DB2 cannot be determined from this matrix.
Protection Conflict Table
Type Delete Modify Access
Meaning to completely remove an object to change and object to add references to an object; e.g. statements in action diagram reference entity types view only
How Many can get this? one person one person unlimited
Others Can Get Read only Access Read Only Modify Access Read only
Read Only
unlimited
Any
Alan D. Bartholomew Consultant
Protection Conflict Table Version 2

If the user requests an object with this protection and the object is in a checked out subset with this protection level or the expansion is incomplete Delete Modify Access Read (only) then the user will get the object with this protection Delete Modify Access Read read read read read access access access read modify modify access read delete modify access read
Where to get help 6
Function Key F1
Context sensitive help is available for most all objects within the Cool:Gen toolset.
can be accessed by highlighting or selecting the object and pressing the F1 key.
This type of help
Electronic Books / Information base
Every workstation should have a copy of Cool:Gens electronic books.
Electronic Books has tons of information ranging from Component Based Development concepts, Subsetting concepts, and Infrastructure. This is another good place to obtain answers to some of the more complex issues you encounter during your design, development, or deployment efforts
Technical Library
THE TECHNICAL LIBRARY CONTAINS TECHNICAL NEWSLETTERS, ARTICLES, AND WHITE PAPERS THAT ADDRESS SOME
RATHER INVOLVED COOL:GEN ISSUES.
Appendix 7
Deployment of Cool:Gen 4.1a Applications on Windows NT and Windows 95

Last Revised: 02/04/1998
This document was developed to assist in the deployment of Cool: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 Cool:Gen 4.1a toolset, is moved to another workstation on which the Cool:Gen 4.1a toolset is not installed. In order to accomplish this deployment, Cool: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 Cool:Gen GUI Runtime Files: from Cool: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 Cool:Gen Codepage File: from Cool:Gen directory to Deployment directory CODEPAGE.INI Cool:Gen Type Libraries: from Cool: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 Cool: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 Cool:Gen type libraries and applications: regedit.exe wroaf.reg regedit.exe <load modulename>.reg To register the Cool: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.
Deployment of Cool:Gen 5 Client Applications on Windows NT and Windows 95

This document was developed to assist in the deployment of Cool:Gen 5 applications on Windows NT and Windows 95 workstations. Deployment is the process in which an application, built on a workstation using the Cool:Gen 5 toolset, is moved to another workstation on which the Cool:Gen 5 toolset is not installed. In order to accomplish this deployment, Cool: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 Cool:Gen GUI Runtime Files for RDA: copy from Cool:Gen directory to Deployment directory CCMIDX.DLL CDCEX.DLL CENCX.DLL CENCX.LIB CIENCBH.H CODEPAGE.INI CSU50N.DLL CSUMG50N.DLL CTUXWSXN.DLL CTUXXN.DLL RTTTRC.DLL RTTTRC.LIB RTTTRC.CNT RTTTRC.HLP SDCEX.DLL SSREGS32.EXE TRSERVER.EXE TRTRACE.TIP TUXMG.DLL WRC500N.DLL
DCEMG.DLL ENCMG.DLL IEFMBT.DLL MGCFBN.DLL MGDCEN.DLL MGTUXN.DLL MQCLX.DLL MQSMG.DLL MQSVX.DLL NETTRACE.HLP OLEPRO32.DLL register files
WRE500N.DLL WRF500N.DLL WRG500N.DLL WRGUIN.DLL WRL500N.DLL WROA0000.TLB WROAF.REG WROF0000.TLB WRU500N.DLL XFCMN.DLL
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. Cool:Gen Client Manager Files for DPC: copy from Cool:Gen directory to Deployment directory BROWS50N.EXE CCMIDX.DLL CDCEX.DLL CENCX.DLL CENCX.LIB CIDE50N.DLL CIENCBH.H CIF50N.DLL CMMSG50N.DLL CODEPAGE.INI CSU50N.DLL CSUMG50N.DLL CTUXWSXN.DLL CTUXXN.DLL DCEMG.DLL DECRE50N.DLL ENCMG.DLL IEFCM50N.HLP IEFCM50N.EXE IEFCM50N.ICO IEFCM50N.DLL IEFCMN.INI IEFCMN.SRV IEFMBT.DLL IOTCP50N.DLL MGCFBN.DLL MGDCEN.DLL MGTUXN.DLL MQCLX.DLL MQSMG.DLL MQSVX.DLL NETTRACE.HLP OLEPRO32.DLL RTTTRC.DLL RTTTRC.LIB RTTTRC.CNT RTTTRC.HLP SDCEX.DLL SSREGS32.EXE TRSERVER.EXE TRTRACE.TIP TUXMG.DLL WRC500N.DLL WRE500N.DLL WRF500N.DLL WRG500N.DLL WRGUIN.DLL WRL500N.DLL
IO6250N.DLL IONB50N.DLL IOPP50N.DLL IORSC50N.DLL IORSC50N.LIB register files
WROA0000.TLB WROAF.REG WROF0000.TLB WRU500N.DLL XFCMN.DLL
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 Cool:Gen directory to Deployment directory xfdcen.dll xfmqin.dll xfmqsn.dll xfencn.dll xftuxn.dll xftuxwsn.dll DCE MQSeries MQSeries Encina Tuxedo 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.
Deployment of Cool:Gen 5.1 Client Applications on Windows NT, Windows 95 & Windows 98
Andy Hebert
This document was developed to assist in the deployment of Cool: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 Cool:Gen 5.1 toolset, is moved to another workstation on which the Cool:Gen 5.1 toolset is not installed. In order to accomplish this deployment, Cool: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 Cool: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 Cool:Gen GUI Runtime Files for RDA: Copy from Cool: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. Cool:Gen Client Manager Files for DPC: Copy from Cool: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: 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 Copy from Cool:Gen directory to deployment directory
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 CASCADE.DLL <load modulename>.HLP <load modulename>.DDE <load modulename>.REG Register files
all DLLs
<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.
Deployment of Cool:Gen 5.1 Web Client Applications on a Windows NT Web Server

This document was developed to assist in the manual deployment of Cool: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 Cool:Gen is not installed. For web clients, the target execution environment is a web server machine. In order to accomplish this deployment, Cool: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 Cool:Gen 5.1 Installation CD to install the TCP/IP or MQSeries runtime, the Cool: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 Cool: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 servers 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 Cool:Gen web client application expects to operate in a specific directory structure within your web servers home document directory. In the web servers home document directory (c:\inetpub\wwwroot), create a new subdirectory using the models 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 Cool:Gen Web Client Enablement Runtime Files Copy from Cool: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 Cool: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 (continued) Configure client/server communications
The Cool:Gen client runtime must know how to communicate with the Cool: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 Cool: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 servers home document directory (c:\inetpub\wwwroot)
*.shtml Copy from Cool:Gen directory on the development machine to web servers 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 engines servlet home (like c:\jrun\servlets)
*.class Application Files (continued) Copy from <model>/c++ directory on the development machine to deployment directory (c:\myapp)
*.dll *.reg 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 engines 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>
Finding SQL in C and Cobol Programs

Alan D. Bartholomew
Consultant
Finding SQL in a C Program

For most simple cases, you can find the SQL generated by Cool: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 the following word: procedure statements Heres a very simple example of what youll 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. Cool:Gen generates a 10-digit statement number. num =nnnnnnnnnn For the example above, do a find on: num = "0000000001" Heres a very simple example of what youll 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) Heres a very simple example of what youll 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.
Finding SQL in cobol

1. Find the statement number or the READ EACH you are trying to look for in this case 15. 15* 15* 15* 15* 15* 15* 15* 15* ! +=>READ EACH (Cursor Hold) p applicant ! ! p appliant_grade ! ! p vacancy_announcement_grade ! ! p vacancy_announcement ! ! SORTED BY ASCENDING p applicant last_name ! ! AND SORTED BY ASCENDING p applicant first_name ! ! AND SORTED BY ASCENDING p applicant middle_name ! ! 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 .
Registering the TE as a Service - regte Within a Command Prompt
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
Sam Glaser
Computer Associates Principal Consultant
Database Status Error Codes

BP BT CT 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. Non-numeric data was detected in a numeric field before a database access. This is always followed by message 45. 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. An error was encountered in the SQL statements. The SQL code and supporting information follows this message. An error was encountered in the supplied date or time duration modules. A record with the current identifier already exists on the database, and the "when duplicate found" clause was not included in the CREATE statement. This can be caused by one of several different errors:
DB DE DF DU
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 FE A non-recoverable error was encountered, usually an SQL error or database integrity problem. IA Data retrieved from the database is unusable because it does not match the permitted values for the field. This is detected after a database READ, and is always followed by message 41. EI An error was encountered in one of the supplied functions. 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. NF Not Found. Exception logic was not included in the previous read and the current action is invalid based on the read results. Add exception logic to the PAD.
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. VU A view was not populated under one of the following conditions: 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
Resolving DB2 805 Errors

Lawrence Joseph Barreca
USDA National Finance Center Computer Specialist (Programmer Analyst)
There are many reasons for an -805 DB2 error message.

research the more common reasons for the error.
Example 1 - DBRM member not bound to the DB2 collection
This give a couple of examples on how to
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, Cool: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. Figure 1
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. Figure 2
We can now verify the token in the DBRM that was generated by Cool: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. Figure 3
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. Figure 4
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.
Figure 5
We can now verify the token in the DBRM that was generated by Cool: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. Figure 6
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.
Steps in Solving Cool:Gen Errors
Some of the problem encountered in Cool: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: a. From the Options menu in the main Cool:Gen window, select Consistency Check Level and decipher the appropriate level. b. In either Analysis or Design menu items, depending on your development phase, Select Check.
2. Browse through the Cool:Gen toolset Help menu for runtime error codes The Cool: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.

Tips and Tricks Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tips and Tricks Guide

Încărcat de

Drepturi de autor:

Formate disponibile

COOL:GEN DEVELOPERS TIPS AND TRICKS

Scott D. Lanouette & Allan James G. Rubio

The palest ink is better than the best memory

Getting to Know Gen 1

7 | Cool:Gen Developers Tips and Tricks

8 | Cool:Gen Developers Tips and Tricks

Number 1 TipSave Often!

CTRL + V for Victory

9 | Cool:Gen Developers Tips and Tricks

Cool:Gen Model Directory Structure

Figure 1. 2 10 | Cool:Gen Developers Tips and Tricks

Important Model files

Contains model objects, properties, associations, and memory management tables.

11 | Cool:Gen Developers Tips and Tricks

IEF0700.DAT, DESCRIPTION FILE

How to Improve Performance

source: Cool:Gen Electronic Books Transaction Files

12 | Cool:Gen Developers Tips and Tricks

Figure 3 13 | Cool:Gen Developers Tips and Tricks

14 | Cool:Gen Developers Tips and Tricks

Cool:Gen Model Paths

15 | Cool:Gen Developers Tips and Tricks

16 | Cool:Gen Developers Tips and Tricks

Window Design Tips 2

17 | Cool:Gen Developers Tips and Tricks

18 | Cool:Gen Developers Tips and Tricks

Field Design List

19 | Cool:Gen Developers Tips and Tricks

Special Actions for Menu Items

20 | Cool:Gen Developers Tips and Tricks

Getting Rid of Help and Window Menu Items

Performing this task is as easy as clicking a checkbox.

Resizing Listbox Columns

21 | Cool:Gen Developers Tips and Tricks

The Selection Character

22 | Cool:Gen Developers Tips and Tricks

Selection Character Values

23 | Cool:Gen Developers Tips and Tricks

Mapping is the process of assigning Import Views to Export Views.

24 | Cool:Gen Developers Tips and Tricks

25 | Cool:Gen Developers Tips and Tricks

26 | Cool:Gen Developers Tips and Tricks

Importing Bitmaps to the Model Directory

27 | Cool:Gen Developers Tips and Tricks

Different Bitmap States

28 | Cool:Gen Developers Tips and Tricks

Positioning Window Objects

29 | Cool:Gen Developers Tips and Tricks

30 | Cool:Gen Developers Tips and Tricks

Designing with Grid On or Off

31 | Cool:Gen Developers Tips and Tricks

Rabbit TestOops, Rapid Test

32 | Cool:Gen Developers Tips and Tricks

33 | Cool:Gen Developers Tips and Tricks

34 | Cool:Gen Developers Tips and Tricks

Action Diagramming Tips 3

36 | Cool:Gen Developers Tips and Tricks

Open Window List Push Button

Action Block Synthesis

37 | Cool:Gen Developers Tips and Tricks

38 | Cool:Gen Developers Tips and Tricks

2. Create a user defined event, Figure 22.2.

3. Call the newly created user defined event, Figure 22.3.