CCF/CCF-II/MDH Transmission Guides

Transcription

1 CCF/CCF-II/ Transmission Guides 2.04 Interface Control Manager (Messaging Output): Function User's Guide The Depository Trust Company

2 ( DTC ). All rights reserved. This work is proprietary and is intended for exclusive use by DTC s Participants and other users of DTC s services. No part of this work may be reproduced or distributed (including by transmission) in any form or by any means, or stored in any information storage and retrieval system, without DTC s prior written permission. All requests for additional copies of this work or inquiries about this work should be directed to DTC Participant Interface Planning, The Depository Trust Company, 55 Water Street, New York, NY 10041, USA. Interface Control Manager (Messaging Output) ii

3 Document History July Corrected the byte layout in section position 17 originally read MDS Prefix 20 Characters Contains message sequence number Message-1? Characters 37 -? Refer to detailed message layout in Section Interface Control Manager (Messaging Output) iii

4 2.04 Interface Control Manager (Messaging Output) Table of Contents 1 Overview Message Queue Concept Unique Message Identification Message Types Output/Back-end Reject Message Transaction Header Output Message Notes Back-end Reject Notes Request To Retrieve Messages Rules For Requesting Messages Format Of The Returned Data Output Message Back-end Reject Message Last Block Of A Transmission Format Of the End Block Format Of The None Block Format Of The Output Message Format of the Back-end Reject Message Request For The Next Transmission Recovery CCF Interface File Preparation Sample CCFUSER Execution For CDSC Function (BTAM): Sample CCFUSER Execution For CDSC Function (VTAM): CCFUSER Information Messages Restart Procedures CCF Output Block Format CCFII Interface File Preparation Password PSW Input Record (User Transmit To DTC) CCFII Error Message Output Record RJE Transmissions Format Of The Output Sent To RJE Users RJE Header And Trailer Record (DTC Transmits To User) Interface Control Manager (Messaging Output) iv

5 9 Example Of RJE Output File RJE/SNA Transmissions Format Of the Output Sent to RJE/SNA Users RJE/SNA Header And Trailer Record (DTC Transmits To User) Example Of RJE/SNA Output File BDT Transmissions NDM Transmissions Interface Request Block Layout Returned Block Layout How To Use The CDSC Function Example Of CCF Errors Return Codes with New Associated Reason Codes and Messages Example Of CF2 Errors Interface Control Manager (Messaging Output) v

6 2.04 Interface Control Manager (Messaging Output) 1 Overview The Messaging Output function applies a new concept of creating and sending data to clients over Computer-to-Computer Facility (CCF). Currently, Users retrieve their output data via the batch file oriented Data Transmission Facility (DTF) system, or an interactive Mainframe Dual Host () interface. Both systems use different record layouts for the same type of data, and have their own software for preparing and spooling data for Users. The Messaging Output function allows all messages to have the same structure. All messages of one record type look the same across all interfaces. Users may retrieve their messages immediately after they are created; data is not time dependent. In addition to current data, messages from the past three business days are available to Users at any time. 1.1 Message Queue Concept All output data is presented to Users as messages of various types and lengths. Messages for one User are grouped into as many as 88 message queues. Any message logged into a queue is immediately available for retrieval by the User. However, the User must initiate a transmission to DTC using one of the available interfaces (CCF, CCFII, or ) to receive messages. Messages from different applications may be stored in the same queue. A User receives messages of different record types and lengths in the same transmission and has to recognize the type of each message. Message logging is handled by the Message Delivery System (MDS). There are two separate MDS files: one for Users and one for CCF/CCFII Users. Messages are logged into queues. Each queue is identified by an 8-byte signon and 2- digit destination number. DTC allows up to 88 destinations (01 to 88) for every signon. Interface Control Manager (Messaging Output) 1

7 Each User's password is associated with a message queue and a 2-digit destination is returned by the logon routine. If a User uses more than one password, they may all be assigned to the same queue. The User may have multiple queues; each associated with a different password. In order to retrieve messages from a selected queue, a User must log on with the password associated with that queue. 1.2 Unique Message Identification The Message Delivery System assigns sequence numbers to the messages for each queue at the time the message is logged. This allows for unique identification of messages. The message number is associated with the queue, not the data type within the queue. MDS maintains message files for the current business day plus three past business day files. Because of end-of-day processing, the current day file becomes 'yesterday's file'. The oldest file is overwritten with current day messages. Each message file is assigned a unique control number to facilitate the identification of messages for prior days. This control number has the format YYYYDDDS where: YYYY is the 4-digit year DDD is the julian day S is the sequence number of the MDS session on that day in case end-of-day was processed more than once not planned, but may happen) Therefore, a unique identification of any message consists of: file control number YYYYDDDS queue name (User's 8-byte signon and the 2-byte destination number) message sequence number within the queue 1.3 Message Types There are two possible sources of messages that may be logged on MDS queues: The majority of the messages are regular output data prepared by DTC applications that notify Users about activities affecting their accounts in DTC. Currently, Users retrieve this type of data from MDS queues in or from the DTF database via the CCF or CCFII interface. Interface Control Manager (Messaging Output) 2

8 The second message type is back-end rejects. These messages are created when an input transaction which was accepted by the front-end editing module, is rejected later by the application-processing program. This situation may happen occasionally because editing and application processing are separated in time and the data within a record is no longer valid. Back-end rejects are queued back to the message queue associated with the password that was used to transmit the input transaction initially. In order to receive a back-end reject, a User must have a valid message queue. Interface Control Manager (Messaging Output) 3

9 2 Output/Back-end Reject Message Transaction Header This is the universal 26-byte segment which is included as part of Output/Back-end messages. The positions of the fields are the actual positions on the Output/Back-end Messages. Field Format/Pic Position Description Type Indicator 1 Character 1 Value '' identifies an output message in the new format. (Important for Users who retrieve messages currently available.) Value '?' identifies a back-end reject. Production/Test Indicator 1 Character 2 'P' for production, 'T' for test messages. Record type 6 Characters 3-8 Identifies type of data in the message. Assigned by the application area. Record suffix 2 Characters 9-10 Allows application to create multiplesegment transactions. Version number 2 Numeric Allows many versions of the message type with different record layouts. User Reference Number 6 Characters Reference number passed from the input transaction or assigned by the application. Not currently used. Addressee ID 8 Characters The ID of the User or other entity for whom the transaction is being processed. Interface Control Manager (Messaging Output) 4

10 2.1 Output Message Notes 1) The length and format of an output message is different for each application. Due to current CCF limitations, messages (without the above 26-byte header) cannot exceed 1384 bytes. 2) Messages contain characters only. Packed and binary fields are not allowed. 3) An output message ready to be sent to MDS has the following format: Transaction Header (26) User Addressee '*' T/P Type Suffix Version Ref# ID (1) (1) (6) (2) (2) (6) (8) Application Data (Max. 1384) For CCF 4) The length of a message stored on MDS is always divisible by four. If an application's data is not divisible, it is padded with 1 to 3 trailing characters. For example, if an application message has a length of 901 bytes, it is stored and retrieved as a 904-byte message. 2.2 Back-end Reject Notes 1) The length and specific format of a back-end reject message depends on input transaction type. 2) Error codes explaining the reason for rejection are appended to the record. It is a 40- byte field with up to five error responses; each error response contains a 4-byte field identifier and a 4-byte error code. 3) A back-end reject ready to be sent to MDS has the following format: This is an input transaction with 40 bytes of error information appended to the end. Input Transaction Transaction Header (26) User Addressee? T/P Type Suffix Version Ref# ID (1) (1) (6) (2) (2) (6) (8) Application Data (Max 1384) for CCF Error Codes (40) Interface Control Manager (Messaging Output) 5

