Вы находитесь на странице: 1из 158

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

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
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. The significance of some
of the files are described below.

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

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.

* The attribute has already been placed on the window. d 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.

h 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 doubleheaded arrow in between the columns status and date-entered. From there, it is a simple click and drag procedure.

F igure 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

* + < >
H A

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

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: 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.

2: 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.

3: 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

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

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.

Post

Move Files t

Check out client procedures with Read protection, Full Expansion, System test

load modu

load modu

load modu

load modu Delete contents of C/DDL directory Delete old files instead of overlaying and empty recycle bin. Not deleting always expand to the action block files may sometimes cause level. Play it safe, always choose generation problems as well as space problems. EXPAND ALL
Check OLE directory and OCX file View expand all, NOT expand

Change Path

Clicking on expand will only expand to the procedure step level. Expand all will

This path module ex

Generation Defaults Check target environment. If generating for only one environment do this set it, save it , and forget it.

Register File

Make sure ole file is in the models ole directory and is registered in its original path.

OCX DLL REG

other runt Include the defaultw.ico Add your customized icon file in the Cool:Gen directory.
Check Build Tool settings Trace ON / OFF

Include Spe

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

You may automate deployme

Check and Set build tool parameters.

Select GenerateCode Selected Try to be selective when generating code. This may save you time.

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: How does the application know what window to execute first if they are all packaged in one
big load module?

A: 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. WROA0000.tlb (application library) and
WROF0000.TLB (function library)

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 27KB 8/4/97 6:43 AM stubinfn.exe 64KB 8/4/97 6:43 AM stuboran.exe 25KB 8/4/97 6:43 AM stubs95n.exe 28KB 8/4/97 6:43 AM stubsybn.exe 82KB 8/4/97 6:43 AM stubxdbn.exe 28KB 8/4/97 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 MOVE ALL THE TIME

LOAD MODULE.REG ONLY MOVE ONCE

LOAD MODULE.SST 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
Encyclopedia Model

Workstation Mainframe
c:\models\<local name>.ief\
FTP Header CHECKOUT.TRN
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 Mainframe
IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT

Only changes are sent to the Encyclopedia -- not your entire subset.

Resend Last Update

Workstation Mainframe
IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT

c:\models\<local name>.ief\
Header UPDATE.TRN

Only changes are sent to the Encyclopedia -- not your entire subset.

Verify Last Update


IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT NFxxx.IEF.MSGS

Workstation Mainframe
c:\models\<local name>.ief\

Comparing Update vs. Resend vs. Verify

Generate New Model

IEF0000.DAT IEF1200.DAT IEF0700.DAT IEF2511.DAT

Mainframe
c:\models\<local name>.ief\
Header UPDATE.TRN

Workstation
Model Encyclopedia Generate New Model

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

D O W N L O A D S U B S E T

U P L O A D S U B S E T

O V E R R I D E S U B S E T

R E N A M E S U B S E T

D E L E T E S U B S E T

C O P Y S U B S E T

C R E M D L F R O M S U B S E T ( S R C )

C R E M D L F R O M S U B S E T ( D S T )

C O D E G E N

R E N A M E M O D E L

D E L E T E

C O P Y

C O P Y M O D E L ( D S T )

M O M D O E D L E L ( S R C )

O B J E C T R E N A M E

O B J E C T D E L E T E

M I G R A T I O N ( S R C )

M I G R A T I O N ( D S T )

A D O P T I O N ( S R C )

A D O P T I O N ( D S T )

M O D E L B A C K U P

M O D E L R E S T O R E

T R I A L M E R G E ( A L L )

M E R G E O L D ( D O M )

M E R G E O L D ( S U B )

M E R G E

I M P N N O E E R W W T ( B O T H ) ( N E W )

M E R G E

P I

R E V E N G I M P O R T

P I E X P O R T

E S F E P O R T

R E P O R T S

C O N V E R S I O N

D O W N L O A D S U B S E T U P L O A D S U B S E T O V E R R I D U

U U

U U

U U

U U

U U U Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

