Using CREA

CREA is defined in the DFHADST group and is automatically installed. Your CICS system must be set up to run Language Environment conforming C applications and Java.

CREA presents you with a series of screens as it progresses through its functions.

Note:
Choose a suitable code page to connect to your CICS system. If you don't, you'll see the square bracket characters [ and ] displaying strangely. One suitable code page is 1047 (United States English).

Starting CREA

Start the transaction by entering CREA (optionally followed by the name of a DJAR definition), on the command line of the screen. Press ENTER. If the DJAR name supplied is valid (that is: if it exists in CICS and is in a resolved state), you are shown the TranID Specification screen (Figure 218), which presents the functions available within CREA.

If you do not give the name of a DJAR definition, or if the DJAR definition you name is invalid, you are shown the initial screen (Figure 217) and a message indicating the state of the DJAR, or indicating that the DJAR was not found, (as is appropriate).

Command syntax

Read syntax diagramSkip visual syntax diagramCREA
 
>>-CREA--+----------+------------------------------------------><
         '-djarname-'
 

Command options

djarname
specifies the identifier of a DJAR definition that you want to work with. The names of the beans and methods in the JAR file associated with this DJAR definition are displayed alongside the tranIDs associated with each.

Response to CREA command

Figure 217. CREA transaction: initial screen
   CREA	  REQUESTMODEL Definition Transaction            APPLID

   Please enter the name of a DJAR you want to work with.

   DJAR name: ________              


   If you want to restrict the display of beans and methods within the 
   DJAR to those associated with a particular transaction then you can 
   use the tranID filter.  The * character can be used as a wildcard.  

 
   TranID filter: ____     
 
 
 
 
<Message Line >
 PF1=Help    3=Quit 

If you enter CREA with a valid DJAR name as a parameter, the initial screen (Figure 217) is not presented to you. Instead you are taken directly to the TranID Specification screen (Figure 218).

If you enter CREA with an invalid DJAR name as a parameter, the name you entered appears in the DJAR name field of the initial screen Figure 217.

If the status of the named DJAR definition is resolving, you have the opportunity to continue. To do so, press enter again and, if the DJAR is now resolved, you are taken to the TranID Specification screen (Figure 218).

This initial screen also offers you the opportunity to enter a tranID with which to filter the beans and methods displayed. The filter can be blank to display all beans and methods, or contain a string with optional wildcard characters (‘*’). If the filter field is not blank, only those beans and methods that match the filter are displayed.

TranID Specification

When a valid DJAR name has been entered, the TranID Specification screen is displayed. It shows tranIDs alongside the bean and method names that are defined in the deployment descriptor of the JAR file associated with the chosen DJAR definition.

Figure 218. CREA transaction: TranID Specification screen
   CREA	 REQUESTMODEL Definition Transaction            APPLID

   Associate a transaction ID with a bean or bean method.

   DJAR name: SampleEJB                             TranID filter:          

   TranID  Bean/Method/Parameters 
   

   CIRP     CICSSample                                     
   CIRP >      getCustomerInfo                             
                  int                                      
   CIRP >      getEJBHome (inherited from EJBObject)       
   CIRP >      getHandle (inherited from EJBObject)        
   CIRP >      getPrimaryKey (inherited from EJBObject)    
   CIRP >      isIdentical (inherited from EJBObject)      
                  javax.ejb.EJBObject                      
   CIRP >      remove (inherited from EJBObject)               
   


   
<Message Line>
 PF1=Help  3=Quit    5=Create ReqMods                       9=Hide Methods

The example given in Figure 218 shows the methods that were found in the Deployment Descriptor of the JAR file associated with DJAR definition SampleEJB .

The tranID that is to be used to execute requests (to be identified at run time by an installed REQUESTMODEL resource definition) precedes each of the beans and methods. If there are any currently installed REQUESTMODELs that relate tranIDs to any of the beans or methods in the JAR file, the REQUESTMODEL tranID is shown next to the relevant bean or method. In this example, it is the default value CIRP in every case.

The way that the tranID is determined is this:

The rules that influence the use, or not, of default values are :

You can see which tranIDs take default values if the bean tranID changes, because:

When entering tranID values:

At anytime during the process of assigning tranIDs, you can change the tranID filter. The filter causes the display to list only those beans and methods that match the filter. The filter can be blank to show all methods, or can contain a string with optional wildcard characters ('*'). Changes to the filter do not cause associations between tranIDs and beans and methods to be lost.

If you enter a new DJAR definition name, a message is displayed, indicating that you have changed the DJAR name, and prompting you to press enter to continue. If any other key is pressed as a response to this message, the DJAR definition name reverts to the current name.

