z/os bdt file-to-file transaction guide - · pdf filecopy a partitioned data set to another...

z/OS

Bulk Data Transfer File-to-File TransactionGuideVersion 2 Release 3

SC14-7583-30

IBM

NoteBefore using this information and the product it supports, read the information in “Notices” on page 95.

This edition applies to Version 2 Release 3 of z/OS (5650-ZOS) and to all subsequent releases and modificationsuntil otherwise indicated in new editions.

Last updated: July 17, 2017

© Copyright IBM Corporation 1986, 2017.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

Figures . . . . . . . . . . . . . . . ix

About This Book. . . . . . . . . . . xiWho Should Read This Book. . . . . . . . . xiHow to Use This Book . . . . . . . . . . . xiRelated Reading . . . . . . . . . . . . . xi

How to send your comments to IBM xiiiIf you have a technical problem . . . . . . . xiii

Summary of changes . . . . . . . . xvSummary of changes for z/OS BDT File-to-FileTransaction Guide for Version 2 Release 3 (V2R3)and its updates . . . . . . . . . . . . . xvz/OS Version 2 Release 1 summary of changes . . xv

Chapter 1. Writing and SubmittingFile-to-File Transactions . . . . . . . . 1The Kinds of Data Sets You Can Copy with BDTFile-to-File Transactions . . . . . . . . . . . 1

Locations of the Data Sets . . . . . . . . . 1Organizations of the Data Sets . . . . . . . 1Record Formats of the Data Sets . . . . . . . 1Record Lengths and Block Sizes of the Data Sets . 2Storage Devices of the Data Sets . . . . . . . 2

How to write a transaction to copy a data set . . . 2Prefix . . . . . . . . . . . . . . . . . 3Transaction Definition . . . . . . . . . . . 4

The Job Definition Section . . . . . . . . . 4The FROM Section . . . . . . . . . . . 4The TO Section . . . . . . . . . . . . 5

How to Punctuate a Transaction . . . . . . . . 6How to Read the Transaction Parameter SyntaxDiagrams . . . . . . . . . . . . . . . 6How to Submit a Transaction . . . . . . . . . 7

How to Submit a Transaction Interactively . . . 7How to Submit a Transaction via ISPF Panels . . 7How to Submit a Transaction in a Batch Job . . . 7

How BDT Processes Transactions . . . . . . . 8How BDT Protects Transaction Processing . . . 9

Chapter 2. Storing and ReusingTransaction Definitions — GMJDLibraries . . . . . . . . . . . . . . 11What GMJD Libraries Are . . . . . . . . . 11How to Use System GMJD Libraries . . . . . . 11How to Create and Use Private GMJD Libraries . . 11

How to Create a Private GMJD Library . . . . 11How to Use a Private GMJD Library . . . . . 12Examples . . . . . . . . . . . . . . 12

How to Modify Stored Transaction Definitions . . 12How to Add Parameters . . . . . . . . . 13How to Remove Parameters . . . . . . . . 13How to Alter Parameters . . . . . . . . . 13

Chapter 3. Controlling the Order inWhich Transactions Are Processed —DTC Networks . . . . . . . . . . . 15What DTC Networks Are. . . . . . . . . . 15What Parameters You Need . . . . . . . . . 15How to Identify the Transactions That Belong to aDTC Network — the NETID Parameter . . . . . 16How to specify the order of transactions — theNETREL and JOBNAME parameters . . . . . . 16

NETREL Can Only Release Successors at theSame Node . . . . . . . . . . . . . 17

How to Make Sure Transactions Run in Order —the NETHOLD Parameter . . . . . . . . . 18How to Tell BDT What to Do If PredecessorTransactions Fail — the NETCOND Parameter . . 18How to Make Sure the First Transaction Doesn’tComplete Before You Can Submit the Second One . 19Example . . . . . . . . . . . . . . . 19

Chapter 4. Sample Transactions . . . . 21Copy a Data Set at Your Node to Another Data Setat Your Node . . . . . . . . . . . . . . 21Copy a Data Set from Your Node to Another Node 21Copy a Data Set from Another Node to Your Node 21Copy a Sequential Data Set to Another SequentialData Set . . . . . . . . . . . . . . . 22Copy a Partitioned Data Set to Another PartitionedData Set . . . . . . . . . . . . . . . 22Copy a Sequential Data Set to the End of anExisting Sequential Data Set . . . . . . . . . 22Copy a Data Set to a New Sequential DASD DataSet . . . . . . . . . . . . . . . . . 22Copy a Data Set to a New Partitioned DASD DataSet . . . . . . . . . . . . . . . . . 23Copy a Tape Data Set to a New Tape Data Set . . . 23Copy a DASD Data Set to a New Tape Data Set . . 23Copy a Cataloged Tape Data Set to a DASD DataSet . . . . . . . . . . . . . . . . . 24

Chapter 5. File-to-File TransactionParameter Reference . . . . . . . . 25Transaction format and parameter summary . . . 26

Required Parameters . . . . . . . . . . 27Transaction Prefixes . . . . . . . . . . 27

ACCT — Supply Accounting Information . . . . 28Rules . . . . . . . . . . . . . . . 28Format . . . . . . . . . . . . . . . 28Usage Note . . . . . . . . . . . . . 28Example . . . . . . . . . . . . . . 28

ALX — Allocate Space in Several Contiguous Areas 28Rules . . . . . . . . . . . . . . . 28Format . . . . . . . . . . . . . . . 29Usage Notes . . . . . . . . . . . . . 29Example . . . . . . . . . . . . . . 29

© Copyright IBM Corp. 1986, 2017 iii

BDTENQ — Request Shared or Exclusive Use of aData Set by a BDT Transaction . . . . . . . . 29

Rules . . . . . . . . . . . . . . . 29Format . . . . . . . . . . . . . . . 29Usage Notes . . . . . . . . . . . . . 30Example . . . . . . . . . . . . . . 30

BLKSIZE — Define the Block Size of a Data Set . . 30Rules . . . . . . . . . . . . . . . 30Format . . . . . . . . . . . . . . . 30Usage Notes . . . . . . . . . . . . . 31Example . . . . . . . . . . . . . . 31

BLOCK — Allocate Space in Block Units . . . . 31Rules . . . . . . . . . . . . . . . 31Format . . . . . . . . . . . . . . . 31Usage Notes . . . . . . . . . . . . . 31Example . . . . . . . . . . . . . . 31

BUFL — Define Buffer Lengths . . . . . . . . 32Rules . . . . . . . . . . . . . . . 32Format . . . . . . . . . . . . . . . 32Usage Notes . . . . . . . . . . . . . 32Example . . . . . . . . . . . . . . 32

CONTIG — Allocate Space in a Contiguous Area. . 32Rules . . . . . . . . . . . . . . . 32Format . . . . . . . . . . . . . . . 33Usage Notes . . . . . . . . . . . . . 33Example . . . . . . . . . . . . . . 33

CSOPT — Compress Duplicate Strings of Blanks orCharacters . . . . . . . . . . . . . . . 33


CYLINDERS — Allocate Space in Cylinder Units . . 34Rules . . . . . . . . . . . . . . . 34Format . . . . . . . . . . . . . . . 34Usage Notes . . . . . . . . . . . . . 34Example . . . . . . . . . . . . . . 34

DAP — Specify the DAP That Is to Copy the DataSet . . . . . . . . . . . . . . . . . 35

Rules . . . . . . . . . . . . . . . 35Format . . . . . . . . . . . . . . . 35Usage Notes . . . . . . . . . . . . . 35Examples . . . . . . . . . . . . . . 36

DATASET — Specify a Data Set Name . . . . . 36Rules . . . . . . . . . . . . . . . 36Format . . . . . . . . . . . . . . . 36Usage Notes . . . . . . . . . . . . . 36Example . . . . . . . . . . . . . . 37

DCBDS — Read DCB Information from a Data SetLabel . . . . . . . . . . . . . . . . 37


DEN — Define the Recording Density of a TapeData Set . . . . . . . . . . . . . . . 38

Rules . . . . . . . . . . . . . . . 38Format . . . . . . . . . . . . . . . 38Example . . . . . . . . . . . . . . 38

DIAGNS — Request the Trace Option . . . . . 38Rules . . . . . . . . . . . . . . . 39

Format . . . . . . . . . . . . . . . 39Usage Note . . . . . . . . . . . . . 39Example . . . . . . . . . . . . . . 39

DIR — Request Directory Blocks for a New PDS . . 39Rules . . . . . . . . . . . . . . . 39Format . . . . . . . . . . . . . . . 39Example . . . . . . . . . . . . . . 39

DISP — Specify the Disposition of a Data Set . . . 40Rules . . . . . . . . . . . . . . . 40Format . . . . . . . . . . . . . . . 40Usage Notes . . . . . . . . . . . . . 40Examples . . . . . . . . . . . . . . 41

DSORG — Specify Data Set Organization . . . . 41Rules . . . . . . . . . . . . . . . 41Format . . . . . . . . . . . . . . . 41Usage Notes . . . . . . . . . . . . . 41Example . . . . . . . . . . . . . . 41

DUMMY — Request a Dummy Data Set . . . . 42Rules . . . . . . . . . . . . . . . 42Format . . . . . . . . . . . . . . . 42Usage Notes . . . . . . . . . . . . . 42Example . . . . . . . . . . . . . . 42

EXPDT — Specify an Expiration Date for a Data Set 42Rules . . . . . . . . . . . . . . . 42Format . . . . . . . . . . . . . . . 43Usage Notes . . . . . . . . . . . . . 43Example . . . . . . . . . . . . . . 43

FROM — Begin the FROM Section . . . . . . 43Rules . . . . . . . . . . . . . . . 43Format . . . . . . . . . . . . . . . 43Usage Notes . . . . . . . . . . . . . 43Examples . . . . . . . . . . . . . . 44

GMJDLIB — Request a GMJD Library . . . . . 44Rules . . . . . . . . . . . . . . . 44Format . . . . . . . . . . . . . . . 44Usage Notes . . . . . . . . . . . . . 44Examples . . . . . . . . . . . . . . 44

HOLD — Put a Transaction into Operator Hold . . 45Rules . . . . . . . . . . . . . . . 45Format . . . . . . . . . . . . . . . 45Usage Note . . . . . . . . . . . . . 45Example . . . . . . . . . . . . . . 45

INTRDR — Copy a Data Set to the MVS InternalReader . . . . . . . . . . . . . . . . 45


JOBNAME — Assign a Name to the Job ThatResults from a Transaction . . . . . . . . . 46


LABEL — Supply Label Information for a Data Set 47Rules . . . . . . . . . . . . . . . 47Format . . . . . . . . . . . . . . . 47Usage Note . . . . . . . . . . . . . 48Example . . . . . . . . . . . . . . 48

LOCATION — Specify the Location of a Data Set . 48Rules . . . . . . . . . . . . . . . 48

iv z/OS BDT File-to-File Transaction Guide

Format . . . . . . . . . . . . . . . 48Example . . . . . . . . . . . . . . 48

LRECL — Specify the Logical Record Length of aData Set . . . . . . . . . . . . . . . 49


MAXVOL — Specify the Maximum Number ofVolumes Required for a Data Set . . . . . . . 49

Rules . . . . . . . . . . . . . . . 49Format . . . . . . . . . . . . . . . 50Usage Note . . . . . . . . . . . . . 50Example . . . . . . . . . . . . . . 50

MEMBER — Specify a Member of a PartitionedData Set . . . . . . . . . . . . . . . 50


MOD — Copy a Data Set to the End of an ExistingData Set . . . . . . . . . . . . . . . 51


MSGCLASS — Specify the Destination of Messages 52Rules . . . . . . . . . . . . . . . 52Format . . . . . . . . . . . . . . . 53Usage Notes . . . . . . . . . . . . . 53Example . . . . . . . . . . . . . . 53

MSVGP — Specify the Mass Storage Volumes onWhich a Data Set Is Located . . . . . . . . . 53


MXIG — Request the Maximum Contiguous Spacefor a Data Set. . . . . . . . . . . . . . 54


NETCOND — Tell BDT What to Do with aTransaction in a DTC Network If a Predecessor Fails 55


NETHOLD — Specify the Hold Count of aTransaction in a DTC Network . . . . . . . . 56


NETID — Assign a Transaction to a DTC Network 57Rules . . . . . . . . . . . . . . . 58Format . . . . . . . . . . . . . . . 58Usage Notes . . . . . . . . . . . . . 58Example . . . . . . . . . . . . . . 58

NETREL — Specify Successor Transactions in a DTCNetwork . . . . . . . . . . . . . . . 58


NEW — Specify That the “To” Data Set Is New . . 59Rules . . . . . . . . . . . . . . . 59Format . . . . . . . . . . . . . . . 60Usage Notes . . . . . . . . . . . . . 60Examples . . . . . . . . . . . . . . 61

OLD — Specify Exclusive Use of an Existing DataSet . . . . . . . . . . . . . . . . . 61


PARALLEL — Specify Parallel Mounting ofVolumes . . . . . . . . . . . . . . . 63


PARMS — Select Messages, Pad Logical Records,and Select, Rename, or Replace PDS Members . . . 63

PARMS(MSG) — Select the Type of MessagesYou Receive About a Transaction . . . . . . 64Rules . . . . . . . . . . . . . . . 64Format . . . . . . . . . . . . . . . 64Usage Notes . . . . . . . . . . . . . 64PARMS(PAD) — Pad Logical Records in the TOData Set . . . . . . . . . . . . . . 64Rules . . . . . . . . . . . . . . . 64Format . . . . . . . . . . . . . . . 64PARMS(R,S,E, or M) — Select, Rename, orReplace PDS Members. . . . . . . . . . 65Rules . . . . . . . . . . . . . . . 65Format . . . . . . . . . . . . . . . 65Usage Notes . . . . . . . . . . . . . 66Examples . . . . . . . . . . . . . . 66

PASSWORD — Supply a Password for aPassword-Protected Data Set . . . . . . . . 67


POSITION — Specify the Position of a Data Set on aTape Volume . . . . . . . . . . . . . . 67


PRIORITY — Assign a Priority to a Job . . . . . 68Rules . . . . . . . . . . . . . . . 68Format . . . . . . . . . . . . . . . 68Usage Note . . . . . . . . . . . . . 69Example . . . . . . . . . . . . . . 69

PROGRAMMER — Supply a Programmer’s Name 69Rules . . . . . . . . . . . . . . . 69Format . . . . . . . . . . . . . . . 69Example . . . . . . . . . . . . . . 69

PROTECT — Provide RACF Protection for a NewData Set . . . . . . . . . . . . . . . 69

Rules . . . . . . . . . . . . . . . 69

Contents v

Format . . . . . . . . . . . . . . . 70Usage Notes . . . . . . . . . . . . . 70Example . . . . . . . . . . . . . . 70

RECFM — Specify the Record Format of a Data Set 70Rules . . . . . . . . . . . . . . . 70Format . . . . . . . . . . . . . . . 70Usage Note . . . . . . . . . . . . . 71Example . . . . . . . . . . . . . . 71

RELEASE — Release Unused Space in a New DASDData Set . . . . . . . . . . . . . . . 72


RETPD — Specify a Retention Period for a Data Set 72Rules . . . . . . . . . . . . . . . 72Format . . . . . . . . . . . . . . . 73Usage Notes . . . . . . . . . . . . . 73Example . . . . . . . . . . . . . . 73

ROUND — Allocate Space in Whole Cylinders . . 73Rules . . . . . . . . . . . . . . . 73Format . . . . . . . . . . . . . . . 73Usage Notes . . . . . . . . . . . . . 73Example . . . . . . . . . . . . . . 74

SECGROUP — Supply a Security Group ID for aData Set That Is Protected with RACF . . . . . 74


SECPSWD — Supply a Security Password for aData Set That Is Protected with RACF . . . . . 75


SECUSER — Supply a Security User ID for a DataSet That Is Protected with RACF . . . . . . . 76


SHR — Permit Shared Use of a Data Set. . . . . 77Rules . . . . . . . . . . . . . . . 77Format . . . . . . . . . . . . . . . 77Example . . . . . . . . . . . . . . 78

SPACE — Request Space for a New Data Set . . . 78Rules . . . . . . . . . . . . . . . 78Format . . . . . . . . . . . . . . . 79Usage Notes . . . . . . . . . . . . . 79Example . . . . . . . . . . . . . . 79

SYSTEM — Specify the BDT Node in a Poly-BDTComplex . . . . . . . . . . . . . . . 79

Rules . . . . . . . . . . . . . . . 79Format . . . . . . . . . . . . . . . 80Usage Note . . . . . . . . . . . . . 80Examples . . . . . . . . . . . . . . 80

TIME — Specify the Maximum Processor Time for aTransaction . . . . . . . . . . . . . . 80

Rules . . . . . . . . . . . . . . . 80Format . . . . . . . . . . . . . . . 80Usage Notes . . . . . . . . . . . . . 81

Example . . . . . . . . . . . . . . 81TO — Begin the TO Section . . . . . . . . . 81


TRACKS — Allocate Space for a New Data Set inTrack Units . . . . . . . . . . . . . . 82

Rules . . . . . . . . . . . . . . . 82Usage Notes . . . . . . . . . . . . . 82Example . . . . . . . . . . . . . . 82

TRTCH — Specify the Translation Technique forTape . . . . . . . . . . . . . . . . . 82


UCOUNT — Specify the Unit Count for aMultivolume Data Set . . . . . . . . . . . 83


UNIT — Specify the Device on Which a Data Set IsLocated. . . . . . . . . . . . . . . . 84


VOLREF — Locate a Data Set on the Same Volumeas a Cataloged Data Set . . . . . . . . . . 85


VOLSEQ — Specify the Volume Sequence Number 85Rules . . . . . . . . . . . . . . . 85Format . . . . . . . . . . . . . . . 86Example . . . . . . . . . . . . . . 86

VOLUME — Specify a Volume Serial Number. . . 86Rules . . . . . . . . . . . . . . . 86Format . . . . . . . . . . . . . . . 86Usage Note . . . . . . . . . . . . . 86Example . . . . . . . . . . . . . . 87

Appendix A. Parameters That RequireOther Parameters . . . . . . . . . . 89Parameters That Allocate New “To” Data Sets . . . 89Parameters That Control DTC Networks. . . . . 89Other Parameters That Require AdditionalParameters . . . . . . . . . . . . . . 90

Appendix B. Accessibility . . . . . . 91Accessibility features . . . . . . . . . . . 91Consult assistive technologies . . . . . . . . 91Keyboard navigation of the user interface . . . . 91Dotted decimal syntax diagrams . . . . . . . 91

Notices . . . . . . . . . . . . . . 95Terms and conditions for product documentation. . 97IBM Online Privacy Statement . . . . . . . . 98

vi z/OS BDT File-to-File Transaction Guide

Policy for unsupported hardware . . . . . . . 98Minimum supported hardware . . . . . . . . 98Trademarks . . . . . . . . . . . . . . 99

GLOSSARY . . . . . . . . . . . . 101

Index . . . . . . . . . . . . . . . 103

Contents vii

viii z/OS BDT File-to-File Transaction Guide

Figures

1. General format of a transaction . . . . . . 32. Sample Syntax Diagram for a Transaction

Parameter . . . . . . . . . . . . . 73. How BDT Merges Parameters . . . . . . 134. A simple dependent transaction control (DTC)

network. . . . . . . . . . . . . . 16

5. A more complex dependent transaction control(DTC) network . . . . . . . . . . . 17

6. BDT nodes in a sample complex . . . . . 17

© Copyright IBM Corp. 1986, 2017 ix

x z/OS BDT File-to-File Transaction Guide

About This Book

This book describes Bulk Data Transfer (BDT) file-to-file transactions. It explainshow to write and submit file-to-file transactions to BDT for execution, anddescribes the file-to-file transaction parameters.

This book does not explain how to submit SNA network job entry (NJE) jobs toJES3 for execution. For information on submitting SNA NJE jobs, see the JCLmanual that is appropriate for your installation.

Who Should Read This BookThis book is for anyone who wishes to submit a BDT file-to-file transaction.

How to Use This BookIf you are unfamiliar with BDT file-to-file transactions, begin with Chapter 1,“Writing and Submitting File-to-File Transactions,” on page 1.

This book contains five chapters, an appendix, and a glossary:v Chapter 1, “Writing and Submitting File-to-File Transactions,” on page 1 explains

what BDT file-to-file transactions can do as well as how to write and submittransactions.

v Chapter 2, “Storing and Reusing Transaction Definitions — GMJD Libraries,” onpage 11 explains how to use generic master job definition (GMJD) libraries.

v Chapter 3, “Controlling the Order in Which Transactions Are Processed — DTCNetworks,” on page 15 explains how to put transactions into dependenttransaction control (DTC) networks to control the order in which they areprocessed.

v Chapter 4, “Sample Transactions,” on page 21 contains sample transactions.v Chapter 5, “File-to-File Transaction Parameter Reference,” on page 25 contains a

summary of optional and required transaction parameters followed by detaileddescriptions of each of the parameters.

v Appendix A, “Parameters That Require Other Parameters,” on page 89 is a quickreference to parameters that require other parameters, including thoseparameters that can be used to allocate new data sets.

Related ReadingWhere necessary, this book references information in other books, using shortenedversions of the book title. For complete titles and order numbers of the books forall products that are part of z/OS, see z/OS Information Roadmap.

© Copyright IBM Corp. 1986, 2017 xi

xii z/OS BDT File-to-File Transaction Guide

How to send your comments to IBM

We appreciate your input on this documentation. Please provide us with anyfeedback that you have, including comments on the clarity, accuracy, orcompleteness of the information.

Use one of the following methods to send your comments:

Important: If your comment regards a technical problem, see instead “If you havea technical problem.”v Send an email to [email protected] Send an email from the Contact z/OS web page (www.ibm.com/systems/z/os/

zos/webqs.html).

Include the following information:v Your name and addressv Your email addressv Your phone or fax numberv The publication title and order number:

z/OS BDT File-to-File Transaction GuideSC14-7583-30

v The topic and page number or URL of the specific information to which yourcomment relates

v The text of your comment.

When you send comments to IBM®, you grant IBM a nonexclusive right to use ordistribute the comments in any way appropriate without incurring any obligationto you.

IBM or any other organizations use the personal information that you supply tocontact you only about the issues that you submit.

If you have a technical problemDo not use the feedback methods that are listed for sending comments. Instead,take one or more of the following actions:v Visit the IBM Support Portal (support.ibm.com).v Contact your IBM service representative.v Call IBM technical support.

© Copyright IBM Corp. 1986, 2017 xiii

mailto:[email protected]

http://www.ibm.com/systems/z/os/zos/webqs.html


http://support.ibm.com

xiv z/OS BDT File-to-File Transaction Guide

Summary of changes

This information includes terminology, maintenance, and editorial changes.Technical changes or additions to the text and illustrations for the current editionare indicated by a vertical line to the left of the change.

Summary of changes for z/OS BDT File-to-File Transaction Guide forVersion 2 Release 3 (V2R3) and its updates

This information contains no technical changes for this release.

z/OS Version 2 Release 1 summary of changesSee the Version 2 Release 1 (V2R1) versions of the following publications for allenhancements related to z/OS V2R1:v z/OS Migration

v z/OS Planning for Installation

v z/OS Summary of Message and Interface Changes

v z/OS Introduction and Release Guide

© Copyright IBM Corp. 1986, 2017 xv

xvi z/OS BDT File-to-File Transaction Guide

Chapter 1. Writing and Submitting File-to-File Transactions

This chapter is a general introduction to writing and submitting BDT file-to-filetransactions. It explains:v The kinds of data sets you can copy with BDTv How to write file-to-file transactions to copy data setsv How to read the transaction parameter syntax diagrams in this bookv How to submit file-to-file transactionsv How BDT processes file-to-file transactions.