11 3 Request To Retrieve Messages If a G, N, M or any other entity wishes to receive messages on behalf of any User, that work must be logged under the G, N or M User's signon. The Addressee field on the transaction header specifies to whom the message is addressed. This field is populated by DTC at the User's request. Otherwise, it is left blank. Messages may be retrieved only from the queue associated with the signon of the User who sent in the request. A User can retrieve messages from the queue identified by the signon and the default destination number associated with the password. The request to retrieve messages has the following format: RQYYYYDDDSNNNNNNRRRRRR Where: RQ is a two-character request type. Possible values are: - AD: All Data. Data retrieval starts from the message specified by the file control number and sequence number then continues through all subsequent files up to the last message of the current day. - OP: Only Prior data. Data retrieval starts from the message specified by file control number and sequence number then continues through all subsequent files up to the last message on the prior day's file. - OD: One Day of Data. All messages logged on the file specified by the control number are returned. YYYYDDDS is the MDS file control number located in the Interface Control Block. NNNNNN is the 6-digit sequence number of the first requested message. Sequence numbers start with located in the MDS Prefix. RRRRRR is a 6-digit maximum number of messages to deliver. Value zero implies all available data. This parameter allows the User to limit the time when the line is utilized by output messages. Interface Control Manager (Messaging Output) 6

12 3.1 Rules For Requesting Messages 1) Request 'AD' with the File Control number equal to zeros should be used the first time a User initially goes live with Interactive ID. If the File Control number is equal to zeros, only messages from the current day's file are returned. The File Control number and the Sequence number of the last message received must be saved and used in the subsequent requests. The optional parameter RRRRRR may be used to limit the number of returned messages and transmission time. 2) Request 'AD' should be used in normal processing, once the User knows the File Control number and the Sequence number of the last message received. The Message Sequence number must be incremented by one before issuing subsequent 'AD' requests. Data retrieval starts with this message and continues through all available files until the last message on the current day's file. The File Control number and the Sequence number of the last delivered message must be saved and used in preparing subsequent 'AD' requests. 3) If normal processing is interrupted by any problems at DTC or at the User's site, then 'AD' requests with zeros as the File Control number can be used to retrieve and process current day messages 'OP' requests with the proper File Control number and Message Sequence number may be used later, after the problems are solved, to retrieve the missing prior day's messages. 4) Request 'OD' returns messages for one day only. The File Control number and Message number must be specified. Data retrieval starts with this message and continues until the end of file is reached. In some situations, there will be more than one file created for a given day. In these situations, all files will be processed until the end of the last file for that day is reached. 5) If a gap in messages is discovered or a transmission is lost, data may be retransmitted by using request 'AD' with the number of messages required specified in the RRRRRR field. For CCF and CCFII Users, this request is specified in the input file sent to DTC. It must start in Position 1 of the 80-byte record. Users send this request as a set of parameters in the type '07' block (Data Request Block). Interface Control Manager (Messaging Output) 7

13 Acceptable Values in the Request for Message Retrieval: Request RQ File Control Number YYYDDDS Message Number NNNNNN Range RRRRRR AD YYYYDDDS OP YYYYDDDS OD YYYYDDDS Format Of The Returned Data Users receive one or more blocks of messages. DTC will neither de-block the messages nor provide the software to do so. Users must be ready to process variable-length blocks containing many different types of messages. Each block has messages from the same MDS file. There may be a short block in the middle of a transmission when all messages from the file are retrieved. The next block contains messages from the next day's file. The last message in each transmission is the special 'End' message. When no messages are found to satisfy a request, a special 'None' message is returned. A block of messages has the following format: Interface Control Block (x) Total Data Length (4) Message 1 Length (4) MDS Prefix (20) Message Message N Length (4) MDS Prefix (20) Message N The Interface Control Block is required by the communication interface. It is 66 bytes for, 22 bytes for CCF, and 8 bytes for CCFII. This control block includes the MDS File Control number. One block always contains messages from the same file. Data length is a 4-digit number representing the total length of all messages in the block plus this field. The block length and number of messages in each block is limited by the communication protocol: for maximum block length (with Interface Control Manager (Messaging Output) 8

14 the Interface Control Block) is 4085 bytes; for CCF/CCFII, this maximum is 1500 bytes. Message length is a 4-digit number representing the total number of bytes in the message plus this field. Due to CCF block length limit, the maximum value in this field is Messages have the identical format for CCF/CCFII and. There are two possible message types: 3.3 Output Message MDS Transaction Header (26) prefix (20) User Addressee '*' T/P Type Suffix Version Ref# ID (1) (1) (6) (2) (2) (6) (8) Application Data (Max. 1384) for CCF 3.4 Back-end Reject Message Input Transaction MDS Transaction Header (26) prefix (20) User Addressee? T/P Type Suffix Version Ref# ID (1) (1) (6) (2) (2) (6) (8) Application Data (Max. 1384) for CCF Error Codes (40) 3.5 Last Block Of A Transmission The last block of every transmission is the End block or the None block, depending on whether any messages are found to satisfy the User's request. The last block of a transmission where messages are retrieved is the End block. The End block is transmitted after all messages that satisfy the User's request are sent. The End block has a 4-character message containing the text End. 3.6 Format Of the End Block Interface Control Block (X) Data Length (4) Message 1 Length (4) Message 1 (4) 'END' Interface Control Manager (Messaging Output) 9

15 The last and only block of a transmission where no message is found that satisfies the User's request is the None block. The None block is sent to indicate that no data messages exist for a specific message queue. The None block contains a 14-character Message, containing the text None followed by a Destination ID field. The Destination ID consists of an 8-character User signon and a 2-digit destination in SSSSSSSSDD format, where: SSSSSSSS= 8-character User signon. DD= 2-character destination. 3.7 Format Of The None Block Interface Control Block (X) Data Length (4) Message 1 Length (4) Message 1 (14) NONE SSSSSSSS DD (4) (8) (2) The File Control number returned in the block containing the End or None message identifies the last file read while searching for messages. 3.8 Format Of The Output Message Field Format/PIC Position Description Interface Control Block Refer to Section for CCF. Refer to Section for CCFII. Refer to Section for. MDS Prefix 1-20 Refer to Section Transaction Header 1-26 Standard Transaction Header. Refer to Section Note: Type Indicator value "*" identifies an output message. Application Data 27 - N Length and contents varies by application for each type + suffix + version combination. Interface Control Manager (Messaging Output) 10

