CA Gen Training

Document created by Chris_Short Employee on Apr 7, 2011Last modified by Chris_Short Employee on Jun 13, 2014
Version 3Show Document
  • View in full screen mode

 

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.

Getting to Know Gen

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.

Gen Model Directory Structure

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)

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

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.

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

Model  Information

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. 

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

CA Gen  Model Paths

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. 

Window  Design Tips

Field  Design List

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. 

Special Actions for Menu Items

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. 

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.

As illustrated above, the user can also change the Foreground Color,  Background Color, and Font Size of the menu within the Menu Properties box. 

Resizing Listbox Columns

Once a list box is placed on a window, the developer can adjust the width of  the columns. This is done by placing the cursor over the column divider line  until a double arrow appears. Figure 9 shows a double-headed arrow in between  the columns “status” and “date-entered”. From there, it is a simple click and  drag procedure.

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.

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.

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

Specifying Commands

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.

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.

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.

Different Bitmap States

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

Video  Properties

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.

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

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.

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.

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

Rabbit Test…Oops, Rapid Test

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.

Action Diagramming Tips

Open Window List Push Button

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.

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.

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.

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

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.

Can I Use this Function?

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. 

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. 

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: Data Passing

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

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.

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

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.

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.

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

Converting Number to Text and  Text to Number

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.

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.

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.

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

Client Deployment Topics

Deployment Architecture

DEFAULTW.ICO

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. 

Build Tool Parameters: The  Win32itm.tgt File

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)

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

How To Verify CA Gen Environment  Variables

“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

Registration of CA 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 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

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 What’s 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.

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

Timestamp of Load Module  Executables

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.

Associating an EAB  Stub with the Desired External Code

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.

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

Subsetting Topics

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.

Checkout  Subset

Update With or Without Checkin

Resend  Last Update

Verify  Last Update

Comparing Update vs. Resend vs.  Verify

Generate New Model

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

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

Protection Conflict Table Version  2

Where to  Get Help

Function Key  F1

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.

Electronic Books / Information  Base

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. 

Technical  Library

The Technical Library contains technical newsletters, articles and white  papers that address some rather involved CA Gen issues.

Appendix

Deployment  of CA 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 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.

Deployment  of CA 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 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.

Deployment  of CA Gen 5.1 Client Applications on Windows NT, Windows 95 & Windows  98

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.

Deployment  of CA 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 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>

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

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

tried to restructure, but do not understand it enough to do that to my  satisfaction.

Registering  the TE as a Service - regte Within a Command Prompt

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

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:
  1. 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. 
  2. A view for an UPDATE has not been populated and locked. 
  3. 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:
  1. 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. 
  2. A view for an UPDATE has not been populated and locked. 
  3. 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.
  4. 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, 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. 

Steps in Solving CA Gen Errors

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.

Attachments

    Outcomes