E S U B S E T R E N A M E S U B S E T D E L E T E S U B S E T C O P Y S U B S E T C R E M D L F R O M S U B S E T ( S R C ) C R E M D L F R O M

S U B S E T ( D S T ) C O D E G E N R E N A M E M O D E L D E L E T E M O D E L C O P Y M O D E L ( S R C ) C O P Y M O D E L ( D S T ) O B Y Y Y Y

J E C T R E N A M E O B J E C T D E L E T E M I G R A T I O N ( S R C ) M I G R A T I O N ( D S T ) A D O P T I O N ( S R C ) A D O P T I O N

Y Y

Y Y

Y Y

Y Y

( D S T ) M O D E L B A C K U P M O D E L R E S T O R E T R I A L M E R G E ( A L L ) M E R G E O L D ( D O M ) M E R G E O L D ( S U B )

M E R G E N E W ( B O T H ) M E R G E N E W ( N E W ) P I I M P O R T R E V E N G I M P O R T P I E X P O R T E S F E X P O R T R E P O R T

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

S C O N V E R S I O N I N T E L L I G E N T R E G E N P A C K A G I N G

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

Meaning to completely remove an object to change and object

How Many can get this? one person one person

Others Can Get Read only Access Read Only

to add references to an object; e.g. statements in action diagram reference entity types Access Read Only view only

unlimited

Modify Access 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. This type of help can be
accessed by highlighting or selecting the object and pressing the F1 key.

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

Last Revised: 09/25/1998

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 RTTTRC.DLL CDCEX.DLL RTTTRC.LIB CENCX.DLL RTTTRC.CNT CENCX.LIB RTTTRC.HLP CIENCBH.H SDCEX.DLL CODEPAGE.INI SSREGS32.EXE CSU50N.DLL TRSERVER.EXE CSUMG50N.DLL TRTRACE.TIP CTUXWSXN.DLL TUXMG.DLL CTUXXN.DLL WRC500N.DLL DCEMG.DLL WRE500N.DLL ENCMG.DLL WRF500N.DLL IEFMBT.DLL WRG500N.DLL MGCFBN.DLL WRGUIN.DLL MGDCEN.DLL WRL500N.DLL MGTUXN.DLL WROA0000.TLB MQCLX.DLL WROAF.REG MQSMG.DLL WROF0000.TLB MQSVX.DLL WRU500N.DLL NETTRACE.HLP XFCMN.DLL OLEPRO32.DLL

register files

WROAF.REG is an ASCII file containing location information for the type libraries. It contains path names that must be changed to indicate the current directory in which the typelib is deployed. (ie. if the typelib was deployed to C:\MYAPP then the paths in WROAF.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)

regedit.exe wroaf.reg ssregs32.exe WRU500N.DLL

Database Support Files for RDA:

The client software from the database vendor must be installed for connectivity to the database server.

Cool:Gen Client Manager Files for DPC:

copy from Cool:Gen directory to Deployment directory

BROWS50N.EXE IOTCP50N.DLL CCMIDX.DLL MGCFBN.DLL CDCEX.DLL MGDCEN.DLL CENCX.DLL MGTUXN.DLL CENCX.LIB MQCLX.DLL CIDE50N.DLL MQSMG.DLL CIENCBH.H MQSVX.DLL CIF50N.DLL NETTRACE.HLP CMMSG50N.DLL OLEPRO32.DLL CODEPAGE.INI RTTTRC.DLL

CSU50N.DLL RTTTRC.LIB CSUMG50N.DLL RTTTRC.CNT CTUXWSXN.DLL RTTTRC.HLP CTUXXN.DLL SDCEX.DLL DCEMG.DLL SSREGS32.EXE DECRE50N.DLL TRSERVER.EXE ENCMG.DLL TRTRACE.TIP IEFCM50N.HLP TUXMG.DLL IEFCM50N.EXE WRC500N.DLL IEFCM50N.ICO WRE500N.DLL IEFCM50N.DLL WRF500N.DLL IEFCMN.INI WRG500N.DLL IEFCMN.SRV WRGUIN.DLL IEFMBT.DLL WRL500N.DLL IO6250N.DLL WROA0000.TLB IONB50N.DLL WROAF.REG IOPP50N.DLL WROF0000.TLB IORSC50N.DLL WRU500N.DLL IORSC50N.LIB XFCMN.DLL