16 3.9 Format of the Back-end Reject Message Field Format/PIC Position Description Interface Control Block Refer to Section for CCF. Refer to Section for CCFII. Refer to Section for. MDS Prefix 1-20 MDS PREFIX. Refer to Section Transaction Header 1-26 Standard Transaction Header. Refer to Section Note: Type indicator Value '?' identifies a back-end reject. Application Data 27 - N Length and contents designed by application group for each type + suffix + version combination. Error Response 40 Characters N+1 - N+40 Reason for rejection. 5 error responses in the form: - 4-byte field identifier - 4-byte error code The MDS prefix provides a unique identification for each message. The Message Sequence number is used to develop the next request for data. Field Format/PIC Position Description Filler 1 Character 1-1 Space Message flag 1 Character 2-2 'O': current day original message 'R': current day reprint 'U': current day requested out-of-sequence 'Y': prior day Filler 1 Character 3-3 Spaces Destination ID 10 Characters 4-13 ID of the MDS queue the message was retrieved from (8-byte User signon + 2-digit destination) Hyphen 1 Character Value ' - ' Message Sequence Number 6 Numeric Message sequence number; unique sequence number for destination ID and MDS file. Interface Control Manager (Messaging Output) 11

17 3.10 Request For The Next Transmission The result of each 'AD' request should be examined in order to prepare the request for the next transmission. A recommended approach based on the returned transmission is: 1) The returned data set contains message blocks and the End block. a) The File Control number in the End block is the same as the File Control number in the last messages block. Messages were found in the current or prior day file. In the next 'AD' request, use the File Control number from the last message-control block. Increment the message number of the last message received by one, and then use it as the message starting number. b) The File Control number in the End block is different from the File Control number specified in the last message block. Messages were found in the prior day file, but none were retrieved from the current day file. Use the File Control number from the End block with the Starting Message number equal to in the next 'AD' request. If no messages are created for this User for three consecutive days and the request is not updated with the File Control number returned in the End block, the transmission may end with an 'INVALID FILE CONTROL NUMBER' error. 2) No new messages were retrieved, only the None block is sent back. a) The File Control number in the None block is the same as the File Control number specified in the request. No new messages were created for the current day. Use the same request in the next transmission. b) The File Control number in the None block is different from the File Control number specified in the request. No new messages arrived since the last request and end-of-day processing for MDS took place. Use the File Control number from the None block with the Starting Message number equal to in the next 'AD' request. Interface Control Manager (Messaging Output) 12

18 3.11 Recovery The unique identification of each message enables Users: To make sure that there are no gaps in sequence numbers Discover and delete duplicate messages It is recommended that specifying a starting message number be utilized at all times. Note: If the User keeps the last message number received and creates new request according to the rules stated in this section, he/she should never be out of sequence. Interface Control Manager (Messaging Output) 13

19 4 CCF Interface CCF Users must use the CDSC function in order to receive interactive messages. 4.1 File Preparation The User must prepare two data files before executing the CDSC function. The Card Image Input file containing the request specification is a fixed or fixed-blocked format file with one 80-byte record in it. The block size of the file can be set to any valid multiple of 80 bytes. The DDNAME representing this file should be specified as the value for the DDIN keyword on the FUNCTION=CDSC control card that is input to CCFUSER. This record must contain the request in the format described in Request To Retrieve Messages. The Output file which contains the data received from DTC is in the normal format for CCFUSER Output Data files (variable blocked, LRECL=1504, BLKSIZE=1508). The DDNAME representing this file should be specified as the value for the DDOUT keyword on the FUNCTION=CDSC control card that is input to CCFUSER. DTC will not distribute any additional software. Users must write their own utilities to extract single messages from output blocks Sample CCFUSER Execution For CDSC Function (BTAM): The following jobstream can be used to execute CCFUSER (with automatic computercontrolled dialing of DTC) and to use the CDSC function to request all current day messages: Note: Bold description denotes changes to current CCFUSER requests. // Proper job card //S1 EXEC PGM=CCFUSER,TIME=1439,DPRTY=11 //SYSPRINT DD SYSOUT=A hard copy log file //SYSUDUMP DD SYSOUT=A hard copy dump file //TPLINE DD UNIT=xxx define DTC communications line //STEPLIB DD define program library on which CCFUSER exists //INPUT DD *file may be on disk AD //OUTPUT DD Define file with RECFM=VB, LRECL=1504, // BLKSIZE=1508 //SYSIN DD *file may be on disk FUNCTION=LOGON,ID=6666,PASSWORD=ABCDEF Interface Control Manager (Messaging Output) 14

20 FUNCTION=CDSC,DDIN=INPUT,DDOUT=OUTPUT // Sample CCFUSER Execution For CDSC Function (VTAM): The following jobstream can be used to execute CCFUSER (VTAM LU 6.2 version) and to use the CDSC function to request all current day messages: // Proper job card //S1 EXEC PGM=CCFUSER,TIME=1439,DPRTY=11 //SYSPRINT DD SYSOUT=A hard copy log file //SYSUDUMP DD SYSOUT=A hard copy dump file //STEPLIB DD define program library on which CCFUSER exists //INPUT DD *file may be on disk AD //OUTPUT DD define file with RECFM=VB, LRECL=1504, // BLKSIZE=1508 //SYSIN DD *file may be on disk FUNCTION=LOGON,ID=6666,PASSWORD=ABCDEF,APPLID=ABCD, DTCAPPL=PLCICS FUNCTION=CDSC,DDIN=INPUT,DDOUT=OUTPUT // CCFUSER Information Messages Before and during the transmission, CCFUSER receives and prints information messages. These messages indicate: The User's request The Destination ID of the message queue associated with the User's signon and password The control number of the message file containing the required messages The control number of the message file bypassed because the required queue is empty The number of blocks and messages sent to the User 4.2 Restart Procedures A Return Code of 0 from CCFUSER indicates a correct transmission. The output file contains message blocks followed by the End block, or only one None block. Note: If errors occur, the Output file may be discarded, and the CCFUSER stream may be re-executed with the same input request. However, for some errors (Return Codes , TP error) the Output file may contain a partial transmission. The User may process received blocks and modify the request for the next transmission. Interface Control Manager (Messaging Output) 15

21 4.3 CCF Output Block Format Field Format/PIC Position Description CCF Interface Control Block Block Type 1 Character 01 Binary value x '08'. CCF Flags 1 Character 02 Value x '80' for the last block. Filler 3 Characters Not Used; binary zeros. Sequence Number 8 Numeric 9(8) Comp Block sequence number within the transmission, used by CCFUSER. Filler 5 Characters Binary zeros. File Control Number 8 Characters MDS file control number in the format YYYYDDDS where: YYYY: year DDD: julian day S: session number Block-Data-length 4 Numeric 1-4 Length of the data following this field plus 4. Maximum value is Message-1-length 4 Numeric 1-4 Length of the message following this field plus 4. Maximum value is MDS Prefix 20 Characters 1-20 Contains message sequence number * Message-1 N Characters 1 - N Refer to Section Message-N-length 4 Numeric? -? Length of the message following this field plus 4. Message-N? Characters? -? Message in standard format. CCF record contains as many messages as will fit in the 1500-byte block. Total number of bytes used is in the Block-Data-Length field. * The Message Sequence number is used to develop the next request for data. Interface Control Manager (Messaging Output) 16

