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.
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).
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.
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.
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:
An ’ sign is not valid in the first tranID field displayed. If one is used there, and in any consecutive fields, then those tranIDs are not changed from their current setting.
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).
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.
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.
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
The REQUESTMODEL Specification screen (Figure 220) shows you, one by one, each of the REQUESTMODEL definitions that is to be created.
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:
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.
Initially a default of N is used. When you change this, the change become the new default for subsequent REQUESTMODEL definitions.
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.
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.
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.
To quit, press PF3
CREA generates and displays a name for each REQUESTMODEL definition that is required. That generated name is produced as follows:
For example, if you overtype CREA1 with:
The same rules about truncation of the prefix apply when the succession of names is based on a string that you previously supplied by overtyping. This is true both when incrementing is on the point of taking you beyond the eight character maximum, and when you supply an over-long prefix by overtyping, for example, if you overtype with ELEPHANT, the following REQUESTMODEL name displayed would be ELEPHAN1.
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.
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:
Such REQUESTMODEL definitions may be redundant, and could potentially be removed from the CICS system (and from the CSD if applicable).
Such REQUESTMODEL definitions are no longer required by the bean, and could potentially be removed from the CICS system (and from the CSD if applicable).
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 ]]