The Kinds of Data Sets You Can Copy with BDT File-to-FileTransactions

BDT file-to-file transactions allow you to copy a data set to another data set. Thedata set you copy from and the data set you copy to can have a variety oflocations, organizations, record formats, record lengths, and storage devices.

Locations of the Data SetsBDT can copy data sets within a network of BDT nodes. A BDT node is a point in aBDT address space that is linked to another BDT address space for data transfer.BDT nodes are defined by your system programmer.

Within the network of nodes, BDT can copy:v A data set located at your node to another data set located at your node. This is

called an internal transfer.v A data set located at your node to a data set located at another node.v A data set located at another node to a data set located at your node.

Organizations of the Data SetsBDT can copy data sets with partitioned or sequential organization. The data setbeing copied from and the data set being copied to may have the sameorganization or different organization. Table 1 shows the combinations ofsequential data sets and partitioned data sets (PDSs) that BDT can copy.

Table 1. Organizations of Data Sets BDT Can Copy

If the “from” data set is: The “to” data set may be:

A sequential data set A sequential data set or PDS member

A PDS member A sequential data set or PDS member

Multiple PDS members Multiple PDS members

Record Formats of the Data SetsBDT can copy data sets with any of these record formats:v Fixed lengthv Fixed length and blockedv Variable lengthv Variable length and blocked

© Copyright IBM Corp. 1986, 2017 1

v Undefined length

The data set being copied from and the data set being copied to may havedifferent record formats. If the record formats of the data sets are different, BDTreformats the data before writing it to the “to” data set.

Record Lengths and Block Sizes of the Data SetsBDT can copy a data set with one logical record length and block size to a data setwith a different logical record length and block size. However, BDT has somerequirements for the logical record lengths and block sizes of data sets beingcopied. These requirements, which depend on the organization and record formatof the data sets being copied, are subsequently shown.

If the organization of thedata sets is: And the record format is:

This must be true of therecord length or block size:

Sequential for both Fixed length, fixed lengthand blocked, variable length,variable length and blocked,or undefined, for either orboth data sets

The logical record length ofthe “from” data set must beequal to or smaller than themaximum record lengthdefined in the “to” data set'sdata control block (DCB).

If the record length of the“from” data set is larger thanthe record length of the “to”data set, BDT truncates therecords in the “to” data set.

Partitioned for one or both Fixed length or fixed lengthand blocked for either dataset

The logical record lengths ofthe “to” and “from” data setsmust be equal.

Variable length or variablelength and blocked for eitherdata set

The logical record length ofthe “to” data set must beequal to or larger than thelogical record length of the“from” data set.

Undefined for either data set The block size of the “to”data set must be equal to orlarger than the block size ofthe “from” data set.

Storage Devices of the Data SetsBDT can copy data sets stored on either direct access storage devices (DASD) or onmagnetic tape. The data set being copied from and the data set being copied tomay be stored on the same type of device or on different types of devices.

How to write a transaction to copy a data setTo copy a data set, you write a transaction and submit it to BDT. The transactiondefines the nodes and data sets that will take part in the transfer of data.

Figure 1 on page 3 shows the general format of a transaction. The pages followingthe figure discuss the parts of a transaction in detail.

2 z/OS BDT File-to-File Transaction Guide

A transaction has two major parts: the prefix and the transaction definition. Thetransaction definition, in turn, is made up of the job definition section, the FROMsection, and the TO section.

PrefixThe first part of a transaction is a prefix that tells the system that this is a BDTtransaction. The prefix you use depends on the type of terminal or console you areusing: TSO, MCS, or JES3; and whether your system programmer has created anyshortcuts for you (such as a special symbol or PF keys). Your system programmercan tell you what prefix to use. Table 2 shows the IBM-defined prefixes fortransactions.

Table 2. IBM-Defined BDT Prefixes

Type of ConsolePrefix in a Single-BDTComplex

Prefix in a Poly-BDTComplex

MCS bdt-charorBDTorF [bdt-proc.]id

same

JES3 *S,BDT *S,BDT,SY(node-name)

TSO BDT BDT SY(node-name)

In Table 2:v bdt-char is a special character (such as +) defined by your system programmer

that routes the transaction directly to a specific system. Do not use a delimiter (acomma or a blank) after bdt-char. For information on defining bdt-char see z/OSBDT Installation.

v bdt-proc is the name of the cataloged procedure in SYS1.PROCLIB that is used tostart BDT. It is optional.

v id is the installation-defined identifier used with F to identify BDT.v SY(node-name) is the system parameter that indicates which BDT system should

process the transaction. Include the parentheses as shown. There is aninstallation-defined default for this parameter.

Prefix Transaction

Definition

FROM and TO

Sections

Job Definition

Section

prefix parameters (ds-name) (node) (dap) parametersQ FROM DATASET LOC DAP

TO DATASET LOC(ds-name) (node) parameters

Figure 1. General format of a transaction

Chapter 1. Writing and Submitting File-to-File Transactions 3

Transaction DefinitionThe transaction definition contains the information that BDT needs to copy thedata set. A transaction definition consists of three sections: the job definitionsection, the FROM section, and the TO section.

The Job Definition SectionThe job definition section begins with a transaction code. The transaction code inFigure 1 on page 3 is “Q”. A transaction code of “Q” tells BDT that the transactiondefinition is wholly contained within the transaction. Other transaction codes tellBDT that the transaction definition is stored in a library. These codes are explainedin Chapter 2, “Storing and Reusing Transaction Definitions — GMJD Libraries,” onpage 11.

After the transaction code, you can add optional job definition parameters.

Some of the things you might do with job definition parameters are:v Give the transaction a name (with the JOBNAME parameter)v Put the transaction on hold (with the HOLD parameter)v Assign the transaction a particular priority (with the PRIORITY parameter)v Assign the transaction a maximum amount of processor time (with the TIME

parameter).

A complete list of the job definition parameters is included in Chapter 5,“File-to-File Transaction Parameter Reference,” on page 25.

You can put job definition parameters anywhere in the transaction definition —you do not have to keep them together after the transaction code. For example,you might put some job definition parameters immediately after the transactioncode, some with the FROM parameters, and some with the TO parameters.However, you may find it easier to keep track of the job definition parameters ifyou group them together.

The FROM SectionThe FROM section describes the data set to be copied, that is, the “from” data set.It includes information BDT needs to locate, allocate, and deallocate the “from”data set. The FROM section is made up of four essential parameters and thenadditional parameters as required. The four essential parameters take part in alltransactions whether you specify values for them or accept defaults. The additionalparameters include optional parameters that you use to meet your needs andparameters that are required by BDT for certain tasks.

Four Essential FROM ParametersThe four FROM parameters that take part in all transactions are shown in Figure 1on page 3. They are:v The FROM parameter. This begins the FROM section. It tells BDT that the

parameters that follow describe the “from” data set.BDT assumes that any parameter that is not a job definition parameter and isnot in the TO section is a FROM parameter. Therefore, you only have to includethe FROM parameter in your transaction if you list parameters describing the“from” data set after the TO section of your transaction.


v The DATASET parameter. This parameter identifies the data set to be copied.The format of this parameter is DATASET(ds-name). Substitute a data set namefor ds-name. You must include this parameter in your transaction.

v The LOC or LOCATION parameter. This parameter identifies the node at whichBDT is to find the “from” data set. The format of this parameter isLOCATION(node-name). Substitute a node name for node-name. You must includethis parameter in your transaction unless:– You are in a single-BDT system and the data set is at your node– You are in a poly-BDT system and the data set is at the node that is defined

as the default for your installation.v The DAP parameter. This parameter specifies whether BDT is to use the PDS or

SEQ dynamic application program (DAP) to copy the data set. The format ofthis parameter is DAP(dap). SEQ is the default for this parameter.– To use the SEQ DAP substitute SEQ for dap or omit the DAP parameter.– To use the PDS DAP substitute PDS for dap.You may put the DAP parameter in either the FROM or TO section of yourtransaction.

Other FROM ParametersSome of the things you might do with other FROM parameters are:v Request shared or exclusive use of the “from” data set (with the OLD or SHR

parameter)v Request that the “from” data set be deleted, kept, or cataloged (with the DISP

parameter)v Specify the member of a PDS to be copied (with the MEMBER parameter)v Provide the password for a password-protected data set (with the PASSWORD

parameter).

Organizing the FROM ParametersThe FROM parameter, in cases when it is required, must be the first parameter inthe FROM section. The other FROM parameters may be in any order.

A complete list of FROM parameters, including those required for particular tasks,is included in Chapter 5, “File-to-File Transaction Parameter Reference,” on page25.

The TO SectionThe TO section describes the data set that is to receive the data, that is, the “to”data set. It includes information BDT needs to locate, allocate, and deallocate the“to” data set, as well as other information you might require.

Like the FROM section, the TO section is made up of essential parameters that takepart in every transaction, and then additional parameters to accomplish particulartasks.

Three Essential TO ParametersThe three TO parameters that are take part in every transaction are shown inFigure 1 on page 3. They are:v The TO parameter. This begins the TO section. It tells BDT that the parameters

that follow describe the “to” data set. You must include the TO parameter inyour transactions.


v The DATASET parameter. This parameter identifies the data set that is toreceive the “from” data set. You should include the DATASET parameter in yourtransactions, unless you use either the DUMMY or INTRDR parameter. TheDUMMY parameter specifies a dummy “to” data set, and the INTRDRparameter specifies the MVS internal reader at the receiving node as the “to”data set.

v The LOC or LOCATION parameter. This parameter identifies the node at whichBDT is to find the “to” data set. You must include this parameter unless:– You are in a single-BDT system and the data set is at your node– You are in a poly-BDT system and the data set is at the node that is defined

as the default for your installation.

Other TO ParametersThings you might do with other parameters in the TO section include:v Specify that the “to” data set is a new data set to be allocated (with the NEW

parameter)v Request RACF protection for the “to” data set (with the PROTECT parameter)v Assign an expiration date to the “to” data set (with the EXPDT parameter).

Organizing the TO ParametersThe TO section must begin with the TO parameter. The other parameters in the TOsection may be in any order.

A complete list of the TO parameters, including those required for specific tasks, isincluded in Chapter 5, “File-to-File Transaction Parameter Reference,” on page 25.

How to Punctuate a TransactionYou must follow some punctuation rules when writing a transaction:v Use one or more blank spaces to separate the transaction prefix, the transaction

code, and transaction parameters. There is one exception to this: If you use thebdt-char prefix, do not separate it from the transaction code with a blank space.

v Use either uppercase or lowercase letters.v Include parentheses when they are shown in the diagrams in this book.

Parameters that include parentheses are called keyword parameters. Substitute avalue for the variable in parentheses. Do not leave a space between the keywordand the first parenthesis. For example, type DATASET(MYDATA).In Figure 1 on page 3, DATASET, LOC, and DAP are all keyword parameters.

How to Read the Transaction Parameter Syntax DiagramsEach BDT transaction parameter is described in this book with a syntax diagram.The syntax diagram shows the parts and punctuation of the parameter. Whenusing a syntax diagram, follow the diagram from left to right, choosing the paththat suits your needs.

Figure 2 on page 7 shows a sample syntax diagram and explains how to read it.


How to Submit a TransactionYou may submit a transaction interactively, or via ISPF panels (at TSO terminalsonly), or in a batch job.

In general you may submit a transaction from any TSO terminal, MCS console, orJES3 console. However, your installation may be configured in a way that preventsyou from using certain consoles or terminals for file-to-file transactions. Checkwith your system programmer to find out which consoles or terminals can be usedfor file-to-file transactions.

How to Submit a Transaction InteractivelyTo submit a transaction interactively at your terminal or console, simply type inthe transaction, following the rules explained in this chapter. The transaction maybe complete in itself, or it may refer to a transaction definition stored in a GMJDlibrary. GMJD libraries are explained in Chapter 2, “Storing and ReusingTransaction Definitions — GMJD Libraries,” on page 11.

How to Submit a Transaction via ISPF PanelsTSO users may be able to use ISPF panels to submit transactions. Your BDT systemprogrammer can tell you whether these panels are available to you and, if they are,how to invoke them. Instructions for using the panels are provided by the panelsthemselves and by a help facility.

Note: When submitting a transaction through an ISPF panel, do not code anampersand (&) within the transaction’s parameter string. A transaction thatcontains an ampersand will be rejected.

How to Submit a Transaction in a Batch JobYou can submit one or several transactions in a batch job. The transactions may becomplete in themselves or may refer to transaction definitions stored in a GMJDlibrary.

►►(1)

prefix(2)

ASAMPLEA

(3)ALLSOMENONE (4)

EQ

▼(5) (6)

jnum ►◄

Notes:

1 Start here.

2 Choose either ASAMPLE or A.

3 Choose one of the options. The default is always atop of the main line. In this case, ALL is the default.

4 Choose E, Q, or neither.

5 Repeat jnum any number of times. Variables are always in italics.

6 End here.

Figure 2. Sample Syntax Diagram for a Transaction Parameter


Use this format for entering transactions in a batch job://job card// EXEC PGM=BDTBATCH//SYSPRINT DD DUMMY//SYSIN DD *transaction/EOTtransaction/EOT

When using a batch job:v Do not use a prefix with the transaction. Start with the transaction code.v Begin the transaction in any column.v Continue the transaction on the next line(s) if necessary.v Do not split a parameter across two statements. Splitting a parameter across

statements causes unpredictable results.v Put each transaction on a separate line, and separate the transactions by an

/EOT statement.

ExampleSubmit two transactions from a batch job. The first transaction (MEM20) refers to atransaction definition in the system GMJD library. The second transaction iscomplete in itself.//BATCHJOB JOB CLASS=A// EXEC PGM=BDTBATCH//SYSPRINT DD DUMMY//SYSIN DD *

MEM20/EOT

Q JOB(BDTJOB) ACCT(MY.DEPT,MY.PROJ)FROM DATASET(MY.DATA) LOC(MYNODE) SHR DAP(SEQ)TO DATASET(OTHER.DATA) LOC(THATNODE) OLD

/EOT

How BDT Processes TransactionsAfter BDT accepts a transaction it creates a BDT job, which it places on the workqueue. The job has a name (assigned when the transaction was submitted, orassigned by the BDT default) and a number (assigned by BDT). Once the job hasbeen selected for processing, it is called an active job, whether or not the actualcopying of data has begun.

BDT selects jobs from the BDT work queue based on requirements such as thejob’s priority. BDT job priorities range from 0 to 15, with 15 being the highest. BDTschedules high priority jobs before lower priority jobs.

If the job involves two nodes, it is managed and scheduled at the global node.

The copying of the data is performed by a BDT dynamic application program(DAP). Copying of sequential data sets uses the SEQ DAP; copying of partitioneddata sets uses the PDS DAP.

After submitting a transaction, you may issue commands to change the way thatBDT processes the transaction, or to inquire about the progress of the transaction.See z/OS BDT Commands for more information. BDT issues messages to keep youinformed of the status of your transaction. The messages are explained in z/OSBDT Messages and Codes


How BDT Protects Transaction ProcessingEach time you submit a transaction, the transaction travels from your addressspace to the BDT address space. In order to reach BDT, the transaction may haveto travel from one processor to another or from one node to another. Withoutadequate protection, a transaction could become lost before reaching BDT. Forexample, if a transaction had to travel from one processor to another and thereceiving processor were disabled, the transaction would be lost.

To reduce the possibility of losing a transaction, BDT uses the transaction queuingintegrity (TQI) facility. When you submit a transaction, TQI makes a copy of thetransaction in the TQI checkpoint data set. The transaction remains in thecheckpoint data set until it has reached the BDT address space. If, for some reason,your transaction does not reach the BDT address space, BDT can recover it fromthe TQI checkpoint data set.


Chapter 2. Storing and Reusing Transaction Definitions —GMJD Libraries

This chapter is an introduction to GMJD libraries. GMJD libraries make it possibleto store and reuse transaction definitions. This chapter explains:v What GMJD libraries arev How to use a system GMJD library created by your system programmerv How to create and use private GMJD librariesv How to alter transaction definitions stored in GMJD libraries.

What GMJD Libraries AreGMJD (generic master job definition) libraries are data sets in which you can storetransaction definitions. You can reuse these stored transaction definitions simply bynaming them in your transactions. This can save you from having to typefrequently used transaction definitions each time you use them. You can also addto or alter stored transaction definitions when you invoke them. There are twotypes of GMJD libraries: system GMJD libraries and private GMJD libraries.

How to Use System GMJD LibrariesSystem GMJD libraries are created for your installation by your systemprogrammer. Your installation may have a system GMJD library; check with yoursystem programmer.

The format for a transaction that uses a transaction definition stored in a systemGMJD library is:

prefix nameprefix is the prefix that is appropriate for your console or terminal andinstallation, and name is the name of the transaction definition stored in thesystem GMJD library. See your system programmer for valid names.

How to Create and Use Private GMJD LibrariesPrivate GMJD libraries are GMJD libraries you create for your own use.

How to Create a Private GMJD LibraryTo create a private GMJD library, follow the two steps described subsequently.1. Allocate and name a data set. The data set may be either sequential or

partitioned. A sequential data set can store a single transaction definition. Apartitioned data set can store several transaction definitions, each as a memberof the data set.The data set, whether partitioned or sequential, must have the followingcharacteristics:v Record format – fixed length or fixed length and blockedv Logical record length – 80 bytes


v Block size – variable. If you have a system GMJD library, the block size ofyour data set may be no larger than the block size of the system GMJDlibrary. If you do not have a system GMJD library, the block size of your dataset may not exceed 6160 bytes.

2. Enter either transaction parameters or comments into each logical record inyour data set, following these rules:v Start the first parameter in a logical record in any column.v Do not split a parameter across logical records, that is, do not start a

parameter in one logical record and finish it in another.v Separate parameters with one or more blanks.v Mark comments by putting an asterisk in the first column of the logical

record. Enter anything you wish following the asterisk.v Use only columns 1 through 71 of each logical record for parameters or

comments.v If your are using a PDS, name the members with any valid PDS member

name except Q, GMJD, GMJDLIB, or any BDT command word (C, CALL,CANCEL, DUMP, F, FAIL, I, INQUIRY, J, JES, MESSAGE, MODIFY, R,RESTART, RETURN, S, START, T, V, VARY, X, Z).

How to Use a Private GMJD LibraryTo use a transaction definition stored in a private GMJD library, enter a transactionwith this format:

prefix code GMJDLIB (gmjd-library-name)

In this transaction:v prefix is the prefix that is appropriate for your console or terminal at your

installation.v code is one of the following:

– For sequential GMJD libraries, any 1-8 character value other than Q– For partitioned GMJD libraries, the name of the member of the partitioned

data set that contains the stored transaction definition you are requesting.v GMJDLIB specifies that the transaction refers to a transaction definition stored in

a private GMJD libraryv gmjd-library-name is the name of the GMJD library in which the transaction

definition is stored.

Examples1. Submit the transaction definition stored as member ENDREPT in your private

GMJD library, which is a partitioned data set named JOESLIB.prefix GMJDLIB(JOESLIB)

2. Submit the transaction definition stored in the private GMJD library that is asequential data set named REPORT.prefix AUG GMJDLIB(REPORT)

How to Modify Stored Transaction DefinitionsWhen using a stored transaction definition you may add to, remove, or later thestored transaction definition's parameters. You do this by including the changes inthe transaction that requests the stored transaction definition. The changes youmake are effective only in the current transaction – they are not permanent


changes in the stored transaction definition. The next time you invoke the storedtransaction definition it will have all of its original parameters.

Figure 3 shows how BDT merges transaction parameters.

How to Add ParametersTo add parameters to a stored transaction definition, simply include the parametersto be added in the transaction that requests the stored transaction definition.

Example: You have stored a skeletal transaction definition for copying a sequentialdata set. The transaction definition is stored in a sequential data set namedSEQTOSEQ. The definition has all the parameters you need except the data setnames and locations. You want to send the data set MONTHEND from your nodeto the data set REPT06 at the node HDQTR.

You use the TSO prefix (BDT). Because the transaction definition is stored in asequential data set, you can use any string of up to 8 characters for the code; youuse STS.BDT STS GMJDLIB(SEQTOSEQ) FROM DATASET(MONTHEND)

TO DATASET(REPT06) LOC (HDQTR)

Note that since the LOCATION parameter defaults to the node at which thetransaction is submitted (your node), you did not need to use the LOCATIONparameter in the FROM section.

How to Remove ParametersTo remove parameters that are included in a stored transaction definition, use the/ character before the parameter you want to remove.

Example: You want to use the transaction definition that is stored as FASTJOB.However, in addition to the parameters that you want, FASTJOB includes thePRTY parameter, which you don't want. The PRTY parameter assigns a specialpriority to a job, and you want your job to run at the priority the BDT systemwould normally assign to jobs. So, when you invoke FASTJOB you remove thePRTY parameter. You use the TSO prefix (BDT).BDT FASTJOB /PRTY

How to Alter ParametersTo alter parameters that are included in a stored transaction definition, include theparameters with the new values in the transaction that requests the storedtransaction definition.

Submitted Stored ExecutedTransaction Transaction TransactionDefinition: Definition: Definition:

parm a parm a parm aparm b ---------► parm d ---------► parm bparm c parm e parm c

parm dparm e

Figure 3. How BDT Merges Parameters

Chapter 2. Storing and Reusing Transaction Definitions — GMJD Libraries 13

Example: You want to submit the transaction definition stored as THATJOB, butyou want to change the data set named in the TO section of THATJOB. You wantthe new “to” data set to be the data set named NEWDATA. You use the TSO prefix(BDT).BDT THATJOB TO DTASET(NEWDATA)

Note that since the parameter you wanted to changed, DATASET, appears in boththe TO and FROM sections of the stored transaction definition, you have to use theTO parameter as well as the DATASET parameter to identify which occurrence ofDATASET you want to change.


Chapter 3. Controlling the Order in Which Transactions AreProcessed — DTC Networks

This chapter is an introduction to DTC networks. DTC networks make it possibleto control the order in which transactions are processed. This chapter explains:v What DTC networks arev What parameters you need to create and use DTC networksv How to create DTC networksv How to specify the order of transactions in a DTC networkv How to make sure the transactions in a DTC network run in orderv How to tell BDT what to do with a transaction in a DTC network if its

predecessor transaction failsv How to make sure the first transaction in a DTC network doesn’t complete

before you can submit the second one.

At the end of the chapter is an example of transactions that create and define aDTC network.

What DTC Networks AreDependent transaction control (DTC) networks are groups of transactions that youcreate. These networks allow you to control the order in which the transactions areprocessed.

Suppose that you have several transactions that copy data to the same data set,and you want to add the data to the receiving data set in a particular order. A DTCnetwork will allow you to do that. Or, suppose you want to break a big transactioninto smaller transactions. A DTC network will allow you to do that as well.

It is important to remember that the BDT dependent transaction control (DTC)network facility and the JES3 dependent job control (DJC) network facility are twodifferent network facilities. Do not attempt to use commands intended for onefacility with the other facility.

What Parameters You NeedTo create and control DTC networks, you need five parameters. You include theseparameters in your transactions. The parameters are:v NETIDv NETRELv JOBNAMEv NETHOLDv NETCOND

Each of these parameters are described subsequently.


How to Identify the Transactions That Belong to a DTC Network — theNETID Parameter

To create a DTC network, you identify each transaction that belongs to the networkwith the NETID parameter. The format of the NETID parmater is NETID(netid),where netid is the name you assign to the network.

For more information on using the NETID parameter, see Chapter 5, “File-to-FileTransaction Parameter Reference,” on page 25.

How to specify the order of transactions — the NETREL andJOBNAME parameters