When you have finished associating tranIDs with beans and methods, you can press PF5 to create the REQUESTMODEL definitions reflecting the tranID & bean/method relationships. This takes you to the REQUESTMODEL Specification screen (Figure 220).

Setting tranIDs for different kinds of remote method calls

You might consider three kinds of remote method calls that may be invoked for a given enterprise bean.

The primary purpose of CREA is to define REQUESTMODELs for the business methods, but CREA treats all three alike, so if, for example, you decide that a particular method on a bean is to run under a different transaction id from the others, or that all the remote methods for a given bean are to run under the same (but not the default) default transaction id, you can use CREA to arrange this.

In Figure 219, a DJAR called HelloWorldEJB, which contains a single enterprise bean called 'HelloWorld', is being processed. This bean has one business method, called 'hello', defined on the component interface. An existing REQUESTMODEL has been defined in the region which maps the 'hello' method of this bean to the 'WIBB' transaction id. All other methods run under the default CIRP transaction id.

Note:
WIBB and the CIRP above it appear in white, the CIRPs below WIBB appear in green.

The line which contains the bean name ('HelloWorld') can be used to set a default transaction id under which all methods on this bean will be invoked (including methods on the home interface). Below this are listed in alphabetical order the business methods of the bean. In this case, there is only one business method. Below the business methods are listed the five methods inherited from the component interface's super class (javax.ejb.EJBObject) - these same methods will be listed for all enterprise beans. Methods on the Home interface are not listed. If you want all the remote methods, including those on the home interface, to run under a specific transaction id then supply new default against the line which lists the bean name. This causes a REQUESTMODEL to be created with an interface type of 'both'. All other REQUESTMODELs are generated with an interface type of ‘remote’ and are only applied to the component interface.

If multiple overloaded method names (methods with the same name but different parameters) exist for a particular bean then a method name that includes wildcard characters will also be shown amongst the list of business methods. This is not illustrated in Figure 219. You can set a transaction id against this method name (that includes wildcard characters) in order to set the preferred transaction id for all the overloaded instances of that method.

In all cases, the most specific REQUESTMODEL defined is the one honoured at run time. So, a REQUESTMODEL set against a specific method will always be used in preference over one set against a set of overloaded methods, and this overloaded REQUESTMODEL will be used in preference to the default set against the entire bean.

Figure 219. CREA transaction: TranID Specification screen
   CREA	 REQUESTMODEL Definition Transaction            APPLID

   Associate a transaction ID with a bean or bean method.

   DJAR name: HelloWorldEJB                         TranID filter:          

   TranID  Bean/Method/Parameters 
   

   CIRP     HelloWorld                                 
   WIBB        hello                                   
                   java.lang.string                                            
   CIRP >      getEJBHome (inherited from EJBObject)   
   CIRP >      getHandle (inherited from EJBObject)      
   CIRP >      getPrimaryKey (inherited from EJBObject)  
   CIRP >      isIdentical (inherited from EJBObject)    
                  javax.ejb.EJBObject                                         
   CIRP >      remove (inherited from EJBObject)         
   


   
<Message Line>
 PF1=Help  3=Quit    5=Create ReqMods                       9=Hide Methods

REQUESTMODEL Specification

The REQUESTMODEL Specification screen (Figure 220) shows you, one by one, each of the REQUESTMODEL definitions that is to be created.

Figure 220. CREA transaction: REQUESTMODEL Specification screen
   CREA	CICS REQUESTMODEL Definition Transaction            APPLID

   Create a REQUESTMODEL definition

   Group:      _    Define to CSD: N   Install to CICS: N   Replace Dups: N

   REQUESTMODEL name CREA                   CORBASERVER EJB1
   
   TranID CIRP            

   Bean CICSSample                                             
                                                               
                                                               
                                                               
 
   Operation *                                                 
                                                               
                                                               
                                                               


<Message Line>
 PF1=Help   3=Quit     8=Skip ReqMod     ENTER=Create ReqMod 

For each REQUESTMODEL definition, the following information and input fields are shown shown:

Group: ________
If you select Define to CSD by entering a Y, .The Group field must contain the name of the group that is to hold the definition. The value given for Group becomes the default for each subsequent REQUESTMODEL definition, but can be changed again at any point.
Define to CSD: _
Indicate where you wish to create the REQUESTMODEL definition by entering a Y in the Define to CSD: field, or the Install to CICS: field, or both.

If you select Define to CSD:, the Group field must contain the name of the group that is to hold the definition. The value given becomes the default for each subsequent REQUESTMODEL definition, but can be changed again at any point.