22 5 CCFII Interface CCFII Users receive their messages in a similar manner as they currently retrieve data. In order to initiate transmission from DTC, they must send in a request for data. To retrieve messages, they must send in a file containing two 80-byte records (a standard password record and a message request record). CCFII Users receive their messages in a variable length file (RECFM=VB, LRECL=1504). Each data record contains one block of messages. Users must write their own routines to extract single messages from the block. Each block may contain messages of different types and different lengths. For RJE and RJE/SNA Users, each variable length block, which can contain variable length records, is reformatted into a multiple of 80 or 255-byte fixed length records. Users have to recreate the variable block before examining single messages. This can be accomplished by examining the block size at the beginning of each block. Messages are retrieved from the message queue associated with the signon ID and password. If a User has multiple queues, different passwords must be used with the signon in order to retrieve messages from the different queues. Group Users are treated the same way as individual Users. They receive messages from the queue assigned to their G signon and password. If errors occur, the User receives only one record with an error message. The error record always starts with an 'ERR' identifier. 5.1 File Preparation Users execute the CDSC function in order to receive messages. Two data sets must be prepared prior to submitting the request. The Card Image Input file containing the request specification is a fixed or fixed-blocked format file with two 80-byte records in it. The block size of the file can be set to any valid multiple of 80 bytes. The first record in this file is the password record in standard format. The second record must contain the request in the format described under Request To Retrieve Messages. Interface Control Manager (Messaging Output) 17

23 The Output File, which contains the data received from DTC, must be For NDM and BDT Users: variable blocked, LRECL=1504, any valid block size (BLKSIZE=27998 is recommended). For RJE Users: LRECL=80, any valid block size. For RJE/SNA Users: LRECL=255, any valid block size. Note: DTC will not distribute any additional utilities to extract single messages from output blocks. 5.2 Password PSW Input Record (User Transmit To DTC) The first record in the Input file must always be the password record. Its format is the same as for any input function or DTF transmission. Group Users and individual Users use the same format. This record must be the same length as the length of the data being transmitted. Password PSW Input Record (User Transmits To DTC) Field Format Position Description PSW Field Character Record Identifier (ALWAYS "PSW") Signon ID Character User Signon ID. Left justified, blank filled. Password Field Character Data Encryption Password assigned by DTC. Function Name Character Function requested: must be CDSC. Left justified, space filled. Transmission ID Numeric Transmission ID. Non-zero value; Zero filled. Interface Control Manager (Messaging Output) 18

24 CCFII Output Block Format: CCFII Users receive blocks in the format described in Request To Retrieve Messages. The CCFII Interface Control Block contains only the 8- byte File Control number: Field Format/PIC Position Description CCFII Interface Control Block File control number Characters MDS File Control number in YYYYDDDS format where: YYYY: year DDD: julian day S: session number Block-Data-length 4 Numeric Length of the data following this field plus 4. Maximum value is Message-1-length 4 Numeric Length of the message following this field plus 4. Maximum value is MDS Prefix 20 Characters Contains message sequence number Message-1? Characters 37 -? Refer to detailed message layout in Request To Retrieve Messages. Message-N-length 4 Numeric? -? Length of the message following this field plus 4. Message-N? Characters? -? Message in standard format. CCFII record contains as many messages as will fit in the 1500-byte block. Total number of bytes used is in the Block- Data-Length field. NDM and BDT Users get their data exactly as described above. For RJE Users, data is reformatted to 80- or 255-byte records. Users have to re-create blocks in the above format before de-blocking messages. Note: The File Control and Message Sequence numbers are used to develop the next request for data. Interface Control Manager (Messaging Output) 19

25 6 CCFII Error Message Output Record If errors occur during processing, one error record is transmitted indicating the problem encountered. Field Format Position Description Record Type 3 Characters Always ERR Signon ID 8 Characters User signon ID; right justified, zero filled. Filler 8 Characters Not used, filled with spaces. Date 6 Characters Processing date. Function Name 6 Characters CDSC Transmission ID 3 Numeric Transmission ID set by the User. Filler 2 Characters Not used, filled with spaces. Error Code 3 Characters Refer to Section for a list of possible errors. Filler 5 Numeric Not used, filled with zeros. Start time 6 Numeric Time the transmission arrived. End time 6 Numeric Time the transmission ended. Interface Control Manager (Messaging Output) 20

26 7 RJE Transmissions The example below shows the Batch Job Control Statements for RJE 3780 Users needed to request output messages. //RJEDxxxxJOB DTC1,'description', // CLASS=O, (This is the letter O not Zero) // MSGCLASS=X, // MSGLEVEL=(1,1),REGION=6M //EXEC RJECDS01,RMT=###,TME=HHMMSS,DATE=MMDDYY, // USERID=xxxx,FUNC=CDSC //INPUT1 DD * PSW (Refer to "Password PSW Input Record," Section ) RQ (Refer to "Request To Retrieve Messages," Section ) /* where: HHMMSS MMDDYY XXXX = time of transmission coded as HHMMSS by the User and supplied by DTC's system. Must be CAPITAL LETTERS = date of transmission coded as MMDDYY by the User and supplied by DTC's system. Must be CAPITAL LETTERS = user number ### = remote number from SIGNON card of first transmission Note: 1. The "RMT, DATE=MMDDYY and the TME=HHMMSS parameters must be on the same physical JCL line as the "EXEC" operand. All other parameters can be coded on the second (continuation) card. 2. There is no difference in JCL for Group Users and individual Users. 3. Data defined in bold denotes changes to current RJE JCL. 7.1 Format Of The Output Sent To RJE Users The Output file is reformatted from variable length 1504-byte message blocks to 80-byte records. Each block may need a different number of 80-byte records. The first 80-byte record contains the length of data in the variable length block. Positions 5-74 of the first record and positions 1-74 of all other records contain the actual data. Control numbers are put into the remaining six positions of each record. The message block is broken down as follows: First 80-byte record: POS 01-04: data length increased by 4 POS 05-74: first 70 bytes of message block, padded with spaces if the block is shorter than 70 bytes POS 75-80: NUMBERING SEQUENCE Interface Control Manager (Messaging Output) 21

27 POS 75-76: POS 77-80: record number '01' block number Remaining records: POS 01-74: 74-byte segment of message block, segment padded with spaces POS 75-80: NUMBERING SEQUENCE POS 75-76: record number starting with '02' POS 77-80: block number Interface Control Manager (Messaging Output) 22

28 8 RJE Header And Trailer Record (DTC Transmits To User) Before and after all data is retrieved, a Header and Trailer record is provided. They contain informational data only and may be used for the User's own purposes. Header and Trailer records are in the following format: Field Format Position Description Record ID 3 Characters 1-3 Always 'HDR' or 'TLR'. Sign-on ID 8 Characters 4-11 User signon ID. Function Requested 6 Characters Always CDSC. Transmission Date 6 Numeric Date of transmission (in DDMMYY format) Transmission Time 6 Numeric Time of transmission (in HHMMSS format). 6 Numeric Number of blocks returned in this transmission. 8 Numeric Number of 80-byte records in the file, without Header and Trailer. 31 characters Reserved field (spaces) for future use. 6 Numeric Numbering Sequence. Used as data integrity check. HDR ===> TLR ===> Interface Control Manager (Messaging Output) 23

29 9 Example Of RJE Output File An RJE User requested all output messages via the CDSC function. There are two messages to satisfy the request: both the same type and same length equal to 200 bytes. The Output file contains two blocks in the format described in CCF Output Block Format: 1st block: two output messages; length = 420 ( ) 2nd block: the 'END' message; length = 20 ( ) An image of the 80-byte record file is shown below. The "."s are representations of data. Please note the length field in the first record for each block and the sequence numbers at the end of each record. cols: HDR st blk: spaces nd blk: spaces TLR Interface Control Manager (Messaging Output) 24