To control the order in which transactions in a DTC network are processed, youspecify the successor transactions in each transaction. A successor transaction is atransaction that cannot be processed until it is released by another transaction,called a predecessor transaction. You specify the successor transactions to aparticular transaction with the NETREL parameter. The format of the NETRELparameter is NETREL(name) where name is the name or names of the transactionsthat are successors to this one. You assign names with the JOBNAME parameter.The format of the JOBNAME parameter is JOBNAME(name).

Figure 4 shows the successor and predecessor transactions in a simple DTCnetwork.

In Figure 4, transaction 2 is a successor to transaction 1 and a predecessor totransaction 3. Transaction 1 releases transaction 2, which releases transaction 3.

Figure 5 on page 17 shows a more complex DTC network — a network in whichtransactions are successors and predecessors to more than one transaction.

Transaction 1

Transaction 2

Transaction 3

Figure 4. A simple dependent transaction control (DTC) network


In Figure 5, transaction D has two predecessors (transaction B and transaction C)and three successors (transaction E, transaction F, and transaction G). Transaction Areleases transaction B and transaction C. It does not matter whether transaction Bor transaction C runs next after transaction A, but both transaction B andtransaction C must run after transaction A and before transaction D. Transaction Dreleases transaction E, transaction F, and transaction G.

NETREL Can Only Release Successors at the Same NodeThe NETREL parameter can only release a successor transaction if it is scheduledfor processing at the same node as its predecessor. You must be aware of this whenconstructing DTC networks. In particular, you should be aware of the global-localrelationships of the nodes in your network.

Global and local nodesWithin a JES complex, each file-to-file node has a global or local relationship withevery other file-to-file node with which it communicates. A given node may be theglobal node in relationships with some nodes and the local node in relationshipswith other nodes. File-to-file transactions are always scheduled at the global node,regardless of whether they are submitted at the global or local node.

Let’s look at a DTC network that does not take the global-local relationship ofnodes into account. The complex for this example consists of two BDT nodes, node1 and node 2. Node 1 is the global node; node 2 is the local node, as shown inFigure 6.

The following DTC network of two transactions is submitted at node 2, the localnode:BDT Q JOBNAME(TRAN1) NETID(NETA) NETREL(TRAN2)

FROM LOC(NODE2) DATASET(DATA3) DAP(SEQ)TO LOC(NODE2) DATASET(DATA4)

Transaction A

Transaction D

Transaction FTransaction E Transaction G

Transaction CTransaction B

Figure 5. A more complex dependent transaction control (DTC) network

Node 1

Global

Node 2

Local

Figure 6. BDT nodes in a sample complex

Chapter 3. Controlling the Order in Which Transactions Are Processed — DTC Networks 17

BDT Q JOBNAME(TRAN2) NETID(NETA) NETHOLD(1)FROM LOC(NODE1) DATASET(DATA1) DAP(SEQ)TO LOC(NODE2) DATASET(DATA2)

TRAN1 will be scheduled for processing at node 2. The transaction identified bythe JOBNAME parameter as TRAN1 copies data within node 2 (as indicated withthe LOC parameters); the global node in this complex (node 1) is not involved.When a transaction copies data within a node, that node acts as both the globaland the local node for the transaction.

TRAN2 will be scheduled for processing at node 1. The transaction identified bythe JOBNAME parameter as TRAN2 copies data from node 1, the global node, tonode 2, the local node. TRAN2 will be scheduled for processing at node 1, theglobal node.

TRAN1 cannot release TRAN2. The NETREL parameter in TRAN1 specifies thatTRAN1 is to release TRAN2 when it completes. However, TRAN1 cannot releaseTRAN2 because they will be scheduled for processing at different nodes.

For more information on using the JOBNAME and NETREL parameters, seeChapter 5, “File-to-File Transaction Parameter Reference,” on page 25.

How to Make Sure Transactions Run in Order — the NETHOLDParameter

To ensure that a transaction with several predecessors runs only after all thepredecessors have run, rather than after only one predecessor has run, you givetransactions hold counts. Hold counts keep track of how many predecessors mustbe processed before successor transactions can run. You assign hold counts withthe NETHOLD parameter. The format of the NETHOLD parameter isNETHOLD(net-hold) where net-hold is the hold count. Most of the time, the holdcount you assign to a transaction will be equal to the number of predecessors forthat transaction.

In Figure 5 on page 17, transaction D would be given a hold count of 2 to ensurethat it would run only after both transaction B and transaction C. A hold count of2 means that the transaction requires the completion of 2 predecessor transactionsto be released. Each of the other transactions in the network, except transaction A,would be given a hold count of 1, because each requires the completion of only 1predecessor transaction to be released. As the first transactions in the network,transaction A is not a successor to any other transactions and so would notordinarily be given a hold count.

For more information on using the NETHOLD parameter, see Chapter 5,“File-to-File Transaction Parameter Reference,” on page 25.

How to Tell BDT What to Do If Predecessor Transactions Fail — theNETCOND Parameter

Because transactions in a DTC network depend on each other to be processed, youmay want to tell BDT what to do with a successor transaction if a predecessortransaction fails. You do this with the NETCOND parameter. The format of theNETCOND parameter is NETCOND(option,option). The first option tells BDT what


do with this transaction if a predecessor completes normally. The second optiontells BDT what to do with this transaction if a predecessor fails. The things you cantell BDT to do with this transaction are:v Decrease the transaction’s hold count by 1 (which will allow it to be released if

its hold count was originally 1)v Leave the hold count of the transaction unchanged (to keep it on hold)v Flush (cancel) the transaction and its successors.

For more information on using the NETCOND parameter, see Chapter 5,“File-to-File Transaction Parameter Reference,” on page 25.

How to Make Sure the First Transaction Doesn’t Complete Before YouCan Submit the Second One

Unless you construct a DTC network carefully, the first transaction in the networkcan complete before you submit the second transaction. If that happens, the rest ofthe network will never run, as the first transaction cannot release its successors.

To prevent this kind of “runaway” first transaction in a DTC network, you can:v Give the first transaction in the network a hold count of 1, even though it has no

predecessors. You can do this with the NETHOLD parameter. Then, to releasethe first transaction use the F,NET,ID,J,D command or the F,NET,ID,J,Rcommand. See z/OS BDT Commands for more information about thesecommands.

v Put the first transaction in the network into operator hold. You can do this byincluding the HOLD parameter in the transaction, or by issuing the F,J,Hcommand after you submit the transaction. Then, use the F,J,R command torelease the transaction from operator hold. See z/OS BDT Commands for moreinformation on the F,J,H and F,J,R commands.

v Submit the transactions in the network “bottoms up”, that is, submit the lasttransaction first and the first transaction last.

ExampleUsing the NETID and JOBNAME parameters in each of three transactions, create aDTC network named MYNET which consists of MYTRAN1, MYTRAN2, andMYTRAN3.

Make MYTRAN1 the first transaction in the network. Using the NETRELparameter, specify that the successor to MYTRAN1 is MYTRAN2, and that thesuccessor to MYTRAN2 is MYTRAN3.

Using the NETHOLD parameter, assign a hold count of 1 to MYTRAN2 and a holdcount of 1 to MYTRAN3. These hold counts are equal to the number ofpredecessor transactions for MYTRAN2 and MYTRAN3.

Using the NETCOND parameter, specify a conditional treatment of MYTRAN3,depending on the outcome of MYTRAN1 and MYTRAN2. Specify that:v If MYTRAN2 completes normally, the hold count of MYTRAN3 is to be

decreased by 1, releasing MYTRAN3v If either MYTRAN1 or MYTRAN2 fails, MYTRAN3 is to be canceled (flushed).

Chapter 3. Controlling the Order in Which Transactions Are Processed — DTC Networks 19

Submit the transactions in reverse order to keep MYTRAN1 from completingbefore MYTRAN2 and MYTRAN3 are submitted.prefix Q JOBNAME(MYTRAN3) NETID(MYNET) NETHOLD(1) NETCOND(D,F)

