CICS TS for z/OS 4.2: Resource Definition Guide · Resource definition .... . 1 Chapter 1. An...

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.


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


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.


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.


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.


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


Table 3. CEDA and DFHCSDUP commands (continued)


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


Table 3. CEDA and DFHCSDUP commands (continued)


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


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.


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.


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


|

|

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.


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).


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▐




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


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▐





CHANGETIMETime of the last coldstart

Time of CICSstartup

Time that theresource isgenerated


Time that theresource isinstalled

CHANGEUSRID Jobstep user ID Jobstep user ID User ID thatgenerated theresource (fordetails, see Table 6)


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


Time that theresource isinstalled

INSTALLUSRID Jobstep user ID Jobstep user ID User ID thatgenerated theinstalled resource(for details, seeTable 6)


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


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 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.


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.


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:


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)


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).


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

CICS TS for z/OS 4.2: Resource Definition Guide · Resource definition .... . 1 Chapter 1. An...

Documents

Transcript of CICS TS for z/OS 4.2: Resource Definition Guide · Resource definition .... . 1 Chapter 1. An...