30 10 RJE/SNA Transmissions The example below shows the Batch Job Control Statements for RJE 3770 Users needed to request messages. //RJESxxxx JOB DTC1,'description', // CLASS=O, (This is the letter O not Zero) // MSGCLASS=X, // MSGLEVEL=(1,1),REGION=6M // EXEC RJESCDS1,RMT=###,TME=HHMMSS,DATE=MMDDYY, // USERID=xxxx,FUNC=CDSC //INPUT1 DD * PSW (Refer to "Password PSW Input Record," Section ) RQ (Refer to "Request To Retrieve Messages," Section ) /* where: HHMMSS = time of transmission coded as HHMMSS by the User and supplied by DTC's system. Must be CAPITAL LETTERS. MMDDYY = date of transmission coded as MMDDYY by the User and supplied by DTC's system. Must be CAPITAL LETTERS. xxxx = User number. ### = remote number from SIGNON card of first transmission. Notes: 1. The "RMT, DATE=MMDDYY and the TME=HHMMSS parameters must be on the same physical JCL line as the "EXEC" operand. All other parameters can be coded on the second (continuation) card. 2. There is no difference in JCL for Group Users and individual Users. 3. Data defined in bold denotes changes to current RJE JCL Format Of the Output Sent to RJE/SNA Users The Output file is reformatted from variable length 1504-byte blocks to 255-byte fixed records. Each message block may need a different number of 255-byte records. The first 255-byte record contains the number of bytes in the variable length block. Positions of the first record and positions of all other records contain the actual data. Control numbers are put into the remaining six positions of each record. The full record is broken down as follows: First 255-byte record: POS 01-04: data length increased by 4 POS : first 245 bytes of message block, padded with spaces if the block is shorter than 245 bytes POS : NUMBERING SEQUENCE Interface Control Manager (Messaging Output) 25

31 POS : record number '01' POS : block number Remaining records: POS : 249-byte segment of message block, last segment padded with spaces POS : NUMBERING SEQUENCE POS : record number starting with '02' POS : block number Interface Control Manager (Messaging Output) 26

32 11 RJE/SNA Header And Trailer Record (DTC Transmits To User) Before and after all data is retrieved, a Header record and Trailer record are provided. They contain informational data only and may be used for the User's own purposes. Header and Trailer records are in the following format: Field Format Position Description Record ID 3 Characters Always 'HDR' or 'TLR'. Signon ID 8 Characters User signon ID. Function Requested 6 Characters Always CDSC. Transmission date 6 Numeric Date of transmission (in DDMMYY format). Transmission Time 6 Numeric Time of transmission (in HHMMSS format). 6 Numeric Number of blocks returned in this transmission. 8 Numeric Number of 255-byte records in the file, without Header and Trailer. 206 characters Reserved field (spaces) for future use. 6 Numeric Numbering Sequence. Used as data integrity check. HDR ===> TLR ===> Interface Control Manager (Messaging Output) 27

33 12 Example Of RJE/SNA Output File An RJE/SNA User requested all messages via the CDSC function. There are two messages to satisfy the request: both the same type and same length equal to 200 bytes. The Output file contains two blocks in the format described in Section : 1st block: two output messages; length = 420 ( ) 2nd block: the 'END' message; length = 20 ( ) An image of the 255-byte record file is shown below. The "." s are representations of data. Please note the length field in the first record for each block and the sequence numbers at the end of each record. cols: HDR header st blk: data spaces nd blk: spaces TLR trailer Interface Control Manager (Messaging Output) 28

34 13 BDT Transmissions The example below shows the Job Control Statements and MVS/BDT control information exactly as they should be coded on each data transmission request for a User's messages. Uppercase characters indicate that they must be coded exactly as illustrated. Lowercase indicates these values must be supplied by the User. If any field specified in the SYSIN section is not included, the Code 13 message is written to the User's BDT log, and no data is transferred. //userjob JOB proper userjob card //* //userstep EXEC PGM=BDTBATCH //SYSPRINT DD SYSOUT=* //SYSIN DD * Q JOBNAME(BDTuuuuv) FROM DSN (user.control.file) LOC(mmmmmmm) DAP(SEQ) SHR DISP(KEEP,KEEP) TO DSN(PROD.BDTCDS01.Uuuuu.CDSC.DDDDDDD.TTTTTTT.I) LOC(QBDTDTC) DAP(SEQ) UNIT(SYSDA) NEW DISP(CATALOG,KEEP) SPACE(1,1) TRK RECFM(FB) LRECL(80) BLKSIZE(80) CSOPT(NJEDUP) ACCT(RD=return.data.set RL=1504 * * -optional parms(see below)- * RG=pppppppp RU=pppppppp RP=pppppppp RJ=j ) /EOT // where: user.control.file contains two 80-byte records: PSW (Refer to "Password PSW Input Record," Section ) RQ (Refer to "Request To Retrieve Messages," Section ) Interface Control Manager (Messaging Output) 29

35 14 NDM Transmissions Note: 1. Although MVS/BDT allows multiple jobnames to execute concurrently, the batch PROC that is submitted to MVS must have a unique jobname. 2. The keywords listed in the Account field may be coded in any order and must be separated by at least one blank. Only the required keywords must be specified. The example below shows the Batch Job Control Statements along with the Process Statements needed when requesting CDSC data transfer through NDM. This illustrates the JCL statements required for each data transmission request. Uppercase characters indicate that they must be coded exactly as illustrated. Lowercase indicates these values must by supplied by the User. //userjob JOB user job card info //* //userstep EXEC PGM=DMBATCH,REGION=512K,PARM=(YYSLYNN) //STEPLIB DD DISP=SHR,DSN=user.prefix.LINKLIB //DMNETMAP DD DISP=SHR,DSN=user.prefix.NETMAP //DMPUBLIB DD DISP=SHR,DSN=user.prefix.PROCESS.LIB //DMMSGFIL DD DISP=SHR,DSN=user.prefix.MSG //DMPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSIN DD * SIGNON USERID = (userid) SUBMIT PROC = procname SNODE = PNDMDTC &jobinfo = NDMuuuuv &fromdsn = user.control.file &todsn = PISP.NDMCDS01.Uuuuu.CDSC.DDDDDDD.TTTTTTT.I &lrecl = 80 &blksize = 80 &spunits = trk &prim = 1 &ckptval = 40K SACCT = \'RD=return.dataset RL=1504 RS=O \ - \ RG=user.Jcl.lib(goodjob) \ - \ RB=user.Jcl.lib(badjob) \ - Interface Control Manager (Messaging Output) 30