Install to CICS: _
Indicate where you wish to create the REQUESTMODEL definition by entering a Y in the Install to CICS: field, or the Define to CSD: field, or both.
Replace Dups: _
To overwrite existing definitions (either already installed in CICS, or already defined in a group on the CSD), enter a Y in the Replace Dups: field. If this field is N, the existence of duplicate definitions is reported as a warning. When the warning is issued, you can choose to replace this duplicate definition by pressing PF9, or skip to the next definition with PF8.

Initially a default of N is used. When you change this, the change become the new default for subsequent REQUESTMODEL definitions.

REQUESTMODEL name: ________
For each REQUESTMODEL definition, a generated name is shown. As each is presented, you can:
Accept
this name and move on to the next REQUESTMODEL definition. For details about the naming of REQUESTMODEL definitions, see CREA generated REQUESTMODEL names.

To create the definition, press enter. Successful creation of the REQUESTMODEL definition causes the next to be displayed.

Also displayed is a message indicating the name of the REQUESTMODEL definition that you have just completed and where it was defined (installed into CICS, written to the CSD, or both).

When the last REQUESTMODEL definition has been processed, the Results screen is displayed with no message indicating creation (as that information is available as part of the Results information).

If the creation of a REQUESTMODEL definition fails for any reason, a message is returned to the user, with a redisplay of the screen that requested the creation of the failing REQUESTMODEL definition. This gives you the opportunity to correct any problems with the group or the name.

When you ask for both Define to CSD: and Install to CICS:, the creation of the REQUESTMODEL definition into CICS is attempted first. If the creation does not work, the definition is not written to the CSD. If the creation of the REQUESTMODEL definition into CICS works, but the definition to the CSD fails, and you make changes to the name or tranID, the REQUESTMODEL installed in CICS is altered (or deleted and recreated) as appropriate.

Override
the generated name, then accept the new name and move on. For details about the naming of REQUESTMODEL definitions, see CREA generated REQUESTMODEL names.

To create the definition, press enter. Successful creation of the REQUESTMODEL definition causes the next to be displayed. The remainder of Override processing is the same as for Accept.

Skip
this REQUESTMODEL definition and move to the next.

If you do not want to create the REQUESTMODEL definition displayed, press PF8 to move to the next definition, or to the Results screen if there are no more. If you choose to skip the REQUESTMODEL definition after an error has occurred, and the REQUESTMODEL definition was installed into CICS, but could not be defined to the CSD, the REQUESTMODEL definition is removed.

Quit
at any point.

To quit, press PF3

CORBASERVER: ____
The CORBASERVER, field is not available for change.
TranID: ____
The TranID field is not available for change.
Bean: ____
The Bean field is not available for change.
Operation: ____
The Operation field is not available for change.

CREA generated REQUESTMODEL names

CREA generates and displays a name for each REQUESTMODEL definition that is required. That generated name is produced as follows:

Results

When you have finished creating REQUESTMODEL definitions, the REQUESTMODEL results screen Figure 221 is displayed, summarising what you have done. It lists the REQUESTMODEL definitions that were installed into CICS and the REQUESTMODEL definitions that were written to the CSD. If more than one group was used to hold definitions, each group is listed with the REQUESTMODEL definitions it contains.

Figure 221. CREA transaction: REQUESTMODEL results screen
   CREA	CICS REQUESTMODEL Definition Transaction            APPLID

REQUESTMODEL definition is complete.     

REQUESTMODELs were processed for DJAR SampleEJB     

The following REQUESTMODELs were installed into CICS:    
RM1, RM2, RM3, RM4, RM5     

The following REQUESTMODELs were written to the CSD in group YOURNAME:    
RM2, RM5     

The following REQUESTMODELs match one or more beans in the DJAR, but either 
do not match any methods on that bean, or have been superceded by a newly 
created REQUESTMODEL.  These REQUESTMODELs are no longer needed and may 
be deleted:                         
RM7, RM8     

The following REQUESTMODELs contain a bean name that matches one or more of 
the beans in the DJAR because wildcard characters were used in the bean name.
These REQUESTMODELs are no longer needed to match the beans in this DJAR and 
may be deleted if other beans in other DJARs no longer require them: 
RM10, RM11     

The following TRANIDs were used, but are not currently installed:
TRN1, TRN2, TRN3, TRN4         

<Message Line>
 PF1=Help   3=Quit                           12=New DJAR

The following messages appear on this screen:

To work with another DJAR definition, restart CREA by pressing F12 to return to the initial, (or DJAR Specification), screen (Figure 217).

[[ Contents Previous Page | Next Page Index ]]