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.
tips-fig20.1.bmp
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.
tips-fig20.2.bmp
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.
tips-fig21.bmp
This dialog box, Figure 21, can be accessed by clicking on Generate…Action Block Synthesis within a Process Action Diagram (PAD). Action Block Synthesis is very useful as a starting point in creating the action blocks that perform your system’s basic database functions. In fact, it is advisable to start with this action block and trim the unnecessary code afterwards.
Non-display procedures also have an automation technique that you could use. This is called Procedure Synthesis.
A TIREVENT is a special external action block used to trigger user defined events in your client procedure. Although it looks like a normal EAB stub, it is PRE-DEFINED to the CA Gen runtime components, and therefore does not have to be compiled outside of the toolset.
These are the precise steps that must be followed in order to successfully utilize this type of event.
1. Create a new action block and name it Tirevent. The action block should have one import view – a work view of IEF supplied command. The only line of code should be one defining the action block as external.
tips-fig22.1.bmp
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.
tips-fig22.2.bmp
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.
tips-fig22.3.bmp
Important: The code you placed within the event will be queued for execution. It is not executed in place like a normal action block call. The Tirevent will be executed once control is passed back to the window manager.
The phrase, “There is more than one way to do that” is applicable throughout the toolset. The Business System Defaults window is an area where this phrase is proven to be true. Within this window, the developer can perform such tasks as adding exit states and commands, and setting up default function keys attributes, edit patterns, and delimiters. The interfaces should be familiar. For example, the dialog box to create an 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.
tips-fig23.bmp
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.
tips-fig24.bmp
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.
tips-fig25.bmp
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.
NOTE: The Action Block Usage tool is limited to what objects are scoped in the currently checked out subset. To determine the true impact of an action block either checkout the entire model, or use the 'Delete Object' encyclopedia report, or use a third party tool.
View Matching is one of the most important concepts in CA Gen. It determines which data is passed from one action block to another. View Matching must be done as part of a USE, PROCEUDRE STEP USE, and USING statement. In these three cases, the View Matching interface is the same. There is a dialog box, for the imports and a dialog box for the exports.
The trick to view matching is to look at the CALLING and a CALLED action block as a ROUNDTRIP process. Just imagine that both your starting and ending point is always the workstation (client). Let us look at an example and Figure 26.
Sample procedure use statement: In this example Server Procedure B is being called by Client Procedure A in an event action.
EVENT ACTION call_server_procedure_b
**USE** server procedure b (procedure step)
**WHICH IMPORTS:** Entity View e_main view a TO Entity View i_main view a
**WHICH EXPORTS:** Entity View e_main view b FROM Entity View e_main view b
The same procedure step use statement:
USE server_procedure_b (procedure step)
server_procedure_b is the name of the action block or procedure you called.
WHICH IMPORTS: Entity View e_calling view a TO Entity View i_called view a
WHICH IMPORTS: This mean that you are SENDING whatever is in e_calling view a TO the i_called view a of the action block you called. The view to the right of TO is always the view of the called action block.
WHICH EXPORTS: This means that e_main view b is RECEIVING data FROM e_main view b of the action block you called. The action block you called is exporting back data you requested. The view to the right of FROM is always the view of the called action block.
WHICH EXPORTS: Entity View e_main view b FROM Entity View e_main view b
The View Neighbors option within Dialog Design is very useful for systems that have multiple procedures. To take advantage of this feature, highlight a procedure and click on View … Neighbors.
tips-fig27.bmp
In the above example, the procedure ‘HQ Employee Maintenance’ is highlighted. After selecting ‘Neighbors’ from the menu, only those procedures which flow to or from ‘HQ Employee Maintenance’ will appear in the Dialog Design window. All other procedures within the system will be hidden from view.
The READ EACH Properties pop-up window lets you specify properties common to all database management systems supported by CA Gen. In addition, you can set characteristics unique to a DBMS by selecting a tab at the top of the dialog box.
The dialog box (Figure 28), can be accessed by highlighting a read each statement within an action diagram and clicking and clicking Detail … Properties, or by double-clicking on the READ EACH statement.
tips-fig28.bmp
Double clicking on a bracket, regardless of the statement type, is a neat shortcut to use in order to select the contents within the bracket. Simply double click on the vertical line designating the left bracket border. The entire contents of the bracket will be highlighted, making Copy, Move, and Delete of multiple lines easier. This technique works for database statements, condition statements, events, and almost any other statement bracket that exists within the toolset. The only exception to this is the outermost bracket of an action block or procedure. If you double click even with the view definition at the top of the action block, the contents of the action diagram will not get selected. However, all contents of the action diagram will be highlighted if that double click occurs on the bracket at a point even with or below the first action diagram statement.
The Keypress event is the most unique event in the toolset. It is triggered much like a change event, but in the case of a keypress event, the code is executed each time a character is entered into a given field. What makes the keypress event unique is the ability given to the developer to trap the keystroke entered by the user. When a keypress event is created, a special view structure is added to the exports of the action block. By interrogating this export view, the developer can trap each stroke and control whether or not it is actually displayed in the entry field on the screen. Figure 29 describes how each of the keystroke view members is used in this process.
Notice that all of the attributes in the keypress work view are followed by a ‘3’. This is because multiple keypress events exist within this business system. Each time a keypress event is added within a business system, a unique set of attributes are created.
tips-fig29.bmp
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.
tips-fig30.bmp
When an event is created, the ‘Import to Export’ radio button is always set to ‘Default ’. For all other types of events, default means that import views are automatically moved to export views after the event is executed. The Changed Event is the exception - the views remain as they were before the event logic was executed.
There is a reason for this deviation from the norm for this event type. Based on certain conditions, the prior value in the field should be displayed instead of what was entered. For example, a default value may be displayed in an entry field. If the user makes an incorrect entry, the default value should remain displayed, not the entry that was made.
The developer can override the default value by choosing one of the other options in the Import to Export radio button group. The most common course of action is to change the selection to ALWAYS MOVE. If the default selection is not changed to ALWAYS MOVE, then the data entered in an entry field will not be automatically redisplayed.
The Customize Pop-Up Menu (Figure 31) option allows developers to select the commands they want to show, as well as set the order in which the commands appear on pop-up menus. This option is available on any window where a click of the right mouse button opens an in place menu within the diagram. The dialog box can be opened by clicking on Options… Customize Pop-Up Menu.
tips-fig31.bmp
To prevent an item from being displayed, highlight that item and click the ‘Hide’ button. The word ‘Hide’ will then appear next to the menu item in the Command Menu Hierarchy box. To promote an item (make it appear one level higher in the menu structure), highlight the item an click the ‘Promote’ button. The item will then appear in the Pop Up Menu Order box, and the word ‘Promote’ will appear next to the menu item in the Command Menu Hierarchy box. To make a hidden item visible again or to demote a promoted item, highlight the item in the Command and Menu Hierarchy box and click ‘Clear’.
NOTE: Menu customization is done on a diagram level. This means that if you change the Action Diagram pop up menu, the pop up menu launched within the Window Design tool will remain unchanged.
Located under Options on the main CA Gen window, the selection of Single or Multiple Adds determines how the toolset behaves when adding objects via a pop-up window. Selecting Single Add causes the pop-up window to appear only until one add is complete. When the OK pushbutton is pressed, the primary window is displayed. Selecting Multiple Adds causes the pop-up windows from which you are adding objects to remain displayed until the Cancel pushbutton is pressed. This enables the developer to add items repeatedly, without initiating the pop-up window each time.
CA Gen provides the developer with a variety of functions that perform data type conversion. Two of these functions are textnum and numtext. The textnum function converts a numeric value into a text string and the numtext function converts a text string into a numeric value.
The important thing to remember about both of these functions is that the numeric portion of the function bases its conversion on a field length of 15. This means that when using the numtext function, the receiving field must be at least 15 characters in length to ensure that no data is lost. If the target field is smaller than 15, the field is zero-filled to 15 characters and only the leftmost characters are displayed. For example, assume that the numeric field CHARSTRING = “1234” and TEXTSTRING is 15 characters long. Consider the statement:
SET TEXTSTRING = NUMTEXT(CHARSTRING)
In this example, the value of TEXTSTRING would be 000000000001234. If CHARSTRING were only 12 characters in length, the value of TEXTSTRING would be 000000000001.
The same type of logic applies to the textnum function. The target field must be at least 15 characters long to ensure that nothing is truncated in the conversion. In both cases, the developer can utilize the substr function to help control the values and field lengths returned.
The Event Locator button (Figure 32.1) is a very useful tool when attempting to navigate an action diagram which contains many events.
tips-fig32.1.bmp
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.
tips-fig32.2.bmp
tips-fig33.bmp
“When in the Dialog Design Diagram, the combination key, CTRL + I [zoom in], comes in handy when you cannot read the entire procedure name. After pressing this, you will able to see and tell which procedures are the clients and which are the servers.” Sheila E. Ratcliff, USDA National Finance Center, Computer Specialist (Programmer Analyst)
Notes in action diagrams: This point can not be stressed enough. It is good practice to place a note at the top of each PAD that contains a description of what the program does, and the person who developed it. This note can also serve as a change log, making maintenance easier for all the members of the development team. Notes should also be used within the body of the code. Here, a developer can explain why they designed something they way they did, as well as explain logic that may not be that easy to follow. It might seem like a little time consuming at first, but it sure does save time in the long run! Always use notes whenever you code. The next person looking at your code will thank you for it.
Setting up Mandatory relationships: Within the data model, each relationship is defined as mandatory or optional. As expected, the decision on how each relationship is defined is based on the customer’s business rules. However, it is important to consider archiving strategy during initial design. If the customer wishes to offload data after a certain period of time, the mandatory relationships that conformed to the business rules might end up making the implementation of an archiving strategy much more difficult. Consider enforcing mandatory relationships within the client code. The same thing can be said for enforcing restrictive delete rules in the data model. The fewer client procedures which maintain data for a given entity, the more beneficial client enforcement of business rules is to a development staff.
Utilizing the proxies: It is a good idea to make all of the import views on the server procedures optional. Why? Well, it is much more efficient to include required field logic on the client side. Otherwise, the server must send the required field error messages back across the data line, slowing down response time, and increasing the amount of time before an eventual successful transaction is processed.
<!-- wikipage stop -->