36 The following are optional. Refer to Section 2.02, Network DataMover, for a complete listing of optional parameters. \ RO=userid,password \ - \ RN=new,catlg,keep \ - \ RV=volume ' \ SIGNOFF /* // Where: user.control.file contains two 80-byte records: PSW (Refer to "CCFII Transmission Password Record ("PASSSWD")," Section ) RQ (Refer to "Request To Retrieve Messages," Section ) 15 Interface Users are already familiar with the message queue concept and the interactive way of receiving data from DTC. Currently, Users execute the MDLU function to retrieve messages. This function is still available and may be invoked to retrieve the current day's messages. However, it is strongly recommended that Users use the MDLS function. This function accepts the request in the format described in Section , Request To Retrieve Messages, and gives access to the current and prior days messages. All Users (whether they use the MDLU or MDLS function) receive messages in the new format intermixed with messages of the format currently used. The type of message may be recognized by examining the first character following the MDS prefix: only '*' or '?' points to a message in the new format. Any other character means that the message is in the currently used format Request Block Layout If a delivery of messages is requested, the 07 -type block must be sent to DTC. The MDLS function recognizes the following format of the request block: Field Format Position Description Block Type 2 Characters Value 07 Time-stamp 6 Characters Time received (in HHMMSS format). Interface Control Manager (Messaging Output) 31

37 User ID 8 Characters User signon, numeric ( ) or alphanumeric (G ). Individual User Number 2 Numeric Entered by sender from Type 02 logon response. LU6.2-TERMID 4 Characters Internal to. Filler 38 Characters Value Spaces. Function Requested 4 Characters Value 'MDLS'. Request Type 2 Characters Value 'AD', OP or OD. File Control Number 8 Characters YYYYDDDS Starting Message Number Maximum Number To Deliver 6 Numeric Numeric: 6 digits. 6 Numeric Numeric: 6 digits Returned Block Layout In response to the User s request, one or more type '08' blocks are sent back to the User. Blocks with messages are followed by the End block. If no messages are retrieved, the None block is sent. In case of an error, the request is rejected and one block with reason code and the 'NONE' message is sent. A block returned to the User has the following format: Field Format/PIC Position Description Interface Control Block Block Type 2 Characters Value 08 Time-stamp 6 Characters Time received in HHMMSS format. User ID 8 Characters User signon, numeric ( ) or alphanumeric (G ). Individual User Number 2 Numeric Internal to. LU6.2-TERMID 4 Characters Internal to. Filler 30 Characters Value Spaces Interface Control Manager (Messaging Output) 32

38 Field Format/PIC Position Description File Control Number 8 Characters MDS File Control number in the format YYYYDDDS. Response Code 1 Character A: accepted R: rejected Response Reason 1 Character A: Not signed on B: Past cutoff C: Not in 'MDLS' function D: Invalid range request E: Function name not 'MDLS' F: Invalid request type G: Invalid File Control Number M: Message Delivery is quiesced N: File Control Number is not prior day for OP request P: is down Transactions In Block Block-Data- Length Message-1- Length 4 Numeric Number of messages returned in this block. 4 Numeric Length of the data following this field plus 4. 4 Numeric Length of the message following this field plus 4. Message-1? Characters 75 -? Refer to detailed message layout described in Format Of The Returned Data. END - last block NONE - the only block Message-N-Length 4 Numeric? -? Length of the message following this field plus 4. Message? Changes? -? record will contain as many messages as will fit in the 4000-byte block. Total number of bytes used is in the field Blockdata-length. Messages can be various types and lengths. Interface Control Manager (Messaging Output) 33

39 16 How To Use The CDSC Function Let's take one hypothetical User and walk through the process of receiving messages. Let's assume that User 1234 has only one password with the Destination Number equal to 02. There are two types of messages User 1234 is interested in: TYPE-A (200 bytes long) and TYPE-B (420 bytes). Both are production messages, all data is contained in one record, and only one version is maintained. User 1234 also sends input transactions of TYPE-C. CCF User Day 1 - Thursday 9 a.m. Eastern Time There are two TYPE-A messages for User 1234 and one TYPE-B message on the message queue. All three messages are sent to destination / a.m. Eastern Time User 1234 logs on for the first time and executes the CDSC function with an initial 'AD' request (file number and starting message number are zeros): AD As a result, two CCF blocks are returned to the User: - Block 1 (858 bytes) CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)0836 Msg 1 length ( 4)0204 MDS prefix ( 20) O std header ( 26) *PTYPE-A0101AAAAAA Appl data (154)... Msg 2 length ( 4)0204 MDS prefix ( 20) O header ( 26) *PTYPE-A0101BBBBBB appl data (154)... Msg 3 length ( 4) 0424 MDS prefix ( 20) O header ( 26) *PTYPE-B appl data (374)... Interface Control Manager (Messaging Output) 34

40 - Block 2 (END block): CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4) 0012 Msg 1 length ( 4) 0008 text ( 4) END The User de-blocks and processes the data. Message number from File was the last one received. The next transmission starts with message number The new request should be as follows: 2 p.m. Eastern Time AD User 1234 sends an input transmission of TYPE-C transactions. All transactions passed front-end editing. Transaction number 15 was later rejected by the processing module. The resulting back-end reject message was added to the MDS queue for User p.m. Eastern Time One more Type-B message is created for User Day 2 - Friday 9 p.m. Eastern Time One TYPE-A message is created for User 1234 and sent to destination / p.m. Eastern Time User 1234 logs on and executes the CDSC function with the 'AD' request prepared yesterday: AD Consequently, three CCF blocks are sent back: the first block contains the back-end reject message and TYPE-B message from yesterday's file. The second block contains the TYPE-A message from the current file, and the last is the End block. Interface Control Manager (Messaging Output) 35

41 - Block 1 (714 bytes): CCF int cntl blk ( 14)... File cntl num ( 8) Data length ( 4) 0692 Msg 1 length ( 4) 0264 MDS prefix ( 20) Y header ( 26) *PTYPE-C appl data (174)... err. codes ( 40)... Msg 2 length ( 4) 0424 MDS Prefix Y header ( 26) *PTYPE-B appl data (374)... - Block 2 (230 bytes): CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)0208 Msg 1 length ( 4)0204 MDS prefix ( 20) O header ( 26) *PTYPE-A0101CCCCCC appl data (154)... - Block 3 (END block) CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)0012 Msg 1 length ( 4)0008 text ( 4) END The User de-blocks and processes the data. Message number from File was the last one received. The next transmission should start from message number The new request is: 2 p.m. Eastern Time AD User 1234 logs on to pick up today's messages starting from message number The request sent is: AD In response, the User gets the None block because no messages were created since the last transmission. Interface Control Manager (Messaging Output) 36

42 - Block 1 (NONE block): CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)0022 Msg 1 length ( 4) 0018 text ( 14) NONE Day 3 - Monday 9 a.m. Eastern Time One TYPE-A message and three TYPE-B messages are created for User All four messages are sent to destination /02. 5 p.m. Eastern Time For User 1234 this day is a holiday, so the messages were not retrieved. 4. Day 4 - Tuesday 8 p.m. Eastern Time User 1234 logs on with the same request as on Friday: AD All messages created on Monday are sent back in two blocks followed by the End block. - Block 1 (1078 bytes): CCF int cntl blk ( 14)... File cntl num ( 8) Data length ( 4) 1056 Msg 1 length ( 4) 0204 MDS prefix ( 20) Y header ( 26) *PTYPE-A0101EEEEEE appl data (154)... Msg 2 length ( 4) 0424 MDS prefix ( 20) Y header ( 26) *PTYPE-B appl data (374)... Msg 3 length ( 4) 0424 MDS prefix ( 20) Y header ( 26) *PTYPE-B appl data (374)... Interface Control Manager (Messaging Output) 37

