Syntax
+-Connection(name)---+
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-LSRpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--attribute list(newvalue)------------------------------------><
You can use the same name for more than one resource definition in a group, if the definitions are for different resource types. For example:
DEFINE PROGRAM(N28A) GROUP(N28APPL)
DEFINE TRANSACTION(N28A) GROUP(N28APPL)
DEFINE TERMINAL(USER) GROUP(USERDEF)
DEFINE PROGRAM(USER) GROUP(USERDEF)
Be careful, when you have any resource definitions with the same name, that you install the one you really want. See Duplicate resource definition names.
You must specify the resource type and name on the command line. You may also specify the group and other attributes on the command line.
The whole definition is displayed on an overtype-to-modify panel, and you can change any of the attributes there, unless you entered a complete DEFINE command on the command line, in which case you can not change the name or groupname attributes.
The definition was created when you entered the DEFINE... command. If you do not wish to further modify it, you may enter another command from the command line.
If a resource definition of the same name and type already exists in the group, any attributes specified on the command line are ignored, and the existing resource definition is displayed. You can then overtype and modify any of the existing values if you wish. If you do not wish to modify the definition, you may enter another command from the command line.
Beware of overtyping values on which other attribute values are dependent. See Creating groups and lists.
Options
Attribute list
The attribute list depends on the resource type being defined; some resources have attributes that must be included in the definition. Attributes that you do not specify are given default values.
Group(groupname)
specifies the name of the group containing the resource definition being defined. Do not use a generic group name. If you specify the name of a group which does not already exist, the group is created.
resource(name)
specifies the name of the resource you want to define. Do not use a generic resource name.
Dynamically make the resource definitions in the named group or group list available to the active CICS(R) system.
Syntax
+-ALl(name)----------+
+-Connection(name)---+
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-Djar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-Lsrpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--+-Group(groupname)-+----------------------------------------><
'-List(listname)---'
You can use single-resource install to install only the resources you require.
When applied to telecommunication and intercommunication resources, there are restrictions on the single-resource INSTALL command. The restrictions apply to resource definitions that are linked--for example, CONNECTION and SESSIONS definitions.
You can install the following resource types only as part of a group:
· CONNECTION definitions, except a CONNECTION with ACCESSMETHOD(INDIRECT)
· SESSIONS definitions
· TERMINAL definitions for pipeline terminals that share the same POOL.
If you want to use single-resource INSTALL for TERMINAL and related TYPETERM definitions, you must install the TYPETERM that is referred to by a TERMINAL definition before you install the TERMINAL definition.
The same applies when installing groups containing TERMINAL and TYPETERM definitions; install the group containing the TYPETERM definition before you install the group containing the TERMINAL definition. Similarly, if you install a list that contains groups containing TERMINAL and TYPETERM definitions, the group containing the TYPETERM definition must be before the group containing the TERMINAL definition. Also, in a list containing groups of DB2(R) resource definitions (DB2CONN, DB2ENTRY, and DB2TRAN definitions), the DB2CONN should be defined in the first group in the list.
A CORBASERVER definition must be either in the same group as the DJAR definitions that refer to it, or in a group that is installed before the group containing those DJAR definitions.
If the named resource already exists in the active CICS system, the existing definition is replaced by the new one.
Replacement of an existing definition occurs only if it is not actually in use.
If the installation of one or more of the resources in the group(s) being installed fails because the resource is in use or for any other reason, the following takes place:
1. The install process continues with the next resource in the group.
2. When the group install is complete, if the resource that failed was part of an installable set, all the resources in the installable set are backed out. Resources that were committed at the individual resource level are not backed out. For a list of the resource types that are committed as part of an installable set, see What happens when you use the INSTALL command.
3. A message is displayed to indicate that the group has been only partially installed. A message is also produced on the message panel for each of the resources that failed to install, stating the reason for each failure. No messages are produced for those resources that have been backed out.
In addition, a message is written to the CEMT log, saying that the install completed with errors.
CEDA INSTALL can be performed from a console, using the MVS(TM) MODIFY command.
Options
Group(groupname)
specifies the group to be installed, or containing the resource to be installed. A generic group name is not accepted.
List(listname)
specifies the list of groups to be installed, or containing the resource to be installed. A generic list name is not accepted.
resource(name)
specifies the resource to be installed.
If you want to use singe-resource install for ENQMODEL, remember that ENQMODELs usually have the default status of ENABLED, so the order of installing ENQMODELs must follow the rules for ENABLING ENQMODELs; that is, ENQMODELs forming nested generic ENQnames must be enabled in order from the most to the least specific. For example, ABCD* then ABC* then AB*.
Syntax
You can use the ADD command from a DISPLAY screen.
Options
After(groupname3)
You can use this to control the placing of the new group name. If you do not specify BEFORE or AFTER, the group name is added at the end of the list.
Before(groupname2)
You can use this to control the placing of the new group name. If you do not specify BEFORE or AFTER, the group name is added at the end of the list.
Group(groupname1)
specifies the name of the group to be added. The name must not already exist in the list. A generic group name is not accepted. If you do not specify a group, the current group name is added.
LIst(listname)
specifies the name of the list to which the group is to be added. If the list does not already exist, a new one is created. If LIST is not specified, the group name is added to the current list if there is one. A generic list name is not accepted.
Examples
To create a list LA01 by adding a group to it:
ADD GROUP(GA001) LIST(LA01)
To add another group to list LA01, without specifying where:
ADD GROUP(GA002) LIST(LA01)
LA01 now looks like this:
· GA001
· GA002
To add another group at the top of the list:
ADD GROUP(GA003) LIST(LA01) BEFORE(GA001)
and another group between GA001 and GA002:
ADD GROUP(GA004) LIST(LA01) AFTER(GA001)
LA01 now looks like this:
· GA003
· GA001
· GA004
· GA002
Syntax
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-Lsrpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--attribute list(new value)-----------------------------------><
Do not use ALTER to change the value of the attributes of a TYPETERM definition on which other attributes depend. If you make a mistake with DEVICE, SESSIONTYPE, or TERMMODEL, delete the definition and define a new one with the correct values.
You can specify null attribute values, for example:
ALTER FILE(TEST) GROUP(ACT1) DESCRIPTION()
If an attribute for which you have specified a null value has a default, the value used depends upon the type of field. For example:
· The command:
ALTER FILE(TEST) GROUP(ACT1) RLSACCESS()
behaves as if RLSACCESS was not specified. The RLSACCESS attribute has a CVDA default value which is ignored.
· The command:
ALTER FILE(TEST) GROUP(ACT1) DESCRIPTION()
has the effect of blanking out the description, as there is no default value for the DESCRIPTION field, and it is option.
· The command:
ALTER FILE(TEST) GROUP(ACT1) PROFILE()
puts the default value of DFHCICSA into the PROFILE field. In this case, the default value is a character string, not a CVDA value.
Changes to resource definitions in the CSD file do not affect the running CICS(R) system until you install the definition, or the group in which the resource definition resides.
You can use CEDA ALTER from a DISPLAY panel. If you use PF12 after making your alterations, CEDA gives you the DISPLAY panel again, with an 'ALTER SUCCESSFUL' message in the Date and Time fields. If you do this but do not make any alterations, an asterisk replaces your 'ALTER' command.
With a generic name, you can use one ALTER command to change the same attributes in the same way on more than one resource definition.
Options
Attribute list
specifies the attributes to be altered.
Group(groupname)
specifies the name of the group containing the resource to be altered.
resource(name)
specifies the resource whose attributes you want to alter.
Examples
To make a program resident:
ALTER PROGRAM(ERR01) GROUP(GENMODS) RESIDENT(YES)
DATALOCATION()
To change the status of a whole group of programs:
ALTER PROGRAM(*) GROUP(GENMODS) STATUS(ENABLED)
If you do not specify an attribute list and type in:
ALTER PROGRAM(ERR01) GROUP(GENMODS)
CEDA gives an "ALTER SUCCESSFUL" message followed by the 'overtype to modify' panel.
Syntax
LIst(listname1)
specifies the source list to be appended. A generic list name is not accepted.
To(listname2)
specifies the target list to be appended to. A generic list name is not accepted. If listname2 already exists, the source list is appended to it. If listname2 does not exist, it is created.
Examples
A list called LISTA contains the following groups:
· GB001
· GB002
· GB003
A list called LISTB contains the following groups:
· G001
· G002
· G003
Append LISTB to LISTA, like this:
APPEND LIST(LISTB) TO(LISTA)
After this, LISTA contains the following groups, in this order:
· GB001
· GB002
· GB003
· G001
· G002
· G003
and LISTB still contains:
· G001
· G002
· G003
The CEDA CHECK command
Check the consistency of definitions.Syntax
>>-CEDA--CHeck-------------------------------------------------->
>--+-Group(groupname)---------------------------------+---------> '-List(listname1, listname2, listname3, listname4)-' >--+---------------------+------------------------------------->< '-Remotesystem(sysid)-' Description
The CHECK command performs a cross-check of a group, list, or lists of resource definitions, and should be used before the resource definitions are installed.It checks that the resource definitions within the group or lists are consistent with one another.
For example: for each TRANSACTION in the list being checked, a check is made that the named PROGRAM definition exists in one of the groups. The success of the check does not necessarily mean that the PROGRAM is available to the running system.
Lists should be checked before being used to initialize CICS(R) during an initial or cold start (when the list or lists are specified in the GRPLIST system initialization parameter).
A group should be checked before you use the INSTALL command to install it on the running CICS system.
A group can be checked before you use the ADD command to add the group to a list. (The group might not be self-contained, in which case there is no point in checking it alone. Put it into a list with the groups containing related resource definitions.)
You can use the CHECK command from a DISPLAY panel.
Checking groups and lists of resource definitions for consistency
Checking terminal definitions
Checks on definitions of DB2 connection resources
Checks on definitions of DB2 entry resources
Checks on definitions of DB2 transaction resources
Checking terminal definitions
Checks on definitions of DB2 connection resources
Checks on definitions of DB2 entry resources
Checks on definitions of DB2 transaction resources
Checking groups and lists of resource definitions for consistency
The CHECK command checks the consistency of definitions within a group or within all of the groups within a list. It does not, however, cross-check every attribute of a resource. You may still get error messages when installing a group although you found no problems when using the CHECK command.If you use the CHECK GROUP command, CEDA cross-checks all of the resources in a specified group to ensure that the group is ready to be used. For example, CHECK might warn you that a transaction definition within the group does not name a program within the same group. (Note, however, that this might not be an error. The group might intentionally be paired with a group that does contain the program, or you may want the program to be autoinstalled, in which case it would not have a definition.)
If you use the CHECK LIST command, CEDA cross-checks every group named in the list or lists. It does not simply check each group in turn, but merges the definitions in all of the listed groups, and checks them all. In this way it warns you if there are duplicate resource definitions, or references to definitions that do not exist.
Options
Group(groupname)
specifies the group you want to check. A generic group name is not accepted.
List(listname1, listname2, etc.)
specifies the list or lists you want to check. A generic list name is not accepted.
Remotesystem(sysid)
specifies that a check is to be run on a group or list in a CICS region with a different sysid from the region that the CHECK command is being issued from. If this option is not used, the CHECK command will use the sysid of the region from which the CHECK command is issued.
Syntax
>>-CEDA--COpy--+--------------------+--Group(groupname)--------->
+-Connection(name)---+
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-Lsrpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--+-AS(newname)-------------------+--+---------+--------------><
+-TO(newgroupname)--------------+ +-Replace-+
'-AS(new-name) TO(newgroupname)-' '-MErge---'
If you do not specify either MERGE or REPLACE, a message warns you that you are attempting to create duplicate resources, and your COPY will be unsuccessful.
Options
AS(newname)
If you copy a definition within a group, you must use AS to rename it. You can also use AS if you want to copy a definition to another group and rename it at the same time. You cannot use a generic name when using AS.
Group(groupname)
specifies the group containing the definitions to be copied.
MErge
This applies when there are duplicate definition names in the groups named in the COPY command. If you specify MERGE, duplicate definitions in the TO group are not replaced.
Replace
This applies when there are duplicate definition names in the groups named in the COPY command. If you specify REPLACE, the definitions being copied replace those in the group named in the TO operand.
resource(name)
specifies the resource you want to copy. The default is ALL, which copies all the resource definitions in a group to another group.
TO(newgroupname)
You can copy definitions to a different group, using TO to specify the new group.
Examples
You can copy a single resource definition into a new group, using the TO option to specify the new group. For example:
COPY SESSIONS(L122) GROUP(CICSC1) TO(CICSC2)
You can copy a resource definition within the same group. If you do this, you must rename it using the AS option. For example:
COPY TERMINAL(TD12) AS(TD34) GROUP(TERMVDU1)
When copying between groups, you can give the copy a new name, using the AS option to specify the new name.
COPY PROGRAM(ABC01) GROUP(XYZ) AS(ABC02) TO(NEWXYZ)
(If you leave the copy with the same name as the original definition, be careful that you install the one you want when the time comes.)
Using the ALL option, without a name, you can copy all the resource definitions in the group to the new group. For example:
COPY ALL GROUP(N21TEST) TO(N21PROD)
You can copy more than one resource definition to a new group, using the TO option to specify the new group.
Using a generic resource definition name, you can copy all or some definitions of the same resource type to the new group. For example:
COPY CONNECTION(*) GROUP(CICSG1) TO(CICSG2)
COPY PROGRAM(N21++) GROUP(NTEST) TO(NPROD)
Using the ALL option with a generic name, you can copy all or some of the resource definitions in the group to the new group. For example:
COPY ALL(N21*) GROUP(N21OLD) TO(N21NEW)
Using the ALL option with a specific name, you can copy all the resource definitions of that name (which must necessarily be for different resource types) in the group to the new group. For example:
COPY ALL(XMPL) GROUP(EXAMPLE) TO(EX2)
If you are copying a number of definitions into another group, and the groups contain duplicate resource names, you must specify either MERGE or REPLACE. For example:
COPY ALL GROUP(TAX1) TO(TAX2) MERGE
COPY ALL GROUP(TAX1NEW) TO(TAX1) REPLACE
The following example copies a group named GA001 to a group named GA002, which already exists, replacing any duplicate resource definitions by those in group GA001.
COPY GROUP(GA001) TO(GA002) REPLACE
The following example copies group GA003 to group GA004, but if any duplicate definitions occur, preserves the group GA004 definitions.
COPY GROUP(GA003) TO(GA004) MERGE
Syntax
+-Connection(name)---+
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-LSRpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--+--------+--------------------------------------------------><
'-REMove-'
Deleting a resource definition is different from removing a group from a list (see The CEDA REMOVE command). A deleted resource definition really does disappear from the CSD file.
When you DELETE the last resource in a group, the group is automatically deleted. An empty group cannot exist.
This command does not affect definitions installed on the active CICS(R) system. To remove installed definitions from the active CICS system, you can use either the CEMT DISCARD transaction or the EXEC CICS DISCARD command in an application program. You can discard AUTINSTMODEL, FILE, PARTNER, PROFILE, PROGRAM, TRANCLASS, and TRANSACTION resources. For information on the CEMT transaction, see CICS Supplied Transactions. For programming information on the EXEC CICS DISCARD command, see the CICS System Programming Reference.
Options
#All
#specifies that all resources are to be deleted from the group.
Group(groupname)
specifies the group containing the resource. Do not use a generic group name.
REMove
specifies that, when a group is deleted, the group is to be removed from all lists that had contained it.
resource(name)
#specifies the resource you want to delete. You can use a generic #resource name.
Examples
To delete all resources in a group:
#DELETE ALL GROUP(TOPS)
To delete all programs in a group:
DELETE PROGRAM(*) GROUP(NSOS)
The CEDA DISPLAY command
Display one or more group names, list names, or resources on a full screen panel.Syntax
>--+-List(listname)--+------------------+-----------------+---->< | '-Group(groupname)-' | '-Group(groupname)--+--------------------+--+--------+-' +-ALl(name)----------+ '-REname-' +-Connection(name)---+ +-CORbaserver(name)--+ +-DB2Conn(name)------+ +-DB2Entry(name)-----+ +-DB2Tran(name)------+ +-DJar(name)---------+ +-DOctemplate(name)--+ +-Enqmodel(name)-----+ +-File(name)---------+ +-Journalmodel(name)-+ +-Lsrpool(name)------+ +-Mapset(name)-------+ +-PARTItionset(name)-+ +-PARTNer(name)------+ +-PROCesstype(name)--+ +-PROFile(name)------+ +-PROGram(name)------+ +-Requestmodel(name)-+ +-Sessions(name)-----+ +-TCpipservice(name)-+ +-TDqueue(name)------+ +-TErminal(name)-----+ +-TRANClass(name)----+ +-TRANSaction(name)--+ +-TSmodel(name)------+ '-TYpeterm(name)-----' Description
The CEDA DISPLAY GROUP command
You can enter the following commands next to the names on the panel: On this panel, all these commands can be abbreviated down to their initial letter. It is unnecessary to type the group name. For the syntax of each command, see that command in this section.
To DISPLAY the group names, you must use a generic name. For more information about using the DISPLAY panel, see Figure 42 and Figure 43.
The CEDA DISPLAY LIST command
- Displays one or more list names on a full screen panel.
- You can enter the following commands next to the names on the panel:
- CHECK
- DISPLAY GROUP
- EXPAND2
- LOCK
- UNLOCK
On this panel, all these commands can be abbreviated down to their initial letter. It is not necessary to type the list name. For the syntax of each command, see that command in this section.
- To DISPLAY the list names, you must use a generic list name.
- For more information about using the DISPLAY panel, see Figure 42 and Figure 43.
Options
Group(groupname)
specifies the name of the group to be displayed. You can use a generic group name.
List(listname)
specifies the name of the list to be displayed. You can use a generic list name.
REname
This option applies only to GROUP. Specifying RENAME allows you to rename resource definitions within the group.
resource(name)
specifies the name of the resource to be displayed.
Examples
To display all groups on the CSD file:
DISPLAY GROUP(*)To display all groups whose names begin with PROD and have seven characters:
DISPLAY GROUP(PROD+++)To display all lists on the CSD file:
DISPLAY LIST(*)To display all lists whose names begin with PROD and have five characters:
DISPLAY LIST(PROD+)The CEDA EXPAND command
Show the resource definitions in one or more groups or lists. This command has been retained for compatibility with previous releases.Syntax
>--+-List(listname)--+------------------+-----------------+---->< | '-Group(groupname)-' | '-Group(groupname)--+--------------------+--+--------+-' +-ALl(name)----------+ '-REname-' +-Connection(name)---+ +-CORbaserver(name)--+ +-DB2Conn(name)------+ +-DB2Entry(name)-----+ +-DB2Tran(name)------+ +-DJar(name)---------+ +-DOctemplate(name)--+ +-Enqmodel(name)-----+ +-File(name)---------+ +-Journalmodel(name)-+ +-Lsrpool(name)------+ +-Mapset(name)-------+ +-PARTItionset(name)-+ +-PARTNer(name)------+ +-PROCesstype(name)--+ +-PROFile(name)------+ +-PROGram(name)------+ +-Requestmodel(name)-+ +-Sessions(name)-----+ +-TCpipservice(name)-+ +-TDqueue(name)------+ +-TErminal(name)-----+ +-TRANClass(name)----+ +-TRANSaction(name)--+ +-TSmodel(name)------+ '-TYpeterm(name)-----' Description
The CEDA EXPAND GROUP command
Shows the resource definitions in one or more groups on a full screen panel.You can enter the following commands next to the names on the panel:
- ALTER
- COPY
- DELETE
- INSTALL
- MOVE
- RENAME
- VIEW
You may EXPAND a generic group name. For example:
- Show all the resource definitions in all groups on the CSD file:
EXPAND GROUP(*)- Show all the resource definitions in groups whose names begin with PROD and are seven characters long:
EXPAND GROUP(PROD+++)You may EXPAND a group to show only one resource type. The name you specify as the resource name may be a generic name. For example: - Show all PROFILE definitions in all groups on the CSD file:
EXPAND GROUP(*) PROFILE(*)- Show all TERMINAL definitions that begin with SZ in a group:
EXPAND GROUP(ZEMGROUP) TERMINAL(SZ++)You may EXPAND a group or groups, limiting the resource definitions to those that share a generic name. For example: - Show all resource definitions, of all types, ending in A1:
EXPAND GROUP(REINDEER) ALL(*A1)If you use the RENAME option, you get a special panel on which you can overtype the resource definition names. This is a quick way of renaming many resource definitions.The CEDA EXPAND LIST command
Shows the group names in one or more lists on a full screen panel.When expanding a list, you can enter the following commands next to the names on the panel:
- ADD
- REMOVE
EXPAND LIST(INITLIST) GROUP(DFH*)You may EXPAND more than one list, by using a generic list name. For example, to show the groups in all lists on the CSD file: EXPAND LIST(*)Show the groups in lists whose names begin with PROD and are five characters long:
EXPAND LIST(PROD+)Options
Group(groupname)
specifies the group to be expanded.
List(listname)
specifies the list to be expanded.
REname
This option applies only to GROUP. Specifying RENAME allows you to rename resource definitions within the group.
resource(name)
specifies the resource you want to see within the expanded group.
The CEDA LOCK command
Restrict update and delete access to a single operator identifier.Syntax
'-List(listname)---' Description
The group or list can be used, looked at, and copied by other users of RDO, but cannot be changed or deleted by them.You can LOCK a nonexistent group or list, thereby reserving the named group or list for your own future use.
The only RDO command that releases a lock is the UNLOCK command. No other RDO commands can unlock a group or list. For example, if you DELETE all the resources in a group, or all the groups in a list, the lock remains.
You must specify either GROUP or LIST, even if you are locking the current group or list.
A generic group or list name is not accepted.
Controlling access to a group or list--LOCK and UNLOCK
The LOCK and UNLOCK commands enable you to control update access to a group or list so that only operators with the same operator identifier can make changes.The lock is held on the CSD file and remains in effect across restarts of CICS(R). The lock is owned by the user, who is identified by a combination of the CICS generic applid (specified by the APPLID system initialization parameter), and the user's operator identifier (OPIDENT).
The OPIDENT is the one associated with the user when he or she signs on to the terminal used for RDO. For further information on OPIDENT, see the CICS RACF(R) Security Guide. Any user who is not signed on or who has a different OPIDENT is not allowed to perform any operation that would change the locked group. However, any user is allowed to do the following things to a locked group:
- CHECK
- COPY
- DISPLAY
- INSTALL
- VIEW
It would be wise to put a lock on your group of TYPETERMs and on your group of AUTINSTMODEL TERMINALs.
Options
Group(groupname)
specifies the group to be locked.
List(listname)
specifies the list to be locked.
Examples
To lock a list L1:
LOCK LIST(L1)To lock a group G1:
LOCK GROUP(G1)Move one or more resource definitions from the group named by the GROUP option to the group named by the TO option.
Syntax
>>-CEDA--Move--+--------------------+--------------------------->
+-Connection(name)---+
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-Lsrpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--Group(groupname)-+--------+---------------------------------->
'-REMove-'
>--+-AS(newname)------------------+--+---------+---------------><
+-TO(newgroupname)-------------+ +-REPlace-+
'-AS(newname) TO(newgroupname)-' '-MErge---'
This command has the effect of copying the resource definitions from the first group into the second, followed by the deletion of the resource definitions from the first group.
When you MOVE the last resource in a group TO a different group, the group is automatically deleted. An empty group cannot exist.
If you do not specify either MERGE or REPLACE, a message warns you that you are attempting to create duplicate resource definitions. The definitions are not moved.
Options
AS(newname)
If you move a definition within a group, you must use AS to rename it. You can also use AS if you want to move a definition to another group and rename it at the same time. You cannot use a generic name when using AS.
Group(groupname)
specifies the group containing the definitions to be moved.
MErge
This applies when there are duplicate definition names in the groups named in the MOVE command. If you specify MERGE, duplicate definitions in the TO group are not replaced.
REMove
specifies that, when a group is deleted because the last resource in the group is moved elsewhere, the group is to be removed from all lists that had contained it.
REPlace
This applies when there are duplicate definition names in the groups named in the MOVE command. If you specify REPLACE, the definitions being moved replace those in the group named in the TO operand.
resource(name)
specifies the resource you want to move. The default is ALL, which moves all the resource definitions in a group to another group.
TO(newgroupname)
You can move definitions to a different group, using TO to specify the new group.
Examples
When you move a single resource definition, you can simultaneously rename it, using the AS option to specify the new name. For example:
MOVE PARTITIONSET(PSETQ1) GROUP(PSET1) AS(PSETQ4)
TO(PSET2)
A generic resource definition name can be specified, to move all or some definitions of the same resource type. For example:
MOVE TRANSACTION(*) GROUP(DENTRY) TO(TEST1)
MOVE MAPSET(ACCT+++) GROUP(ACCOUNTS1) TO(ACCOUNTS2)
To move all the resource definitions in a group to the new group, you can use ALL. For example:
MOVE ALL GROUP(N21TEST) TO(N21PROD)
You can use ALL with a generic name, to move all qualifying resource definitions in the group to the new group. For example:
MOVE ALL(N21*) GROUP(N21OLD) TO(N21NEW)
You can use ALL with a specific name, to move all the resource definitions of that name (which must be for different resource types) in the group to the new group. For example:
MOVE ALL(XMPL) GROUP(EXAMPLE) TO(EXAMPLE2)
To merge definitions from group X in with the definitions in group Y, keeping the Y version of any duplicates:
MOVE GROUP(X) TO(Y) MERGE
To combine definitions from group X in with definitions in group Y, keeping the X version of any duplicates:
MOVE GROUP(X) TO(Y) REPLACE
Syntax
The group, and all its resource definitions, still exists on the CSD file. When the last group is removed from a list, the list no longer exists on the CSD file.
A generic list name is not accepted.
A generic group name can be specified to remove many or all groups from a list with one command.
When a group is deleted, the user may have requested that the group be removed from all lists that had contained it. When the last group is removed from a list, the list is deleted.
Options
Group(groupname)
specifies the group to be removed.
List(listname)
specifies the list from which the group is to be removed.
Examples
A list LL02 contains the following groups:
· G001
· X001
· XG001
· G002
· G003
· X002
· G004
To remove all groups beginning with G:
REMOVE GROUP(G*) LIST(LL02)
This leaves:
· X001
· XG001
· X002
To remove the list completely:
REMOVE GROUP(*) LIST(LL02)
Syntax
+-ALl(name)----------+ '-Group(groupname)-'
+-Connection(name)---+
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-Lsrpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-REQuestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--+-------------+--+------------------+--+--------+-----------><
'-AS(newname)-' '-TO(newgroupname)-' '-REMove-'
You can also rename a resource definition by using the DISPLAY command or the EXPAND command with the RENAME option. See The CEDA DISPLAY command and The CEDA EXPAND command for information about these commands.
Options
AS(newname)
If you copy a definition within a group, you must use AS to rename it. You can also use AS if you want to copy a definition to another group and rename it at the same time. You cannot use a generic name when using AS.
Group(groupname)
specifies the group containing the definitions to be copied. A generic group name is not accepted.
REMove
specifies that, when a group is deleted, the group is to be removed from all lists that had contained it.
resource(name)
specifies the resource you want to copy. The default is ALL, which copies all the resource definitions in a group to another group. A generic resource definition name is not accepted.
TO(newgroupname)
You can copy definitions to a different group, using TO to specify the new group.
Examples
To rename a resource and keep it in its current group:
RENAME PROFILE(PROF1) AS(NEWPROF) GROUP(PROFS)
You can rename all resource definitions which share the same name, to a new name, using the ALL option instead of a resource type. For example:
RENAME ALL(TVA) AS(XTVA) GROUP(XTVA1)
RENAME ALL(USER) AS(OLDU) GROUP(USERDEF)
You can move a resource definition to a new group, which you specify in the TO option, at the same time as renaming it. (You can also do this with the MOVE command.) For example:
RENAME PROGRAM(N20ZA) AS($SOSERR) GROUP(N20) TO($MODULES)
You can move all the resource definitions of the same name from one group to another, using the TO option, at the same time as renaming them. For example:
RENAME ALL(USER) GROUP(USERDEF) AS(TEMP) TO(TEMPGRP)
You cannot rename a resource definition to a name that already exists in the target group.
The CEDA UNLOCK command
Remove the lock from a group or a list of definitions.Syntax
'-List(listname)---' Description
The UNLOCK command is the only RDO command that can remove a lock on a list or group put there by use of the RDO LOCK command.You can UNLOCK a nonexistent group or list.
You must specify either the GROUP or the LIST option, even if you are unlocking the current group or list, because the UNLOCK command can be used with both.
For more information about UNLOCK, see Security of resource definitions.
Controlling access to a group or list--LOCK and UNLOCK
The LOCK and UNLOCK commands enable you to control update access to a group or list so that only operators with the same operator identifier can make changes.The lock is held on the CSD file and remains in effect across restarts of CICS(R). The lock is owned by the user, who is identified by a combination of the CICS generic applid (specified by the APPLID system initialization parameter), and the user's operator identifier (OPIDENT).
The OPIDENT is the one associated with the user when he or she signs on to the terminal used for RDO. For further information on OPIDENT, see the CICS RACF(R) Security Guide. Any user who is not signed on or who has a different OPIDENT is not allowed to perform any operation that would change the locked group. However, any user is allowed to do the following things to a locked group:
- CHECK
- COPY
- DISPLAY
- INSTALL
- VIEW
It would be wise to put a lock on your group of TYPETERMs and on your group of AUTINSTMODEL TERMINALs.
Options
Group(groupname)
specifies the group to be unlocked. A generic group name is not accepted.
List(listname)
specifies the list to be unlocked. A generic list name is not accepted.
Examples
To unlock a group G1:
UNLOCK GROUP(G1)To unlock a LIST L1:
UNLOCK LIST(L1)Syntax
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-Lsrpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROCesstype(name)--+
+-PROFile(name)------+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
>--attribute list(newvalue)------------------------------------><
USERDEFINE is an alternative to the DEFINE command. Instead of using CICS(R)-supplied default values, USERDEFINE uses your own defaults. Otherwise it operates in exactly the same way as DEFINE.
To set up your own defaults, use DEFINE to create a dummy resource definition named USER in a group named USERDEF. Each dummy resource definition must be complete (for example, a transaction definition must name a program definition, even though you always supply a program name when you USERDEFINE a transaction). You need not install the dummy resource definitions before using USERDEFINE.
Do this for each type of resource for which you want to set default values. Each of them is named USER, but this does not matter because the fact that they are definitions of different resource types makes them unique.
So you could have the following resources in your USERDEF group:
· CONNECTION(USER)
· CORBASERVER(USER)
· DB2CONN(USER)
· DB2ENTRY(USER)
· DB2TRAN(USER)
· DJAR(USER)
· DOCTEMPLATE(USER)
· ENQMODEL(USER)
· FILE(USER)
· JOURNALMODEL(USER)
· LSRPOOL(USER)
· MAPSET(USER)
· PARTITIONSET(USER)
· PARTNER(USER)
· PROCESSTYPE(USER)
· PROFILE(USER)
· PROGRAM(USER)
· REQUESTMODEL(USER)
· SESSIONS(USER)
· TCPIPSERVICE(USER)
· TDQUEUE(USER)
· TERMINAL(USER)
· TRANCLASS(USER)
· TRANSACTION(USER)
· TSMODEL(USER)
· TYPETERM(USER).
This example is reviewed in the 'Examples' section for this command.
Options
Attribute list
The attribute list depends on the resource type being defined; some resources have attributes that must be included in the definition. Attributes that you do not specify are given default values.
Group(groupname)
The name of the group to be defined.
Examples
Assembler programmers at an installation have created a dummy program definition called USER with Assembler as the default language. They use USERDEFINE to define their programs to CICS.
First you must define a program called USER in group USERDEF. You could do this with the command:
CEDA DEFINE PROGRAM(USER) GROUP(USERDEF)
The following figure shows the panel you would see as a result of this command:
DEFINE PROGRAM(USER)
GROUP(USERDEF) CICS RELEASE = 0620
OVERTYPE TO MODIFY
CEDA DEFine
PROGram : USER
Group : USERDEF
DEscription ==>
Language ==> CObol | Assembler | Le370 | C | Pli
RELoad ==> No No | Yes
RESident ==> No No | Yes
USAge ==> Normal Normal | Transient
USElpacopy ==> No No | Yes
Status ==> Enabled Enabled | Disabled
RSl : 00 0-24 | Public
Cedf ==> Yes Yes | No
DAtalocation ==> Below Below | Any
I New group USERDEF created
SYSID=ABCD APPLID=DBDCCICS
DEFINE SUCCESSFUL TIME: 11.24.39 DATE: 97.359
PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL
Type in ASSEMBLER as the LANGUAGE option and press ENTER:
OVERTYPE TO MODIFY
CEDA USerdefine
PROGram : USER
Group : USERDEF
DEscription ==>
Language ==> Assembler CObol | Assembler | Le370 | C | Pli
RELoad ==> No No | Yes
RESident ==> No No | Yes
USAge ==> Normal Normal | Transient
USElpacopy ==> No No | Yes
Status ==> Enabled Enabled | Disabled
RSl : 00 0-24 | Public
Cedf ==> Yes Yes | No
DAtalocation ==> Below Below | Any
SYSID=ABCD APPLID=DBDCCICS
DEFINE SUCCESSFUL TIME: 11.24.41 DATE: 97.359
PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL
Now, each time you want to define a new program, you can use the USERDEFINE command to get the default value ASSEMBLER automatically. So, if you want to define a new program P2 in group GRP you enter the command:
CEDA USERDEFINE PROGRAM(P2) GROUP(GRP)
The following figure shows the panel resulting from this command.
USERDEFINE PROGRAM(P2)
GROUP(GRP)
OVERTYPE TO MODIFY
CEDA USerdefine
PROGram : P2
Group : GRP
DEscription ==>
Language ==> Assembler CObol | Assembler | Le370 | C | Pli
RELoad ==> No No | Yes
RESident ==> No No | Yes
USAge ==> Normal Normal | Transient
USElpacopy ==> No No | Yes
Status ==> Enabled Enabled | Disabled
RSl : 00 0-24 | Public
Cedf ==> Yes Yes | No
DAtalocation ==> Below Below | Any
APPLID=DBDCCICS
USERDEFINE SUCCESSFUL TIME: 11.25.48 DATE: 97.359
PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL
You see that the ASSEMBLER option has appeared for the LANGUAGE attribute. You can overtype the option values on this panel to complete the definition just as you can with the DEFINE command panel.
After you have set up your own defaults in a USER resource definition, anyone using the USERDEFINE command for that resource type gets those default values.
By renaming your USER to something else and defining your own dummy resource definition, you can use your own default values. Normally, however, your installation probably agrees on default values for standardization reasons, and puts a LOCK on the USERDEF GROUP.
Syntax
+-ALl(name)----------+
+-Connection(name)---+
+-CORbaserver(name)--+
+-DB2Conn(name)------+
+-DB2Entry(name)-----+
+-DB2Tran(name)------+
+-DJar(name)---------+
+-DOctemplate(name)--+
+-Enqmodel(name)-----+
+-File(name)---------+
+-Journalmodel(name)-+
+-Lsrpool(name)------+
+-Mapset(name)-------+
+-PARTItionset(name)-+
+-PARTNer(name)------+
+-PROFile(name)------+
+-PROCesstype(name)--+
+-PROGram(name)------+
+-Requestmodel(name)-+
+-Sessions(name)-----+
+-TCpipservice(name)-+
+-TDqueue(name)------+
+-TErminal(name)-----+
+-TRANClass(name)----+
+-TRANSaction(name)--+
+-TSmodel(name)------+
'-TYpeterm(name)-----'
The VIEW command lets you look at the resource definition attributes in the same way as the ALTER command. However, you cannot update any of the definitions.
Options
Group(groupname)
specifies the group to be viewed. If no name is given, the current group is assumed.
Examples
VIEW TERMINAL(SZT1) GROUP(ZEMTERMS)
VIEW MAPSET(N20MAP01) GROUP(N20)
You supply resource definition information to CICS(R) by using one or more of the following methods of resource definition:
This method uses the CICS-supplied online transactions CEDA (Cross Environment Data Access), CEDB, and CEDC. Definitions are stored in the CICS system definition (CSD) file, and are installed into an active CICS system from the CSD file.
CEDB and CEDC
Two further resource definition transactions CEDB and CEDC, allow you to use some, but not all, of the functions of CEDA.CEDB
When you use the CEDB transaction, the INSTALL command is not available to you. This means that you can update the CSD, but not the running CICS system. ENTER ONE OF THE FOLLOWING ADd ALter APpend CHeck COpy DEFine DELete DIsplay Expand Lock Move REMove REName UNlock USerdefine View SYSID=CI41 APPLID=IYAHZCCV PF 1 HELP 3 END 6 CRSR 9 MSG 12 CNCLCEDC
The CEDC transaction allows you only to look at data on the CICS system definition (CSD) file. You cannot update either the CSD file or the running CICS system. The only options that are available are DISPLAY, EXPAND, and VIEW. ENTER ONE OF THE FOLLOWING Display Expand View SYSID=CI41 APPLID=IYAHZCCV PF 1 HELP 3 END 6 CRSR 9 MSG 12 CNCLThis method allows you to make changes to definitions in the CSD file by means of a batch job submitted offline. The definitions are stored in the CSD file
Autoinstall minimizes the need for a large number of definitions, by dynamically creating new definitions based on a "model" definition provided by you.
You can use the EXEC CICS CREATE commands to create resources independently of the CSD file. For further information, see CICS System Programming Reference.
You can use assembler macro source to define resources that cannot be stored on the CSD. Definitions are stored in assembled tables in a program library, from which they are installed during CICS initialization.
You can use CICSPlex SM Business Application Services (BAS) to define and manage resources. Definitions are stored in the CICSPlex SM data repository and can be installed either automatically, during CICS initialization, or dynamically, into a running CICS system. For information on CICSPlex SM BAS, see CICSPlex System Manager Managing Business Applications.
Which methods you use depends on the resources you want to define. Table 1 shows you the methods you can use for each resource. Table 2 suggests some of the things you should consider when deciding which definition method to use.
| Resource | RDO/EXEC CICS CREATE commands | DFHCSDUP | Autoinstall | Macro | CICSPlex SM BAS |
| Connections | Yes (CONNECTION) | Yes | Yes | No | Yes (CONNDEF) |
| CorbaServers | Yes (CORBASERVER) | Yes | No | No | Yes (EJCODEF) |
| DB2(R) Connections | Yes (BD2CONN) | Yes | No | No | Yes (DB2CDEF) |
| DB2 entries | Yes (BD2ENTRY) | Yes | No | No | Yes (DB2EDEF) |
| DB2 transactions | Yes (DB2TRAN) | Yes | No | No | Yes (DB2TDEF) |
| Deployed jar files | Yes (DJAR) | Yes | No | No | Yes (EJDJDEF) |
| Document template | Yes (DOCTEMPLATE) | Yes | No | No | Yes (DOCDEF) |
| Enqueue models | Yes (ENQMODEL) | Yes | No | No | Yes (ENQMDEF) |
| FEPI node lists | No | No | No | No | Yes (FENODDEF) |
| FEPI pool definitions | No | No | No | No | Yes (FEPOODEF |
| FEPI property sets | No | No | No | No | Yes (FEPRODEF |
| FEPI target lists | No | No | No | No | Yes (FETRGDEF) |
| Files (BDAM) | No | No | No | Yes (DFHFCT) | No |
| Files (VSAM) | Yes (FILE) | Yes | No | No | Yes (FILEDEF) |
| File segments (CICS for OS/2(R) only) | No | No | No | No | Yes (FSEGDEF) |
| Journals | No | No | Yes | No | Yes (JRNLDEF) |
| Journal models | Yes (JOURNALMODEL) | Yes | No | No | Yes (JRNMDEF) |
| Local shared resource (LSR) pools | Yes (LSRPOOL) | Yes | No | No | Yes (LSRDEF) |
| Map sets | Yes (MAPSET) | Yes | Yes | No | Yes (MAPDEF) |
| Partition sets | Yes (PARTITIONSET) | Yes | Yes | No | Yes (PRTNDEF) |
| Partners | Yes (PARTNER) | Yes | No | No | Yes (PARTDEF) |
| Process types | Yes (PROCESSTYPE) | Yes | No | No | Yes (PROCDEF) |
| Profiles | Yes (PROFILE) | Yes | No | No | Yes (PROFDEF) |
| Programs | Yes (PROGRAM) | Yes | Yes | No | Yes (PROGDEF) |
| Recoverable service elements | No | No | No | Yes (DFHRST) | No |
| Request models | Yes (REQUESTMODEL) | Yes | No | No | Yes (RQMDEF) |
| Sessions | Yes (SESSIONS) | Yes | No. | No | Yes (SESSDEF) |
| TCP/IP services | Yes (TCPIPSERVICE) | Yes | No | No | Yes (TCPDEF) |
| Temporary storage (defined by macro) | No | No | No | Yes (DFHTST) | No |
| Temporary storage models (resource definition) | Yes (TSMODEL) | Yes | No | No | Yes (TSMDEF) |
| Terminals (non-VTAM(R)) | No | No | No | Yes (DFHTCT) | No |
| Terminals (VTAM) | Yes (TERMINAL) | Yes | Yes | No | Yes (TERMDEF) |
| Transactions | Yes (TRANSACTION) | Yes | No | No | Yes (TRANDEF) |
| Transaction classes | Yes (TRANCLASS) | Yes | No | No | Yes (TRNCLDEF) |
| Transient data queues (destinations) | Yes (TDQUEUE) | Yes | No | No | Yes (TDQDEF) |
| Typeterms | Yes (TYPETERM) | Yes | No | No | Yes (TYPTMDEF) |
| Method | Description | Advantages | Disadvantages |
| RDO | This method uses the CEDA transaction, which allows you to define, alter, and install resources in a running CICS system. | RDO is used while CICS is running, so allows fast access to resource definitions. | Because CEDA operates on an active CICS system, care should be taken if it is used in a production system. Use some form of auditing as a control mechanism. |
| EXEC CICS CREATE system commands | This method allows you to add CICS resources to a CICS region without reference to the CSD file. | It enables configuration and installation of CICS resources for large numbers of CICS regions from a single management focal point. It also allows you to write applications for administering the running CICS system. | CREATE commands neither refer to nor record in the CSD file. The resulting definitions are lost on a cold start, and you cannot refer to them in a CEDA transaction. |
| DFHCSDUP | DFHCSDUP is an offline utility that allows you to define, list, and modify resources using a batch job. DFHCSDUP can be invoked as a batch program or from a user-written program running either in batch mode or under TSO. Using the second method, you can specify up to five user exit routines within DFHCSDUP. |
|
|
| Autoinstall | This applies to VTAM terminals, LU6.2 sessions, journals, programs, mapsets, and partitionsets. You set up "model" definitions using either RDO or DFHCSDUP. CICS can then create and install new definitions for these resources dynamically, based on the models. | If you have large numbers of resources, much time is needed to define them, and if they are not all subsequently used, storage is also wasted for their definitions. Using autoinstall reduces this wasted time and storage. | You must spend some time initially setting up autoinstall in order to benefit from it. |
| Macro | Using this method, you code and assemble macro instructions to define resources in the form of tables. | Where possible, use the other methods. |
|
| CICSPlex SM BAS | Using BAS, you can create, maintain, and install CICS resources in a running CICS system. For full information, see CICSPlex System Manager Managing Business Applications. |
| |
