cics ts for z/os 4.2: resource definition guide · dual-purpose r esour ce definition for transient...
TRANSCRIPT
-
CICS Transaction Server for z/OSVersion 4 Release 2
Resource Definition Guide
SC34-7181-01
IBM
-
CICS Transaction Server for z/OSVersion 4 Release 2
Resource Definition Guide
SC34-7181-01
IBM
-
NoteBefore using this information and the product it supports, read the information in “Notices” on page 875.
This edition applies to Version 4 Release 2 of CICS Transaction Server for z/OS (product number 5655-S97) and toall subsequent releases and modifications until otherwise indicated in new editions.
© Copyright IBM Corporation 1982, 2014.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.
-
Contents
Preface . . . . . . . . . . . . . . . xiWhat this book is about . . . . . . . . . . xiWho should read this book . . . . . . . . . xiWhat you need to know to understand this book . . xiNotes on terminology . . . . . . . . . . . xiUse of the dollar symbol ($) . . . . . . . . . xiSyntax notation . . . . . . . . . . . . . xii
Changes in CICS Transaction Serverfor z/OS, Version 4 Release 2 . . . . . xiii
Part 1. Resource definition . . . . . 1
Chapter 1. An overview of resourcedefinition . . . . . . . . . . . . . . 3Methods for defining resources . . . . . . . . 3
Using the CSD and control tables together . . . 7Where resource definitions are held. . . . . . . 8How resource definitions are organized . . . . . 8Commands for managing resources. . . . . . . 8Shared resources for intercommunication . . . . 11Security of resource definitions . . . . . . . . 12Auditing resources . . . . . . . . . . . . 13
The definition signature for resource definitions 14The installation signature for resource definitions 16Summary of the resource signature field values 17
Getting started with resource definition . . . . . 19
Chapter 2. CSD file management . . . 21Compatibility mode (CSD file sharing) . . . . . 21Creating a CSD file . . . . . . . . . . . . 21
Chapter 3. Groups and lists. . . . . . 23What should be in a group? . . . . . . . . . 23How many resource definitions should a groupcontain? . . . . . . . . . . . . . . . 24Setting up lists for initialization . . . . . . . 24
Using several lists . . . . . . . . . . . 25Creating groups and lists . . . . . . . . . . 27Checking groups and lists of resource definitions forconsistency . . . . . . . . . . . . . . 27
Chapter 4. Resource definitioninstallation . . . . . . . . . . . . . 29What happens when CICS is initialized . . . . . 29
Initial or cold start . . . . . . . . . . . 29Warm or emergency start . . . . . . . . . 29
What happens when you use the INSTALLcommand . . . . . . . . . . . . . . . 30How to install a limited number of data definitions 30Duplicate resource definition names . . . . . . 31
Part 2. RDO resources . . . . . . . 33
Chapter 5. ATOMSERVICE resources 37Installing ATOMSERVICE resource definitions . . . 37ATOMSERVICE attributes . . . . . . . . . 37
Chapter 6. BUNDLE resources . . . . 41BUNDLE attributes . . . . . . . . . . . . 42
Chapter 7. CONNECTION resources . . 45Installing connection definitions . . . . . . . 48CONNECTION attributes . . . . . . . . . 49
Chapter 8. CORBASERVER resources 61Installing CORBASERVER definitions. . . . . . 61CORBASERVER: related resources . . . . . . . 62CORBASERVER: interrelated attributes . . . . . 63CORBASERVER attributes . . . . . . . . . 64
Chapter 9. DB2CONN resources . . . . 71Installing DB2 connection definitions . . . . . . 71
Checks on definitions of DB2 connectionresources . . . . . . . . . . . . . . 72
DB2CONN attributes . . . . . . . . . . . 73General attributes . . . . . . . . . . . 73Connection attributes . . . . . . . . . . 74Pool thread attributes . . . . . . . . . . 79Command thread attributes . . . . . . . . 82
Chapter 10. DB2ENTRY resources . . . 85Installing DB2 entry definitions. . . . . . . . 85
Checks on definitions of DB2 entry resources . . 85DB2ENTRY attributes . . . . . . . . . . . 86
General attributes . . . . . . . . . . . 86Thread selection attributes . . . . . . . . 87Thread operation attributes . . . . . . . . 87
Chapter 11. DB2TRAN resources . . . 91Checks on definitions of DB2 transaction resources 91Installing DB2 transaction definitions . . . . . . 91DB2TRAN attributes . . . . . . . . . . . 92
Wildcard characters for transaction IDs . . . . 92
Chapter 12. DJAR resources . . . . . 95Defining deployed JAR files using the CICSscanning mechanism . . . . . . . . . . . 95Installing deployed JAR files . . . . . . . . 97DJAR attributes . . . . . . . . . . . . . 98
Chapter 13. DOCTEMPLATE resources 101DOCTEMPLATE attributes . . . . . . . . . 101
Chapter 14. ENQMODEL resources 105Installing enqueue model definitions . . . . . 106ENQMODEL attributes . . . . . . . . . . 106
© Copyright IBM Corp. 1982, 2014 iii
||
-
Chapter 15. FILE resources . . . . . 109Remote files . . . . . . . . . . . . . . 109Coupling facility data tables . . . . . . . . 110Shared data tables . . . . . . . . . . . . 111Installing file definitions . . . . . . . . . . 111FILE attributes . . . . . . . . . . . . . 111
Chapter 16. IPCONN resources . . . . 131Installing IPCONN definitions. . . . . . . . 131IPCONN attributes . . . . . . . . . . . 131
Chapter 17. JOURNALMODELresources . . . . . . . . . . . . . 143JOURNALMODEL attributes . . . . . . . . 144The default JOURNALMODEL . . . . . . . 148Examples . . . . . . . . . . . . . . . 149
Chapter 18. JVMSERVER resources 151JVMSERVER attributes . . . . . . . . . . 151
Chapter 19. LIBRARY resources . . . 153Installing a LIBRARY resource definition by usingCEDA . . . . . . . . . . . . . . . . 153LIBRARY attributes . . . . . . . . . . . 154
Chapter 20. LSRPOOL resources . . . 157LSRPOOL attributes . . . . . . . . . . . 158
Chapter 21. MAPSET resources . . . 165MAPSET attributes . . . . . . . . . . . 166
Chapter 22. MQCONN resources . . . 169MQCONN attributes . . . . . . . . . . . 169
Chapter 23. PARTITIONSET resources 173PARTITIONSET attributes . . . . . . . . . 174
Chapter 24. PARTNER resources . . . 177Installing partner definitions . . . . . . . . 177PARTNER attributes . . . . . . . . . . . 178
Chapter 25. PIPELINE resources . . . 181PIPELINE attributes . . . . . . . . . . . 181
Chapter 26. PROCESSTYPE resources 185PROCESSTYPE attributes . . . . . . . . . 186
Chapter 27. PROFILE resources . . . 189PROFILE attributes . . . . . . . . . . . 189
Chapter 28. PROGRAM resources . . 197PROGRAM attributes . . . . . . . . . . 197
Chapter 29. REQUESTMODELresources . . . . . . . . . . . . . 209Installing request models . . . . . . . . . 210REQUESTMODEL attributes . . . . . . . . 210
Examples . . . . . . . . . . . . . . . 216
Chapter 30. SESSIONS resources. . . 219Installing session definitions . . . . . . . . 220SESSIONS attributes . . . . . . . . . . . 221
Chapter 31. TCPIPSERVICE resources 233TCPIPSERVICE: interrelated attributes . . . . . 233TCPIPSERVICE attributes . . . . . . . . . 235
Chapter 32. TDQUEUE resources . . . 249Dual-purpose resource definition for transient data 249Installing transient data queue definitions . . . . 250Replacing existing transient data queue definitions 250Disabling transient data queues . . . . . . . 251TDQUEUE attributes . . . . . . . . . . . 251Required TDQUEUE definitions . . . . . . . 264
Chapter 33. TERMINAL resources. . . 271Terminals for printing . . . . . . . . . . 271
Printers . . . . . . . . . . . . . . 272Associating printers with display devices . . . 273
Pipeline terminal definitions . . . . . . . . 273Defining pipeline terminals. . . . . . . . 274
Devices with LDC lists . . . . . . . . . . 275APPC (LUTYPE6.2) single session terminal . . . 275Terminals for transaction routing . . . . . . . 276
Terminal definitions used in transaction routing 276Making partial definitions available fortransaction routing . . . . . . . . . . 278APPC devices for transaction routing . . . . 283Transaction routing summary . . . . . . . 283
Installing terminal definitions . . . . . . . . 284Checking terminal definitions . . . . . . . . 285TERMINAL attributes . . . . . . . . . . 286
Chapter 34. TRANCLASS resources 299TRANCLASS attributes . . . . . . . . . . 299
Chapter 35. TRANSACTION resources 303TRANSACTION attributes . . . . . . . . . 304
Chapter 36. TSMODEL resources . . . 321TSMODEL attributes . . . . . . . . . . . 321
Chapter 37. TYPETERM resources 327Default values for TYPETERM attributes . . . . 329Devices supported. . . . . . . . . . . . 336TYPETERM attributes . . . . . . . . . . 341
Chapter 38. URIMAP resources . . . . 369Installing URIMAP resource definitions. . . . . 370URIMAP: related resources . . . . . . . . . 371URIMAP attributes . . . . . . . . . . . 372
Chapter 39. WEBSERVICE resources 387Installing WEBSERVICE resource definitions . . . 388WEBSERVICE attributes . . . . . . . . . . 388
iv CICS TS for z/OS 4.2: Resource Definition Guide
-
Part 3. Defining resources . . . . 391
Chapter 40. Resource definition online(RDO) transaction CEDA . . . . . . 393The CEDA transaction tutorial. . . . . . . . 393
Accessing CEDA . . . . . . . . . . . 393Using the CEDA panels . . . . . . . . . 393Using the command line . . . . . . . . 402Displaying messages . . . . . . . . . . 404Using CEDA HELP . . . . . . . . . . 404CEDA panel functions . . . . . . . . . 409
Resource management transaction CEDAcommands . . . . . . . . . . . . . . 414
The CEDA ADD command . . . . . . . . 415The CEDA ALTER command . . . . . . . 416The CEDA APPEND command . . . . . . 418The CEDA CHECK command . . . . . . . 418The CEDA COPY command . . . . . . . 420The CEDA DEFINE command. . . . . . . 423The CEDA DELETE command . . . . . . 425The CEDA DISPLAY command . . . . . . 427The CEDA EXPAND command . . . . . . 429The CEDA INSTALL command . . . . . . 432The CEDA LOCK command . . . . . . . 434The CEDA MOVE command . . . . . . . 435The CEDA REMOVE command . . . . . . 438The CEDA RENAME command . . . . . . 439The CEDA UNLOCK command . . . . . . 440The CEDA USERDEFINE command . . . . . 442The CEDA VIEW command . . . . . . . 445
Chapter 41. The resource definitionbatch utility DFHCSDUP. . . . . . . 447System definition file utility program (DFHCSDUP) 447
Sharing the CSD between CICS TransactionServer for z/OS, Version 4 Release 2 and earlierreleases . . . . . . . . . . . . . . 448Invoking DFHCSDUP as a batch program . . . 448Invoking the DFHCSDUP program from a userprogram . . . . . . . . . . . . . . 451Rules for the syntax and preparation ofcommands for the DFHCSDUP program . . . 453Command processing in DFHCSDUP followinginternal error detection . . . . . . . . . 454Resource management utility DFHCSDUPcommands . . . . . . . . . . . . . 454
Chapter 42. Autoinstall . . . . . . . 477Autoinstall models . . . . . . . . . . . 477Autoinstall control program . . . . . . . . 477Autoinstalling z/OS Communications Serverterminals . . . . . . . . . . . . . . . 477
Deciding which terminals to autoinstall . . . 478Autoinstall and z/OS Communications Server 480Implementing z/OS Communications Serverautoinstall . . . . . . . . . . . . . 483Recovery and restart of autoinstalled terminaldefinitions . . . . . . . . . . . . . 486
Autoinstalling MVS consoles . . . . . . . . 489
Implementing autoinstall for MVS consoles . . 490The autoinstall control program for MVSconsoles . . . . . . . . . . . . . . 492
Autoinstalling APPC connections . . . . . . . 493Implementing APPC connection autoinstall . . 494Model definitions for connection autoinstall . . 495The autoinstall control program for connections 495Recovery and restart for connection autoinstall 496
Autoinstalling IPIC connections . . . . . . . 496Autoinstalling programs, map sets, and partitionsets. . . . . . . . . . . . . . . . . 497
Implementing program autoinstall . . . . . 497Cataloging for program autoinstall . . . . . 498Model definitions for program autoinstall . . . 499The autoinstall control program for programs 499Program autoinstall and recovery and restart 500
Autoinstalling model terminal definitions . . . . 500Autoinstalling journals . . . . . . . . . . 501
Chapter 43. Macro resource definition 503Introduction to CICS control tables and macros . . 503
Format of macros . . . . . . . . . . . 506Defining resources in CICS control tables . . . . 507
Defining control tables to CICS . . . . . . 509Assembling and link-editing control tables: theDFHAUPLE procedure . . . . . . . . . 509
CLT—command list table . . . . . . . . . 512Control section—DFHCLT TYPE=INITIAL . . 513Specifying alternate systems—DFHCLTTYPE=LISTSTART . . . . . . . . . . . 514Specifying takeover commands—DFHCLTTYPE=COMMAND . . . . . . . . . . 514Messages to the operator—DFHCLTTYPE=WTO . . . . . . . . . . . . . 515Closing the command list—DFHCLTTYPE=LISTEND . . . . . . . . . . . 515
PDIR—DL/I directory . . . . . . . . . . 515Control section—DFHDLPSB TYPE=INITIAL 516Program specification blocks—DFHDLPSBTYPE=ENTRY . . . . . . . . . . . . 516
FCT—file control table . . . . . . . . . . 517Control section—DFHFCT TYPE=INITIAL . . 517Local files—DFHFCT TYPE=FILE . . . . . 517DFHFCT example . . . . . . . . . . . 525
MCT - monitoring control table . . . . . . . 525Control section—DFHMCT TYPE=INITIAL . . 526User event monitoring points—DFHMCTTYPE=EMP . . . . . . . . . . . . . 529Control data recording—DFHMCTTYPE=RECORD . . . . . . . . . . . 533DFHMCT examples . . . . . . . . . . 542
PLT—program list table . . . . . . . . . . 543Control section—DFHPLT TYPE=INITIAL. . . 544Entries in program list table—DFHPLTTYPE=ENTRY . . . . . . . . . . . . 545DFHPLT example . . . . . . . . . . . 546
RST—recoverable service table . . . . . . . 547Control section—DFHRST TYPE=INITIAL. . . 548Recoverable service elements—DFHRSTTYPE=RSE . . . . . . . . . . . . . 548DBCTL subsystems—DFHRST TYPE=SUBSYS 548
Contents v
-
DFHRST example . . . . . . . . . . . 549SRT—system recovery table . . . . . . . . 549
Control section—DFHSRT TYPE=INITIAL. . . 549Abend codes—DFHSRT TYPE=SYSTEM|USER 550DFHSRT example . . . . . . . . . . . 551
TCT—terminal control table . . . . . . . . 551DFHTCT macro types . . . . . . . . . 552DFHTCT logical device codes: z/OSCommunications Server non-3270 . . . . . 555Sequential devices . . . . . . . . . . . 563Remote terminals for transaction routing . . . 568DFHTCT: CICS terminals list . . . . . . . 571
TLT—terminal list table . . . . . . . . . . 572Control section—DFHTLT TYPE=INITIAL. . . 573Entries in terminal list table—DFHTLTTYPE=ENTRY . . . . . . . . . . . . 573DFHTLT example . . . . . . . . . . . 574
TST—temporary storage table . . . . . . . . 575Control section—DFHTST TYPE=INITIAL. . . 577Recoverable temporary storage—DFHTSTTYPE=RECOVERY . . . . . . . . . . 577Local temporary storage—DFHTSTTYPE=LOCAL . . . . . . . . . . . . 579Remote temporary storage—DFHTSTTYPE=REMOTE . . . . . . . . . . . 580Temporary storage security checking—DFHTSTTYPE=SECURITY . . . . . . . . . . . 581Temporary storage data sharing—DFHTSTTYPE=SHARED . . . . . . . . . . . 582DFHTST example . . . . . . . . . . . 583
XLT—transaction list table . . . . . . . . . 584Control section—DFHXLT TYPE=INITIAL. . . 585Entries in transaction list table—DFHXLTTYPE=ENTRY . . . . . . . . . . . . 585DFHXLT example . . . . . . . . . . . 586
Chapter 44. Defining applicationbundles . . . . . . . . . . . . . . 587Application types that support bundles. . . . . 588Manifest contents . . . . . . . . . . . . 589Scoping of bundles . . . . . . . . . . . 591Recovery of resources in bundles . . . . . . . 592
Chapter 45. Defining terminalresources . . . . . . . . . . . . . 593Defining z/OS Communications Server terminals 593
Defining CICS terminal resources to z/OSCommunications Server . . . . . . . . . 593Defining terminal resources to CICS . . . . . 594Defining the terminal shutdown time limit . . 594Choosing an appropriate value for TCSWAIT 595
Defining sequential (BSAM) devices . . . . . . 595Terminating . . . . . . . . . . . . . 596
Defining console devices . . . . . . . . . 598Defining console devices to CICS. . . . . . 598
Defining z/OS Communications Server persistentsessions support . . . . . . . . . . . . 601
Part 4. Resource definition online(RDO) transaction CEDA . . . . . 603
Chapter 46. The CEDA transactiontutorial . . . . . . . . . . . . . . 605Accessing CEDA . . . . . . . . . . . . 605Using the CEDA panels . . . . . . . . . . 605
Creating a resource definition . . . . . . . 606Displaying a resource definition . . . . . . 608Altering a resource definition . . . . . . . 613Copying a resource definition . . . . . . . 613
Using the command line . . . . . . . . . 614Creating a resource definition . . . . . . . 615Renaming a resource definition . . . . . . 615Moving a resource definition . . . . . . . 615Checking resource definitions . . . . . . . 615Removing resource definitions from the CSD file 616
Displaying messages . . . . . . . . . . . 616Using CEDA HELP . . . . . . . . . . . 616CEDA panel functions . . . . . . . . . . 621
Using abbreviations . . . . . . . . . . 621Changing attribute values . . . . . . . . 622Using the PF keys . . . . . . . . . . . 623Generic naming in CEDA . . . . . . . . 624Entering mixed-case attributes. . . . . . . 625
Chapter 47. Resource managementtransaction CEDA commands . . . . 627The CEDA ADD command . . . . . . . . . 627The CEDA ALTER command . . . . . . . . 628The CEDA APPEND command . . . . . . . 630The CEDA CHECK command . . . . . . . . 631The CEDA COPY command . . . . . . . . 633The CEDA DEFINE command. . . . . . . . 636The CEDA DELETE command . . . . . . . 638The CEDA DISPLAY command . . . . . . . 640
The CEDA DISPLAY GROUP command . . . 642The CEDA DISPLAY LIST command . . . . 642
The CEDA EXPAND command . . . . . . . 643The CEDA EXPAND GROUP command . . . 644The CEDA EXPAND LIST command . . . . 645
The CEDA INSTALL command . . . . . . . 645The CEDA LOCK command . . . . . . . . 648The CEDA MOVE command . . . . . . . . 649The CEDA REMOVE command . . . . . . . 652The CEDA RENAME command . . . . . . . 653The CEDA UNLOCK command . . . . . . . 654The CEDA USERDEFINE command . . . . . . 656The CEDA VIEW command . . . . . . . . 659
Part 5. The resource definitionbatch utility DFHCSDUP . . . . . 661
Chapter 48. System definition fileutility program (DFHCSDUP) . . . . . 663Sharing the CSD between CICS Transaction Serverfor z/OS, Version 4 Release 2 and earlier releases . 664Invoking DFHCSDUP as a batch program . . . . 664
vi CICS TS for z/OS 4.2: Resource Definition Guide
-
Invoking the DFHCSDUP program from a userprogram . . . . . . . . . . . . . . . 667
Entry parameters for the DFHCSDUP program 667Responsibilities of the user program. . . . . 668
Rules for the syntax and preparation of commandsfor the DFHCSDUP program . . . . . . . . 669Command processing in DFHCSDUP followinginternal error detection . . . . . . . . . . 670Resource management utility DFHCSDUPcommands . . . . . . . . . . . . . . 670
The DFHCSDUP ADD command . . . . . . 670The DFHCSDUP ALTER command . . . . . 671The DFHCSDUP APPEND command . . . . 673The DFHCSDUP COPY command . . . . . 675The DFHCSDUP DEFINE command. . . . . 676The DFHCSDUP DELETE command . . . . 678The DFHCSDUP EXTRACT command . . . . 680The DFHCSDUP INITIALIZE command . . . 682The DFHCSDUP LIST command . . . . . . 682The DFHCSDUP PROCESS command . . . . 684The DFHCSDUP REMOVE command . . . . 685The DFHCSDUP SCAN command . . . . . 685The DFHCSDUP SERVICE command . . . . 687The DFHCSDUP UPGRADE command. . . . 688The DFHCSDUP USERDEFINE command . . . 689The DFHCSDUP VERIFY command . . . . . 691
Part 6. Autoinstall . . . . . . . . 693
Chapter 49. Autoinstall models . . . . 695
Chapter 50. Autoinstall controlprogram . . . . . . . . . . . . . 697
Chapter 51. Autoinstalling z/OSCommunications Server terminals . . 699Deciding which terminals to autoinstall . . . . 699
Automatic transaction initiation . . . . . . 699The TCT user area (TCTUA) . . . . . . . 700The terminal list table (TLT) . . . . . . . 700Transaction routing . . . . . . . . . . 701Autoinstall and output-only devices . . . . . 701
Autoinstall and z/OS Communications Server . . 701The process of logging on to CICS usingautoinstall . . . . . . . . . . . . . 701What happens when the user logs off . . . . 704
Implementing z/OS Communications Serverautoinstall . . . . . . . . . . . . . . 704Recovery and restart of autoinstalled terminaldefinitions . . . . . . . . . . . . . . 707
What happens at CICS restart . . . . . . . 707Automatic sign-off, logoff, and TCTTE deletion 708
Chapter 52. Autoinstalling MVSconsoles . . . . . . . . . . . . . 711Implementing autoinstall for MVS consoles . . . 712
Defining model TERMINAL definitions forconsoles . . . . . . . . . . . . . . 713Specifying automatic preset security . . . . . 713
The autoinstall control program for MVS consoles 714
Chapter 53. Autoinstalling APPCconnections . . . . . . . . . . . . 715Implementing APPC connection autoinstall . . . 716Model definitions for connection autoinstall . . . 716The autoinstall control program for connections 717Recovery and restart for connection autoinstall . . 718
Chapter 54. Autoinstalling IPICconnections . . . . . . . . . . . . 719
Chapter 55. Autoinstalling programs,map sets, and partition sets . . . . . 721Implementing program autoinstall . . . . . . 721Cataloging for program autoinstall . . . . . . 722Model definitions for program autoinstall . . . . 723The autoinstall control program for programs . . 723
When the autoinstall control program isinvoked for program autoinstall . . . . . . 723Sample programs . . . . . . . . . . . 724Program autoinstall functions . . . . . . . 724
Program autoinstall and recovery and restart . . . 724
Chapter 56. Autoinstalling modelterminal definitions . . . . . . . . . 725
Chapter 57. Autoinstalling journals 727
Part 7. Macro resource definition 729
Chapter 58. Introduction to CICScontrol tables and macros . . . . . . 731Format of macros . . . . . . . . . . . . 734
TYPE=INITIAL (control section) . . . . . . 734TYPE=FINAL (end of table) . . . . . . . 735
Chapter 59. Defining resources inCICS control tables . . . . . . . . . 737Defining control tables to CICS . . . . . . . 738Assembling and link-editing control tables: theDFHAUPLE procedure . . . . . . . . . . 739
Steps in the DFHAUPLE procedure . . . . . 739
Chapter 60. CLT—command list table 743Control section—DFHCLT TYPE=INITIAL . . . 743Specifying alternate systems—DFHCLTTYPE=LISTSTART . . . . . . . . . . . . 744Specifying takeover commands—DFHCLTTYPE=COMMAND . . . . . . . . . . . 745Messages to the operator—DFHCLT TYPE=WTO 746Closing the command list—DFHCLTTYPE=LISTEND . . . . . . . . . . . . 746
Chapter 61. PDIR—DL/I directory . . . 747Control section—DFHDLPSB TYPE=INITIAL. . . 747
Contents vii
-
Program specification blocks—DFHDLPSBTYPE=ENTRY . . . . . . . . . . . . . 747
Chapter 62. FCT—file control table 749Control section—DFHFCT TYPE=INITIAL . . . 749Local files—DFHFCT TYPE=FILE . . . . . . 749
Summary table . . . . . . . . . . . . 756DFHFCT example . . . . . . . . . . . . 757
Chapter 63. MCT - monitoring controltable . . . . . . . . . . . . . . . 759Control section—DFHMCT TYPE=INITIAL . . . 759User event monitoring points—DFHMCTTYPE=EMP . . . . . . . . . . . . . . 763Control data recording—DFHMCT TYPE=RECORD 767DFHMCT examples . . . . . . . . . . . 775
Chapter 64. PLT—program list table 779Control section—DFHPLT TYPE=INITIAL. . . . 780Entries in program list table—DFHPLTTYPE=ENTRY . . . . . . . . . . . . . 780DFHPLT example . . . . . . . . . . . . 781
Chapter 65. RST—recoverable servicetable . . . . . . . . . . . . . . . 783Control section—DFHRST TYPE=INITIAL. . . . 783Recoverable service elements—DFHRST TYPE=RSE 783DBCTL subsystems—DFHRST TYPE=SUBSYS . . 784DFHRST example . . . . . . . . . . . . 784
Chapter 66. SRT—system recoverytable . . . . . . . . . . . . . . . 785Control section—DFHSRT TYPE=INITIAL. . . . 785Abend codes—DFHSRT TYPE=SYSTEM|USER . . 785DFHSRT example . . . . . . . . . . . . 787
Chapter 67. TCT—terminal controltable . . . . . . . . . . . . . . . 789DFHTCT macro types . . . . . . . . . . 789
Control section—DFHTCT TYPE=INITIAL . . 790Migrating TCT definitions—DFHTCTTYPE=GROUP . . . . . . . . . . . . 792
DFHTCT logical device codes: z/OSCommunications Server non-3270 . . . . . . 793
Logical device codes—DFHTCT TYPE=LDCmacro . . . . . . . . . . . . . . . 796Logical device codes—DFHTCT TYPE=LDCLIST 799DFHTCT examples: LDC . . . . . . . . 800
Sequential devices . . . . . . . . . . . . 800JCL for sequential devices . . . . . . . . 801Sequential devices—DFHTCT TYPE=SDSCI . . 801Sequential devices—DFHTCT TYPE=LINE . . 802Sequential devices—DFHTCTTYPE=TERMINAL . . . . . . . . . . 803
Remote terminals for transaction routing . . . . 806Remote definitions for terminals for transactionrouting . . . . . . . . . . . . . . 806Remote terminals, method 1—DFHTCTTYPE=REGION . . . . . . . . . . . 807
Remote terminals, method 1—DFHTCTTYPE=TERMINAL . . . . . . . . . . 807Remote terminals, method 2—DFHTCTTYPE=REMOTE . . . . . . . . . . . 808
DFHTCT: CICS terminals list . . . . . . . . 809z/OS Communications Server LUs . . . . . 810
Chapter 68. TLT—terminal list table 811Control section—DFHTLT TYPE=INITIAL . . . . 811Entries in terminal list table—DFHTLTTYPE=ENTRY . . . . . . . . . . . . . 812DFHTLT example . . . . . . . . . . . . 813
Chapter 69. TST—temporary storagetable . . . . . . . . . . . . . . . 815Control section—DFHTST TYPE=INITIAL. . . . 816Recoverable temporary storage—DFHTSTTYPE=RECOVERY . . . . . . . . . . . 817Local temporary storage—DFHTST TYPE=LOCAL 819Remote temporary storage—DFHTSTTYPE=REMOTE . . . . . . . . . . . . 819Temporary storage security checking—DFHTSTTYPE=SECURITY . . . . . . . . . . . . 821Temporary storage data sharing—DFHTSTTYPE=SHARED . . . . . . . . . . . . 822DFHTST example . . . . . . . . . . . . 822
Chapter 70. XLT—transaction list table 825Control section—DFHXLT TYPE=INITIAL. . . . 825Entries in transaction list table—DFHXLTTYPE=ENTRY . . . . . . . . . . . . . 826DFHXLT example . . . . . . . . . . . . 827
Part 8. Appendixes . . . . . . . . 829
Appendix A. Obsolete attributes . . . 831Obsolete attributes retained for compatibility . . . 831
Appendix B. CICS-supplied resourcedefinitions, groups, and lists. . . . . 833DFHLIST definitions . . . . . . . . . . . 833CICS-supplied groups not in DFHLIST . . . . . 844CICS-supplied compatibility groups . . . . . . 845The sample application program groups . . . . 845CICS transactions supplied by IBM . . . . . . 849TYPETERM definitions in group DFHTYPE . . . 862Model TERMINAL definitions in group DFHTERM 867PROFILE definitions in group DFHEP . . . . . 870PROFILE definitions in group DFHISC . . . . . 870PROFILE definitions in group DFHSTAND . . . 871Model definitions in group DFHPGAIP . . . . 873TCPIPSERVICE definition in group DFH$SOT . . 874
Notices . . . . . . . . . . . . . . 875Trademarks . . . . . . . . . . . . . . 876
Bibliography. . . . . . . . . . . . 877CICS books for CICS Transaction Server for z/OS 877
viii CICS TS for z/OS 4.2: Resource Definition Guide
-
CICSPlex SM books for CICS Transaction Serverfor z/OS . . . . . . . . . . . . . . . 878Other CICS publications . . . . . . . . . . 878Other IBM publications . . . . . . . . . . 878
Accessibility . . . . . . . . . . . . 881
Index . . . . . . . . . . . . . . . 883
Contents ix
-
x CICS TS for z/OS 4.2: Resource Definition Guide
-
Preface
What this book is aboutThis book tells you how to define the characteristics of your data processingresources to your CICS® system. It describes four methods of resource definition:v Online definition (CEDA)v Batch definition (DFHCSDUP)v Automatic installation (autoinstall)v Macro definition
You can also use EXEC CICS CREATE commands, which are described in CICSSystem Programming Reference; and CICSPlex® SM Business Application Services(BAS) commands, which are described in CICSPlex System Manager ManagingBusiness Applications.
Who should read this bookThis book is for those responsible for defining resources to CICS.
What you need to know to understand this bookThis book assumes that you have a basic understanding of CICS concepts andfacilities. You must also be familiar with your own system and the resources to bedefined and maintained.
Notes on terminologyWhen the term “CICS” is used without any qualification in this book, it refers tothe CICS element of CICS Transaction Server for z/OS®.
“CICS/ESA” is used for IBM® Customer Information Control System/EnterpriseSystem Architecture.
Other abbreviations that may be used for CICS releases are as follows:v CICS/MVS Version 2 Release 1 and subsequent modification levels—CICS/MVS
2.1v CICS/ESA Version 3 Release 3—CICS/ESA 3.3v CICS/ESA Version 4 Release 1—CICS/ESA 4.1.
MVS™ refers to the operating system, which is a base element of z/OS.
Use of the dollar symbol ($)In the character sets given in this book, the dollar symbol ($) is used as a nationalcurrency symbol and is assumed to be assigned the EBCDIC code point X'5B'. Insome countries a different currency symbol, for example the pound symbol (£), orthe yen symbol (¥), is assigned the same EBCDIC code point. In these countries,the appropriate currency symbol should be used instead of the dollar symbol.
© Copyright IBM Corp. 1982, 2014 xi
-
Syntax notationSyntax notation specifies the permissible combinations of options or attributes thatyou can specify on CICS commands, resource definitions, and many other things.
The conventions used in the syntax notation are:
Notation Explanation
►► ABC
►◄Denotes a set of required alternatives. Youmust specify one (and only one) of thevalues shown.
►► ▼ ABC
►◄
Denotes a set of required alternatives. Youmust specify at least one of the valuesshown. You can specify more than one ofthem, in any sequence.
►►ABC
►◄Denotes a set of optional alternatives. Youcan specify none, or one, of the valuesshown.
►► ▼
ABC
►◄
Denotes a set of optional alternatives. Youcan specify none, one, or more than one ofthe values shown, in any sequence.
►►A
BC
►◄
Denotes a set of optional alternatives. Youcan specify none, or one, of the valuesshown. A is the default value that is used ifyou do not specify anything.
►► Name ►◄
Name:
AB
A reference to a named section of syntaxnotation.
►► A=value ►◄A= denote characters that should be enteredexactly as shown.
value denotes a variable, for which youshould specify an appropriate value.
xii CICS TS for z/OS 4.2: Resource Definition Guide
-
Changes in CICS Transaction Server for z/OS, Version 4Release 2
For information about changes that have been made in this release, please refer toWhat's New in the information center, or the following publications:v CICS Transaction Server for z/OS What's Newv CICS Transaction Server for z/OS Upgrading from CICS TS Version 4.1v CICS Transaction Server for z/OS Upgrading from CICS TS Version 3.2v CICS Transaction Server for z/OS Upgrading from CICS TS Version 3.1
Any technical changes that are made to the text after release are indicated by avertical bar (|) to the left of each new or changed line of information.
© Copyright IBM Corp. 1982, 2014 xiii
-
xiv CICS TS for z/OS 4.2: Resource Definition Guide
-
Part 1. Resource definition
Resource definition is the process in which you specify the resources that will beused by a CICS region, and by applications running in the region.
© Copyright IBM Corp. 1982, 2014 1
-
2 CICS TS for z/OS 4.2: Resource Definition Guide
-
Chapter 1. An overview of resource definition
To run your system, you need to supply CICS with information about your systemresources, including software resources such as programs and data, and hardwareresources such as terminals, printers, and telecommunications links. Many of theproperties of these resources are variable, so you can choose the particularfunctions and combinations of resources that your business needs.
Every resource is defined with a set of attributes. The attributes are the propertiesof the resource, telling CICS, for example, whether a file can be updated, whatsecurity level should be given to a transaction, or the remote systems with whichCICS can communicate.
Methods for defining resourcesYou can define most resources to CICS using several different methods.
CICS ExplorerYou can use the CICS Explorer to define, install, and manage resources. IfCICS Explorer is connected to a CICS system, definitions are stored in theCICS system definition (CSD) file, and are installed into an active CICSsystem from the CSD file.If CICS Explorer is connected to CICSPlex SM,definitions are stored in the CICSPlex SM data repository and can beinstalled either automatically, during CICS initialization, or dynamically,into a running CICS system.
CICSPlex SM Business Application ServicesYou can use CICSPlex SM Business Application Services (BAS) to defineand manage resources. Definitions are stored in the CICSPlex SM datarepository and can be installed either automatically, during CICSinitialization, or dynamically, into a running CICS system. For informationon CICSPlex SM BAS, see CICSPlex System Manager Managing BusinessApplications.
Resource definition online (RDO)This method uses the CICS-supplied online transactions CEDA, CEDB, andCEDC. Definitions are stored in the CSD file, and are installed into anactive CICS system from the CSD file.
Application bundlesYou can deploy an application into CICS as a bundle and use the BUNDLEresource to create and manage the associated CICS resources. When youinstall a BUNDLE resource, CICS creates the required application resourcesdynamically. CICS also maintains a relationship with each of the resourcesso that you can enable or disable the application using the BUNDLEresource, rather than managing each application resource individually. TheBUNDLE resource that represents the application is stored in the CSD file.The resources that are created dynamically when you install a BUNDLEresource are not stored in the CSD file.
DFHCSDUP offline utilityThis method allows you to make changes to definitions in the CSD file bymeans of a batch job submitted offline. The definitions are stored in theCSD file.
© Copyright IBM Corp. 1982, 2014 3
-
Automatic installation (autoinstall)Autoinstall minimizes the need for a large number of definitions, bydynamically creating new definitions based on a “model” definitionprovided by you.
System programming, using the EXEC CICS CREATE commandsYou can use the EXEC CICS CREATE commands to create resourcesindependently of the CSD file. For further information, see the CICS SystemProgramming Reference.
System programming, using the EXEC CICS CSD commandsYou can use the EXEC CICS CSD commands to manage resourcedefinitions in the CSD file from a user-written program. EXEC CICS CSDcommands can perform all of the functions of CEDA except CEDACHECK.
Macro definitionYou can use assembler macro source to define resources that cannot bestored on the CSD. The definitions are stored in assembled control tables ina program library, from which they are installed during CICS initialization.
You must use macro instructions to define non-VTAM networks andterminals, non-VSAM files, databases, and resources for monitoring andsystem recovery.
Which methods you use depends on the resources you want to define. Table 1shows you the methods you can use for each resource. Table 2 on page 6 suggestssome of the things you should consider when deciding which definition method touse.
Table 1. Resources and how you can define them to the running CICS systemResource CICS
ExplorerCICSPlex SM BAS RDO/EXEC CICS
CREATE and EXECCICS CSD commands
Applicationbundles
DFHCSDUP Autoinstall Macro
Atomdocuments
Yes Yes (ATOMDEF) Yes (ATOMSERVICE) Yes Yes No No
Bundles Yes Yes (BUNDDEF) Yes (BUNDLE) N/A Yes No No
Capturespec No No No No Yes No No
Connections Yes Yes (CONNDEF) Yes (CONNECTION) No Yes LUTYPE 6.2only
No
CorbaServers Yes Yes (EJCODEF) Yes (CORBASERVER) No Yes No No
DB2®
ConnectionsYes Yes (DB2CDEF) Yes (DB2CONN) No Yes No No
DB2 entries Yes Yes (DB2EDEF) Yes (DB2ENTRY) No Yes No No
DB2transactions
Yes Yes (DB2TDEF) Yes (DB2TRAN) No Yes No No
Deployed jarfiles
Yes Yes (EJDJDEF) Yes (DJAR) No Yes No No
Documenttemplate
Yes Yes (DOCDEF) Yes (DOCTEMPLATE) No Yes No No
Enqueuemodels
Yes Yes (ENQMDEF) Yes (ENQMODEL) No Yes No No
Event binding Yes No No Yes No No No
Eventprocessingadapter
Yes No No Yes No No No
FEPI nodelists
No Yes (FENODDEF) No No No No No
FEPI pooldefinitions
No Yes (FEPOODEF No No No No No
4 CICS TS for z/OS 4.2: Resource Definition Guide
-
Table 1. Resources and how you can define them to the running CICS system (continued)Resource CICS
ExplorerCICSPlex SM BAS RDO/EXEC CICS
CREATE and EXECCICS CSD commands
Applicationbundles
DFHCSDUP Autoinstall Macro
FEPI propertysets
No Yes (FEPRODEF No No No No No
FEPI targetlists
No Yes (FETRGDEF) No No No No No
Files (BDAM) No No No No No No Yes(DFHFCT)
Files (VSAM) Yes Yes (FILEDEF) Yes (FILE) No Yes No No
IPICconnections
Yes Yes (IPCONDEF) Yes (IPCONN) No Yes Yes No
Journals Yes Yes (JRNLDEF) No No No Yes No
Journalmodels
Yes Yes (JRNMDEF) Yes (JOURNALMODEL) No Yes No No
LIBRARYresources
Yes Yes (LIBDEF) Yes (LIBRARY) No Yes No No
Local sharedresource(LSR) pools
Yes Yes (LSRDEF) Yes (LSRPOOL) No Yes No No
Map sets Yes Yes (MAPDEF) Yes (MAPSET) No Yes Yes No
Partition sets Yes Yes (PRTNDEF) Yes (PARTITIONSET) No Yes Yes No
Partners Yes Yes (PARTDEF) Yes (PARTNER) No Yes No No
Pipelines Yes Yes (PIPEDEF) Yes (PIPELINE) No Yes No No
Process types Yes Yes (PROCDEF) Yes (PROCESSTYPE) No Yes No No
Profiles Yes Yes (PROFDEF) Yes (PROFILE) No Yes No No
Programs Yes Yes (PROGDEF) Yes (PROGRAM) No Yes Yes No
Recoverableserviceelements
No No No No No No Yes (DFHRST)
Requestmodels
Yes Yes (RQMDEF) Yes (REQUESTMODEL) No Yes No No
Sessions Yes Yes (SESSDEF) Yes (SESSIONS) No Yes No. No
TCP/IPservices
Yes Yes (TCPDEF) Yes (TCPIPSERVICE) No Yes No No
Temporarystorage(defined bymacro)
No No No No No No Yes (DFHTST)
Temporarystoragemodels(resourcedefinition)
Yes Yes (TSMDEF) Yes (TSMODEL) No Yes No No
Terminals(non-VTAM®)
No No No No No No Yes(DFHTCT)
Terminals(VTAM)
Yes Yes (TERMDEF) Yes (TERMINAL) No Yes Yes No
Transactions Yes Yes (TRANDEF) Yes (TRANSACTION) No Yes No No
Transactionclasses
Yes Yes (TRNCLDEF) Yes (TRANCLASS) No Yes No No
Transient dataqueues
Yes Yes (TDQDEF) Yes (TDQUEUE) No Yes No No
Typeterms Yes Yes (TYPTMDEF) Yes (TYPETERM) No Yes No No
URI maps Yes Yes Yes (URIMAP) No Yes No No
Web services Yes Yes Yes (WEBSERVICE) No Yes No No
WebSphere®
MQconnection
Yes Yes (MQCONDEF) Yes (MQCONN) No Yes No No
Xmltransform No No No No Yes No No
Chapter 1. An overview of resource definition 5
-
Table 2. Methods of resource definition
Method Description Advantages Disadvantages
CICS Explorer Using the CICS Explorer youcan define, alter, and installresources in a running CICSsystem.
v Intuitive and easy to useinterface
v Integration point for otherCICS tools
v Centralized resourcedefinition
v Logical scopingv Distributed resource
installation
FEPI resources cannot bedefined with CICS Explorer.
CICSPlex SMBAS
Using BAS, you can create,maintain, and install CICSresources in a running CICSsystem. For full information,see the CICSPlex SystemManager Managing BusinessApplications.
v Centralized resourcedefinition
v Logical scopingv Distributed resource
installation
None
RDO This method uses the CEDAtransaction, which allows youto define, alter, and installresources in a running CICSsystem.
RDO is used while CICS isrunning, so allows fast accessto resource definitions.
Because CEDA operates on anactive CICS system, care shouldbe taken if it is used in aproduction system. Use someform of auditing as a controlmechanism.
EXEC CICSCREATEsystemcommands
This method allows you to addCICS resources to a CICSregion without reference to theCSD file.
It enables configuration andinstallation of CICS resourcesfor large numbers of CICSregions from a singlemanagement focal point. It alsoallows you to writeapplications for administeringthe running CICS system.
CREATE commands neitherrefer to nor record in the CSDfile. The resulting definitionsare lost on a cold start, and youcannot refer to them in a CEDAtransaction.
EXEC CICSCSD systemcommands
This method updates resourceson the CSD file, which meansyou can define, alter, and installresources in a running CICSsystem.
You can write applicationscustomized to yourenvironment that can managethe CSD and installedresources. Resources updatedby this method can be referredto by CEDA.
Requires more work toimplement than some othermethods.
DFHCSDUP DFHCSDUP is an offline utilitythat allows you to define, list,and modify resources using abatch job. DFHCSDUP can beinvoked as a batch program orfrom a user-written programrunning either in batch modeor under TSO. Using thesecond method, you can specifyup to five user exit routineswithin DFHCSDUP.
v You can modify or define alarge number of resources inone job.
v You can run DFHCSDUPagainst a non-recoverableCSD file while it is beingshared between CICS regionsusing RLS access mode.
v You cannot install resourcesinto an active CICS system.
v You cannot make updates viaDFHCSDUP against arecoverable CSD file that isbeing accessed in RLS mode.
6 CICS TS for z/OS 4.2: Resource Definition Guide
-
Table 2. Methods of resource definition (continued)
Method Description Advantages Disadvantages
Applicationbundles
This method applies toapplication resources only. Ituses the bundle deploymentsupport in CICS to create theapplication resources andmaintains a relationship toenable and disable all resourcestogether.
v You do not have to create allof the required resources foran application manually.
v You can change theavailability of applicationsavailable by updating oneresource.
v You cannot browse thecontents of a bundle usingCEMT.
v A limited set of applicationresources are supported.
Autoinstall This applies to VTAMterminals, LU6.2 sessions, IPICconnections, journals,programs, mapsets, andpartitionsets. You set up“model” definitions usingeither RDO or DFHCSDUP.CICS can then create and installnew definitions for theseresources dynamically, based onthe models.
If you have large numbers ofresources, much time is neededto define them, and if they arenot all subsequently used,storage is also wasted for theirdefinitions. Using autoinstallreduces this wasted time andstorage.
You must spend some timeinitially setting up autoinstall inorder to benefit from it.
Macro Using this method, you codeand assemble macroinstructions to define resourcesin the form of tables.
Where possible, use the othermethods.
v You can change thedefinitions contained in thetables while CICS is running,but you must stop andrestart CICS if you want it touse the changed tables.
v You must do time-consumingassemblies to generate macrotables.
Using the CSD and control tables togetherIn some cases, you can use resources that are defined in the CSD with resourcesthat are defined in control tables.
About this task1. On an initial or cold start, you can mix file control resources that are defined in
the CSD with those that were defined using DFHFCT macros. BDAM filedefinitions are loaded from the DFHFCT load module first, then the definitionsfor other types of files are loaded from the RDO groups specified in theGRPLIST system initialization parameter. When CICS is running, you can useCEDA commands to add more file resource definitions.
2. You can also mix terminal resource definitions for BSAM sequential devicesand logical device codes (LDCs) that are defined in a TCT with resourcedefinitions for SNA LUs that are defined using RDO.However, avoid duplicate terminal IDs, because a TCT entry using the sameterminal ID (TRMIDNT in the TCT) as an SNA LU in the CSD (TERMINALname in the CSD), prevents CICS installing the z/OS Communications Serverdefinition.
3. For temporary storage queues, you can use TSMODEL resource definitions incombination with a temporary storage table (TST). To combine a TST withTSMODEL resources:v Specify a TST suffix using the TST system initialization parameter.
Chapter 1. An overview of resource definition 7
-
v Assemble the TST load module with the MIGRATE option. If the TST is notassembled with the MIGRATE option, CICS loads the TST only and does notprovide any RDO support for temporary storage queues, and any attempts toinstall TSMODEL resource definitions are rejected.
If you use both a TST and TSMODEL resource definitions, the use of the TST islimited to support for temporary storage data sharing queues that arereferenced by an explicit SYSID option specified on a temporary storage EXECCICS command, and also the use of the TSAGE attribute.
Where resource definitions are heldEvery resource defined to CICS by means of CEDA or DFHCSDUP is held on theCICS system definition (CSD) file, which is a VSAM data set.
The CSD file can be defined as recoverable, so that changes made by CEDA orCEDB that were incomplete when an abend occurred are backed out. CICS allowsa CSD file and its resource definitions to be shared between different CICSsystems. For more information on defining the CSD, see in the CICS SystemDefinition Guide.
CICS control tables contain resource definition records for resources that cannot bedefined in the CSD. The tables and their resource definitions are created by usingthe CICS table assembly macro instructions. You have to code assembler-languagemacro statements for each resource to appear in the table, assemble the completeset of macro statements, link-edit the output to produce a load module, and specifythe module suffix in DFHSIT. See “Defining resources in CICS control tables” onpage 507.
How resource definitions are organizedResource definitions held on the CSD are organized into groups and lists.
Group A collection of related resources on the CSD. Each resource that you definemust belong to a group; you cannot define a resource without naming thegroup.
List The names of groups that CICS installs at an initial or cold start. You canadd groups to lists if you want them installed at an initial or cold start, orif it helps you to manage your groups better. Groups do not have tobelong to lists, and can be defined independently.
For more information on groups and lists, see Chapter 3, “Groups and lists,” onpage 23.
Commands for managing resourcesYou manage your resource definitions using commands supplied as part of CEDAor DFHCSDUP. These commands allow you to work with your resources, forexample, by defining, deleting, copying, and renaming.
The commands are listed in Table 3 on page 9. For the syntax of these commandsand information on how to use them, see “System definition file utility program(DFHCSDUP)” on page 447 To help you use CEDA, see “The CEDA transactiontutorial” on page 393.
8 CICS TS for z/OS 4.2: Resource Definition Guide
-
Table 3. CEDA and DFHCSDUP commands
Command Function CEDA—see DFHCSDUP—see
ADD Adds a group name to a list. “The CEDAADDcommand” onpage 415
“TheDFHCSDUPADDcommand” onpage 454
ALTER Modifies the attributes of an existing resourcedefinition.
“The CEDAALTERcommand” onpage 416
“TheDFHCSDUPALTERcommand” onpage 455
APPEND Copies a list to the end of another list. “The CEDAAPPENDcommand” onpage 418
“TheDFHCSDUPAPPENDcommand” onpage 457
CHECK (CEDA only) Cross checks the resource definitions within agroup, or within the groups in a list or lists, upto a maximum of four lists.
“The CEDACHECKcommand” onpage 418
COPY Copies one or more resource definitions fromone group to another, or one resource definitionwithin a group.
“The CEDACOPYcommand” onpage 420
“TheDFHCSDUPCOPYcommand” onpage 459
DEFINE Creates a new resource definition. “The CEDADEFINEcommand” onpage 423
“TheDFHCSDUPDEFINEcommand” onpage 460
DELETE Deletes one or more resource definitions. “The CEDADELETEcommand” onpage 425
“TheDFHCSDUPDELETEcommand” onpage 462
DISPLAY (CEDA only) Shows the names of one or more groups, lists,or resource definitions within a group.
“The CEDADISPLAYcommand” onpage 427
EXPAND (CEDA only) Shows the names of the resource definitions inone or more groups or lists.
“The CEDAEXPANDcommand” onpage 429
EXTRACT (DFHCSDUP only) Extracts and processes resource definition datafrom groups or lists on the CSD file.
“TheDFHCSDUPEXTRACTcommand” onpage 464
INITIALIZE (DFHCSDUP only) Prepare a newly-defined data set for use as aCSD file.
“TheDFHCSDUPINITIALIZEcommand” onpage 466
Chapter 1. An overview of resource definition 9
-
Table 3. CEDA and DFHCSDUP commands (continued)
Command Function CEDA—see DFHCSDUP—see
INSTALL (CEDA only) Dynamically adds a resource definition or agroup of resource definitions to the active CICSsystem.
“The CEDAINSTALLcommand” onpage 432
LIST (DFHCSDUP only) Produce listings of the current status of theCSD file.
“TheDFHCSDUPLISTcommand” onpage 466
LOCK (CEDA only) Prevents other operators updating or deleting agroup or the groups in a list.
“The CEDALOCKcommand” onpage 434
MOVE (CEDA only) Moves one or more resource definitions fromone group to another.
“The CEDAMOVEcommand” onpage 435
PROCESS (DFHCSDUP only) Applies maintenance to the CSD file for aspecific APAR.
“TheDFHCSDUPPROCESScommand” onpage 468
REMOVE Removes a group name from a list. “The CEDAREMOVEcommand” onpage 438
“TheDFHCSDUPREMOVEcommand” onpage 469
RENAME (CEDA only) Renames a resource definition, either within agroup, or while simultaneously moving it toanother group.
“The CEDARENAMEcommand” onpage 439
SCAN (DFHCSDUP only) Scans all of the IBM-supplied groups anduser-defined groups for a resource. Thedefinition of the matched resource in anIBM-supplied group is compared to thedefinition(s) of the corresponding matchedresource in the user groups.
“TheDFHCSDUPSCANcommand” onpage 469
SERVICE (DFHCSDUP only) Applies corrective maintenance to the CSD file. “TheDFHCSDUPSERVICEcommand” onpage 471
UNLOCK (CEDA only) Releases a lock on a group or list. “The CEDAUNLOCKcommand” onpage 440
UPGRADE (DFHCSDUP only) Upgrades the CICS-supplied resourcedefinitions on the CSD file (for example, whenyou migrate to a higher release of CICS).
“TheDFHCSDUPUPGRADEcommand” onpage 472
10 CICS TS for z/OS 4.2: Resource Definition Guide
-
Table 3. CEDA and DFHCSDUP commands (continued)
Command Function CEDA—see DFHCSDUP—see
USERDEFINE Creates a new resource definition with yourown defaults.
“The CEDAUSERDEFINEcommand” onpage 442
“TheDFHCSDUPUSERDEFINEcommand” onpage 473
VERIFY (DFHCSDUP only) Removes internal locks on groups and lists. “TheDFHCSDUPVERIFYcommand” onpage 474
VIEW (CEDA only) Shows the attributes of an existing resourcedefinition.
“The CEDAVIEWcommand” onpage 445
Shared resources for intercommunicationResources that reside on a remote system, but are accessed by a local CICS system,have to be defined on both the remote and local systems. To avoid duplicatingdefinitions in the CSD files for the local and remote systems, you can createresource definitions on a CSD file that is shared by the local and remote systems.This reduces disk storage and maintenance, because you require only one CSD filerecord for each shared resource.
If you decide to use dual-purpose resource definition, you may want to considerreorganizing your resources within your resource definition groups. For example,you might currently have two groups: one containing all the resources for a CICStransaction-owning region (TOR), and one containing all the resources for a CICSapplication-owning region (AOR).
When you use shared resource definitions, you can have three groups, with thefirst group containing resources specific to the TOR, the second group containingresources specific to the AOR, and the third group containing resources to beinstalled in both the TOR and the AOR.
These resources should be defined as both local and remote. When the definition isinstalled on the TOR, CICS compares the SYSIDNT name with theREMOTESYSTEM name. If they are different, a remote transaction definition iscreated. When the definition is installed on the AOR, CICS compares theREMOTESYSTEM name with the SYSIDNT name. If they are the same, a localtransaction definition is installed.
Dual-purpose resource definition can be used with the following resources:v Filesv Programsv Temporary storage models (TSMODELs)v Terminalsv Transient data queues (TDQUEUEs)v Transactions
Chapter 1. An overview of resource definition 11
-
Security of resource definitionsCICS provides a number of facilities that help you keep your resource definitionssecure from unauthorized use.
When you are considering the security of your resource definitions:
Limited access to resource definitions in the CSDYou should limit read/write access to resource definitions in the CSD to asmall number of people. To do this:v Protect groups of resources by using the CEDA command LOCKv Protect the list of resource groups that is specified in the system
initialization parameter GRPLIST by using the CEDA command LOCKv Use the CEDB transaction to create resource definitions, but not to
INSTALL themv Use the CEDC transaction for read-only access to resource definitions.
Resource security checking
Resource security checking ensures that terminal operators can access onlythose resources for which they have been authorized. You can use resourcesecurity checking (RESSEC) for the TRANSACTION definition.
Multiple CSD files
You can have different CSD files for different CICS systems. The users ofone CICS do not have access to the CSD file for another CICS.
You could have a test CSD file in a system where the RDO transactions canbe used, and a production CSD file in a system where the RDOtransactions are not available. There would then be no chance ofunauthorized users altering resource definitions needed for productionwork.
Read-only and update definitions for the same CSD file
Having two CSD files means duplicating resource definitions for resourcesthat are shared by more than one system. An advantage of RDO is thatyou need only one definition for each resource. You can define one CSDfile to be shared among several CICS systems with only one having writeaccess. To do this, you define one CSD file differently to different systemsby using the CSDACC system initialization parameter. For the systemwhere the CSD file can be used but not updated, you specify:CSDACC=READONLY
and, for the system where you are planning to update the CSD, youspecify:CSDACC=READWRITE
You need READONLY access to install definitions. This also allows you touse the DISPLAY and VIEW commands. You need READWRITE access touse the ADD, APPEND, ALTER, COPY, MOVE, and RENAME commands.For information on defining the CSD file, see “Resource managementutility DFHCSDUP commands” on page 454.
Controlling access to a group or list—LOCK and UNLOCK
RDO also provides a means of controlling access to any group or list, sothat users in the same system can have different types of access. This isdone with the LOCK and UNLOCK commands.
12 CICS TS for z/OS 4.2: Resource Definition Guide
-
The LOCK and UNLOCK commands enable you to control update accessto a group or list so that only operators with the same operator identifiercan make changes.
The lock is held on the CSD file and remains in effect across restarts ofCICS. The lock is owned by the user, who is identified by a combination ofthe CICS generic applid (specified by the APPLID system initializationparameter), and the user's operator identifier (OPIDENT).
The OPIDENT is the one associated with the user when he or she signs onto the terminal used for RDO. For further information on OPIDENT, seethe CICS RACF Security Guide.
Any user who is not signed on or who has a different OPIDENT is notallowed to perform any operation that would change the locked group.However, any user is allowed to do the following things to a locked group:v COPYv CHECKv DISPLAYv INSTALLv VIEW
The lock can be removed, using the UNLOCK command, only by a user onthe same system and with the same operator identifier.
It would be wise to put a lock on your group of TYPETERMs and on yourgroup of AUTINSTMODEL TERMINALs.
Controlling access to the RDO transactions
Recommended access for the CEDA, CEDB, and CEDC transactions is asfollows:v CEDC can be given fairly wide access, because it allows only read-only
commands.v CEDB should be restricted, because it allows modification of the CSD
file as well as read-only commands.v CEDA should be further restricted to the few people allowed to modify
both the active CICS system and the CSD file.
Installing resourcesA user who is authorized to use CEDA can install any resources in theCICS system: beyond checking the user's authority to use the transactionitself, CICS does not do any command or resource security checking in theCEDA transaction.
This is not the case for transactions that use the CREATE command toinstall resources; here, CICS usesv command security to check that the user is authorized to use the
CREATE command. For more information, see the CICS RACF SecurityGuide.
v resource security to check that the user is authorized to modify theresource in question. For more information, see the CICS RACF SecurityGuide.
Auditing resourcesThe resource signature, the combination of the definition and the installationsignatures, can be used to audit and manage resources by capturing details whenthe resource is defined, installed, and last changed.
Chapter 1. An overview of resource definition 13
-
Being able to display information about when the resource was defined, installed,and last changed helps with problem determination. The details improve theauditing and tracing of resources and can be displayed in the CICS Explorer views,CICSPlex SM views, CEDA panels, using EXEC CICS INQUIRE SPI commands andCEMT INQUIRE commands. The following resource types support the resourcesignature:
ATOMSERVICEBUNDLECONNECTIONCORBASERVERDB2CONNDB2ENTRYDB2TRANDJARDOCTEMPLATEENQMODELEPADAPTEREVENTBINDINGFILEIPCONNJOURNALMODELJVMSERVERLIBRARYMQCONNMQINIOSGIBUNDLEPIPELINEPROFILEPROCESSTYPEPROGRAMREQUESTMODELTCPIPSERVICETDQUEUETRANCLASSTRANSACTIONTSMODELURIMAPWEBSERVICEXMLTRANSFORM
For these resources, their definition and installation signatures can be compared toidentify their origin. For more information, see the following topics.
The definition signature for resource definitionsThe definition signature captures details about when, how, and by whom eachresource is defined or changed in the CSD file or in the CICSPlex SM EYUDREP
14 CICS TS for z/OS 4.2: Resource Definition Guide
|
|
-
data repository. The definition signature is updated each time a change is made tothe resource. You can use these details to detect resource modifications for auditingor for fixing problems.
The definition signature is displayed in the CICS Explorer views, on CEDA andCEMT panels, CICSPlex SM BAS views, EXEC CICS INQUIRE commands, and inDFHCSDUP reports. These are the definition signature fields:
DEFINESOURCEThe source of the resource definition. The DEFINESOURCE value dependson the CHANGEAGENT.
DEFINETIMEThe time when the resource definition was created using the DEFINE,USERDEFINE, COPY, MOVE, or RENAME commands. When you alter anexisting resource using the ALTER command, the value specified byDEFINETIME does not change. On CEDA panels, the date is displayed inthe format that you specified in the DATFORM system initializationparameter.
CHANGEAGENT How the resource was defined or last modified, by using one of thesemethods:
AutoinstallAutoinstall
CsdapiCEDA, the programmable interface to DFHEDAP, or EXEC CICSCSD command
CsdbatchDFHCSDUP
DrepapiCICSPlex SM BAS API command
DynamicThe resource was generated by:
A PIPELINE scan (URIMAP or WEBSERVICE).CICS Web template management, using DFHWBTL orDFHWBBMS (DOCTEMPLATE).The installation of a DB2ENTRY resource definition withtransid specified (DB2TRAN).The installation of an ATOMSERVICE resource definition withXSDBIND specified (XMLTRANSFORM).The installation of an MQCONN resource definition withINITQNAME specified (MQINI).The installation of a CORBASERVER resource definition withautopublish specified (DJAR).
SystemCICS or CICSPlex SM system
Table Table definition
CHANGEAGRELThe level of the CICS system used for the definition of, or last modificationto, the resource definition.
Chapter 1. An overview of resource definition 15
-
CHANGETIMEThe time when the resource definition was last modified. When theresource is first defined, the CHANGETIME value is identical to theDEFINETIME value. On CEDA panels, the date is displayed in the formatthat you specified in the DATFORM system initialization parameter.
CHANGEUSRID The ID of the user who defined or last modified the resource definition.
To display the definition signature for an individual resource, or a group ofresources, in the CEDA DISPLAY and EXPAND GROUP panels press PF2. Toreturn to the previous CEDA command panel, press PF2 again.
To display a summary of the definition signatures for all the specified resources,add the SIGSUMM parameter to the DFHCSDUP LIST command. The definitionsignature fields are displayed with the resource attributes when you use theOBJECTS option on the command. The DFHCSDUP EXTRACT command also extracts thedefinition signature fields from the CSD file.
Resources defined in CICS releases before CICS TS 4.1 do not have informationdisplayed for the definition signature until they are modified in this CICS releaseor later. When the resource is modified, the DEFINETIME field remains blank.
The installation signature for resource definitionsThe installation signature shows when, how, and by whom each resource isinstalled.
The installation signature is displayed in the CICS Explorer views, the CICSPlexSM Operations views, on the expanded view panel of the CEMT INQUIRE commandfor the resource, or you can use an EXEC CICS INQUIRE command. These are theinstallation signature fields:
INSTALLAGENTHow the resource was installed, by using one of these methods:
AutoinstallAutoinstall
BundleBundle deployment
CreatespiEXEC CICS CREATE command
CsdapiCEDA, the programmable interface to DFHEDAP, or EXEC CICSCSD command
DynamicThe installed resource was generated by:
A PIPELINE scan (URIMAP or WEBSERVICE).CICS Web template management, using DFHWBTL orDFHWBBMS (DOCTEMPLATE).The installation of a DB2ENTRY resource definition withtransid specified (DB2TRAN).The installation of an ATOMSERVICE resource definition withXSDBIND specified (XMLTRANSFORM).
16 CICS TS for z/OS 4.2: Resource Definition Guide
-
The installation of an MQCONN resource definition withINITQNAME specified (MQINI).The installation of a CORBASERVER resource definition withautopublish specified (DJAR).
GrplistGRPLIST INSTALL
SystemCICS or CICSPlex SM system
Table Table definition
INSTALLTIMEThe time when the resource was installed.
INSTALLUSRIDThe ID of the user who installed the resource.
Summary of the resource signature field valuesUse these tables for details of the contents of the resource signature fields for all ofthe methods used to install resource definitions in a running CICS system.
Table 4. Resource signature contents. Part 1.
Resource signaturefield GRPLIST INSTALL
CEDA INSTALLor EXEC CICSCSD INSTALL
EXEC CICSCREATE
CICSPlex SM(EXEC CICSCREATE) Autoinstall
DEFINESOURCE CSD GROUP CSD GROUP Name of theprogram issuingthe EXEC CICSCREATE
CPSMVnn where"nn" is the versionof the CICSPlexSM BAS resourcedefinition (the VERattribute)
Autoinstall userprogram name
DEFINETIME Time stamp of CSDrecord creation
Time stamp of CSDrecord creation
Time that theresource is created
CREATETIMEfrom EYUDREP
Time of theautoinstall
CHANGEAGENT CSDAPI orCSDBATCH
CSDAPI orCSDBATCH
CREATESPI DREPAPI orSYSTEM
AUTOINSTALL
CHANGEAGREL CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
CHANGETIME Time stamp of CSDrecord change
Time stamp of CSDrecord change
Time that theresource is created
CHANGETIMEfrom EYUDREP
Time of theautoinstall
CHANGEUSRID User ID that ran theCHANGEAGENT
User ID that rantheCHANGEAGENT
User ID that ranthe EXEC CICSCREATE
CHANGEUSRIDfrom EYUDREP▌2▐
User ID that ranthe autoinstall
INSTALLAGENT GRPLIST CSDAPI CREATESPI CREATESPI AUTOINSTALL
INSTALLTIME Time of the last coldstart
Time of the install Time that theresource is created(from earlier run ifwarm-started)
Time that theresource is created(from earlier run ifwarm-started)
Time of theautoinstall (fromearlier run ifwarm-started)
INSTALLUSRID Jobstep user ID User ID that ranthe install
User ID that ranthe EXEC CICSCREATE
User ID that ranthe create orpassed fromCICSPlex SM
User ID that ranthe autoinstall
Chapter 1. An overview of resource definition 17
-
Table 5. Resource signature contents. Part 2.
Resource signaturefield Table definition System defined
Dynamicallycreated
Created byBUNDLE
CICSPlex SMSYSLINK
DEFINESOURCE Table name SYSTEM For details, seeTable 6
BUNDLE name SYSLINK
DEFINETIME Time of the last coldstart
Time of CICSstartup
Time that theresource isgenerated
Inherited fromBUNDLE
Time that theresource isinstalled.
CHANGEAGENT TABLE SYSTEM DYNAMIC Inherited fromBUNDLE
DREPAPI
CHANGEAGREL CICS release fromtable assembly in"nnnn" format ▌1▐
CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
Inherited fromBUNDLE
CICS release ofCHANGEAGENTsystem in "nnnn"format ▌1▐
CHANGETIMETime of the last coldstart
Time of CICSstartup
Time that theresource isgenerated
Inherited fromBUNDLE
Time that theresource isinstalled
CHANGEUSRID Jobstep user ID Jobstep user ID User ID thatgenerated theresource (fordetails, see Table 6)
Inherited fromBUNDLE
User ID thatrequested theSYSLINKinstallation ▌2▐
INSTALLAGENT TABLE SYSTEM DYNAMIC BUNDLE CREATESPI
INSTALLTIME Time of the last coldstart
Time of CICSstartup
Time that theinstalled resourceis generated
Inherited fromBUNDLE
Time that theresource isinstalled
INSTALLUSRID Jobstep user ID Jobstep user ID User ID thatgenerated theinstalled resource(for details, seeTable 6)
Inherited fromBUNDLE
User ID thatrequested theSYSLINKinstallation
Notes1. The "nnnn" format for the CICS release is the unique 4-digit identifier; for
example, 0660 is the identifier for CICS TS 4.1.2. For the CICSPlex SM BAS resource definitions in the EYUDREP data repository,
when CICS security is active the CHANGEUSRID field contains the user ID thatmade the last modification to the resource definition. When CICS security is notactive, the CHANGEUSRID field contains blanks.
Table 6. The contents of the CHANGEUSRID, DEFINESOURCE, and INSTALLUSRID fields for dynamic resources
Dynamic resource Generated by CHANGEUSRID DEFINESOURCE INSTALLUSRID
DB2TRAN The installation of aDB2ENTRY resourcedefinition withTRANSID specified
User ID that installedthe DB2ENTRY
DB2ENTRY name User ID that installedthe DB2ENTRY
DJAR A CORBASERVER scan User ID that ran theCORBASERVER scan
CORBASERVER name User ID that ran theCORBASERVER scan
DOCTEMPLATE CICS Web templatemanagement, usingDFHWBTL orDFHWBBMS
User ID that ranDFHWBBMS orDFHWBTL
DFHWBBMS orDFHWBTL
User ID that ranDFHWBBMS orDFHWBTL
MQINI The installation of anMQCONN resourcedefinition withINITQNAME specified
User ID that installedthe MQCONN
MQCONN name User ID that installedthe MQCONN
URIMAP A PIPELINE scan User ID that ran thePIPELINE scan
PIPELINE name User ID that ran thePIPELINE scan
18 CICS TS for z/OS 4.2: Resource Definition Guide
-
Table 6. The contents of the CHANGEUSRID, DEFINESOURCE, and INSTALLUSRID fields for dynamicresources (continued)
Dynamic resource Generated by CHANGEUSRID DEFINESOURCE INSTALLUSRID
WEBSERVICE A PIPELINE scan User ID that ran thePIPELINE scan
PIPELINE name User ID that ran thePIPELINE scan
XMLTRANSFORM The installation of anATOMSERVICE resourcedefinition withXSDBIND specified
User ID that installedthe ATOMSERVICE
ATOMSERVICE name User ID that installedthe ATOMSERVICE
Getting started with resource definitionThere are several steps that you must perform to begin defining resources.
Procedure1. Create and initialize a CSD. See the CICS System Definition Guide for
information on how to do this.2. Using the DFHCSDUP UPGRADE command, bring the CICS supplied definitions in
your CSD file up to the level of CICS Transaction Server for z/OS, Version 4Release 2.
3. Work with your resource definitions. Use Table 1 on page 4 and Table 2 on page6 to help you decide which methods to use to define and manage yourresources.v If you want to use CEDA, read “The CEDA transaction tutorial” on page 393
for help in using CEDA and “Resource management transaction CEDAcommands” on page 414 for reference information.
v If you want to use DFHCSDUP, read “System definition file utility program(DFHCSDUP)” on page 447 for guidance information and “Resourcemanagement utility DFHCSDUP commands” on page 454 for referenceinformation.
v If you want to use autoinstall, read Chapter 42, “Autoinstall,” on page 477.
Chapter 1. An overview of resource definition 19
-
20 CICS TS for z/OS 4.2: Resource Definition Guide
-
Chapter 2. CSD file management
The CICS system definition (CSD) file is a VSAM data set containing a resourcedefinition record for every resource defined to CICS by means of CEDA orDFHCSDUP.
The CSD can be defined as recoverable, so that changes made by CEDA or CEDBthat were incomplete when an abend occurred, are backed out.
You can change the contents of the CSD without interfering with a running CICSregion that uses the CSD. This is because when you install the definitions in theCICS region, CICS copies the information from the CSD, and keeps it in its ownstorage. You can also change the definitions in the running CICS region byreinstalling them, or add more definitions by installing new ones.
Compatibility mode (CSD file sharing)CICS allows a CSD file and its resource definitions to be shared between differentCICS systems.
The systems might be running the same or different releases of CICS.Compatibility mode is intended for use when you want to create or changeresource definitions on a CSD file that is shared between different releases.
All maintenance should be done under the latest release of CICS. This avoids therisk of earlier releases modifying entries created under more recent releases withnew attributes that the older version does not recognize. Ensure this by restrictingwrite access to the CSD file to the latest release. See the CICS System DefinitionGuide for further details on defining CSD files.
Compatibility mode is entered by using PF2 on the CEDA panels where it isavailable. It gives you access to those attributes that were current at your earlierrelease, but are obsolete at your later release. However, you can use compatibilitymode only with commands affecting individual resources: you cannot performgeneric commands (ALTER, DEFINE, and VIEW) in compatibility mode.
There is more information about issues relating to compatibility mode in thefollowing places:v For the usage and meaning of attributes and their compatibility with previous
releases of CICS, see Appendix A, “Obsolete attributes,” on page 831.v For information about what compatibility groups you need in your startup
group list for CSD file sharing to work, see “CICS-supplied compatibilitygroups” on page 845, and the CICS Transaction Server for z/OS Upgrading fromCICS TS Version 4.1, which has a table showing the DFHCOMPx groups youneed to include for the earlier releases.
Creating a CSD fileIf you do not already have a CSD file, you must create one.
© Copyright IBM Corp. 1982, 2014 21
-
About this task
For detailed information about creating a CSD file, see the CICS System DefinitionGuide.
You can create more than one CSD file, depending on your requirements. Forexample, you can have different CSD files for different systems, so that your testsystems and production systems are separate from each other.
You can also share one CSD file between CICS releases; see “Compatibility mode(CSD file sharing)” on page 21.
When the CSD file has been initialized, it contains a number of groups (allbeginning with the letters 'DFH') containing related resource definitions, and onelist, called DFHLIST. These definitions are supplied by CICS and are necessary forsome system functions and for running CICS-supplied transactions.
22 CICS TS for z/OS 4.2: Resource Definition Guide
-
Chapter 3. Groups and lists
Information on the CSD file is organized into groups and lists.
The main purpose of the group is to provide a convenient method of collectingrelated resources together on the CSD file. Every resource that you define mustbelong to a group; you cannot define a resource without also naming its group.
A list contains the names of groups that CICS installs at an initial or cold start.You can add groups to lists if you want them to be installed at an initial or coldstart, or if it helps you to manage your groups better. Groups do not have tobelong to lists, and can be defined independently.
What should be in a group?When you organize resource definitions into groups, you should consider keepingresources together that have something in common. For example, you might keepall resources related to an application in the same group. In some cases, CICSrequires you to put certain resources in the same group.
Usually, the definitions within a group have something in common. For example:
For application resources:v It is more convenient to keep all the resource definitions belonging to one
application in one group.v If you use PARTITIONSET or PROFILE definitions for many applications,
keeping them separate in their own groups avoids the possibility of unnecessaryduplication.
For communication resources:v SESSIONS definitions must be in the same group as the CONNECTION
definition to which they refer. You may have more than one group of definitionsfor each system and its sessions with other systems, in a single CSD file that isshared by all the systems. Be careful that you install each group of definitions inthe correct system.
v Restrict a group to contain only one CONNECTION definition with itsassociated SESSIONS definitions.
v Keep all your TYPETERM definitions in one group. This avoids the possibility ofunnecessary duplication. You must put the group of TYPETERMs before thegroups of TERMINAL definitions in your lists.
v It is convenient to group TERMINAL definitions according to departmentalfunction or geographical location.
v You must keep all the TERMINAL definitions for one pool of pipeline terminalsin the same group.
v Keep AUTINSTMODEL TERMINAL definitions separately in a group of theirown.
For CORBA resources:
© Copyright IBM Corp. 1982, 2014 23
-
v A CORBASERVER definition must be in the same group as the DJAR definitionsthat refer to it, or in a group that is installed before the group containing thoseDJAR definitions, otherwise CICS may attempt to install the DJAR before theCORBASERVER it requires.
For transient data resources, sample definitions for the CICS-supplied transientdata queues (those beginning with the letter “C”) are provided in groupDFHDCTG. For these definitions to become available for use at the earliestpossible point during CICS initialization, include group DFHDCTG as the firstgroup installed during an initial or cold start.
How many resource definitions should a group contain?Try to keep your groups to a manageable size; ideally, there should be no morethan about 100 resource definitions in a group.
Allocate your resource definitions between groups to obtain optimum performance,in both system and administration terms. The following considerations may help:v A large group can involve a lot of unnecessary processing time to install. This is
particularly true of those containing TERMINAL and SESSIONS definitions,because they take a large amount of dynamic storage.
v A large number of very small groups can also use unnecessary processing time,because of the extra I/O involved in reading many group names from the CSDfile. In theory, you could have one resource definition per group, but this is notrecommended; the processing of a large number of single-resource groups canaffect DASD space, initial or cold start performance, and the performance ofboth CEDA and DFHCSDUP.
v Administration is easier if you have smaller groups. For example, the DISPLAYGROUP ALL command involves a lot of scrolling if the resource definitions inthe group extend over many screens. You cannot see at a glance the contents ofa large group.
v You may find that you have storage problems when you EXPAND, COPY, orINSTALL a large group. In particular, if a very large number of CSD file recordsare defined in a region with a small dynamic storage area, issuing a CEDAEXPAND GROUP(*) command can result in the system going short on storage(SOS).
Setting up lists for initializationYou can specify up to four lists, using specific or generic naming, on the GRPLISTsystem initialization parameter. The default list is the CICS-supplied list DFHLIST.
The lists that you name in the GRPLIST system initialization parameter mustinclude all the resource definitions required by CICS. These are supplied by CICSand are added to the CSD file when you initialize it before starting to use RDO.For further information about this, see “Resource management utility DFHCSDUPcommands” on page 454.
To create a list containing both CICS-supplied and your own resource definitions:1. Start to create the list that you use to initialize CICS, by appending DFHLIST to
a new list. For example:CEDA APPEND LIST(DFHLIST) TO(INITLIST)
24 CICS TS for z/OS 4.2: Resource Definition Guide
-
This ensures that all CICS-supplied definitions are installed, whether or not youneed to change them.
2. Remove the groups containing definitions for function that you do not require.For example:CEDA REMOVE GROUP(DFHMISC) LIST(INITLIST)
3. Copy all the resource definitions that you need to change into your owngroups. For example:CEDA COPY TRANSACTION(CEDF) GROUP(DFHOPER) TO(SECTRANS)CEDA COPY PROFILE(DFHCICST) GROUP(DFHSTAND) TO(REQMOD)
Do not rename the copies. You can now use ALTER to change the attributes asnecessary. For example:CEDA ALTER TRANSACTION(CEDF) GROUP(SECTRANS)
4. Add these groups to your list for initialization. For example:CEDA ADD GROUP(SECTRANS) LIST(INITLIST)CEDA ADD GROUP(REQMOD) LIST(INITLIST)
Make sure that you add this group after the DFH groups. Although you nowhave two definitions for the resources that you have altered, the seconddefinition in the list is the one that will be installed, if you name this list as aGRPLIST parameter when you initialize CICS.
5. Add any other groups containing resource definitions of your own that youwant to use, or append other lists. Your list might look like this:DFHBMSDFHCONS...DFHVTAMPSECTRANSREQMODZEMAPPLZEMCOMMZEMTYPESZEMTERMS
Note that the group containing the TYPETERMs should come before the groupscontaining the TERMINAL definitions.
6. Cold start your CICS system, naming the list or lists that you have created inthe GRPLIST system initialization parameter. For example:START=COLD,GRPLIST=INITLIST
Using several listsYou can create lists that contain different sets of groups so that you can initializedifferent “flavors” of CICS using the GRPLIST system initialization parameter.
Using different lists at different timesInitialize your CICS system with the START=AUTO system initializationparameter, so that the CICS catalog is used to define the system wheneverpossible, instead of the list or lists named in the GRPLIST operand.
However, if you use CICS differently each time you initialize it, specify theSTART=COLD system initialization parameter, and specify a different list to defineyour system every time you initialize CICS. For example, you might have:v A different list for each day of the week, if the pattern of work is different on
each day.
Chapter 3. Groups and lists 25
-
v A list for the CICS used for the day shift, and a list for the CICS used for thenight shift.
v A test only list used only when CICS is started up by the system programmerson a day of rest (for example).
v For security reasons, a special list containing groups of restricted resourcedefinitions. You could append this list to your usual one, when these resourcesare needed.
Consider how you might use the list and group mechanisms with transactionsrelated to a company's salary operations.
Assume that some transactions used by the salary administrators are used everyday. For example, a transaction for handling an employee's tax details may have tobe performed at any time. Other transactions, such as minor weekly or monthlypayroll adjustments, are run at predefined intervals, or on specific days or dates.You would therefore not want to include the same mixture of transactions andprograms every time the system was started up.
By creating a resource definition group for taxation transactions, and another forpayroll transactions, you could add them to different lists to produce the requiredsystem tables for different days. In the above example, one list would identify onlythe taxation group; the other would identify both taxation and payroll groups. Youwould specify the appropriate list in a system initialization parameter.
Clearly, a real system would have many more groups and lists than this.
Using different lists for different CICS regionsIf you are running more than one CICS region in the same MVS image, you mayuse the same CSD file to define your resources to both regions.
This helps you to ensure that each region has the same definition of resourceswhere necessary. You probably do not want to use all the same resources in eachregion, so you could create a list for each region. You name the appropriate list inthe system initialization parameter for each region.
For example, you might have two production CICS regions sharing a CSD file.Assume that one production region runs three applications: customer inquiry,billing, and adjustments. Each application has its own resources (programs, mapsets, and transactions), so you put the resource definitions in three groups:CUSTINQ, CUSTBILL, and CUSTADJ. Then you add these groups to a list calledCICS1A.
Another production region runs two more applications in addition to customerinquiry: customer update and customer credit authorization. For these, you createtwo more groups (CUSTCRED and CUSTUPDT) and another list called CICS1B.
CICS1B contains the same CUSTINQ group as CICS1A, and it also containsCUSTCRED and CUSTUPDT. If you decide, for performance reasons, to move oneof your applications to a different CICS region, all you need to do is add theappropriate group name to the appropriate list. The next time you initialize CICSwith this list specified in the GRPLIST system initialization parameter, you installthe new group.
Using different lists when you introduce changesThe list with which you initialize CICS is a definition of your system (for RDOresources).
26 CICS TS for z/OS 4.2: Resource Definition Guide
-
When you introduce changes to your resources, it is useful to create a new list,keeping the old list to return to if something goes wrong. Then you can reinitializeCICS with the old list, knowing that everything is as it was previously.
Creating groups and listsA group is created when you specify it as the GROUP name in a DEFINEcommand or as the TO group in a COPY command.
About this task
For example, the command:CEDA DEFINE PROGRAM(PROG1) GROUP(MYGROUP)
defines a program called PROG1, and creates a group called MYGROUP if it doesnot already exist.
These are the only ways to create a group; a nonexistent group can be named in alist, but naming it in a list does not create it.
A group must not have the same name as an existing group or list.
You can create a list in either of the following ways:v Use the ADD command to add a group to a list. If the specified list does not
exist, it is created.v Use the APPEND command to append the contents of one list to another list. If
the appended-to list does not exist, it is created, containing the contents of thefirst list.
A list must not have the same name as an already existing group or list.
Checking groups and lists of resource definitions for consistencyThe CEDA CHECK command checks the consistency of definitions within a groupor within all of the groups within a list or lists. It does not, however, cross-checkevery attribute of a resource. You may still get error messages when installing agroup, although there were no problems when you used the CHECK command.
About this