43 - Block 2 (230 bytes): CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4) 0208 Msg 1 length ( 4) 0424 MDS prefix ( 20) Y header ( 26) *PTYPE-B appl data (374)... - Block 3 (END block) CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4) 0012 Msg 1 length ( 4) 0008 text ( 4) END Note: The File Control number in the End block is not the same as the File Control number of the previous block. That means that all messages were retrieved from Monday's file, and no messages were found on Tuesday's file. The request for the next CDSC transmission is: 2 p.m. Eastern Time AD Two TYPE-A messages are created for User Day 5 - Wednesday 9 a.m. Eastern Time Two TYPE-B messages are created for User a.m. Eastern Time User 1234 logs on to DTC to retrieve all undelivered messages with the request: AD The Transmission is unsuccessful because yesterday's file (Tuesday's file with control number ) is unavailable due to a DTC system problem. CCF transmission ends with Reason Code 125 and the message CCF1113 is printed on CCFUSER hard copy log. The User changes the request to: Interface Control Manager (Messaging Output) 38

44 AD The transmission is now successful and two TYPE-B messages are sent back: - Block 1 (874 bytes): CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)0852 Msg 1 length ( 4)0424 MDS prefix ( 20) O header ( 26) *PTYPE-B appl data (374)... Msg 2 length ( 4) 0424 MDS prefix ( 20) O header ( 26) *PTYPE-B appl data (374)... - Block 2 (End block) CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)0012 Msg 1 length ( 4)0008 text ( 4) END 1 p.m. Eastern Time All problems with Tuesday's file are solved, and the file is available again. User 1234 comes in with request: OP One block with TYPE-A messages created on Tuesday and the End block are sent back: - Block 1 (874 bytes): CCF int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)0852 Msg 1 length ( 4)0424 MDS prefix ( 20) Y header ( 26) *PTYPE-B0101GGGGGG appl data (374)... Msg 2 length ( 4)0424 MDS prefix ( 20) Y header ( 26) *PTYPE-B0101HHHHHH appl data (374)... Interface Control Manager (Messaging Output) 39

45 - Block 2 (END block) CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4) 0012 Msg 1 length ( 4) 0008 text ( 4) END Note: Only Tuesday's file (control number ) was searched for messages. The current day messages were not retrieved because request 'OP' limits the search to the prior days' files. 6. Day 6 - Thursday 10 a.m. Eastern Time The file with Monday's messages was mistakenly deleted at the User's site. Messages 1-3 must be retransmitted from DTC. In order to do that, User 1234 logs on with the request: AD The starting message number is one and the request is limited to three messages. Control number points to Monday's file. The return transmission consists of two blocks: - Block 1 (1078 bytes): CCF Int cntl blk ( 14)... File cntl num ( 8) Data length ( 4)1056 Msg 1 length ( 4)0204 MDS prefix ( 20) Y header ( 26) *PTYPE-A0101EEEEEE appl data (154)... Msg 2 length ( 4)0424 MDS prefix ( 20) Y header ( 26) *PTYPE-B appl data (374)... Msg 3 length ( 4)0424 MDS prefix ( 20) Y header ( 26) *PTYPE-B appl data (374)... - Block 2 (End block) CCF header ( 14)... File cntl number ( 8) Data length ( 4) 0012 Msg 1 length ( 4) 0008 text ( 4) END Interface Control Manager (Messaging Output) 40

46 17 Example Of CCF Errors CCF Error Messages Added For the CDSC Function CCF1101 FUNCTION SELECTION UNSUCCESSFUL: MESSAGE DELIVERY SYSTEM IS DOWN Explanation: The Message Delivery System that maintains the message queues is down. The CCF User cannot retrieve the messages. System Action: The current control card's transmission is not processed by DTC. If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Wait until later and re-execute CCFUSER. If the problem persists, contact DTC Network Operations or, if during normal business hours, User Interface Planning. Issuing Module: CCFSELCT (DTF100) CCF1102 APPLICATION ERROR: CDSC: INVALID REQUEST TYPE (XX); VALID VALUES ARE: 'AD', OP, OD Explanation: The first two characters of the User's request are invalid. XX is the value specified. The valid requests are 'AD' (all data), OP (only previous data) or OD (one day only). System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Correct the Input Card. Issuing Module: CCFRECV (DTF100) CCF1103 APPLICATION ERROR: CDSC: INVALID FILE CONTROL NUMBER (XXXXXXXX); MUST BE NUMERIC Interface Control Manager (Messaging Output) 41

47 Explanation: The File Control number (characters 3-10) in the Input Card is not numeric. XXXXXXXX is the value specified by the User. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Correct the Input Card. Issuing Module: CCFRECV (DTF100) CCF1104 APPLICATION ERROR: CDSC: INVALID STARTING MESSAGE NUMBER (XXXXXX); MUST BE NUMERIC Explanation: The starting message number (characters 11-16) in the Input Card is not numeric. XXXXXX is the value specified by the User. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Correct the Input Card. Issuing Module: CCFRECV (DTF100) CCF1105 APPLICATION ERROR: CDSC: INVALID MESSAGE RANGE (XXXXXX); MUST BE NUMERIC Explanation: The maximum number of messages allowed to be sent in this transmission (characters in the Input Card) is not numeric. XXXXXX is the value specified. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Correct the Input Card. Issuing Module: CCFRECV (DTF100) Interface Control Manager (Messaging Output) 42

48 CCF1106 APPLICATION ERROR: CDSC: FILE CONTROL NUMBER CANNOT BE EQUAL TO ZERO. Explanation: The File Control number equal to zero is allowed only for request 'AD'. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Correct the Input Card by specifying the File Control number, or changing the Request Code to 'AD'. Issuing Module: CCFRECV (DTF100) CCF1107 APPLICATION ERROR: CDSC: STARTING MESSAGE NUMBER CANNOT BE EQUAL TO ZERO Explanation: The starting message number equal to zero is allowed only for request 'AD'. The File Control number must also equal zero. To read the message queue from the beginning, specify as the starting message number. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Correct the Input Card. Issuing Module: CCFRECV (DTF100) CCF1108 APPLICATION ERROR: CDSC: STARTING MESSAGE NUMBER MUST BE EQUAL TO ZERO Explanation: If the File Control number for request 'AD' equals zero, the Starting Message number must also be zero. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. Interface Control Manager (Messaging Output) 43

49 User Response: Move zeros to the Starting Message number. Issuing Module: CCFRECV (DTF100) CCF1109 APPLICATION ERROR: CDSC: INVALID CDSC REQUEST ----> EXTRA RECORDS 'TRANSMITTED' Explanation: The data request specification for CDSC is invalid. CDSC requires one 80- character record to specify the request. More than one record was supplied. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Make sure that only one data request specification is supplied. Issuing Module: CCFRECV (DTF100) CCF1110 APPLICATION ERROR: CDSC: REQUESTED FILE (XXXXXXXX) IS NOT AVAILABLE Explanation: The file specified in the input request is not available. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Wait until later and re-execute CCFUSER. If the problem persists, contact DTC Network Operations or, if during normal business hours, Participant Interface Planning. Issuing Module: CCFRECV (DTF100) CCF1111 APPLICATION ERROR: CDSC: REQUESTED FILE (XXXXXXXX) NOT FOUND Explanation: The file specified in the input request does not exist. Either the File Control number is invalid, or the file is more than three days old and was overwritten with more current data. Interface Control Manager (Messaging Output) 44