FROM DATASET(DDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

prefix Q JOBNAME(MYTRAN2) NETID(MYNET) NETHOLD(1) NETREL(MYTRAN3)FROM DATASET(CDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

prefix Q JOBNAME(MYTRAN1) NETID(MYNET) NETREL(MYTRAN2)FROM DATASET(ADATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD


Chapter 4. Sample Transactions

This chapter contains samples of several useful transactions. These samples includethe required parameters and a few optional parameters.

The transaction prefixes and the FROM, DATASET, LOCATION, DAP, and TOparameters that are used in the samples are explained in Chapter 1, “Writing andSubmitting File-to-File Transactions,” on page 1. Brief explanations of all otherparameters used in the samples are included with the samples. For moreinformation on the parameters shown in the samples, see Chapter 5, “File-to-FileTransaction Parameter Reference,” on page 25.

If you use these samples, substitute values for the variables shown in italic type.

Copy a Data Set at Your Node to Another Data Set at Your Node

prefix Q FROM DATASET(ds-name) DAP(dap) OLDTO DATASET(ds-name) OLD

Because the LOCATION parameter defaults to your node, you can omit theLOCATION parameter in both the TO and FROM sections.

The OLD parameter gives BDT exclusive use of an existing data set. It is optional.

Copy a Data Set from Your Node to Another Node

prefix Q FROM DATASET(ds-name) OLD DAP(dap)TO DATASET(ds-name) LOCATION(node-name) OLD

Because the LOCATION parameter defaults to your node, you can omit theLOCATION parameter in the FROM section.


Copy a Data Set from Another Node to Your Node

prefix Q FROM DATASET(ds-name) LOCATION(node-name) OLDDAP(dap)TO DATASET(ds-name) OLD

Because the LOCATION parameter defaults to your node, you can omit theLOCATION parameter in the TO section.



Copy a Sequential Data Set to Another Sequential Data Set

prefix Q FROM DATASET(ds-name) LOCATION(node-name) SHRTO DATASET(ds-name) LOCATION(node-name) OLD

Because the DAP parameter defaults to SEQ, you can omit the DAP parameter.

The SHR parameter gives BDT shared use of an existing data set. It is optional.


Copy a Partitioned Data Set to Another Partitioned Data Set

prefix Q FROM DATASET(ds-name) LOCATION(node-name) SHR DAP(PDS)TO DATASET(ds-name) LOCATION(node-name) OLD



Copy a Sequential Data Set to the End of an Existing Sequential DataSet

prefix Q FROM DATASET(ds-name) LOCATION(node-name) SHRTO DATASET(ds-name) LOCATION(node-name) MOD



The MOD parameter specifies that the copied data is to be added to the end of anexisting data set.

Copy a Data Set to a New Sequential DASD Data Set

prefix Q FROM DATASET(ds-name) LOCATION(node-name) SHRTO DATASET(ds-name) LOCATION(node-name)NEW SPACE(primary,secondary) TRACKS BLKSIZE(blk-size)LRECL(length) RECFM(rf) UNIT(3380)DISP(CATLG,DELETE) VOLUME(111111)



The NEW, SPACE, TRACKS, BLKSIZE, LRECL, and RECFM parameters define thenew “to:” data set.

The UNIT parameter specifies the device on which the data set is to be stored.

The DISP parameter specifies that the data set is to be cataloged if the transactioncompletes normally, and deleted if the transaction completes abnormally. It isoptional.


The VOLUME parameter specifies the serial number of the volume on which thedata set is stored.

Copy a Data Set to a New Partitioned DASD Data Set

prefix Q FROM DATASET(ds-name) LOCATION(node-name) SHR DAP(PDS)TO DATASET(ds-name) LOCATION(node-name)NEW SPACE(primary,secondary) TRACKS BLKSIZE(blk-size)LRECL(length) RECFM(rf) DSORG(PO) UNIT(3380)DIR(blocks) DISP(CATLG,DELETE) VOLUME(111111)

The SHR parameter gives BDT shared use an existing data set. It is optional.

The NEW, SPACE, TRACKS, BLKSIZE, LRECL, RECFM, DSORG and DIRparameters define the new “to:” data set.

The UNIT parameter specifies the device on which the data set is to be stored.

The DISP parameter specifies that the data set is to be cataloged if the transactioncompletes normally and deleted if the transaction completes abnormally.

The VOLUME parameter specifies the serial number of the volume on which thedata set is stored.

Copy a Tape Data Set to a New Tape Data Set

prefix Q FROM DATASET(ds-name) LOCATION(node-name) DAP(SEQ)TO DATASET(ds-name) LOCATION(node-name)LRECL(length) RECFM(rf) BLKSIZE(blk-size)UNIT(TAPE) VOLUME(vol-ser) LABEL(SL) NEW

The NEW, LRECL, RECFM, and BLKSIZE parameters define the new “to:” dataset.

The UNIT parameter indicates the device on which the data set is to be stored.

The VOLUME parameter identifies the tape volume on which the data set isstored.

The LABEL parameter supplies a label for the data set. It is optional.

Copy a DASD Data Set to a New Tape Data Set

prefix Q FROM DATASET(ds-name) UNIT(3350) VOLUME(vol-ser)LOCATION(node-name) DAP(SEQ)TO DATASET(ds-name) LOCATION(node-name)NEW UNIT(TAPE) VOLUME(111111) LABEL(label)RECFM(rf) LRECL(length)BLKSIZE(blk-size)

The NEW, LRECL, RECFM, and BLKSIZE parameters define the new “to:” dataset.

The UNIT parameter indicates the device on which the data set is stored.

Chapter 4. Sample Transactions 23

The VOLUME parameter identifies the volume on which the data set is stored.

The LABEL parameter supplies a label for the data set. It is optional.

Copy a Cataloged Tape Data Set to a DASD Data Set

prefix Q FROM DATASET(ds-name) LOCATION(node-name)DAP(SEQ) UNIT(TAPE)TO DATASET(ds-name) LOCATION(node-name)UNIT(3350) OLD

The SHR parameter gives the transaction shared use of an existing data set. It isoptional.


The UNIT parameter indicates the device on which the data set is stored. It isoptional.


Chapter 5. File-to-File Transaction Parameter Reference

This chapter describes the parameters you use to write transactions. It includes:v A summary of the transaction format and parameters.v A list of the transaction prefixes.v A list of parameters required in particular circumstances.v A description of each of the transaction parameters. The parameters are in

alphabetic order. Each parameter begins a new page. The description of eachparameter explains the purpose, rules for use, and format of the parameter. Inaddition, each description includes brief usage notes, examples, and defaults forthe parameter, if any.

Note: The defaults described in this book are those provided by IBM. Yourinstallation may change these defaults or provide additional defaults. Checkwith your system programmer for more information.

If you need more general information about transactions, or do not understandterms used in this chapter, see Chapter 1, “Writing and Submitting File-to-FileTransactions,” on page 1.


Transaction format and parameter summaryThe preceding section contains the parts of a transaction.

Prefix Job Definition FROM Parameters TO Parametersprefix

(See “TransactionPrefixes” on page 27.)

Q ACCTCSOPTGMJDLIBHOLDJOBNAMEMSGCLASSNETCONDNETHOLDNETIDNETRELPRIORITYPROGRAMMERSYSTEMTIME

FROMDAPDATASETLOCATION

BDTENQBLKSIZEDENDISPDUMMYLABELLRECLMEMBEROLDPARALLELPARMSPASSWORDPOSITIONSECGROUPSECPSWDSECUSERSHRTRTCHUNITVOLREFVOLSEQVOLUME

TODATASETLOCATION

ALXBDTENQBLKSIZEBLOCKBUFLCONTIGCYLINDERSDAPDCBDSDENDIAGNSDIRDISPDSORGDUMMYEXPDTINTRDRLABELLRECLMAXVOLMEMBERMODMSGVPMXIGNEWOLDPARALLELPARMSPASSWORDPOSITIONPROTECTRECFMRELEASERETPDROUNDSECGROUPSECUSERSECPSWDSHRSPACETRACKSTRTCHUCOUNTUNITVOLREFVOLSEQVOLUME


Required ParametersThe parameters in “Transaction format and parameter summary” on page 26 takepart in every transaction, although you can accept defaults for FROM, DAP, andLOCATION.

Other parameters are required in particular circumstances, as explained in thefollowing table. Your installation may provide defaults which allow you to omitsome of the parameters shown in the table.

If the Transaction Involes a Data Set ThatIs:

Then the Transaction Must Include TheseAdditional Parameters:

New NEW, BLKSIZE, LRECL, RECFM, UNIT,VOLUME; also, SPACE, and either BLOCK,CYLINDERS, or TRACKS for DASD datasets; also, DIR for partitioned data sets

Without an explicit block size BLKSIZE

Labeled with other than a standard IBM label LABEL

Unlabeled BLKSIZE, LRECL

Stored on more than five volumes MAXVOL

Stored on a mass storage system MSVGP

Protected with a password PASSWORD

Uncataloged RECFM and UNIT; also, POSITION for datasets stored on a tape that contains severaldata sets

Transaction PrefixesTable 3. Transaction Prefixes

Type ofConsole Prefix in a Single-BDT Complex Prefix in a Poly-BDT Complex

MCS bdt-charorBDTorF [bdt-proc.]bdt-id

same

JES3 *S,BDT *S,BDT,SY(node-name)

TSO BDT BDT SY(node-name)

In Table 3:v bdt-char is a special character (such as +) defined by your system programmer

that routes the transaction directly to a specific system. Do not use a delimiter (ablank space or a comma) after bdt-char.

v bdt-proc is the name of the cataloged procedure in SYS1.PROCLIB that is used tostart BDT. It is optional.

v bdt-id is the installation-defined identifier of BDT.

Chapter 5. File-to-File Transaction Parameter Reference 27

v SY(node-name) is the system parameter. See “SYSTEM — Specify the BDT Nodein a Poly-BDT Complex” on page 79.

ACCT — Supply Accounting InformationUse this parameter to supply accounting information with your transaction.

RulesOptional or Required: Optional

Section: Job definition, FROM, TO

DAP: SEQ, PDS

Format

►► ACCT(acct-info) ►◄

acct-infois the accounting information you want to supply. This information may be nomore than 142 characters in length. Any commas used count in the totalnumber of characters.

Usage NoteAccounting information is read beginning with the first column. If there areleading blanks in the accounting information, the blanks are read as part of theinformation.

ExampleSupply your ID, department number, and project number in your transaction. Usethe TSO prefix (BDT).BDT Q ACCT(BRK,73A,35748)

FROM DATASET(ADATA) LOCATION(KGN01) DAP(SEQ)TO DATASET(DATAFILE) LOCATION(KGN02)

ALX — Allocate Space in Several Contiguous AreasUse this parameter with the SPACE parameter when allocating a new “to” data setto be stored on a direct access storage device (DASD). ALX specifies that MVS maysatisfy the primary allocation request of the SPACE parameter by allocating up tofive different contiguous areas of space. The size of each area must be equal to orgreater than the amount of primary space requested.


Also Requires: The NEW and SPACE parameters, and either the BLOCK,CYLINDERS, or TRACKS parameter

Section: TO

DAP: SEQ, PDS


Format

►► ALX ►◄

Usage Notes1. Specify the units of space to be allocated with the BLOCK, CYLINDERS, or

TRACKS parameter.2. This parameter is invalid with the CONTIG or MXIG parameters.3. If you code this parameter in the FROM section of your transaction, BDT will

accept the parameter but will not use it.4. For a list of parameters that can be used to allocate a new data set, see

Appendix A, “Parameters That Require Other Parameters,” on page 89.

ExampleCopy the data set MYDATA.A1 to the new data set YOURDATA.A1. Specify thatthe primary allocation request on the SPACE parameter be satisfied with severalcontiguous areas of space. Use the TSO prefix (BDT).BDT Q FROM DATASET(MYDATA.A1) LOCATION(KGN01) DAP(SEQ)

TO DATASET(YOURDATA.A1) LOCATION(KGN03) NEW SHRALX SPACE(1,1) CYLINDERS UNIT(SYSDA)BLKSIZE(800) LRECL(80) RECFM(F)DSORG(PS) VOLUME(BDTDS8)

BDTENQ — Request Shared or Exclusive Use of a Data Set by a BDTTransaction

Use this parameter to request shared use or exclusive use of the “from” or “to”data sets by a BDT transaction. Shared use permits other BDT transactions to reada data set while a transaction is being processed. Exclusive use prevents other BDTtransactions from reading or writing to a data set while a transaction is beingprocessed.


Section: FROM, TO

DAP: SEQ, PDS

Format

►► BDTENQ (OLD)(EXC)(SHR)

►◄

SHRrequests shared use of the data set. Other BDT transactions may read from (butnot write to) the data set while your transaction is reading the data set.

If you do not specify the BDTENQ parameter, and the MVS status is SHR,SHR is assumed for the “from” data set.

ALX


OLD or EXCrequests exclusive use of the data set. No other BDT transaction can read fromor write to the data set until your transaction is completed.

If you do not specify the BDTENQ parameter, OLD or EXC is assumed for the“to” data set. If you do not specify the BDTENQ parameter, and the MVSstatus is not share, OLD or EXC is assumed for the “from” data set.

Usage Notes1. For a partitioned data set, the BDTENQ status applies to the entire data set, not

to individual members.2. You may want to specify SHR for the “from” data set. This allows multiple

transactions to read (but not write to) the data set concurrently.3. You may want to specify OLD or EXC for the “to” data set. This prevents other

transactions from writing to the data set until your transaction completes.

ExampleSubmit two transactions that should be able to run at the same time. The first is tocopy the member MEMA from the partitioned data set PDS1.SET, located at nodeTHISNODE, to the member MEMB of the partitioned data set PDS2.SET at nodeELSEWHER. The second is to copy the member MEMC of the data set PDS3.SET,located at node ANYWHERE, to member MEMD of the data set PDS1.SET. Use theTSO prefix (BDT).BDT Q FROM DATASET(PDS1.SET) LOCATION(THISNODE) DAP(SEQ)

MEMBER(MEMA) BDTENQ(SHR)TO DATASET(PDS2.SET) MEMBER(MEMB) LOCATION(ELSEWHER)

BDT Q FROM DATASET(PDS3.SET) MEMBER(MEMC) LOCATION(ANYWHERE)DAP(SEQ)TO DATASET(PDS1.SET) MEMBER(MEMD) LOCATION(THISNODE)OLD BDTENQ(SHR)

BLKSIZE — Define the Block Size of a Data SetUse this parameter to define the block size of the “from” or “to” data sets.

RulesOptional or Required: Required for:v Data sets that are newv Data sets that are unlabeled, or when you want to bypass label processingv Data sets with no explicit block size

Section: FROM, TO

DAP: SEQ, PDS

Format

►► BLKSIZE(blk-size) ►◄

blk-sizeis the block size of the data sets. It is a number from 1 through 32760. Thedefault for existing data sets is the block size in the data set label.

BDTENQ


Usage Notes1. You can use this parameter to reblock and reformat a data set by giving the

“to” data set in a transaction a different block size than the “from” data set.2. Do not use this parameter in the FROM section unless the “from” data set is

unlabeled or label processing is bypassed.3. For more information about the use of BLKSIZE, see the discussion about the

DCB BLKSIZE parameter in the JCL manual that is appropriate for yourinstallation.

ExampleCopy the data set BIGDATA to the new data set JUNEDATA. Define the block sizeof JUNEDATA as 800. Use the TSO prefix (BDT).BDT Q FROM DATASET(BIGDATA) LOCATION(SPK01) DAP(SEQ) SHR

TO DATASET(JUNEDATA) LOCATION(SPK02)NEW SPACE(1,1) CYLINDERS UNIT(3380)BLKSIZE(800) LRECL(80) RECFM(F)VOLUME(111111)

BLOCK — Allocate Space in Block UnitsUse this parameter when defining a new “to” data set that is to be stored on adirect access storage device (DASD). BLOCK requests that MVS allocate space forthe data set in block units.


Also Requires: The NEW and SPACE parameters

Section: TO

DAP: SEQ, PDS

Format

►► BLOCKAVBLOCK

(length) ►◄

lengthdefines the average length of a block of data. length can be any number from 1through 32760.

Usage Notes1. This parameter is invalid with the CYLINDERS or TRACKS parameters.2. For a list of parameters that can be used to allocate a new data set, see


ExampleAllocate direct access space for a new “to” data set in block units. Specify that theaverage length of a block of data will be 3120. Use the TSO prefix (BDT).

BLKSIZE


BDT Q FROM DATASET(FILEDATA) LOCATION(SPK01) DAP(SEQ) SHRTO DATASET(RPT) LOCATION(SPK02)NEW SPACE(1,1) BLKSIZE(3120) LRECL(80) RECFM(FB)BLOCK(3120) UNIT(SYSDA) VOLUME(111111)

BUFL — Define Buffer LengthsUse this parameter when defining a new “to” data set. Use this parameter todefine the size of each buffer in the I/O buffer pool.



Section: TO

DAP: SEQ, PDS

Format

►► BUFL(length) ►◄

lengthis the length of the buffers in bytes. It is a decimal number from 1 through32760.

Usage Notes1. If you code this parameter in the FROM section, BDT will accept the parameter

but will not use it.2. For a list of parameters that can be used to allocate a new data set, see


ExampleCopy a data set to a new data set, specifying an I/O buffer length of 4096. Use theJES3 prefix (*S,BDT).*S,BDT Q FROM DATASET(BDATA.AA) DAP(PDS) LOCATION(NODEB)

TO DATASET(CDATA.AA) LOCATION(NODEC)NEW LRECL(255) BLKSIZE(259) RECFM(V) DIR(12)SPACE(1,2) CYL DSORG(PO) VOLUME(111111)DISP(KEEP,DELETE) UNIT(3350)BUFL(4096)

CONTIG — Allocate Space in a Contiguous AreaUse this parameter when allocating a new “to” data set that is to be stored on adirect access storage device (DASD). This parameter requests that the primaryspace for the data set be allocated in a contiguous area.


BLOCK


Also Requires: The NEW and SPACE parameters, and either the BLOCK,CYLINDERS, or TRACK parameter

Section: TO

DAP: SEQ, PDS

Format

►► CONTIG ►◄

Usage Notes1. This parameter is invalid with the ALX or MXIG parameters.2. If you code this parameter in the FROM section, BDT will accept the parameter



ExampleCopy the data set DATAB to the new direct access data set DATAC. Allocate theprimary space for DATAC in a contiguous area. Use the TSO prefix (BDT).BDT Q FROM DATASET(DATAB) LOCATION(MYNODE) DAP(SEQ)

TO DATASET(DATAC) LOCATION(YOURNODE)NEW SPACE(1,1) UNIT(3380) VOLUME(111111)CONTIG BLOCK(80) BLKSIZE(800) LRECL(80) RECFM(F)

CSOPT — Compress Duplicate Strings of Blanks or CharactersUse this parameter to remove, or compress, duplicate strings of blanks or charactersin the data being copied. The duplicate strings are removed before the data set iscopied.


Section: Job definition

DAP: SEQ, PDS

Format

►► CSOPT( DUPREPDUPREPNJENJEDUP

) ►◄

DUP or REPDUP or REPcompresses 3 to 127 duplicate characters (including spaces).

NJE or NJEDUPcompresses 2 to 63 spaces or 3 to 63 consecutive duplicate characters.

CONTIG


Usage Notes1. For this parameter to function, your installation must have defined the data

compression option during initialization. Your system programmer can tell youwhich option (REPDUP or NJEDUP) is in effect. For more information see thedescription of the BDTNODE statement in z/OS BDT Installation.

2. Use DUP for data sets with a large amount of binary data or small amount ofconsecutive blanks.

3. Use NJE for data sets with a large amount of consecutive blanks, such as text,SYSOUT, or card-image data transfers.

4. Do not use CSOPT more than once in a transaction.

ExampleCopy the data set MYDATA to the data set MOREDATA. Compress repeatedrepeated blanks in the copied data. Use the TSO prefix (BDT).BDT Q CSOPT(DUP) FROM DATASET(MYDATA) LOCATION(KGN01)

DAP(SEQ)TO DATASET(MOREDATA) LOCATION(KGN02)

CYLINDERS — Allocate Space in Cylinder UnitsUse this parameter when allocating a new “to” data set that is to be stored on adirect access storage device (DASD). This parameter allocatesspace for the “to”data set in cylinder units.



Section: TO

DAP: SEQ, PDS

Format

►► CYLINDERSCYL

►◄

Usage Notes1. This parameter is invalid with the BLOCK or TRACKS parameters.2. For a list of parameters that can be used to allocate a new data set, see


ExampleCopy the data set JUNEDATA to a new data set, NEWDATA, and allocate spacefor NEWDATA in cylinder units. Use the TSO prefix (BDT).BDT Q FROM DATASET(JUNEDATA) LOCATION(NODEA) DAP(SEQ)

TO DATASET(NEWDATA) LOCATION(NODEB) NEWCYL SPACE(1,1) UNIT(SYSDA)BLKSIZE(800) LRECL(80)RECFM(F) VOLUME(111111)

CSOPT


DAP — Specify the DAP That Is to Copy the Data SetUse this parameter to specify the dynamic application program (DAP) that is tocopy a data set.

RulesOptional or Required: Required for partitioned data sets (PDSs)

Section: FROM, TO

DAP: SEQ, PDS

Format

►► DAP ( PDSSEQ

) ►◄

PDSspecifies that the PDS DAP is to copy the data set. Use the PDS DAP to copyan entire partitioned data set or selected members of a partitioned data set.

To copy selected members of a partitioned data set use DAP(PDS) with theSELECT or EXCLUDE options of the PARMS parameter.

SEQspecifies that the SEQ DAP is to copy the data set. Use the SEQ DAP to copy asequential data set or one member of a partitioned data set.

To copy one member of a PDS, use DAP(SEQ), and specify the member to becopied as part of the fully-qualified data set name in the DATASET parameter,or with the MEMBER parameter. If you do not specify the DAP parameter,SEQ is assumed.

Usage Notes1. You only need to include the DAP parameter in the FROM or the TO section of

your transaction. If you include the DAP parameter in both the FROM and TOsections, be sure that you specify the same value in both sections.

2. Do not use BDT to copy a PDS member whose directory entry contains userTTRs (relative track addresses) or note lists (pointers to blocks within a PDSmember). BDT will not copy user TTRs or note lists. This means that youcannot copy programs that have been processed into an overlay structure bythe linkage editor.

3. If you use DAP(SEQ), the record length of the “from” data set must be equal toor less than the maximum record length defined in the “to” data set’s datacontrol block (DCB). If not, BDT will truncate records in the “to” data set.

4. The following combinations of parameters are invalid. Do not code them in thesame section of a transaction:v DAP(PDS) and DUMMYv DAP(PDS) and MEMBER

Note: Do not use DAP(SEQ) and MEMBER(member) to copy a load modulethat is a member of a PDS. A load module copied with these parameters willnot be executable.

DAP


Examples1. Copy a the sequential data set ADATA to the sequential data set BDATA using

the SEQ DAP. Use the TSO prefix (BDT).BDT Q FROM DATASET(ADATA) LOCATION(ANODE) DAP(SEQ)

TO DATASET(BDATA) LOCATION(BNODE)

2. Copy the PDS member MEMA of the PDS PDS1.AA to the PDS member MEMBof the PDS PDS2.AA. Use the SEQ DAP and the MEMBER parameter.BDT Q FROM DATASET(PDS1.AA) MEMBER(MEMA) LOCATION(THISNODE)

DAP(SEQ) SHRTO DATASET(PDS2.AA) MEMBER(MEMB) LOCATION(OTHRNODE)OLD

3. Copy the PDS DATA.ONE to the PDS DATA.TWO using the PDS DAP.BDT Q FROM DATASET(DATA.ONE) LOCATION(ONENODE) DAP(PDS) SHR

TO DATASET(DATA.TWO) LOCATION(TWONODE) OLD

DATASET — Specify a Data Set NameUse this parameter to specify the names of the “from” and “to” data sets.

RulesOptional or Required: Required in the FROM section. Required in the TO sectionunless you use the INTRDR or DUMMY parameters.

Section: FROM, TO

DAP: SEQ, PDS

Format

►► DATASETDADSNAMEDSNDS

(ds-name) ►◄

ds-nameis the fully-qualified data set name.

Usage Notes1. Do not code this parameter together with the DUMMY or INTRDR parameters

in the TO section. The DUMMY parameter can be used to specify a dummydata set as the “to” data set. The INTRDR parameter can be used to specify theMVS internal reader at the receiving node as the “to” data set.

2. If you omit the DATASET, DUMMY, and INTRDR parameters from the TOsection, the system copies the “from” data set to a temporary system data set.After the transfer is completed, the system deletes the temporary data setregardless of any disposition you may have specified with the DISP parameter.

3. The information the system will use to resolve a generation data group (GDG)data set referenced by relative number is controlled by the BDT optionGDGLOCS. For more information, see z/OS BDT Installation.

4. If a transaction is entered by a TSO user and the data set name is not enclosedin single quotation marks, the TSO prefix specified for the user is added as aprefix to the data set name.

DAP


ExampleCopy the data set named PRTDATA to the data set named JANDATA. Use the TSOprefix (BDT).BDT Q FROM DATASET(PRTDATA) LOCATION(MYNODE) DAP(SEQ)

TO DATASET(JANDATA) LOCATION(JANNODE)

DCBDS — Read DCB Information from a Data Set LabelUse this parameter when allocating a new “to” data set to be stored on a directaccess storage device (DASD). This parameter requests that MVS read the datacontrol block (DCB) information for the “to” data set from the label of another dataset.


Also Requires: The NEW and SPACE parameters, and either the BLOCK,CYLINDERS, or TRACKS parameters

Section: TO

DAP: SEQ, PDS

Format

►► DCBDS(ds-name) ►◄

ds-nameis the fully-qualified data set name of the data set from which you want toobtain DCB information.

The data set:v Must be catalogedv Must be on a direct access devicev Must be on the same system as the “to” data set.

Usage Notes1. The DCB information obtained from the data set label is:v Block sizev Data set organizationv Logical record lengthv Record format.

2. If you code the BLKSIZE, DSORG, LRECL, or RECFM parameters in yourtransaction, the parameter value that you code will be used instead of the valuefound in the data set label of the data set specified with the DCBDS parameter.

3. If a transaction is entered by a TSO user and the data set name is not enclosedin single quotation marks, the TSO prefix specified for the user is added as aprefix to the data set name.

4. Do not code the DCBDS parameter in the FROM section. If you do and thedata set’s DCB information is incompatible with the information contained inthe DCBDS parameter, the transaction will fail.

DATASET


5. For a list of parameters that can be used to allocate a new data set, seeAppendix A, “Parameters That Require Other Parameters,” on page 89.

ExampleCopy the data set FILEA to the new data set FILEB, and read DCB information forFILEB from FILEA. Use the JES3 prefix (*S,BDT).*S,BDT Q FROM DATASET(FILEA) LOCATION(NODEA) DAP(SEQ)

TO DATASET(FILEB) LOCATION(NODEB) NEW SPACEDCBDS(FILEA) CYLINDERS UNIT(SYSDA)VOLUME(111111)

DEN — Define the Recording Density of a Tape Data SetUse this parameter to define the recording density of a data set stored on magnetictape.


Section: FROM, TO

DAP: SEQ

Format

►► DEN ( 01234

) ►◄

0 is the density for 200 bpi 7-track tapes.


2 is the density for 800 bpi 7-track or 800 bpi 9-track tapes.



If you do not specify this parameter, the highest applicable density is assumed.

ExampleCopy the data set DEPTA to the data set NAMES, which is stored on a 1600 bpi9-track magnetic tape. Use the TSO prefix (BDT).BDT Q FROM DATASET(DEPTA) LOCATION(KGN01) DAP(SEQ)

TO DATASET(NAMES) LOCATION(KGN02)NEW VOLSER(11111) UNIT(TAPE9)DEN(3) BLKSIZE(8000) LRECL(80) RECFM(F)

DIAGNS — Request the Trace OptionUse this parameter to request the OPEN/CLOSE/EOV trace option, which gives amodule-by-module trace of OPEN/CLOSE/EOV’s work area and the user’s datacontrol block (DCB).

DCBDS



Section: TO

DAP: SEQ, PDS

Format

►► DIAGNS(TRACE) ►◄

Usage NoteIf you use the trace option, the generalized trace facility (GTF) must be active inthe system on which your transaction executes. Check with the MVS operator onyour system to find out if the GTF is active.

ExampleCopy the data set ONEDATA to the data set TWODATA and request the traceoption. Use the TSO prefix (BDT).BDT Q FROM(ONEDATA) LOCATION(ONENODE) DAP(SEQ)

TO(TWODATA) LOCATION(TWONODE) DIAGNS(TRACE)

DIR — Request Directory Blocks for a New PDSUse this parameter when allocating a new “to” partitioned data set (PDS) to bestored on a direct access storage device (DASD). This parameter requests directoryblocks for the new PDS.

RulesOptional or Required: Required for a new PDS


Section: TO

DAP: PDS

Format

►► DIR(blocks) ►◄

blocksis the number of directory blocks, from 1 to 999999.

ExampleCopy the data set OLDDATA to the new PDS NEWDATA and request 50 directoryblocks for NEWDATA. Use the TSO prefix (BDT).

DIAGNS


BDT Q FROM DATASET(OLDDATA) LOCATION(NODEA) DAP(PDS) SHRTO DATASET(NEWDATA) LOCATION(NODEB)NEW SPACE(1,1) CYL BLKSIZE(800) LRECL(80) RECFM(F)DIR(10) UNIT(SYSDA) VOLUME(111111)

DISP — Specify the Disposition of a Data SetUse this parameter to tell MVS what to do with the “to” or “from” data set whenthe transaction completes or when the BDT address space terminates while thetransaction is active.


Section: FROM, TO

DAP: SEQ, PDS

Format

►► DISP( CATALOGCATLGUNCATALOGUNCATLG

DELETEKEEP

,CATALOG,CATLG,UNCATALOG,UNCATLG

,DELETE,KEEP

) ►◄

If you specify one disposition, it tells MVS what to do with the data set after thedata transfer completes normally.

If you specify two dispositions, the first disposition tells MVS what to do with thedata set after the data transfer completes normally, and the second disposition tellsMVS what to do with the data set if the transaction terminates abnormally.

CATALOG or CATLGspecifies that the data set is to be kept and that an entry pointing to the dataset is to be added to the system or user catalog. CATALOG is the default fornew “to” data sets.

UNCATALOG or UNCATLGspecifies that the data set is to be kept but the system or user catalog entry forthe data set is to be removed.

DELETEspecifies that the data set is no longer needed; its space is to be released foruse by other data sets.

KEEPspecifies that the data set is to be kept. KEEP is the default for existing datasets.

Usage Notes1. If you use DISP(DELETE) together with the EXPDT or RETPD parameter, MVS

ignores the EXPDT or RETPD parameter and deletes the data set.2. For more information on cataloging data sets, see the z/OS MVS JCL User's

Guide that is appropriate for your installation.

DIR


Examples1. Copy a data set to an existing data set and specify that MVS is to keep the “to”

data set after the transcation completes. Use the TSO prefix (BDT).BDT Q FROM DATASET(DATAB) LOCATION(KGN01) DAP(PDS)

TO DATASET(DATAC) LOCATION(KGN02) OLD DISP(KEEP)

2. Copy a data set to a new data set. If the transaction completes normally, MVSis to keep the “from” data set, but not catalog it, and also catalog the new “to”data set. If the transaction terminates abnormally, MVS is to delete the “from”and “to” data sets.BDT Q FROM DATASET(FILEA) LOCATION(NODEA) DAP(PDS)

DISP(KEEP,DELETE)TO DATASET(FILEB) LOCATION(NODEB)NEW LRECL(80) BLKSIZE(800) RECFM(F) DIR(12)SPACE(1,2) CYL DSORG(PO) VOLUME(222222)DISP(CATLG,DELETE) UNIT(3380)

DSORG — Specify Data Set OrganizationUse this parameter when allocating a new “to” data set that is to be stored on adirect access storage device (DASD). This parameter specifies the organization ofthe “to” data set.



DAP: SEQ, PDS

Section: TO

Format

►► DSORG ( POPS

) ►◄

PO specifies that the data set organization is partitioned.

PS specifies that the data set organization is physical sequential.

Usage Notes1. Do not code the DSORG parameter in the FROM section. If you do so and the

data set’s data control block (DCB) information is incompatible with theinformation contained in the DSORG parameter, the transfer will fail.


ExampleCopy the data set MAYDATA to the new data set JUNEDATA and specify that theorganization of the JUNEDATA is partitioned. Use the TSO prefix (BDT).BDT Q FROM DATASET(MAYDATA) LOCATION(KGN01) DAP(PDS)

TO DATASET(JUNEDATA) LOCATION(KGN02)NEW DSORG(PO)

DISP


LRECL(255) BLKSIZE(259) RECFM(V) DIR(12)SPACE(1,2) CYL VOLUME(111111)DISP(KEEP,DELETE) UNIT(3350)BUFL(4096)

DUMMY — Request a Dummy Data SetUse this parameter to request a dummy data set instead of a real data set. Using adummy data set allows you to test a transaction without actually copying data.


Also Requires: The LRECL and RECFM parameters, and either the DCBDS orBLKSIZE parameter

Section: FROM, TO

DAP: SEQ

Format

►► DUMMY ►◄

Usage Notes1. The DUMMY parameter is invalid if used with the INTRDR or DATASET

parameters in the TO section.2. For a dummy data set, MVS bypasses device and space allocation, I/O

operations, and data set disposition.3. For more information on the use of dummy data sets, see the JCL manual that

is appropriate for your installation.

ExampleTest a transaction using the data set TESTDSN as the “from” data set and adummy data set as the “to” data set. Use the TSO prefix (BDT).BDT Q FROM DATASET(TESTDSN) LOCATION(KGN01) DAP(SEQ)

TO DUMMY RECFM(FB) LRECL(80) BLKSIZE(800)LOCATION(KGN03)

EXPDT — Specify an Expiration Date for a Data SetUse this parameter to assign an expiration date to a data set. MVS will not allowthe data set to be deleted or written over before this date.


Also Requires: The LABEL parameter if the data set is new

Section: TO

DAP: SEQ, PDS

DSORG


Format

►► EXPDT(yyddd) ►◄

yydddis the expiration date you want to assign to the data set. yy is the year andmay be any number from 00 to 99. ddd is the day and may be any numberfrom 001 to 366.

Usage Notes1. If you want to protect a data set from being overwritten or deleted for a certain

number of days, you can use the RETPD parameter.2. If you code the EXPDT parameter in the FROM section, BDT will accept the

parameter but will not use it.3. For more information on the use of the EXPDT parameter, see the LABEL

parameter in the JCL manual that is appropriate for your installation.

ExampleCopy the data set MYDSN to the data set THATDSN and assign an expiration dateof June 13, 1987 to THATDSN. Use the TSO prefix (BDT).BDT Q FROM DATASET(MYDSN) LOCATION(MYNODE) DAP(SEQ)

TO DATASET(THATDSN) LOCATION(THATNODE) EXPDT(87164)

FROM — Begin the FROM SectionUse this parameter to mark the beginning of the FROM section of the transaction.The parameters following FROM describe the data set to be copied and the node atwhich the data set is located.

RulesOptional or Required: Optional, unless you place FROM parameters after the TOparameter

Section: FROM

DAP: SEQ, PDS

Format

►► FROM ►◄

FROMmarks the beginning of the FROM section of the transaction.

Usage Notes1. You can split the FROM section of your transaction into several parts, each

beginning with a FROM parameter.2. See Chapter 1, “Writing and Submitting File-to-File Transactions,” on page 1 for

general information on the FROM section of a transaction.

EXPDT


Examples1. Copy the data set DDATA to the data set GDATA. List all the parameters

describing the “from” data set before the TO section of the transaction and omitthe FROM parameter. Use the TSO prefix (BDT).BDT Q DATASET(DDATA) LOCATION(KGN01) DAP(SEQ)

TO DATASET(GDATA) LOCATION(KGN02)

2. Copy the data set BDATA to the data set HDATA. Specify the location of the“from” data set after the TO section of the transaction.BDT Q FROM DATASET(BDATA) DAP(SEQ)

TO DATASET(HDATA) LOCATION(SPK01)FROM LOCATION(SPK02)

GMJDLIB — Request a GMJD LibraryUse this parameter to request that BDT combine your transaction definition with atransaction definition that is stored in a private GMJD library.


Section: Job definition

DAP: SEQ, PDS

Format

►► GMJDLIBGMJD

(ds-name) ►◄

ds-nameis the name of the data set that contains the private GMJD library.

Usage Notes1. The data set that contains the private GMJD library must be located at the node

where you submit your transaction, must be accessible to BDT, and must becataloged.

2. Do not use this parameter with a transaction code of Q.3. For general information about submitting transactions from GMJD libraries, see

Chapter 2, “Storing and Reusing Transaction Definitions — GMJD Libraries,”on page 11.

Examples1. Submit the transaction definition stored as member ENDREPT in your private

GMJD library, which is a partitioned data set named JOESLIB. Use the TSOprefix (BDT).BDT ENDREPT GMJDLIB(JOESLIB)

2. Submit the transaction definition stored in the private GMJD library that is asequential data set named REPORT. Use the TSO prefix (BDT).BDT AUG GMJDLIB(REPORT)

FROM


HOLD — Put a Transaction into Operator HoldUse this parameter to put a transaction into operator hold on the BDT workqueue.This prevents the transaction from running until it is released from hold.


DAP: SEQ, PDS


Format

►► HOLD ►◄

Usage NoteTo release the transaction from hold, use the F,J,R command. See z/OS BDTCommands for more information.

ExampleRequest that a transaction be put into operator hold. Use the JES3 prefix (*S,BDT).*S,BDT Q JOBNAME(MYJOB) HOLD

FROM DATASET(ADATA) LOCATION(NODEA) DAP(SEQ)TO DATASET(BDATA) LOCATION(NODEB)

INTRDR — Copy a Data Set to the MVS Internal ReaderUse this parameter to copy a data set to the MVS internal reader at the receivingnode.


Also Requires: The BLKSIZE parameter

Section: TO

DAP: SEQ

Format

►► INTRDR ►◄

Usage Notes1. This parameter is invalid if used with either the DATASET or DUMMY

parameters in the TO section.2. INTRDR also allows a user’s BDT transaction stream to submit an MVS job at a

remote node. Conversely, the BDT batch program allows a user’s MVS job

HOLD


stream to submit BDT transactions at a remote node. See Chapter 1, “Writingand Submitting File-to-File Transactions,” on page 1 for more information.

ExampleCopy the data set COPYDATA to the MVS internal reader at node KGN01. Use theTSO prefix (BDT).BDT Q FROM DATASET(COPYDATA) LOCATION(NODEA) DAP(SEQ)

TO INTRDR LOCATION(KGN01) BLKSIZE(1330)

JOBNAME — Assign a Name to the Job That Results from aTransaction

Use this parameter to assign a name to the job that results from your transaction.

RulesOptional or Required: Required with the NETREL parameter


DAP: SEQ, PDS

Format

►► JOBNAMEJOB

(name) ►◄

nameis the name you want to be assigned to the job. The name may be 1 to 8alphanumeric characters.

If you do not specify this parameter, your job will be given one of thefollowing names:v The GMJD member name if you have specified a GMJD libraryv “AQJOB” if you have specified a Q-type transaction (if you have used a

transaction code of Q).

Usage Notes1. Use JOBNAME if you merge several transactions with the same GMJD library

member. The name (and the job number) will help you distinguish onetransaction from another.

2. Use JOBNAME when creating dependent transaction control networks, toassign names to predecessors and successors in the network.

Examples1. Submit a transaction to copy a data set and name the resulting job MYJOB. Use

the TSO prefix (BDT).BDT Q JOBNAME(MYJOB)

FROM DATASET(ONEDATA) LOCATION(ONENODE) DAP(SEQ)TO DATASET(TWODATA) LOCATION(TWONODE)

2. Submit a transaction using a GMJD library and name the resulting jobTHISJOB. The GMJD library is a partitioned data set named MYLIB. The

INTRDR


member of the library that contains the stored transaction definition isMYMEMBER. Use the TSO prefix (BDT).BDT MYMEMBER GMJD(MYLIB) JOBNAME(THISJOB)

LABEL — Supply Label Information for a Data SetUse this parameter to supply label information for a data set.

RulesOptional or Required: Required for:v An existing data set, if the data set has a label other than a standard IBM labelv A new data set, if:

– You want to assign a label other than a standard IBM label to the data set.– You use the PASSWORD parameter with the data set.– You use the EXPDT parameter or the RETPD parameter with the data set.

Section: FROM, TO

DAP: SEQ, PDS

Format

►► LABELLBL

( ALAULBLPLTMNLNSLSLSUL

) ►◄

AL specifies the American National Standard label.

AULspecifies American National Standard and user labels.

BLPspecifies that label processing is to be bypassed.

LTMspecifies a leading tape mark.

NL specifies no labels.

NSLspecifies nonstandard labels.

SL specifies the IBM standard label.

SULspecifies both IBM standard and user labels.

If you do not specify this parameter:v A label is obtained from the catalog for a cataloged data set.v An IBM standard label is given to a new data set.

JOBNAME


Usage NoteFor more information on data set labels, see the z/OS MVS JCL User's Guide that isappropriate for your installation.

ExampleCopy the data set JANDATA, which is stored on tape, to a new tape data set,RPTDATA. Specify that no label information is to be supplied for either data set.Use the TSO prefix (BDT).BDT Q FROM DATASET(JANDATA) LOCATION(KGN01) DAP(SEQ)

LABEL(NL)UNIT(TAPE) VOL(1025) RECFM(FB) LRECL(80) BLKSIZE(3120)TO DATASET(RPTDATA) LOCATION(KGN02)LABEL(NL)NEW EXPDT(82163)UNIT(TAPE) RECFM(FB) LRECL(80) BLKSIZE(3120)VOLUME(222222)

LOCATION — Specify the Location of a Data SetUse this parameter to specify the locations (nodes) of the “from” or “to” data sets.

RulesOptional or Required: Required in a single-BDT complex unless the data setnamed in the DATASET parameter is at the node where the transaction issubmitted. Required in a poly-BDT complex unless the data set named in theDATASET parameter is at the node that is defined as the default for yourinstallation.

Section: FROM, TO

DAP: SEQ, PDS

Format

►► LOCATIONLOC

(node-name) ►◄

node-nameis the name of the node at which the data set is located.

If you do not specify this parameter, the following location is assumed:v In a single-BDT complex, the node at which you submit the transaction.

Your installation may override this default.v In a poly-BDT complex, the node that is defined as the default node for your

installation.

Contact your BDT system programmer for the default node and for the namesof the nodes in your network.

ExampleCopy a data set located at your node to a data set located at the node namedOTHERNODE. You do not need to use the LOCATION parameter in the FROMsection of the transaction because the “from” data set is located at the node whereyou submit the transaction. Use the TSO prefix (BDT).

LABEL


BDT Q FROM DATASET(MY.DATA.SET) DAP(SEQ)TO DATASET(OTHER.DATA.SET) LOCATION(OTHERNODE)

LRECL — Specify the Logical Record Length of a Data SetUse this parameter when allocating a new “to” data set. This parameter tells MVSthe logical record length of the data set.

RulesOptional or Required: Required for new “to” data sets, and for existing tape datasets that are not labeled

Section: FROM, TO

DAP: SEQ, PDS

Format

►► LRECL ( LENGTHX

) ►◄

lengthis the logical record length of the data set in bytes. It is a number from 0through 32760.

X specifies that the data set has a variable-length or spanned record type, with alogical record length exceeding 32756 bytes.

The default for existing data sets is the logical record length in the data setlabel. For a data set without a label, there is no IBM-defined default.

ExampleCopy the data set CODATA to a new data set named NEWDATA. Specify a logicalrecord length of 80 bytes for NEWDATA. Use the TSO prefix (BDT).BDT Q FROM DATASET(CODATA) LOCATION(CONODE) DAP(SEQ)

TO DATASET(NEWDATA) LOCATION(NNODE)NEW SPACE(2,1) CYL VOLUME(KGN01) DSORG(PS)LRECL(80) BLKSIZE(3120) RECFM(FB) DIR(2)UNIT(SYSDA)

MAXVOL — Specify the Maximum Number of Volumes Required for aData Set

Use this parameter when allocating a new “to” data set. This parameter specifiesthe maximum number of volumes required for the data set.

RulesOptional or Required: Required if the data set needs more than five volumes andyou do not use the VOLUME parameter

Section: TO

DAP: SEQ

LOCATION


Format

►► MAXVOL(volumes) ►◄

volumesis the maximum number of volumes required by the data set. volumes is anumber from 1 through 255.

If you do not specify this parameter, 5 volumes is assumed, unless you use theVOLUME parameter.

Usage NoteIf you use the both the MAXVOL and VOLUME parameters, the VOLUMEparameter will override the MAXVOL parameter.

ExampleCopy the data set DATA to the new tape data set NEWDATA and specify thatNEWDATA will require a maximum of 7 volumes. Use the TSO prefix (BDT).BDT Q FROM DATASET(DATA) LOCATION(NODEA) DAP(SEQ)

TO DATASET(NEWDATA) LOCATION(NODEB) NEWMAXVOL(7) LRECL(133) BLKSIZE(133) RECFM(F)UNIT(TAPE) (KGN02)

MEMBER — Specify a Member of a Partitioned Data SetUse this parameter to specify a member of a partitioned data set (PDS).


Section: FROM, TO

DAP: SEQ

Format

►► MEMBERMBR

(member) ►◄

memberis the name of the PDS member you want to copy or to receive the copied dataset.

Usage Notes1. If you use this parameter to copy data sets with different logical record lengths

and do not use the PAD parameter, the “to” data set will be padded withbinary zeroes.

2. The PARMS parameter offers more options for copying members of partitioneddata sets.

MAXVOL


Examples1. Copy the member FIRST from the partitioned data set MY.DATA to the

member ONE of the partitioned data set THAT.DATA. Use the TSO prefix(BDT).BDT Q FROM DATASET(MY.DATA) LOCATION(MYNODE) DAP(SEQ)

MEMBER(FIRST) OLDTO DATASET(THAT.DATA) LOCATION(THATNODE)MEMBER(ONE)

2. Copy the member MEMONE from the PDS MY.DATA to the sequential data setTARGET.BDT Q FROM DATASET(MY.DATA) LOCATION(MYNODE) DAP(SEQ)

MEMBER(MEMONE)TO DATASET(TARGET) LOCATION(OTHERNODE)

3. Copy the sequential data set SOURCE to the member SRCMEM of the PDSMANY.SOURCES.BDT Q FROM DATASET(SOURCE) LOCATION(MYNODE) DAP(SEQ)

TO DATASET(MANY.SOURCES) LOCATION(OTHERNODE)MEMBER(SRCMEM)

MOD — Copy a Data Set to the End of an Existing Data SetUse the MOD parameter to:v Add a copied data set to the end of an existing sequential data set.v Add a copied data set to an existing partitioned data set (PDS) as a new

member.

MOD gives your BDT subsystem exclusive use of the TO data set.


Section: TO

DAP: SEQ, PDS

FormatMOD is one of four data set status parameters that can be specified in the TOsection of a transaction. All four are shown and explained subsequently. Use onlyone in the TO section of a transaction.

►► MOD ►◄

►► NEW ►◄

►► OLD ►◄

►► SHR ►◄

Used in the TO section of a transaction,

MEMBER


MODspecifies that the “to” data set is an existing data set, and that the copied dataset is to be added to it. This parameter gives your BDT subsystem exclusiveuse of the “to” data set.

NEWspecifies that the “to” data set is a new data set to be allocated in thetransaction. It gives your BDT subsystem exclusive use of the data set.

OLDspecifies that the “to” data set is an existing data set, and that the copied dataset is to overwrite it. This parameter gives your BDT subsystem exclusive useof the data set.

This is the default for the TO section.

SHRspecifies to MVS that the “to” data set is an existing data set and allows otherusers to share the use of it with your BDT subsystem.

Usage Notes1. You may want to use the BDTENQ parameter to indicate to BDT whether a

data set can be shared by other BDT transactions. The default value for theBDTENQ parameter is exclusive use of the “to” data set. See the BDTENQparameter for more information.

2. Use only one of the four data set status parameters in the TO section of atransaction.

3. If you code the MOD parameter in the FROM section, BDT will accept theparameter but will not use it.

4. If you use MOD to add the copied data as a new PDS member, you must alsouse the MEMBER parameter to name the member. The name you give to thePDS member must not already exist in the PDS directory.

ExampleAdd the data set DATAB to the end of the data set DATAC. Use the TSO prefix(BDT).BDT Q FROM DATASET(DATAB) LOCATION(SPK01) DAP(SEQ)

TO DATASET(DATAC) LOCATION(SPK01) MOD

MSGCLASS — Specify the Destination of MessagesUse this parameter to indicate where BDT is to send messages that pertain to thistransaction.



DAP: SEQ, PDS

MOD


Format

►► MSGCLASSMSG

( *LOGNONE

) ►◄

* specifies that messages are to be sent to the terminal where you submitted thetransaction and to the BDT system log.

LOGspecifies that messages are to be sent to a log defined by the installation. Themessages may be processed by an installation-written exit routine.

NONEspecifies that messages are to be sent to the BDT system log.

Usage Notes1. When using the * option to send messages to a terminal, you can reduce the

number of messages sent to the terminal by specifying MSG=S on the PARMSparameter.

2. Do not confuse this parameter (which stands alone) with the MSG option of thePARMS parameter.

ExampleCopy a data set to another data set and specify that messages related to thetransaction be sent to the terminal at which you submit the transaction.BDT Q MSGCLASS(*)

FROM LOC(SYSA1) DATASET(ADATA.SET) DAP(SEQ)TO LOC(SYSA2) DATASET(BDATA.SET)NEW LRECL(80) BLKSIZE(3120) RECFM(FB)SPACE(12,1) CYLINDERS VOLUME(BDTDS8)DISP(CATLG,DELETE) DSORG(PS)UNIT(3380)

MSVGP — Specify the Mass Storage Volumes on Which a Data Set IsLocated

Use this parameter to indicate that a data set is located on a specific group of massstorage volumes on a mass storage system (MSS) device.

RulesOptional or Required: Required for MSS data sets

Section: TO

DAP: SEQ, PDS

Format

►► MSVGP(mss-id) ►◄

mss-idis the mass storage volume group identifier (1 to 8 characters).

MSGCLASS


Usage NoteThis parameter is invalid with the ALX, MXIG, and VOLUME parameters.

ExampleCopy a data set to the data set SDATA, which is stored on the group of massstorage volumes named MYGROUP. Use the TSO prefix (BDT).BDT Q FROM DATASET(RDATA) LOCATION(KGN01) DAP(SEQ)

TO DATASET(SDATA) MSVGP(MYGROUP) LOCATION(KGN02)

MXIG — Request the Maximum Contiguous Space for a Data SetUse this parameter when allocating a new data set that is to be stored on a directaccess storage device (DASD). This parameter requests the largest area ofcontiguous space on a volume.



Section: TO

DAP: SEQ, PDS

Format

►► MXIG ►◄

Usage Notes1. The size of the space allocated with this parameter must be equal to or larger

than the amount of primary space requested through the SPACE parameter.2. This parameter is invalid with the ALX or CONTIG parameters.3. If you code the MXIG parameter in the FROM section, BDT will accept the

parameter but will not use it.4. For a list of parameters that can be used to allocate a new data set, see


ExampleCopy the data set OLDDATA to the new data set NEWDATA, and request thelargest area of contiguous space on the volume for NEWDATA. Use the TSO prefix(BDT).BDT Q FROM LOC(SYSA1) DATASET(OLDATA) DAP(SEQ) SHR

TO LOC(SYSA2) DATASET(NEWDATA)NEW LRECL(80) BLKSIZE(3120) RECFM(FB)MXIG SPACE(12,1) CYLINDERS VOLUME(NEWDS8)DSORG(PS) UNIT(SYSDA)

MSVGP


NETCOND — Tell BDT What to Do with a Transaction in a DTCNetwork If a Predecessor Fails

Use this parameter with transactions that belong to a dependent transaction control(DTC) network. This parameter tells BDT what to do with this transaction afterany of its predecessors in the DTC network completes normally or fails.


Also Requires: The NETID parameter


DAP: SEQ, PDS

Format

►► NETCONDNETC

( DECREMENTDFLUSHFRETAINR

, DECREMENTDFLUSHFRETAINR

) ►◄

The first option (the one immediately after NETCOND) tells BDT what to do aftera predecessor transaction completes normally.

The second option tells BDT what to do after a predecessor transaction completesabnormally (fails).

D or DECREMENTdecreases this transaction’s hold count by 1 when any predecessor completes.This is the default.

F or FLUSHflushes this transaction and its successors when any predecessor completes.

R or RETAINretains (does not change) the hold count of this transaction when anypredecessor completes.

Usage NoteFor basic information about dependent transaction control networks, see Chapter 3,“Controlling the Order in Which Transactions Are Processed — DTC Networks,”on page 15.

ExampleSpecify that MYJOB3, in the DTC network MYNET, should have its hold countlowered when any of its predecessor transactions completes normally, but shouldbe flushed if any of its predecessor transactions fails. Use the TSO prefix (BDT).BDT Q JOBNAME(MYJOB3) NETID(MYNET) NETHOLD(1)

NETREL(MYJOB4) NETCOND(D,F)FROM DATASET(MYDATA) LOCATION(KGN01) DAP(SEQ)TO DATASET(YOURDATA) LOCATION(KGN02)

NETCOND


NETHOLD — Specify the Hold Count of a Transaction in a DTCNetwork

Use this parameter to specify the hold count of a transaction in a dependenttransaction control (DTC) network.


Also Requires: The NETID parameter


DAP: SEQ, PDS

Format

►► NETHOLDNETHC

(net-hold) ►◄

net-holdis the hold count of the transaction. net-hold is a number from 1 to 32767.

Usage Notes1. In most cases, the hold count you give a transaction should agree with the

number of predecessor transactions specified with the NETREL parameter.However, you can give a transaction a hold count that is higher than thenumber of predecessor transactions. This will hold the transaction until yourelease it with the F,NET,ID,J,D command or the F,NET,ID,J,R command. Seez/OS BDT Commands for more information.

2. You can give a transaction a hold count that is lower than the number ofpredecessor transactions. You might want to do this when you want atransaction to run after some, rather than all, of its predecessor transactionshave completed.

3. You can use operator hold to hold the processing of transactions in a DTCnetwork. Use either the F,J,C or the F,J,H command to put the first transactionin a DTC network into operator hold, and then the F,J,R command to releasethe transaction from hold. See z/OS BDT Commands for more information.

4. For basic information about dependent transaction control networks, seeChapter 3, “Controlling the Order in Which Transactions Are Processed — DTCNetworks,” on page 15.

Examples1. Create a DTC network called MYNET, in which MYJOB1 releases MYJOB2

which releases MYJOB3. Note that MYJOB2 and MYJOB3 each have onepredecessor and a NETHOLD count of 1.Give MYJOB1 a hold count of 1 with the NETHOLD parameter to keep it fromrunning before the rest of the network is submitted. Use the TSO prefix (BDT).BDT Q JOBNAME(MYJOB1) NETID(MYNET) NETREL(MYJOB2) NETHOLD(1)

FROM DATASET(AADATA) LOCATION(BANODE) DAP(SEQ)TO DATASET(DADATA) LOCATION(DANODE) MOD

NETHOLD


BDT Q JOBNAME(MYJOB2) NETID(MYNET) NETHOLD(1) NETREL(MYJOB3)FROM DATASET(BADATA) LOCATION(BANODE) DAP(SEQ)TO DATASET(DADATA) LOCATION(DANODE) MOD

BDT Q JOBNAME(MYJOB3) NETID(MYNET) NETHOLD(1)FROM DATASET(CADATA) LOCATION(BANODE) DAP(SEQ)TO DATASET(DADATA) LOCATION(DANODE) MOD

2. Create a DTC network called ANET. In ANET, AJOB1 releases AJOB2 andAJOB3. AJOB2 also releases AJOB3. As AJOB3 has two predecessors, giveAJOB3 a hold count of 2.Give AJOB1 a hold count of 1 (with the NETHOLD parameter) to keep it fromrunning before the rest of the network is submitted.BDT Q JOBNAME(AJOB1) NETID(ANET) NETREL(AJOB2,AJOB3) NETHOLD(1)

FROM DATASET(ADATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

BDT Q JOBNAME(AJOB2) NETID(ANET) NETHOLD(1) NETREL(AJOB3)FROM DATASET(CDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

BDT Q JOBNAME(AJOB3) NETID(ANET) NETHOLD(2)FROM DATASET(DDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

3. Create a DTC network called BNET, in which BJOB1 and BJOB2 arepredecessors to BJOB3. Specify that BJOB3 is to remain in DTC hold until it isreleased by a command. To do this, give BJOB3 a NETHOLD count of 3although it has only two predecessors.Submit BJOB1 and BJOB2 in operator hold (using the HOLD parameter) tokeep them from running before BJOB3 is submitted.BDT Q JOBNAME(BJOB1) NETID(BNET) NETREL(BJOB3) HOLD


BDT Q JOBNAME(BJOB2) NETID(BNET) NETREL(BJOB3) HOLDFROM DATASET(CDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

BDT Q JOBNAME(BJOB3) NETID(BNET) NETHOLD(3)FROM DATASET(DDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

4. Create a DTC network called CNET, in which CJOB3 is released by CJOB1 andCJOB2. Allow CJOB3 to run when either CJOB1 or CJOB2 completes. To do this,give CJOB3 a hold count of 1 even though it has two predecessors.BDT Q JOBNAME(CJOB1) NETID(CNET) NETREL(CJOB3)


BDT Q JOBNAME(CJOB2) NETID(CNET) NETREL(CJOB3)FROM DATASET(CDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

BDT Q JOBNAME(CJOB3) NETID(CNET) NETHOLD(1)FROM DATASET(DDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

NETID — Assign a Transaction to a DTC NetworkUse this parameter to assign a transaction to a specific dependent transactioncontrol (DTC) network.

NETHOLD




DAP: SEQ, PDS

Format

►► NETIDNET

(net-id) ►◄

net-idis the name of the DTC network to which BDT is to assign the transaction. Thenet-id must be 1 to 8 alphanumeric characters. The first character must bealphabetic.

Usage Notes1. All transactions that are to be in the same DTC network must use the same

net-id.2. For basic information about dependent transaction control (DTC) networks, see

Chapter 3, “Controlling the Order in Which Transactions Are Processed — DTCNetworks,” on page 15.

ExampleCreate a DTC network called MYNET, in which MYJOB1 releases MYJOB2 whichreleases MYJOB3. Use the TSO prefix (BDT).BDT Q JOBNAME(MYJOB1) NETID(MYNET) NETREL(MYJOB2)


BDT Q JOBNAME(MYJOB2) NETID(MYNET) NETHOLD(1) NETREL(MYJOB3)FROM DATASET(CDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

BDT Q JOBNAME(MYJOB3) NETID(MYNET) NETHOLD(1)FROM DATASET(DDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

NETREL — Specify Successor Transactions in a DTC NetworkUse this parameter to tell BDT what transactions are successors to a transaction ina dependent transaction control (DTC) network.


Also Requires: The NETID, JOBNAME, and NETHOLD parameters


DAP: SEQ, PDS

NETID


Format

►► NETREL ( ▼

,

name ) ►◄

namespecifies the name or names of the transactions that are successors to thistransaction. Names are assigned to transactions with the JOBNAME parameter.

Usage Notes1. You must use the NETHOLD parameter on transactions that are released by

(are successors to) this transaction; otherwise they will not wait to be released.2. This transaction and its successor transactions must all be part of the same

DTC network, that is, they must all have the same net-id, specified with theNETID parameter.

3. The NETREL parameter can only release a successor transaction that isscheduled for processing at the same node as the predecessor transaction. SeeChapter 3, “Controlling the Order in Which Transactions Are Processed — DTCNetworks,” on page 15 for more information.

ExampleCreate a DTC network called XNET in which XJOB1 releases XJOB2 and XJOB3,and XJOB2 also releases XJOB3. Give XJOB3 a hold count of 2 (with theNETHOLD parameter) so that it will not run until both XJOB1 and XJOB2complete. As XJOB3 does not have any successors, it does not need a NETRELparameter.

Submit XJOB1 in operator hold (with the HOLD parameter) to keep it fromrunning before the rest of the network is submitted. Use the TSO prefix (BDT).BDT Q JOBNAME(XJOB1) NETID(XNET) NETREL(XJOB2,XJOB3) HOLD


BDT Q JOBNAME(XJOB2) NETID(XNET) NETHOLD(1) NETREL(XJOB3)FROM DATASET(CDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

BDT Q JOBNAME(XJOB3) NETID(XNET) NETHOLD(2)FROM DATASET(DDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(BDATA) LOCATION(BNODE) MOD

NEW — Specify That the “To” Data Set Is NewUse this parameter to indicate to MVS that the “to” data set is a new data set to beallocated in the transaction.

Your BDT subsystem will have exclusive use of the data set while the transactionis being processed.

RulesOptional or Required: Required for new “to” data sets

NETREL


Also Requires: The BLKSIZE, LRECL, RECFM, UNIT, and VOLUME parameters. Ifthe data set is a DASD data set, NEW also requires the SPACE parameter, andeither the BLOCK, CYLINDERS, or TRACKS parameter. If the data set is a PDS,NEW also requires the DIR parameter.

Section: TO

DAP: SEQ, PDS

FormatNEW is one of four data set status parameters that can be specified in the TOsection of a transaction. All four are shown and explained subsequently. Use onlyone in the TO section of a transaction.

►► NEW ►◄

►► MOD ►◄

►► OLD ►◄

►► SHR ►◄

Used in the TO section of a transaction,

NEWspecifies that the “to” data set is a new data set to be allocated in thetransaction. This parameter gives your BDT subsystem exclusive us of the “to”data set.

MODspecifies that the “to” data set is an existing data set, and that the copied dataset is to be added to it. This parameter gives your BDT subsystem exclusive usof the “to” data set.

OLDspecifies that the “to” data set is an existing data set, and that the copied dataset is to overwrite it. This parameter gives your BDT subsystem exclusive useof the data set.


SHRspecifies that the “to” data set is an existing data set and that other users mayshare the use of it with your BDT subsystem.

Usage Notes1. When allocating a new sequential data set, you may be able to accept defaults

and omit the SPACE parameter, and the BLOCK, CYLINDERS, or TRACKSparameter. Defaults are provided as part of the MVS product; they may havebeen modified at your installation.

NEW


2. You may want to use the BDTENQ parameter to indicate to BDT whether adata set can be shared by other BDT transactions. The default value for theBDTENQ parameter is exclusive use of the “to” data set. See the BDTENQparameter for more information.

3. Use only one of the four data set status parameters in the TO section of atransaction.

4. If you do not specify a data set disposition, using the DISP parameter, thesystem catalogs and keeps the new “to” data set after the transactioncompletes.

5. For a list of parameters that can be used to allocate new data sets, seeAppendix A, “Parameters That Require Other Parameters,” on page 89.

Examples1. Copy the existing data set, BOBSDATA, to a new data set, JOESDATA. Use the

TSO prefix (BDT).BDT Q FROM DATASET(BOBSDATA) OLD LOCATION(BOBSNODE) DAP(SEQ)

TO DATASET(JOESDATA) LOCATION(JOESNODE)NEW SPACE(1,1) TRACKS UNIT(SYSDA)BLKSIZE(800) LRECL(80) RECFM(FB)VOLUME(111111)

2. Copy a DASD data set named DATA.ONE to a new tape data set namedDATA.TWO.BDT Q FROM DATASET(DATA.ONE) UNIT(3380) VOLUME(11111)

LOCATION(NODEONE) DAP(SEQ)TO DATASET(DATA.TWO) NEWRECFM(F) LRECL(80) BLKSIZE(800)UNIT(TAPE) LABEL(SL)VOLUME(22222)

OLD — Specify Exclusive Use of an Existing Data SetUse this parameter to indicate to MVS that a data set already exists, and that youwant your BDT subsystem to have exclusive use of the data set while thetransaction is being processed.


Section: FROM, TO

DAP: SEQ, PDS

FormatOLD is one of two data set status parameters that can be specified in the FROMsection of a transaction. In addition, OLD is one of four data set status parametersthat can be specified in the TO section of a transaction. The options for the FROMand TO sections are explained separately subsequently.

FROM Options:

►► OLD ►◄

NEW


►► SHR ►◄

Use only one of the options in the FROM section of a transaction.

OLDspecifies that the “from” data set is an existing data set, and that your BDTsubsystem has exclusive use of the data set while the transaction is beingprocessed.

SHRspecifies that the “from” data set is an existing data set and that other usersmay share the use of it with your BDT subsystem. This is the default for the“from” data set.

TO Options:

►► OLD ►◄

►► SHR ►◄

►► MOD ►◄

►► NEW ►◄

Use only one of the options in the TO section of a transaction.

OLDspecifies that the “to” data set is an existing data set, and that the copied dataset is to overwrite it. This parameter gives your BDT subsystem exclusive useof the data set while the transaction is being processed.



MODspecifies that the “to” data set is an existing data set and that the copied dataset is to be added to it. This parameter gives your BDT subsystem exclusive usof the “to” data set.

NEWspecifies that the “to” data set is a new data set to be allocated in thetransaction. This parameter gives your BDT subsystem exclusive us of the “to”data set.

Usage NoteYou may want to use the BDTENQ parameter to indicate to BDT whether a dataset can be shared by other BDT transactions. The default value for the BDTENQparameter is exclusive use of the “to” data set. See the BDTENQ parameter formore information.

OLD


ExampleCopy an existing data set, IDATA, to another existing data set, JDATA, and specifyexclusive use of both data sets while the transaction is being processed. Use theJES3 prefix (*S,BDT).*S,BDT Q FROM DATASET(IDATA) LOCATION(INODE) DAP(SEQ) OLD

TO DATASET(JDATA) LOCATION(JNODE) OLD

PARALLEL — Specify Parallel Mounting of VolumesUse this parameter to indicate that an existing data set occupies more than onevolume and that each volume is to be mounted on a separate device.


Also Requires: The VOLUME parameter, with a volume serial for each volume

Section: FROM, TO

DAP: SEQ, PDS

Format

►► PARALLEL ►◄

Usage Notes1. All volumes of the data set must be mounted before BDT will execute your

transaction.2. If you use the UNIT parameter together with this parameter, do not specify a

unit address with the UNIT parameter.

ExampleCopy the data set DATA.AAA to the multi-volume data set DATA.BBB, and specifythat each volume of DATA.BBB is to be mounted on a separate device. Use theTSO prefix (BDT).BDT Q FROM LOCATION(SYSA1)

DATASET(DATA.AAA) DAP(SEQ) SHRTO LOC(SYSA2)DATASET(DATA.BBB) OLD VOLUME(BDTDS8,BDTDS9)PARALLEL

PARMS — Select Messages, Pad Logical Records, and Select,Rename, or Replace PDS Members

Use the PARMS parameter to:v Select the type of messages you want to receive about a transaction.v Define a padding character when copying sequential data sets. BDT uses this

padding character to pad the “to” data set when the logical record length of the“to” data set is larger than the logical record length of the “from” data set.

v Select the members of the “from” PDS to copy, and specify whether to replace orrename the members in the “to” data set.

OLD


Each of these options will be discussed separately. When using the PARMSparameter, however, you can combine the MSG and PAD options. See the examplesfor an illustration of this.

PARMS(MSG) — Select the Type of Messages You ReceiveAbout a Transaction


Section: If used with DAP(SEQ), this parameter can be used in either the FROM orTO sections; if used with DAP(PDS), this parameter can be used in the TO section

DAP: SEQ, PDS

Format

►► PARMSPARMUSER

(MSG= A )S

►◄

MSG=Aspecifies that you wish to receive all messages.

MSG=Sspecifies that you wish to receive status messages only. This is the default.

Usage Notes1. You might want to use PARMS(MSG) to reduce the number of messages you

get when your transaction completes.2. Do not confuse the PARMS(MSG) parameter with the MSGCLASS parameter

that stands alone. The MSGCLASS parameter directs messages to a particulardestination; the PARMS(MSG) parameter controls the type of messages that aresent to you.

PARMS(PAD) — Pad Logical Records in the TO Data Set


Section: TO

DAP: SEQ

Format

►► PARMSPARMUSER

(PAD= C'x‘ )X‘nn'nnn

►◄

PARMS


PAD=C‘x’specifies that the EBCDIC character x is to be used for padding. x can be anyEBCDIC character or a blank. The quotation marks are required.

PAD=X‘nn’specifies that the hexadecimal number nn is to be used for padding. Thenumber nn can be 1 or 2 digits, in the range from 0 to FF. The quotation marksare required. Leading zeroes are not required. Hex 40 will pad each line withEBCDIC blanks.

PAD=nnnspecifies that the decimal number nnn is to be used for padding. nnn can be 1to 3 digits, in the range from 0 to 255.

If you do not specify a padding character, each record in the “to” data set that islonger than the record sent from the “from” data set is padded with binary zeros(hex 00).

PARMS(R,S,E, or M) — Select, Rename, or Replace PDSMembers


Section: FROM

DAP: PDS

Format

►► PARMSPARMUSER(

►

► ▼ ▼

▼

▼

▼

, ,

R=Y SELECT , M = ( mem ) R=Y SELECT , M = ( mem )S S ,EXCLUDEE ( mem,rename )

,

( mem,rename,R ),

( mem,,R )

) ►◄

R=Yspecifies that members of the “to” data set are to be replaced by members withthe same member names from the “from” data set.

Used alone, R=Y copies the entire PDS, and replaces all members of the “to”data set with members of the “from” data set that have the same membernames.

Used with S (SELECT), R=Y copies and replaces those members of the PDSthat are selected. Used with E (EXCLUDE), R=Y copies and replaces allmembers of the PDS except those that are excluded. If you use R=Y with eitherS (SELECT) or E (EXCLUDE), you must specify R=Y first.

PARMS


S or SELECTselects members of the PDS to be copied, copied and renamed, or copied,renamed and replaced, as indicated by R and M.

E or EXCLUDEexcludes (prevents) members of the PDS from being copied and replaced.

M begins the list of members to be selected or excluded.

memis the member to be selected or excluded. If you list only one member, youmay omit the parentheses.

The maximum number of members you may specify is 230.

(mem,rename)assigns a new name, rename, in the “to” data set to the member named memwhen mem is copied from the “from” data set. If there is already a membernamed rename in the “to” data set, it is not affected unless you use R=Y. Ifthere is already a member named mem in the “to” data set, it is not affected.

Use this only with SELECT.

(mem,rename,R)assigns a new name, rename, in the “to” data set to the member named memwhen mem is copied from the “from” data set. If there is already a membernamed rename in the “to” data set, it is replaced. If there is already a membernamed mem in the “to” data set, it is not affected.


(mem,,R)replaces the member named mem in the “to” data set with the member namedmem from the “from” data set.

Use this to replace individual members of a PDS.


Usage Notes1. Do not use both SELECT and EXCLUDE.2. If you want to use SELECT or EXCLUDE to copy members with aliases

(alternate names), you must specify each alias you want to select or exclude.When the primary member and its aliases are copied, the primary member inthe “from” data set becomes the primary member in the “to” data set.

3. If only aliases are copied, the member that is the lowest in the sorting ordersequence becomes the primary in the “to” data set.

4. If only one alias is specified, it alone is copied and it becomes the primary inthe “to” data set.

Examples1. Copy the data set FEBDATA to the data set MARDATA and ask to receive only

status messages about the transaction. Use the TSO prefix (BDT).BDT Q FROM DATASET(FEBDATA) LOCATION(ANODE) OLD DAP(SEQ)

TO DATASET(MARDATA) LOCATION(BNODE) OLDPARMS(MSG=S)

2. Copy the data set XDATA to the data set YDATA, and pad YDATA with blanks.BDT Q FROM DATASET(XDATA) LOCATION(XNODE) OLD DAP(SEQ)

TO DATASET(YDATA) LOCATION(YNODE) OLDPARMS(PAD=C’ ’)

PARMS


3. Copy the data set FEBDATA to the data set MARDATA, pad MARDATA withblanks, and ask to receive only status messages about the transaction.BDT Q FROM DATASET(FEBDATA) LOCATION(ANODE) OLD DAP(SEQ)

TO DATASET(MARDATA) LOCATION(BNODE) OLDPARMS(MSG=S,PAD=C’ ’)

4. Copy members MEM1 and MEM2 of the PDS PDSDATA to the PDS PDDATA.BDT Q FROM DATASET(PDSDATA) LOCATION(KGN02) OLD DAP(PDS)

PARMS(S M=(MEM1,MEM2))TO DATASET(PDDATA) LOCATION(KGN03) OLD

PASSWORD — Supply a Password for a Password-Protected Data SetUse this parameter to provide the password for a password-protected data set.

RulesOptional or Required: Required for password-protected data sets

Also Requires: The LABEL parameter for new data sets

Section: FROM, TO

DAP: SEQ, PDS

Format

►► PASSWORDPSWD

(pswd) ►◄

pswdis the password. The password may be 1 to 8 alphanumeric characters.

Usage Notes1. You cannot use this parameter to assign a password.2. The passwords for the “to” and “from” data sets, if both are

password-protected, may be different.3. See the SECGROUP, SECPSWD, and SECUSER parameters for information on

supplying RACF security information.

ExampleCopy the data set PASSDATA to the data set SECDATA. Both data sets arepassword protected. Use the TSO prefix (BDT).BDT Q FROM DATASET(PASSDATA) LOCATION(KGN01) DAP(SEQ)

PASSWORD(3ED4RF)TO DATASET(SECDATA) LOCATION(KGN02)PASSWORD(CFTGY7)

POSITION — Specify the Position of a Data Set on a Tape VolumeUse this parameter to tell MVS the relative position of a data set on a tape volumethat contains multiple data sets.

PARMS


RulesOptional or Required: Required for tape transfers if the data set is not catalogedand there are multiple files on the volume

Section: FROM, TO

DAP: SEQ

Format

►► POSITIONPOSFILEFILESEQ

(seq-no) ►◄

seq-nois the file sequence number. seq-no may be any decimal number from 1 to 9999.If you do not specify this parameter, MVS assumes that the data set is the firstdata set on the volume.

ExampleCopy the data set DATA.AAA to the data set DATA.BBB. Data set DATA.BBB isstored on a tape volume that contains several other data sets. Specify that the filesequence number of DATA.BBB is 2. Use the TSO prefix (BDT).BDT Q FROM LOCATION(SYSA1)

DATASET(DATA.AAA) DAP(SEQ) SHRTO LOCATION(SYSA2)DATASET(DATA.BBB) OLDPOSITION(2) UNIT(TAPE)VOLUME(111111)

PRIORITY — Assign a Priority to a JobUse this parameter to assign a BDT scheduling priority to the BDT job that resultsfrom a transaction. For jobs going to the same destination, BDT schedules higherpriority jobs before lower priority jobs.



DAP: SEQ, PDS

Format

►► PRIORITYPRTY

(priority) ►◄

priorityis the priority to be assigned to the job. Priorities range from 0 to 15, with 15the highest priority. If you do not specify this parameter a priority of 4 isassumed.

POSITION


Usage NoteYour installation may restrict you to a limited range of priorities. Check with thesystem programmer.

ExampleCopy a data set to another data set and assign a priority of 8 to the BDT job thatperforms the copying. Use the TSO prefix (BDT).BDT Q JOB(MYJOB) PRIORITY(8)

FROM DATASET(ADATA) LOCATION(KGN01) DAP(SEQ)TO DATASET(BDATA) LOCATION(KGN02)

PROGRAMMER — Supply a Programmer’s NameUse this parameter to supply a name or identification with your transaction, to beused with your installation’s accounting routines.



DAP: SEQ, PDS

Format

►► PROGRAMMERPGMRNAME

(name) ►◄

nameis the name or other identification to be supplied. This information may be upto 20 characters long, and may include any EBCDIC character.

ExampleCopy a data set to another data set and supply your name with the transaction.Use the TSO prefix (BDT).BDT Q PGMR(BROMLEY)

FROM DATASET(DDATA) LOCATION(ANODE) DAP(SEQ)TO DATASET(EDATA) LOCATION(BNODE)

PROTECT — Provide RACF Protection for a New Data SetUse this parameter to provide RACF protection for a newly created data set.


Section: TO

DAP: SEQ, PDS

PRIORITY


Format

►► PROTECT ►◄

Usage Notes1. If you use this parameter, your installation must have RACF Release 1.6 or

higher or the transaction will fail.2. If you use PROTECT with an existing data set an allocation error will occur.3. For more information, see the PROTECT keyword in theJCL manual that is

appropriate for your installation.

ExampleCopy an existing data set, BOBSDATA, to a new data set, JOESDATA, and RACFprotect JOESDATA. Use the TSO prefix (BDT).BDT Q FROM DATASET(BOBSDATA) OLD LOCATION(BOBSNODE)

DAP(SEQ)TO DATASET(JOESDATA) LOCATION(JOESNODE)PROTECT NEW VOLUME(KGN02)SPACE(1,1) CYL UNIT(SYSDA)BLKSIZE(800) LRECL(80) RECFM(F)

RECFM — Specify the Record Format of a Data SetUse this parameter to tell BDT the record format of a data set.

RulesOptional or Required: Required on uncataloged data sets and new data sets

Section: TO

DAP: SEQ, PDS

Format

PROTECT


►► RECFM ( U

TAM

F

BSTBSBTBSTAM

V

BSTBSBTBSTAM

) ►◄

A specifies that records contain ANSI device control characteristics.

B specifies that the records are blocked.

F specifies that the records are fixed-length.

M specifies that the records contain machine code control characteristics.

S specifies that the records are standard blocks of fixed length or spanned blocksof variable length.

T specifies that, if required, records may be written onto overflow tracks.

U specifies that the records are of an undefined length. This is the default.

V specifies that the records are variable length non-ASCII.

Usage NoteDo not code RECFM in the FROM section. If you do so and the data set’s datacontrol block (DCB) information is incompatible with the information contained inthe RECFM parameter, the transaction will fail.

ExampleCopy the data set BDATA to a new data set, CDATA. Specify a record format ofvariable length non-ASCII for CDATA. Use the TSO prefix (BDT).BDT Q FROM DATASET(BDATA) DAP(PDS) LOCATION(NODEB)

TO DATASET(CDATA) LOCATION(NODEC) NEWRECFM(V) LRECL(255) BLKSIZE(259) DIR(12)SPACE(1,2) CYL DSORG(PO) VOLUME(111111)BUFL(4096) UNIT(3380)

RECFM


RELEASE — Release Unused Space in a New DASD Data SetUse this parameter to release unused space in a new “to” data set that is on adirect access storage device (DASD). The space is to be released after thetransaction has completed.



Section: TO

DAP: SEQ, PDS

Format

►► RELEASERLSE

►◄

Usage Notes1. Using this parameter helps make efficient use of DASD space. Use it when you

may have asked for more space than is needed for a new data set.2. Do not use this parameter for tape data sets.3. If you code this parameter in the FROM section, BDT will accept the parameter



ExampleCopy a data set to a new sequential DASD data set, and release unused directaccess space in the new data set after the transaction is completed. Use the TSOprefix (BDT).BDT Q FROM DATASET(ONEDATA) LOCATION(ONENODE) DAP(SEQ)

TO DATASET(TWODATA) LOCATION(TWONODE)NEW SPACE(1,1) CYL BLKSIZE(800)LRECL(80) RECFM(FB) UNIT(3350)RELEASE VOLUME(111111)

RETPD — Specify a Retention Period for a Data SetUse this parameter to specify a retention period of a certain number of days for adata set. The data set cannot be written over or deleted until the retention periodhas ended.


Also Requires: The LABEL parameter for new data sets

Section: TO

RELEASE


DAP: SEQ, PDS

Format

►► RETPD(days) ►◄

daysis the number of days the data set is to be protected from being written overor deleted. days may be any decimal number from 0 to 9999.

Usage Notes1. If you want to protect a data set from being written over or deleted before a

certain date, use the EXPDT parameter.2. If you code the RETPD parameter in the FROM section, BDT will accept the

parameter but will not use it.3. For more information about the use of RETPD, see the JCL manual that is

appropriate for your installation.

ExampleCopy the data set MYDSN to the data set THATDSN and assign a retention periodof 100 days to THATDSN. Use the TSO prefix (BDT).BDT Q FROM DATASET(MYDSN) LOCATION(MYNODE) DAP(SEQ)

TO DATASET(THATDSN) LOCATION(THATNODE)RETPD(100)

ROUND — Allocate Space in Whole CylindersUse this parameter when allocating a new “to” data set that is to be stored on adirect access storage device (DASD). This parameter requests that MVS allocatedirect access space for the data set in whole cylinder increments, rounding up tothe next full cylinder where necessary.



Section: TO

DAP: SEQ, PDS

Format

►► ROUNDRND

►◄

Usage Notes1. If you code the ROUND parameter in the FROM section, BDT will accept the

parameter but will not use it.

RETPD



ExampleCopy a data set to a new data set. Allocate space for the new data set in tracks, butrequest that the space be rounded up to a whole cylinder. Use the TSO prefix(BDT).BDT Q FROM DATASET(SMP.DATA) LOCATION(SMPNODE) DAP(SEQ)

TO DATASET(NEW.DATA) LOCATION(SMNODE)NEW SPACE(12,1) BLKSIZE(2660) LRECL(133) RECFM(VB)TRACKS ROUND UNIT(SYSDA)VOLUME(11111) DISP(CATLG,DELETE)

SECGROUP — Supply a Security Group ID for a Data Set That IsProtected with RACF

Use this parameter to supply your RACF group ID when accessingRACF-protected resources.


Section: FROM, TO

DAP: SEQ, PDS

Format

►► SECGROUPSECGSG

( (group-id) )*

►◄

* with RACF Release 1.6 or later, will cause BDT to use the default user ID orpassword or both if they are not coded with the SECUSER and SECPSWDparameters.

group-idis the RACF group ID (1 to 8 alphanumeric characters).

If you do not specify this parameter, a default group ID will be provided:v If you are at an MCS or JES3 console, the default is provided by user exit

BDTUX19. User exit BDTUX19 is described in z/OS BDT Installation.v If you are at a TSO terminal, the default is the group name you used to log on

to the system.v If you are running a batch job, the default is the group ID you specified on the

JOB card.

ExampleCopy the RACF-protected data set MYDSN to the RACF-protected data setYOURDSN, supplying RACF group IDs to access the data sets. Use the TSO prefix(BDT).

ROUND


BDT Q FROM DATASET(MYDSN) LOCATION(KGN01) DAP(SEQ)SECGROUP(MYGROUP)TO DATASET(YOURDSN) LOCATION(KGN02)SECGROUP(YOURGROUP)

SECPSWD — Supply a Security Password for a Data Set That IsProtected with RACF

Use this parameter to supply the password for a RACF-protected data set.


Section: FROM, TO

DAP: SEQ, PDS

Format

►► SECPSWDSECCPSP

( (password) )*

►◄

* Will cause BDT to use the default user ID or group ID or both if they are notspecified with the SECUSER and SECGROUP parameters.

passwordis the password for the data set (1 to 8 alphanumeric characters).

If you do not specify this parameter, a default password will be provided for adata set that is at the node where you submit the transaction:v If you are at a TSO terminal, the default is your logon password.v If you are running a batch job, the default is the password you specified on the

JOB card.

You must use SECPSWD(*) to request the default password for a data set that is atanother node.

Usage Notes1. You cannot use this parameter at an MCS or JES3 console.2. Passwords may be encrypted if:v Your installation has defined an encryption algorithm in user exit BDTUX19.Both the “from” and “to” nodes must support the same encryption algorithmin order for the password to be encrypted. See your system programmer forfurther information.

3. If you code your user ID with the SECUSER parameter, do not default yourgroup ID by using the asterisk (*) in the SECGROUP parameter, and do notcode the password in the SECPSWD parameter, BDT will default the passwordto blanks. See the preceding figure.

If you code this for theSECUSER parameter:

And code this for theSECGROUP parameter:

The default for SECPSWDwill be:

(user ID) (user ID) blanks

SECGROUP


If you code this for theSECUSER parameter:

And code this for theSECGROUP parameter:

The default for SECPSWDwill be:

(user ID) (*) default

(user ID) blanks

ExampleCopy the data set MYDSN to the data set YOURDSN, both of which areRACF-protected. Supply the passwords with the SECPSWD parameter. Use theTSO prefix (BDT).BDT Q FROM DATASET(MYDSN) LOCATION(SPK01) DAP(SEQ)

SECPSWD(MYPSWD)TO DATASET(YOURDSN) LOCATION(SPK02)SECPSWD(YOURPSWD)

SECUSER — Supply a Security User ID for a Data Set That IsProtected with RACF

Use this parameter to supply your user security ID for RACF-protected data sets.


Section: FROM, TO

DAP: SEQ, PDS

Format

►► SECUSERSECUSU

( (user-id) )*

►◄

* with RACF Release 1.6 or later, will cause BDT to use the default password orgroup ID or both if they are not specified with the SECPSWD and SECGROUPparameters.

user-idis your user security ID (1 to 8 alphanumeric characters).

If you do not specify this parameter, a default user ID will be providedautomatically for a data set that is at the node where you submit thetransaction:v If you are at an MCS or JES3 console, the default will be provided by user

exit BDTUX19. User exit BDTUX19 is described in z/OS BDT Installation.v If you are at a TSO terminal, the default is your logon user ID.v If you are running a batch job, the default is the user ID you specified on

the JOB card.

You must use SECUSER(*) to request the default value for a data set that islocated at another node.

SECPSWD


Usage NoteWith RACF Release 1.6 or later, requesting the default by coding SECUSER(*)causes BDT to use the default value contained in the BTUDEFU text unit forSECUSER.

ExampleCopy the data set MYDSN to the data set YOURDSN. Both data sets areRACF-protected. Supply your security ID with the SECUSER parameter. Use theTSO prefix (BDT).BDT Q FROM DATASET(MYDSN) LOCATION(KGN01) DAP(SEQ)

SECUSER(MYUSERID)TO DATASET(YOURDSN) LOCATION(KGN02)SECUSER(YOURUSERID)

SHR — Permit Shared Use of a Data SetUse this parameter to indicate to MVS that the data set exists and that otheraddress spaces within MVS, in addition to your BDT subsystem, may share the useof the data set.


Section: FROM, TO

DAP: SEQ, PDS

FormatSHR is one of two data set status parameters that can be specified in the FROMsection of a transaction. In addition, SHR is one of four data set status parametersthat can be specified in the TO section of a transaction. The options for the FROMand TO sections are discussed separately in the preceding section.

FROM Options:

►► OLD ►◄

►► SHR ►◄

Use only one of the options in the FROM section of a transaction.

SHRspecifies that the “from” data set is an existing data set and that other usersmay share the use of it with your BDT subsystem while the transaction isbeing processed. This is the default for the “from” data set.

OLDspecifies that the “from” data set is an existing data set, and that your BDTsubsystem has exclusive use of the data set while the transaction is beingprocessed.

SECUSER


TO Options:

►► OLD ►◄

►► SHR ►◄

►► MOD ►◄

►► NEW ►◄

Use only one of the options in the TO section of a transaction.


OLDspecifies that the “to” data set is an existing data set, and that the copied dataset is to overwrite the existing data set. This parameter gives your BDTsubsystem exclusive use of the data set.


MODspecifies that the “to” data set is an existing data set, and that the copied dataset is to be added to it. This parameter also gives your BDT subsystemexclusive use of the “to” data set.

NEWspecifies that the “to” data set is a new data set to be allocated in thetransaction. This parameter also gives your BDT subsystem exclusive use of the“to” data set.

ExampleCopy the data set PDS1.AA to the data set PDS2.BB. Both are existing data sets.Request shared use of PDS1.AA and exclusive use of PDS2.BB. Use the TSO prefix(BDT).BDT Q FROM DATASET(PDS1.AA) LOCATION(THISNODE)

DAP(PDS) SHRTO DATASET(PDS2.BB) LOCATION(OTHRNODE) OLD

SPACE — Request Space for a New Data SetUse this parameter to request primary and secondary space for a new data setstored on a direct access storage device (DASD).

RulesOptional or Required: Required for new DASD data sets

Also Requires: The NEW parameter and either the BLOCK, CYLINDERS, orTRACKS parameter

Section: TO

SHR


DAP: SEQ, PDS

Format

►► SPACE (primary ),secondary

►◄

primaryis the amount of primary space to be allocated to the data set. primary may bea number from 0 to 999999, depending on the limits at your installation.

secondaryis the amount of secondary space to be allocated to the data set. secondary maybe a number from 1 to 999999, depending on the limits of your installation.Secondary space is space to be used only if the data set exceeds the primaryspace.

Usage Notes1. Specify the units of primary and secondary space by coding another parameter

with the SPACE parameter:v Use the BLOCK parameter to allocate the space in blocks.v Use the CYLINDERS parameter to allocate the space in cylinders.v Use the TRACKS parameter to allocate the space in tracks.

2. This parameter is invalid with the OLD, MOD, or SHR parameters.3. Do not use this parameter for data sets stored on tape.4. For a list of parameters that can be used to allocate a new data set, see


ExampleCopy the data set BDATA to a new data set, CDATA. Specify primary space of 1and secondary space of 2. Use the CYLINDERS parameter to specify cylinder units.Use the TSO prefix (BDT).BDT Q FROM DATASET(BDATA) DAP(PDS) LOCATION(NODEB)

TO DATASET(CDATA) LOCATION(NODEC) NEWSPACE(1,2) LRECL(255) BLKSIZE(259) RECFM(V)DIR(12) CYLINDERS DSORG(PO) VOLUME(111111)DISP(KEEP,DELETE) UNIT(3380)BUFL(4096)

SYSTEM — Specify the BDT Node in a Poly-BDT ComplexUse this parameter in a poly-BDT complex to identify the BDT node on which youwish to have your transaction executed.

RulesOptional or Required: Optional, unless you want the transaction to be executed ata node other than the node that has been defined as the default for yourinstallation

Section: Job Definition, FROM, TO

DAP: SEQ, PDS

SPACE


Format

►► SYSTEMSYSSY

(node-name) ►◄

node-nameis the name of the BDT node at which the transaction is to be executed. If youdo not specify this parameter, the node that has been defined as the default foryour installation is assumed. Contact your system programmer for the name ofthe default node and for a list of valid node names.

Usage NoteThis parameter cannot be used in a transaction definition stored in a GMJD library.

Examples1. Submit a transaction from a TSO terminal in a poly-BDT complex. Request that

the transaction be executed at node BDT01.BDT SY(BDT01) Q FROM DATASET(BIGDATA) LOCATION(KGN01)

DAP(SEQ)TO DATASET(LITDATA) LOCATION(KGN02)

2. Submit a transaction from a JES3 console in a poly-BDT complex. Request thatthe transaction be executed at node BDT01.*S,BDT SY(BDT01) Q FROM DATASET(BIGDATA) LOCATION(KGN01)

DAP(SEQ)TO DATASET(LITDATA) LOCATION(KGN02)

TIME — Specify the Maximum Processor Time for a TransactionUse this parameter to put a maximum on the amount of processor time you wishto allow your transaction to use. If your transaction exceeds the maximum, BDTwill remove it from the system.



DAP: SEQ, PDS

Format

►► TIME (minutes ),seconds

►◄

minutesis the minutes of processor time the transaction is to be allowed. minutes can beany integer up to 1440.

secondsis the seconds of processor time the transaction is to be allowed. seconds can befrom 1 to 59.

SYSTEM


If you do not specify this parameter, a maximum processor time of 4 minutes isassumed.

Usage Notes1. Use this parameter if you suspect that there are problems that will cause your

transaction to use an excessive amount of processor time.2. BDT will remove a transaction from the system when it exceeds its time limit,

even if the data transfer is only partially completed.

ExampleCopy the data set ONEDATA to the data set TWODATA, and set a maximumprocessor time for the transaction of 15 minutes. Use the JES3 prefix (*S,BDT).*S,BDT Q TIME(15) FROM DATASET(ONEDATA) LOCATION(ONENODE)

DAP(SEQ)TO DATASET(TWODATA) LOCATION(TWONODE)

TO — Begin the TO SectionUse this parameter to mark the beginning of the TO section in the transaction. Theparameters following TO describe the “to” node and data set.

RulesOptional or Required: Required

Section: TO

DAP: SEQ, PDS

Format

►► TO ►◄

Usage Notes1. See Chapter 1, “Writing and Submitting File-to-File Transactions,” on page 1 for

general information on the TO section.2. You may use the FROM or TO parameters more than once in a transaction.

Each time you use the FROM parameter, you must use a TO parameter if youwant to add parameters that belong in the TO section.

3. Once BDT finds the TO parameter, all parameters that are not job definitionparameters are assumed to be TO parameters unless the FROM parameter isused to begin more FROM parameters.

Examples1. Copy the data set TRYDATA to the data set SETDATA, which is located at node

BNODE. Use the TSO prefix (BDT).BDT Q FROM DATASET(TRYDATA) LOCATION(ANODE) DAP(SEQ)

TO DATASET(SETDATA) LOCATION(BNODE)

2. Copy the data set TRYDATA to the data set SETDATA. Break the FROM andTO sections of the transaction into several parts.

TIME


BDT Q FROM DATASET(TRYDATA) DAP(SEQ)TO DATASET(SETDATA)FROM LOCATION(ANODE)TO LOCATION(BNODE)

TRACKS — Allocate Space for a New Data Set in Track UnitsUse this parameter when allocating a new “to” data set that is to be stored on adirect access storage device (DASD). This parameter requests that space for thenew data set be allocated in track units.



Section: TO

DAP: SEQ, PDS

►► TRACKSTRK

►◄

Usage Notes1. This parameter is invalid with the BLOCK and CYLINDERS parameters.2. For a list of parameters that can be used to allocate a new data set, see


ExampleCopy the data set BSET to a new data set DSET, and allocate space for the newdata set in track units. Use the TSO prefix (BDT).BDT Q FROM DATASET(BSET) LOCATION(KGN01) DAP(SEQ)

TO DATASET(DSET) LOCATION(KGN02)NEW SPACE(1,1)TRACKS UNIT(SYSDA) VOLUME(111111)BLKSIZE(800) LRECL(80) RECFM(F)

TRTCH — Specify the Translation Technique for TapeUse this parameter to indicate the translation technique for 7-track tape.


Section: FROM, TO

DAP: SEQ

Format

TO


►► TRTCH ( CE

TT

) ►◄

C specifies data conversion with odd parity and no translation.

E specifies even parity with no translation and no conversion.

T specifies odd parity with no conversion. When reading, BCD is to be translatedto EBCDIC; when writing, EBCDIC is to be translated to BCD.

ET specifies even parity with no conversion. When reading, BCD is to betranslated to EBCDIC; when writing, EBCDIC is to be translated to BCD.

ExampleCopy the data set DEPTA, which is on an 800 bpi 7-track magnetic tape, to thenew data set NAMES. For a translation technique, specify even parity with noconversion. Use the TSO prefix (BDT).BDT Q FROM DATASET(DEPTA) LOCATION(KGN01) DAP(SEQ)

UNIT(TAPE7)TO DATASET(NAMES) LOCATION(KGN02)NEW UNIT(TAPE) VOLSER(11111)TRTCH(ET) DEN(2)BLKSIZE(259) LRECL(255)RECFM(V)

UCOUNT — Specify the Unit Count for a Multivolume Data SetUse this parameter to indicate the number of devices to be allocated to amultivolume data set. This parameter does not allocate specific volumes.


Also Requires: The UNIT parameter

Section: TO

DAP: SEQ

Format

►► UCOUNT(units) ►◄

unitsis the number of devices to be allocated. units may be any decimal numberfrom 1 to 59.

Usage Notes1. You might want to use this parameter when allocating scratch tapes.2. This parameter is invalid with the PARALLEL parameter.

TRTCH


ExampleCopy the data set ABA.DATA to the data set ABA.DATB. ABA.DATB is a newDASD data set. Use the TSO prefix (BDT).BDT Q FROM DATASET(ABA.DATA) LOCATION(SYSA1)

DAP(SEQ) SHRTO DATASET(ABA.DATB) LOCATION(SYSA2)UNIT(SYSDA) UCOUNT(1) VOLUME(ABADS8)NEW LRECL(80) BLKSIZE(800) RECFM(F)SPACE(12,1) CYL DSORG(PS) DISP(KEEP,DELETE)

UNIT — Specify the Device on Which a Data Set Is LocatedUse this parameter to identify the device, by unit group name, unit device type, orunit device address, on which a data set is located or is to be allocated.

RulesOptional or Required: Required for new data sets and for uncataloged data sets.

Also Requires: The VOLUME parameter

Section: FROM, TO

DAP: SEQ, PDS

Format

►► UNIT (group name) (device type) (address) ►◄

group nameis the unit group name. Unit group names are defined by your installation.They identify groups of devices that may or may not be all of the same type.

device typeis the unit device type. Unit device types identify devices of a single type, suchas 3350 or 3380 direct access storage devices.

addressis the unit address. Unit addresses are 3-character or 4-character identifiers ofparticular devices. They are defined by your installation.

See your system programmer for valid unit group names, unit device types, andunit addresses.

Usage NoteFor identifying devices for multivolume data sets, see the PARALLEL andUCOUNT parameters.

ExampleCopy the data set DATAA to a new tape data set DATAB. The device type ofDATAA is 3350; the device type of DATAB is TAPE. Use the TSO prefix (BDT).BDT Q FROM DATASET(DATAA) DAP(SEQ)

UNIT(3350) VOLUME(11111)TO DATASET(DATAB) UNIT(TAPE) NEW LABEL(NL)RECFM(F) LRECL(80) BLKSIZE(800) VOLUME(22222)

UCOUNT


VOLREF — Locate a Data Set on the Same Volume as a CatalogedData Set

Use this parameter to locate a data set on the same volume or volumes as acataloged data set.


Section: FROM, TO

DAP: SEQ, PDS

Format

►► VOLREFVREF

(ds-name) ►◄

ds-nameis the name of a cataloged data set. BDT obtains the volume serial number ornumbers for the data set and then uses those numbers to locate another dataset (specified with the DATASET parameter) on the same volume or volumes.

Usage Notes1. This parameter is invalid with the VOLUME parameter.2. If a transaction is entered by a TSO user and the data set name is not enclosed

in single quotation marks, the TSO prefix specified for the user is added as aprefix to the data set name.

ExampleCopy the data set DATA.NOV to the new data set DATA.DEC. Put the new dataset on the same volume as DATA.OCT. Use the TSO prefix (BDT).BDT Q JOB(VOLUME5)

FROM LOC(SYSA1)DA(DATA.NOV) DAP(SEQ) SHRTO LOC(SYSA2)DA(DATA.DEC) NEW LRECL(80) BLKSIZE(80) RECFM(F)SPACE(55) TRK DSORG(PS) DISP(CATLG,DELETE)VOLREF(DATA.OCT)

VOLSEQ — Specify the Volume Sequence NumberUse this parameter to identify which volume of a multivolume data set is to beused to begin processing.


Also Requires: The VOLUME parameter. If the data set is not cataloged, thisparameter also requires the UNIT parameter.

Section: FROM, TO

VOLREF


DAP: SEQ

Format

►► VOLSEQVSEQ

(seq-no) ►◄

seq-nois a number from 0 to 255 that identifies the volume you want used to beginprocessing.

ExampleCopy the data set BDTREG3.KGN1A to the new data set BDTREG3.KGN2A. The“from” data set is a multivolume data set; use the VOLSEQ parameter to specifythat you want to begin processing with volume 0. Use the TSO prefix (BDT).BDT Q FROM DA(BDTREG3.KGN1A) LOC(SYSA1)

DAP(SEQ) SHRVOLUME(BDTDS8) UNIT(3330-1) VOLSEQ(0)TO DA(BDTREG3.KGN2A) LOC(SYSA2)NEW LRECL(133) BLKSIZE(2660) RECFM(VB)SPACE(140) TRK DSORG(PS) DISP(CATLG,DELETE)VOLUME(BDTDS8) UNIT(3350)

VOLUME — Specify a Volume Serial NumberUse the VOLUME parameter to identify the serial number of the volume on whicha data set is located.


Section: FROM, TO

DAP: SEQ, PDS

Format

►► VOLUMEVOLSERVOLVSN

( ▼

,

vol-ser ) ►◄

vol-seris the serial number of the volume on which the data set is located. If you donot specify this parameter, the volume serial number in the data set label isassumed for existing data sets.

Usage NoteIf the “to” data set is a new, multivolume data set, the primary SPACE parametermust specify an amount of space that is equal to or less than the space remainingon the first volume. Otherwise, the transaction will fail.

VOLSEQ


ExampleCopy the data set ONEDATA to the new data set TWODATA. Specify that theserial number of the volume on which TWODATA is to be allocated is 111111. Usethe TSO prefix (BDT).BDT Q FROM DATASET(ONEDATA) LOCATION(KGN01) DAP(PDS)

TO DATASET(TWODATA) LOCATION(KGN02)NEW LRECL(255) BLKSIZE(259) RECFM(V) DIR(12)SPACE(1,2) CYL DISP(KEEP,DELETE)BUFL(4096) DSORG(PO)VOLUME(111111) UNIT(3380)

VOLUME


VOLUME


Appendix A. Parameters That Require Other Parameters

The tables on the following pages provide a quick reference to parameters thatrequire other parameters.

Parameters That Allocate New “To” Data Sets

Parameter Purpose Other Parameters Required

NEW Allocate a new “to” data set BLKSIZE, LRECL, RECFM, UNIT,VOLUME

Also, SPACE, and either BLOCK,CYLINDERS, or TRACKS forDASD data sets

Also, DIR for partitioned data sets

These parameters can be added for DASD data sets:


ALX Allocate the space in severalcontiguous areas

NEW, BLKSIZE, LRECL, RECFM,SPACE and either BLOCK,CYLINDERS, or TRACKS

BUFL Define the size of the buffer in theI/O buffer pool

DIR if the data set is partitioned

CONTIG Allocate the space in a contiguousarea

DCBDS Read DCB information for the newdata set from the label of anexisting data set

DSORG Specify the organization for thenew data set

MXIG Allocate the largest contiguousarea on a volume for the data set

RELEASE Release unused space from thedata set after the transactioncompletes

ROUND Allocate the space in wholecylinders

Parameters That Control DTC Networks


NETCOND Tell BDT what to do if apredecessor transaction fails

NETID

NETHOLD Assign hold counts to transactions NETID

NETREL Name the successor transactions toa transaction

NETID, NETHOLD, JOBNAME


Other Parameters That Require Additional Parameters


DUMMY Specify a dummy data set for the“from” or “to” data set

LRECL, RECFM, and eitherDCBDS or BLKSIZE

EXPDT Assign an expiration date to a dataset

LABEL if the data set is a newdata set

INTRDR Make the “to” data set the MVSinternal reader

BLKSIZE

PARALLEL Specify that an existing data setoccupies more than one volumeand that each volume is to bemounted on a separate device

VOLUME

PASSWORD Supply the password for apassword-protected data set

LABEL if the data set is new

RETPD Assign a retention period to a dataset

LABEL if the data set is new

UCOUNT Specify the number of devices tobe allocated to a multivolume dataset that is not on specific volumes

UNIT

UNIT Identify the device on which adata set is located

VOLUME

VOLSEQ Identify the volume of amultivolume data set with whichto begin processing

VOLUME, and UNIT if the dataset is uncataloged


Appendix B. Accessibility

Accessible publications for this product are offered through IBM KnowledgeCenter (www.ibm.com/support/knowledgecenter/SSLTBW/welcome).

If you experience difficulty with the accessibility of any z/OS® information, send adetailed message to the Contact z/OS web page (www.ibm.com/systems/z/os/zos/webqs.html) or use the following mailing address.

IBM CorporationAttention: MHVRCFS Reader CommentsDepartment H6MA, Building 7072455 South RoadPoughkeepsie, NY 12601-5400United States

Accessibility features

Accessibility features help users who have physical disabilities such as restrictedmobility or limited vision use software products successfully. The accessibilityfeatures in z/OS can help users do the following tasks:v Run assistive technology such as screen readers and screen magnifier software.v Operate specific or equivalent features by using the keyboard.v Customize display attributes such as color, contrast, and font size.

Consult assistive technologiesAssistive technology products such as screen readers function with the userinterfaces found in z/OS. Consult the product information for the specific assistivetechnology product that is used to access z/OS interfaces.

Keyboard navigation of the user interfaceYou can access z/OS user interfaces with TSO/E or ISPF. The followinginformation describes how to use TSO/E and ISPF, including the use of keyboardshortcuts and function keys (PF keys). Each guide includes the default settings forthe PF keys.v z/OS TSO/E Primer

v z/OS TSO/E User's Guide

v z/OS ISPF User's Guide Vol I

Dotted decimal syntax diagramsSyntax diagrams are provided in dotted decimal format for users who access IBMKnowledge Center with a screen reader. In dotted decimal format, each syntaxelement is written on a separate line. If two or more syntax elements are alwayspresent together (or always absent together), they can appear on the same linebecause they are considered a single compound syntax element.

Each line starts with a dotted decimal number; for example, 3 or 3.1 or 3.1.1. Tohear these numbers correctly, make sure that the screen reader is set to read out


http://www.ibm.com/support/knowledgecenter/SSLTBW/welcome

http://www.ibm.com/support/knowledgecenter/SSLTBW/welcome



punctuation. All the syntax elements that have the same dotted decimal number(for example, all the syntax elements that have the number 3.1) are mutuallyexclusive alternatives. If you hear the lines 3.1 USERID and 3.1 SYSTEMID, yoursyntax can include either USERID or SYSTEMID, but not both.

The dotted decimal numbering level denotes the level of nesting. For example, if asyntax element with dotted decimal number 3 is followed by a series of syntaxelements with dotted decimal number 3.1, all the syntax elements numbered 3.1are subordinate to the syntax element numbered 3.

Certain words and symbols are used next to the dotted decimal numbers to addinformation about the syntax elements. Occasionally, these words and symbolsmight occur at the beginning of the element itself. For ease of identification, if theword or symbol is a part of the syntax element, it is preceded by the backslash (\)character. The * symbol is placed next to a dotted decimal number to indicate thatthe syntax element repeats. For example, syntax element *FILE with dotted decimalnumber 3 is given the format 3 \* FILE. Format 3* FILE indicates that syntaxelement FILE repeats. Format 3* \* FILE indicates that syntax element * FILErepeats.

Characters such as commas, which are used to separate a string of syntaxelements, are shown in the syntax just before the items they separate. Thesecharacters can appear on the same line as each item, or on a separate line with thesame dotted decimal number as the relevant items. The line can also show anothersymbol to provide information about the syntax elements. For example, the lines5.1*, 5.1 LASTRUN, and 5.1 DELETE mean that if you use more than one of theLASTRUN and DELETE syntax elements, the elements must be separated by a comma.If no separator is given, assume that you use a blank to separate each syntaxelement.

If a syntax element is preceded by the % symbol, it indicates a reference that isdefined elsewhere. The string that follows the % symbol is the name of a syntaxfragment rather than a literal. For example, the line 2.1 %OP1 means that you mustrefer to separate syntax fragment OP1.

The following symbols are used next to the dotted decimal numbers.

? indicates an optional syntax elementThe question mark (?) symbol indicates an optional syntax element. A dotteddecimal number followed by the question mark symbol (?) indicates that allthe syntax elements with a corresponding dotted decimal number, and anysubordinate syntax elements, are optional. If there is only one syntax elementwith a dotted decimal number, the ? symbol is displayed on the same line asthe syntax element, (for example 5? NOTIFY). If there is more than one syntaxelement with a dotted decimal number, the ? symbol is displayed on a line byitself, followed by the syntax elements that are optional. For example, if youhear the lines 5 ?, 5 NOTIFY, and 5 UPDATE, you know that the syntax elementsNOTIFY and UPDATE are optional. That is, you can choose one or none of them.The ? symbol is equivalent to a bypass line in a railroad diagram.

! indicates a default syntax elementThe exclamation mark (!) symbol indicates a default syntax element. A dotteddecimal number followed by the ! symbol and a syntax element indicate thatthe syntax element is the default option for all syntax elements that share thesame dotted decimal number. Only one of the syntax elements that share thedotted decimal number can specify the ! symbol. For example, if you hear thelines 2? FILE, 2.1! (KEEP), and 2.1 (DELETE), you know that (KEEP) is the


default option for the FILE keyword. In the example, if you include the FILEkeyword, but do not specify an option, the default option KEEP is applied. Adefault option also applies to the next higher dotted decimal number. In thisexample, if the FILE keyword is omitted, the default FILE(KEEP) is used.However, if you hear the lines 2? FILE, 2.1, 2.1.1! (KEEP), and 2.1.1(DELETE), the default option KEEP applies only to the next higher dotteddecimal number, 2.1 (which does not have an associated keyword), and doesnot apply to 2? FILE. Nothing is used if the keyword FILE is omitted.

* indicates an optional syntax element that is repeatableThe asterisk or glyph (*) symbol indicates a syntax element that can berepeated zero or more times. A dotted decimal number followed by the *symbol indicates that this syntax element can be used zero or more times; thatis, it is optional and can be repeated. For example, if you hear the line 5.1*data area, you know that you can include one data area, more than one dataarea, or no data area. If you hear the lines 3* , 3 HOST, 3 STATE, you knowthat you can include HOST, STATE, both together, or nothing.

Notes:

1. If a dotted decimal number has an asterisk (*) next to it and there is onlyone item with that dotted decimal number, you can repeat that same itemmore than once.

2. If a dotted decimal number has an asterisk next to it and several itemshave that dotted decimal number, you can use more than one item from thelist, but you cannot use the items more than once each. In the previousexample, you can write HOST STATE, but you cannot write HOST HOST.

3. The * symbol is equivalent to a loopback line in a railroad syntax diagram.

+ indicates a syntax element that must be includedThe plus (+) symbol indicates a syntax element that must be included at leastonce. A dotted decimal number followed by the + symbol indicates that thesyntax element must be included one or more times. That is, it must beincluded at least once and can be repeated. For example, if you hear the line6.1+ data area, you must include at least one data area. If you hear the lines2+, 2 HOST, and 2 STATE, you know that you must include HOST, STATE, orboth. Similar to the * symbol, the + symbol can repeat a particular item if it isthe only item with that dotted decimal number. The + symbol, like the *symbol, is equivalent to a loopback line in a railroad syntax diagram.

Appendix B. Accessibility 93

Notices

This information was developed for products and services that are offered in theUSA or elsewhere.

IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not grant youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle Drive, MD-NC119Armonk, NY 10504-1785United States of America

For license inquiries regarding double-byte character set (DBCS) information,contact the IBM Intellectual Property Department in your country or sendinquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan Ltd.19-21, Nihonbashi-Hakozakicho, Chuo-kuTokyo 103-8510, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not applyto you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.


This information could include missing, incorrect, or broken hyperlinks.Hyperlinks are maintained in only the HTML plug-in output for the KnowledgeCenters. Use of hyperlinks in other output formats of this information is at yourown risk.

Any references in this information to non-IBM websites are provided forconvenience only and do not in any manner serve as an endorsement of thosewebsites. The materials at those websites are not part of the materials for this IBMproduct and use of those websites is at your own risk.

IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM CorporationSite Counsel2455 South RoadPoughkeepsie, NY 12601-5400USA

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM's future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.


COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs. The sampleprograms are provided "AS IS", without warranty of any kind. IBM shall not beliable for any damages arising out of your use of the sample programs.

Terms and conditions for product documentationPermissions for the use of these publications are granted subject to the followingterms and conditions.

Applicability

These terms and conditions are in addition to any terms of use for the IBMwebsite.

Personal use

You may reproduce these publications for your personal, noncommercial useprovided that all proprietary notices are preserved. You may not distribute, displayor make derivative work of these publications, or any portion thereof, without theexpress consent of IBM.

Commercial use

You may reproduce, distribute and display these publications solely within yourenterprise provided that all proprietary notices are preserved. You may not makederivative works of these publications, or reproduce, distribute or display thesepublications or any portion thereof outside your enterprise, without the expressconsent of IBM.

Rights

Except as expressly granted in this permission, no other permissions, licenses orrights are granted, either express or implied, to the publications or anyinformation, data, software or other intellectual property contained therein.

IBM reserves the right to withdraw the permissions granted herein whenever, in itsdiscretion, the use of the publications is detrimental to its interest or, asdetermined by IBM, the above instructions are not being properly followed.

You may not download, export or re-export this information except in fullcompliance with all applicable laws and regulations, including all United Statesexport laws and regulations.

IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESEPUBLICATIONS. THE PUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUTWARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDINGBUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY,

Notices 97

NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.

IBM Online Privacy StatementIBM Software products, including software as a service solutions, (“SoftwareOfferings”) may use cookies or other technologies to collect product usageinformation, to help improve the end user experience, to tailor interactions withthe end user, or for other purposes. In many cases no personally identifiableinformation is collected by the Software Offerings. Some of our Software Offeringscan help enable you to collect personally identifiable information. If this SoftwareOffering uses cookies to collect personally identifiable information, specificinformation about this offering’s use of cookies is set forth below.

Depending upon the configurations deployed, this Software Offering may usesession cookies that collect each user’s name, email address, phone number, orother personally identifiable information for purposes of enhanced user usabilityand single sign-on configuration. These cookies can be disabled, but disablingthem will also eliminate the functionality they enable.

If the configurations deployed for this Software Offering provide you as customerthe ability to collect personally identifiable information from end users via cookiesand other technologies, you should seek your own legal advice about any lawsapplicable to such data collection, including any requirements for notice andconsent.

For more information about the use of various technologies, including cookies, forthese purposes, see IBM’s Privacy Policy at ibm.com/privacy and IBM’s OnlinePrivacy Statement at ibm.com/privacy/details in the section entitled “Cookies,Web Beacons and Other Technologies,” and the “IBM Software Products andSoftware-as-a-Service Privacy Statement” at ibm.com/software/info/product-privacy.

Policy for unsupported hardwareVarious z/OS elements, such as DFSMS, JES2, JES3, and MVS™, contain code thatsupports specific hardware servers or devices. In some cases, this device-relatedelement support remains in the product even after the hardware devices pass theirannounced End of Service date. z/OS may continue to service element code;however, it will not provide service related to unsupported hardware devices.Software problems related to these devices will not be accepted for service, andcurrent service activity will cease if a problem is determined to be associated without-of-support devices. In such cases, fixes will not be issued.

Minimum supported hardwareThe minimum supported hardware for z/OS releases identified in z/OSannouncements can subsequently change when service for particular servers ordevices is withdrawn. Likewise, the levels of other software products supported ona particular release of z/OS are subject to the service support lifecycle of thoseproducts. Therefore, z/OS and its product publications (for example, panels,samples, messages, and product documentation) can include references tohardware and software that is no longer supported.v For information about software support lifecycle, see: IBM Lifecycle Support for

z/OS (www.ibm.com/software/support/systemsz/lifecycle)


http://www.ibm.com/privacy

http://www.ibm.com/privacy/details

http://www.ibm.com/software/info/product-privacy

http://www.ibm.com/software/info/product-privacy

http://www.ibm.com/software/support/systemsz/lifecycle

http://www.ibm.com/software/support/systemsz/lifecycle

v For information about currently-supported IBM hardware, contact your IBMrepresentative.

TrademarksIBM, the IBM logo, and ibm.com are trademarks or registered trademarks ofInternational Business Machines Corp., registered in many jurisdictions worldwide.Other product and service names might be trademarks of IBM or other companies.A current list of IBM trademarks is available at Copyright and Trademarkinformation (www.ibm.com/legal/copytrade.shtml).

Notices 99

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml

GLOSSARY

This glossary defines important terms andabbreviations used in this book. If you do notfind the term you are looking for, refer to theindex or to the IBM Dictionary of Computing NewYork: McGraw-Hill, 1994.

catalogThe collection of all data set indexes thatis used by the control program to locate avolume containing a specific data set.

checkpoint data setSee TQI checkpoint data set.

DAP Dynamic application program.

dependent transaction control (DTC)A method of controlling the scheduling offile-to-file transactions by organizing thetransactions into a network in whichsome transactions wait for the completionof other transactions before beingscheduled.

DTC Dependent transaction control.

dynamic application program (DAP)A part of BDT that performs a particularfunction, especially the transfer of data.

generic master job definition libraryIn BDT, a data set that containspredefined transaction definitions.

global nodeIn BDT, the node that schedules andmanages all file-to-file transactionsinvolving itself and a local node andresponds to commands issued againstthose transactions.

GMJDGeneric master job definition.

Interactive System Productivity Facility (ISPF)A licensed program that provides menusand data entry panels for using systemfunctions.

ISPF Interactive System Productivity Facility.

JES3 Job entry subsystem 3.

job entry subsystem 3 (JES3)A component of MVS/SP that receivesjobs into the system and processes all

output data produced by the jobs. JES3exerts centralized control over multipleprocessor complexes.

local nodeIn BDT, the node that receives file-to-filetransactions and commands submitted byusers and sends them to the global nodefor processing.

MCS Multiple console support.

multiple console support (MCS)A feature of MVS that permits selectivemessage routing to multiple operator’sconsoles.

networkIn BDT, two or more BDT nodes that arejoined by SNA sessions.

network job entry (NJE)The transmission of jobs, in-stream datasets, operator commands and messages,system output data sets, and jobaccounting information from onecomputer complex to another across atelecommunication link. Synonymouswith job networking.

NJE Network job entry.

node In BDT, the point in a BDT address spacethat is linked to another BDT addressspace for either file-to-file communicationor SNA NJE communication.

poly-BDT complexA JES complex that has more than oneBDT address space.

RACF Resource Access Control Facility.

Resource Access Control Facility (RACF)A licensed program that provides foraccess control by identifying andverifying users to the system, authorizingaccess to DASD data sets, loggingdetected unauthorized attempts to enterthe system, and logging detected accessesto protected data sets.

sessionIn SNA, a logical connection between twonetwork-addressable units. Theconnection can be activated, deactivated,or tailored to provide different protocols.


SNA Systems Network Architecture.

Systems Network Architecture (SNA)The description of the logical structure,formats, protocols, and operationalsequences for transmitting informationunits through and controlling theconfiguration and operation of networks.

Time sharing option (TSO)A component of MVS that providesinteractive computing from remotestations.

TQI Transaction queuing integrity.

TQI checkpoint data setIn BDT, a data set on which thetransaction queuing integrity (TQI) facilityrecords user-submitted commands andfile-to-tile transactions before sendingthem to the BDT address space. Should acommand or transaction fail to reach theBDT address space, BDT automaticallyrecovers it from the TQI checkpoint dataset and attempts the transfer again.

transactionIn BDT, (1) a request to copy a data set,transmit a SNA NJE job, or transmit SNANJE output (SYSOUT), and (2) the workthat BDT does to process the request.Requests to copy data sets are submittedto BDT by users. Requests to transmitSNA NJE jobs and output are submittedto BDT by JES3.

transaction definitionIn BDT, a character string that identifiesthe data set that BDT is to copy, the dataset into which BDT is to write the copieddata set, and parameter values that BDTis to use while copying the data set.

transaction queuing integrityIn BDT, a program that recordscommands and file-to-file transactions ona data set at the submitting node, thusallowing the transfers to be resubmittedautomatically should they not reach theBDT work queue. TQI also allows usersto receive messages.

TSO Time sharing option.

user exitA point in an IBM-supplied program atwhich a user exit routine may be givencontrol.

user exit routineA routine written by a user to take controlat a user exit of a program supplied byIBM.

work queueIn BDT, a queue whose elementsrepresent work that BDT must do onbehalf of a transaction.


Index

Aaccessibility 91

contact IBM 91features 91

accounting information, supplying intransaction 28, 69

ACCT parameter 28adding copied data set to existing data

set 22, 51aliases, of data set members 66allocating space for new data sets 22,

59, 89in block units 31in contiguous areas 28, 32, 54in cylinder units 34, 73in track units 82primary space 78secondary space 78

ALX parameter 28American National Standard labels,

supplying 47ANSI device control characteristics, in

data set records 70assistive technologies 91

Bbatch job submission of transactions 7BDT system log, routing messages to 52BDTENQ parameter 29BLKSIZE parameter 30BLOCK parameter 31block size of data sets, defining 30block units, allocating space in 31buffers for new data sets 32BUFL parameter 32

Ccataloging a data set

defined 101cataloging data sets 40compressing blanks or characters 33contact

z/OS 91CONTIG parameter 32copying data sets, sample transactions

for 21copying a data set from another

node 21copying a data set to another

node 21copying a data set within your

node 21copying from a cataloged partition

data set 22copying from a cataloged sequential

data set 22copying from a DASD data set to a

tape data set 23

copying data sets, sample transactionsfor (continued)

copying from a tape data set to a tapedata set 23

copying to a new PDS 23copying to a new sequential DASD

data set 22CSOPT parameter 33CYL parameter 34cylinders, allocating space in 34, 73

DDA parameter 36DAP parameter 35DASD data sets

allocating space for 59, 78, 89in largest contiguous areas 54in whole cylinders 73maximum number of volumes 49

copying to tape data sets 23devices for 84multivolume 63, 83, 85volume serial numbers for 85, 86

data control block (DCB)information, reading from data set

label 37requesting trace of 38

data set labels 48data sets 1

cataloging 40copying to MVS internal reader 45deleting 40devices for 84disposition of after transaction 40dummies 42exclusive use of, by BDT 61expiration dates of 42label information for 47location of 48, 84, 86multivolume 63

specifying number of devicesfor 83

specifying volume to beginprocessing 85

names of 36organization of 1, 41parallel mounting of 63protecting from being deleted 42, 72protecting from being

overwritten 42, 72relative position of on tape

volume 68repeated characters in,

compressing 33retention period of 72security of 67, 69, 74, 75, 76shared use of, by BDT 77that BDT can copy 1

block sizes of 2locations of 1

data sets (continued)that BDT can copy (continued)

organizations of 1record formats of 1record lengths of 2storage devices of 2

unused space in, releasing 72volume serial numbers of 86

DATASET parameter 36DCB (data control block)

information, reading from data setlabel 37

requesting trace of 38DCBDS parameter 37deleting data sets

after copying 40protection from 42, 72

DEN parameter 38dependent transaction control (DTC)

networks 15assigning transactions to 57conditional release option 55creating 16defined 15, 101examples of 19failed transactions in 18, 55global and local nodes in 17hold counts in 18, 56holding 19holding transactions in 19, 56naming 16parameters for 15predecessor transactions in 16runaway transactions in 19successor transactions in 16, 58

device on which data set is located,specifying 84

DIAGNS parameter 38DIR parameter 39direct access storage device data sets

allocating space for 59, 78, 89in contiguous areas 32in largest contiguous areas 54in whole cylinders 73maximum number of volumes 49

copying to tape data sets 23devices for 84multivolume 63, 83, 85volume serial numbers for 85, 86

directory blocks for PDS, requesting 39DISP parameter 40DS parameter 36DSN parameter 36DSNAME parameter 36DSORG parameter 41DTC networks 15

assigning transactions to 57conditional release option 55creating 16defined 15, 101examples of 16, 19


DTC networks (continued)failed transactions in 18, 55global and local nodes in 17hold counts in 18, 56holding 19holding transactions in 19, 56naming 16parameters for 15predecessor transactions in 16runaway first transactions in 19successor transactions in 16, 58

dummy data set, requesting 42DUMMY parameter 42dynamic application program (DAP) 5

specifying 35

Eexcluding PDS members 65exclusive use of data sets

by a BDT transaction 29by BDT 61

EXPDT parameter 42expiration date, for data sets 42

FFILE parameter 68FILESEQ parameter 68FROM parameter 43FROM section 4, 43

parameters belonging to 4purpose of 4rules for 4

Ggeneration data group (GDG) 36generic master job definition (GMJD)

librariesdefined 101requesting 44

global node, in DTC networks 17global-local relationship of nodes 17glossary 101GMJD libraries

defined 101requesting 44

GMJD parameter 44GMJDLIB parameter 44

Hhold count of transactions in DTC

networks 18, 56HOLD parameter 45holding

DTC networks 19transactions in DTC networks 19transactions, DTC network hold 56transactions, operator hold 45

IIBM standard labels, supplying 47internal reader, copying data sets to 45internal transfer 1INTRDR parameter 45ISPF panels, using 7

JJES3 console, transaction prefix for 3job definition section 4


JOB parameter 46JOBNAME parameter 46jobs

assigning names to 46assigning priorities to 68numbers of 8putting in operator hold 45specifying maximum processor time

for 80

Kkeeping data sets after copying 40

with protection from beingdeleted 42, 72

with protection from beingoverwritten 42, 72

keyboardnavigation 91PF keys 91shortcut keys 91

Llabel information

supplying 47types of 47

LABEL parameter 47LBL parameter 47LOC parameter 48local node, in DTC networks 17location of data sets

on mass storage system 53specifying 48, 84

LOCATION parameter 48log, routing messages to 52logical record length of data sets,

specifying 49logical records, padding 64LRECL parameter 49

Mmachine code control characteristics, in

data set records 70magenetic tape data sets

allocating space for 59magnetic tape data sets

allocating space formaximum number of volumes 49

devices for 84

magnetic tape data sets (continued)multivolume 63, 83, 85position of 68recording density of 38translation technique of 82volume serial numbers for 85, 86

mass storage system (MSS), locating dataset on 53

maximum number of volumes requiredfor data set, specifying 49

MAXVOL parameter 49MBR parameter 50MCS console, transaction prefix for 3member of PDS, specifying

to copy 50, 63to receive data 50to rename 63to replace 63

MEMBER parameter 50messages

selecting types to be received 63specifying destination of 52

MOD parameter 51mounting volumes on separate

devices 63MSG parameter 52MSGCLASS parameter 52MSS (mass storage system), locating data

set on 53MSVGP parameter 53multivolume data sets

number of devices to be allocatedto 83

parallel mounting of 63specifying volume of to begin

processing 85MVS internal reader, copying data sets

to 45MXIG parameter 54

NNAME parameter 69name, assigning to a job 46navigation

keyboard 91NET parameter 57NETC parameter 55NETCOND parameter 55NETHC parameter 56NETHOLD parameter 56NETID parameter 57NETREL parameter 58new data sets 89

allocating space for 59in block units 31in contiguous areas 32, 54in cylinder units 34, 73in track units 82

block size of 30buffer lengths for 32data control block (DCB) information

for 37devices for 83, 84directory blocks for 39label information for 47logical record length of 49


new data sets (continued)maximum number of volumes

required for 49organization of 41primary and secondary space for 78RACF protection for 69record format of 70unused space in 72

NEW parameter 59nodes

copying between 1, 21defined 1, 101global, defined 101in poly-BDT 79local, defined 101

OOLD parameter 61OPEN/CLOSE/EOV trace option,

requesting 38operator hold

entering transaction into 45releasing transaction from 45

organization of data setsspecifying 41specifying DAP for 35that BDT can copy 1

Ppadding character, defining 63padding logical records 64panels, ISPF 7parallel mounting of volumes 63PARALLEL parameter 63parameters 25

ACCT 28ALX 28BDTENQ 29BLKSIZE 30BLOCK 31BUFL 32CONTIG 32CSOPT 33CYL 34DA 36DAP 35DATASET 36DCBDS 37DEN 38DIAGNS 38DIR 39DISP 40DSORG 41DUMMY 42EXPDT 42FILE 68FILESEQ 68FROM 43GMJD 44GMJDLIB 44HOLD 45INTRDR 45JOB 46JOBNAME 46

parameters (continued)LABEL 47LBL 47LOC 48LOCATION 48LRECL 49MAXVOL 49MBR 50MEMBER 50MOD 51MSG 52MSGCLASS 52MSVGP 53MXIG 54NAME 69NET 57NETC 55NETCOND 55NETHC 56NETHOLD 56NETID 57NETREL 58NEW 59OLD 61PARALLEL 63PARM 64PARMS 64PASSWORD 67PGMR 69POS 68POSITION 68PRIORITY 68PROGRAMMER 69PROTECT 69PRTY 68RECFM 70RELEASE 72RETPD 72RLSE 72RND 73ROUND 73SECGROUP 74SECPSWD 75SECUSER 76SHR 77SPACE 78SY 79SYS 79SYSTEM 79TIME 80TO 81TRACKS 82TRK 82TRTCH 82UCOUNT 83UNIT 84USER 64VOL 86VOLREF 85VOLSEQ 85VOLSER 86VOLUME 86VREF 85VSEQ 85VSN 86

PARM parameter 64PARMS parameter 64

partitioned data sets (PDSs)allocating new 39copying 1, 50, 65excluding members 65renaming members 65replacing members 65selecting members 50, 65specifying DAP for 35

PASSWORD parameter 67password, supplying 67, 75PDS (partitioned data set) members

allocating new 39copying 1, 50, 65excluding members 65renaming members 65replacing members 65selecting members 50, 65specifying DAP for 35

PGMR parameter 69poly-BDT 3

defined 101specifying node in 79transaction prefix for 3

POS parameter 68POSITION parameter 68predecessor transactions 15prefixes for transactions

for JES3 console 3for MCS console 3for poly-BDT 3for TSO terminal 3

primary space for data sets,requesting 78

PRIORITY parameter 68priority, assigning to job 68processing of transactions 8processor time, specifying maximum for

transaction 80PROGRAMMER parameter 69programmer’s name, supplying in

transaction 69PROTECT keyword in JCL 70PROTECT parameter 69protecting data sets

from being deleted 42, 72from being overwritten 42, 72with RACF 69

PRTY parameter 68punctuation of a transaction 6

RRACF

group ID, supplying 74password, supplying 75protection, providing for data set 69user security ID, supplying 76

RECFM parameter 70record formats

specifying for data sets 70that BDT can copy 1

record lengthsspecifying for data sets 49that BDT can copy 2

recording density of magnetic tape datasets, defining 38

RELEASE parameter 72

Index 105

releasing unused space in a data set 72renaming PDS members 65replacing PDS members 65requirements for data sets to be

copied 1retention period for data sets,

specifying 72RETPD parameter 72RLSE parameter 72RND parameter 73ROUND parameter 73

Ssample transactions 21scratch tapes, allocating 83SECGROUP 74secondary space for data sets,

requesting 78SECPSWD 75security of data sets

providing passwords 67providing RACF protection 69supplying RACF IDs 74, 75, 76

SECUSER 76sending comments to IBM xiiisequence number of volume,

specifying 85serial number of volume, specifying 86shared use of data sets

between BDT and other addressspaces 77

between BDT transactions 29shortcut keys 91SHR parameter 77SNA session, defined 101space for data sets 89

allocatingin block units 31in contiguous areas 28, 32, 54in cylinder units 34, 73in track units 82primary space 78secondary space 78

unused, releasing 72SPACE parameter 78storage devices

DASD, copying to 24of data sets BDT can copy 2tape, copying from 23, 24

submittingSNA NJE jobs xitransactions 7

successor transactions 15summary of changes

z/OS BDT File-to-File TransactionGuide xv

Summary of changes xvSY parameter 79syntax diagrams, how to read 6syntax rules for transactions 6SYS parameter 79system log, routing messages to 52SYSTEM parameter 79

Ttape data sets

allocating space for 59maximum number of volumes 49

devices for 84multivolume 63, 83, 85position of 68recording density of 38translation techniques of 82volume serial numbers for 85, 86

testing a transaction using dummy dataset 42

TIME parameter 80time, specifying maximum for

transaction 80TO parameter 81TO section 5


TQI (transaction queueing integrity) 9definition of 102protection of transactions 9

trace option, requesting 38track units, allocating space in 82TRACKS parameter 82trademarks 99transaction queueing integrity (TQI) 9

definition of 102protection of transactions 9

transactions 1accounting information in 28, 69code in 4format of 2FROM section of 4job definition section of 4job number of 8networks of 15prefix of 3priorities, assigning to 68processing of 8protection of 9sample formats of 21submitting 7syntax of 2, 6TO section of 5transaction definition section of 4writing 2

translation technique, specifying 82TRK parameter 82TRTCH parameter 82TSO terminal, transaction prefix for 3

UUCOUNT parameter 83unit count for multivolume data set,

specifying 83UNIT parameter 84user interface

ISPF 91TSO/E 91

USER parameter 64

VVOL parameter 86VOLREF parameter 85VOLSEQ parameter 85VOLSER parameter 86volume of multivolume data set,

specifying 85VOLUME parameter 86volume sequence number, specifying 85volume serial numbers

obtaining to locate data set on aparticular volume 85

specifying for data sets 86volumes

mass storage 53maximum number for data set 49parallel mounting of 63sequence numbers of 85serial numbers of 86

VREF parameter 85VSEQ parameter 85VSN parameter 86

Wwork queue

defined 102jobs on 8, 45

Zz/OS BDT File-to-File Transaction Guide

summary of changes xv


IBM®

Product Number: 5650-ZOS

Printed in USA

SC14-7583-30

z/os bdt file-to-file transaction guide - · pdf filecopy a partitioned data set to another...

Documents