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