register files

WROAF.REG is an ASCII file containing location information for the type libraries. It contains path names that must be changed to indicate the current directory in which the typelib is deployed. (ie. if the typelib was deployed to C:\MYAPP then the paths in WROAF.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)

regedit.exe wroaf.reg ssregs32.exe WRU500N.DLL

Communications Middleware Files for DPC:

copy from Cool:Gen directory to Deployment directory

xfdcen.dll DCE xfmqin.dll MQSeries xfmqsn.dll MQSeries xfencn.dll Encina xftuxn.dll Tuxedo xftuxwsn.dll Tuxedo

The client software from the communications middleware vendor must be installed for connectivity to the server.

Application Files

Each application requires one deployment per workstation.

Executable and Support Files:

copy from <model>/c directory to Deployment directory

<load modulename>.EXE *.DLL all DLLs <load modulename>.SST <load modulename>.HLP <load modulename>.DDE <load modulename>.REG

<load modulename>.REG is an ASCII files containing location information for the application. It contains path names that must be changed to indicate the current directory in which the application is deployed. (ie. if the application was deployed to C:\MYAPP then the paths in <load modulename>.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)

regedit.exe <load modulename>.reg

OCX / OLE Files:

All OCX controls and OLE servers used in the application have to be installed on the Workstation. Each requires one deployment per workstation. Refer to the installation instructions from the OCX supplier.

copy from Windows System directory (NT: winnt/system32 or W95: windows/system) to Windows System directory

OLEAUT32.DLL OLEPRO32.DLL

register files

ssregs32.exe OLEPRO32.DLL

Support Application Files:

Any applications that have been used to create the contents of an OLE AREA must be installed on the deployment target to get in-place or out-of-place activation. For example, if an Excel spreadsheet is placed in an OLE AREA on a window, then Excel would have to be installed on the deployment target to activate and edit the OLE AREA contents.

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:

Copy from Cool:Gen directory to deployment directory

DCE DCECF51N.DLL DCECX51N.DLL DCEMG51N.DLL DCEMO51N.DLL DCESX51N.DLL MQ Series

CFBMO51N.DLL MQICF51N.DLL MQSCF51N.DLL MQSCX51N.DLL MQSMG51N.DLL MQSSX51N.DLL ENCINA DCEMO51N.DLL ENCCF51N.DLL ENCCX51N.DLL ENCMG51N.DLL ENSCF51N.DLL ENSCX51N.DLL ENSSX51N.DLL PPCCF51N.DLL PPCCX51N.DLL PPCMG51N.DLL TUXEDO TXWCF51N.DLL TXCF51N.DLL TXCX51N.DLL TXWCX51N.DLL TXMG51N.DLL TXMO51N.DLL TCP CFBMO51N.DLL TCPCF51N.DLL TCPCX51N.DLL TCPMG51N.DLL

The client software from the communications middleware vendor must be installed for connectivity to the server.

Application Files

Each application requires one deployment per workstation.

Executable and Support Files:

Copy from <model>/c directory to deployment directory

<load modulename>.EXE <load modulename>.DLL all DLLs CASCADE.DLL <load modulename>.HLP <load modulename>.DDE <load modulename>.REG

Register files

<load modulename>.REG is an ASCII files containing location information for the application. It contains path names that must be changed to indicate the current directory in which the application is deployed. (ie. if the application was deployed to C:\MYAPP then the paths in <load modulename>.REG should be changed to C:\MYAPP instead of the default which is C:\IEF.)

regedit.exe <load modulename>.reg

OCX / OLE Files:

All OCX controls and OLE servers used in the application have to be installed on the Workstation. Each requires one deployment per workstation. Refer to the installation instructions from the OCX supplier.

Copy from Windows System directory (NT: winnt/system32 or W95/W98: windows/system) to Windows System directory

OLEAUT32.DLL OLEPRO32.DLL

Register files

regsvr32.exe OLEPRO32.DLL

Support Application Files:

Any applications that have been used to create the contents of an OLE AREA must be installed on the deployment target to get in-place or out-of-place activation. For example, if an Excel spreadsheet is placed in an OLE AREA on a window, then Excel would have to be installed on the deployment target to activate and edit the OLE AREA contents.

Deployment of Cool:Gen 5.1 Web Client Applications on a Windows NT Web Server

Last Revised: 03/28/2000

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

0 inetpub 0 wwwroot 0 <model short name> 0 bitmap 0 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

0 winnt

9 0 system32 9 9 <Microsoft supporting runtime files> 0 inetpub 9 0 wwwroot 9 9 0 <model short name> 9 9 9 0 bitmap 9 9 9 9 *.jpq 9 9 9 9 *.gif 9 9 9 9 *.png 9 9 9 *.HTML 9 9 9 *.JS 9 9 9 *.CSS 9 9 9 purge.properties 9 9 *.SHTML 9 9 COOLGen_Default.html 9 9 COOLGen_End.html 9 9 COOLGen_History.js 9 9 COOLGen_Make.js 9 9 COOLGen_pageDn.gif 9 9 COOLGen_pageLt.gif 9 9 COOLGen_pageRt.gif 9 9 COOLGen_pageUp.gif 9 9 COOLGen_rowDn.gif 9 9 COOLGen_rowLt.gif 9 9 COOLGen_rowRt.gif 9 9 COOLGen_rowUp.gif 0 jrun

9 0 servlets 9 9 *.class 0 myapp 9 *.dll 9 *.reg 9 runtimesupport.jar 9 Validation.jar 9 <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* ! +=>READ EACH (Cursor Hold) p applicant 15* ! ! p appliant_grade 15* ! ! p vacancy_announcement_grade 15* ! ! p vacancy_announcement 15* ! ! SORTED BY ASCENDING p applicant last_name 15* ! ! AND SORTED BY ASCENDING p applicant first_name 15* ! ! AND SORTED BY ASCENDING p applicant middle_name 15* ! ! AND SORTED BY ASCENDING p applicant

2. Do a find/ Refind using the 10 digit statement number found above 0000000015. The figure below should be what you are looking for.

COMPUTE LAST-STATEMENT-NUM = 0000000015 MOVE N TO READ-EACH-0043647041-ESC-FLAG PERFORM PARA-0023461916-OPEN THRU PARA-0023461916-OPEN-EXIT IF SL-23461916 NOT = SUCCEEDS

READ

1.

COMPUTE LAST-STATEMENT-NUM = 0000000012 PERFORM PARA-0000000000-TRACE THRU PARA-0000000000-TRACE-EXIT IF TRACE-RET-CD NOT = 8 PERFORM PARA-0158351222 THRU PARA 0158351222-EXIT EVALUATE SL-158351222

2.

MOVE SUCCEEDS TO SL-23461916 the SQL should be above this .

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 Data is unusable because it does not match the permitted values for the field. This is detected before a database access and is always followed by message 40. BT Non-numeric data was detected in a numeric field before a database access. This is always followed by message 45. CT When the Enforce Data Modeling Constraints option is selected for code generation, checks are generated to ensure that whenever a row is added to the database, all mandatory relationships are created as well. These checks are generated at the exit from the action block that includes the CREATE verb. If any mandatory relationship is missing, the transaction is aborted, and the CT code is set. DB An error was encountered in the SQL statements. The SQL code and supporting information follows this message. DE An error was encountered in the supplied date or time duration modules. DF A record with the current identifier already exists on the database, and the "when duplicate found" clause was not included in the CREATE statement. DU This can be caused by one of several different errors:

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. This give a couple of examples on how to research the
more common reasons for the error.

Example 1 - DBRM member not bound to the DB2 collection

You just received the error message below (Figure 1). In this first example the error message shows a DBRM token 167B2F34195D9880 for action block PDA_3108U_HOLD_REQUEST. This is the version of the DBRM that is linked into load module PD25. At generation time, 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:

1. From the Options menu in the main Cool:Gen window, select Consistency Check Level and decipher the appropriate level. 2. 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.

Вам также может понравиться