50 System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Correct the File Control number. Contact DTC Network Operations or, if during normal business hours, Participant Interface Planning for the correct number or send in request 'AD' with zeros to retrieve the current day's messages. Issuing Module: CCFRECV (DTF100) CCF1112 APPLICATION ERROR: CDSC: REQUESTED FILE (XXXXXXXX) IS CURRENT. OP REQUEST NOT VALID Explanation: The file specified is the current day's file and the request OP asks for prior day's data. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Change the request to AD or change the File Control number. Issuing Module: CCFRECV (DTF100) CCF1113 APPLICATION ERROR: CDSC: NOT ALL FILES NECESSARY TO PROCESS THE REQUEST ARE AVAILABLE Explanation: Not all files that can be accessed while processing the request are available. Multiple files may be searched for an OP or AD request with the file number specified. The first file to be accessed is always the one specified in the request. The last one is the current file for AD or the prior day's file for the OP request. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Contact DTC Network Operations or, if during normal business hours, Participant Interface Planning. It may be necessary to change the request to get around the unavailable file. Issuing Module: CCFRECV (DTF100) Interface Control Manager (Messaging Output) 45

51 CCF1114 APPLICATION ERROR: CDSC: MESSAGE DELIVERY SYSTEM CAME DOWN Explanation: The Message Delivery System that maintains the message queues came down in the middle of transmission. The output file may contain some data records, but it will not have the End message. System Action: If ERROR=GO is in effect, CCFUSER continues and processes the next Input Control Card (and eventually terminates with Return Code 4). Otherwise, CCFUSER immediately terminates with Return Code 8. User Response: Re-execute CCFUSER later. A User may choose to process the partial file or rerun the whole transmission from the beginning. Issuing Module: CCFRECV (DTF100) CCF1120 REQUEST XX ACCEPTED. FILE IS XXXXXXXX, START NO. IS XXXXXX, RANGE IS XXXXXX Explanation: This message displays all fields from the User's request. It confirms that the request was accepted. System Action: Data retrieval and transmission continues. User Response: None Issuing Module: CCFRECV (DTF100) CCF1121 DESTINATION ID IS XXXXXX/XX Explanation: This message displays the destination ID of the message queue being searched for the User's messages. System Action: Data retrieval and transmission continues. User Response: None Issuing Module: CCFRECV (DTF100) Interface Control Manager (Messaging Output) 46

52 CCF1122 MESSAGES ARE BEING SENT FROM FILE XXXXXXXX Explanation: This message displays the File Control number of the file that contains the User's messages. System Action: Data retrieval and transmission continues. User Response: None Issuing Module: CCFRECV (DTF100) CCF1123 NO MESSAGES FOUND IN FILE XXXXXXXX Explanation: The message displays the File Control number of the file that was searched, but does not contain any messages for the User. System Action: Data retrieval and transmission continues. User Response: None Issuing Module: CCFRECV (DTF100) CCF1124 SENT TOTAL NUMBER OF NNNNNN MESSAGES IN MMMMMM BLOCKS Explanation: This message displays the total number of messages and blocks sent to the User. The counts include the final 'END' message (1 message in 1 block). If both counts are equal to 1, the only message sent was the 'NONE' message. System Action: Data retrieval and transmission continues. User Response: None Issuing Module: CCFRECV (DTF100) Interface Control Manager (Messaging Output) 47

53 17.1 Return Codes with New Associated Reason Codes and Messages Return Code 4/8 - Function Level Error Reason Message delivery system is down CCF1101 FUNCTION SELECTION UNSUCCESSFUL: MESSAGE DELIVERY SYSTEM IS DOWN Reason Invalid request for CDSC function CCF1102 APPLICATION ERROR: CDSC: INVALID REQUEST TYPE (XX); VALID ARE: AD, OP, OD CCF1103 APPLICATION ERROR: CDSC: INVALID FILE CONTROL NUMBER MUST BE NUMERIC CCF1104 APPLICATION ERROR: CDSC: INVALID STARTING MESSAGE NUMBER (xxxxxx); MUST BE NUMERIC CCF1105 APPLICATION ERROR: CDSC: INVALID MESSAGE RANGE (xxxxxx); MUST BE NUMERIC CCF1106 APPLICATION ERROR: CDSC: FILE CONTROL NUMBER CANNOT BE EQUAL TO ZERO. CCF1107 APPLICATION ERROR: CDSC: STARTING MESSAGE NUMBER CANNOT BE EQUAL TO ZERO CCF1108 APPLICATION ERROR: CDSC: STARTING MESSAGE NUMBER MUST BE EQUAL TO ZERO CCF1109 APPLICATION ERROR: CDSC: INVALID CDSC REQUEST ----> EXTRA RECORDS TRANSMITTED'. Reason Logical error in the CDSC request. CCF1111 APPLICATION ERROR: CDSC: REQUESTED FILE (xxxxxxxx) NOT FOUND CCF1112 APPLICATION ERROR: CDSC: REQUESTED FILE (xxxxxxxx) IS CURRENT. OP REQUEST NOT VALID Reason Unable to process the request for the CDSC function. CCF1110 APPLICATION ERROR: CDSC: REQUESTED FILE (xxxxxxxx) IS NOT AVAILABLE Interface Control Manager (Messaging Output) 48

54 CCF1113 APPLICATION ERROR: CDSC: NOT ALL FILES NECESSARY TO PROCESS THE REQUEST ARE AVAILABLE Reason CDS transmission interrupted. CCF1114 APPLICATION ERROR: CDSC: MESSAGE DELIVERY SYSTEM CAME DOWN Interface Control Manager (Messaging Output) 49

55 18 Example Of CF2 Errors The table below lists all possible error codes. Error Code Error Description 111 CDSC function not available Past cutoff time Function temporarily disabled 112 Invalid function executed ( not CDSC ) 221 Invalid password record Input file missing Incorrect format of the password record (the first record of the input file) Signon or function in the password record does not match Parameters passed in JCL. 222 Logon unsuccessful Unknown User ID Invalid password 223 User already logged on with the same password. 333 User ineligible for the CDSC function. 444 Duplicate Tran ID* 555 Invalid Group User or User not valid* for that Group User. 601 Message Delivery System is down. 602 Syntax error in CDSC request: Transmitted more than one request record Request is not 'AD', OP, AD File Control number is not numeric Starting message number is not numeric Range is not numeric File Control number is zero for OP or OD request Starting message number is zero with non-zero File Control number Starting message number is not zero when File Control number is zero and request is 'AD' Interface Control Manager (Messaging Output) 50

56 Error Code Error Description 603 Logical error in CDSC request: Specified file does not exist Current file specified for request OP 604 Files necessary to process the request are not available. Contact Network Operations or Participant Interface Planning. 666 No data for User within the requested data type. * 777 DTF compress is running and the files* are temporarily unavailable. 888 DTF database has an error. Contact Network Operations or Participant Interface Planning. * 901 DTC internal error. Contact Network Operations or Participant Interface Planning. * The code is not set by the CDSC function. Interface Control Manager (Messaging Output) 51