CCF/
CCF II/
MDH
2.04
CCF/CCF-II/MDH Transmission Guides
Interface
Control
Manager
(Messaging
Output): Function User's Guide
The Depository Trust Company
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
Copyright © 2004 by The Depository Trust Company (“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)
Copyright © 2004 by The Depository Trust Company
ii
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
Document History
July 2003 - Corrected the byte layout in section 2.04.05 position 17 originally read 17 - 37
MDS Prefix
20 Characters
17 - 36
Contains message sequence number
Message-1
? Characters
37 - ?
Refer to detailed message layout in
Section 2.04.3.
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
iii
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
2.04
Interface
Control
Manager
(Messaging
Output)
Table of Contents
1
Overview ................................................................................................ 1
1.1
1.2
1.3
2
Output/Back-end Reject Message Transaction Header ........................... 4
2.1
2.2
3
Rules For Requesting Messages ......................................................... 7
Format Of The Returned Data ........................................................... 8
Output Message .............................................................................. 9
Back-end Reject Message ................................................................. 9
Last Block Of A Transmission ............................................................ 9
Format Of the End Block................................................................... 9
Format Of The None Block ...............................................................10
Format Of The Output Message ........................................................10
Format of the Back-end Reject Message ............................................11
Request For The Next Transmission ..................................................12
Recovery .......................................................................................13
CCF Interface........................................................................................ 14
4.1
4.2
4.3
5
Output Message Notes ..................................................................... 5
Back-end Reject Notes ..................................................................... 5
Request To Retrieve Messages................................................................ 6
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
4
Message Queue Concept................................................................... 1
Unique Message Identification ........................................................... 2
Message Types ................................................................................ 2
File Preparation ..............................................................................14
4.1.1 Sample CCFUSER Execution For CDSC Function (BTAM): ...........14
4.1.2 Sample CCFUSER Execution For CDSC Function (VTAM): ...........15
4.1.3 CCFUSER Information Messages .............................................15
Restart Procedures .........................................................................15
CCF Output Block Format ................................................................16
CCFII Interface..................................................................................... 17
5.1
5.2
File Preparation ..............................................................................17
Password PSW Input Record (User Transmit To DTC) ..........................18
6
CCFII Error Message Output Record ..................................................... 20
7
RJE Transmissions ................................................................................ 21
7.1
8
Format Of The Output Sent To RJE Users ...........................................21
RJE Header And Trailer Record (DTC Transmits To User) ...................... 23
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
iv
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
9
Example Of RJE Output File .................................................................. 24
10
RJE/SNA Transmissions........................................................................ 25
10.1
Format Of the Output Sent to RJE/SNA Users .....................................25
11
RJE/SNA Header And Trailer Record (DTC Transmits To User).............. 27
12
Example Of RJE/SNA Output File .......................................................... 28
13
BDT Transmissions ............................................................................... 29
14
NDM Transmissions .............................................................................. 30
15
MDH Interface ...................................................................................... 31
15.1
15.2
Request Block Layout ......................................................................31
Returned Block Layout ....................................................................32
16
How To Use The CDSC Function ............................................................ 34
17
Example Of CCF Errors .......................................................................... 41
17.1
18
Return Codes with New Associated Reason Codes and Messages...........48
Example Of CF2 Errors .......................................................................... 50
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
v
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 (MDH) 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
MDH) 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 MDH Users and one for CCF/CCFII Users.
Messages are logged into queues. Each queue is identified by an 8-byte signon and 2digit destination number. DTC allows up to 88 destinations (01 to 88) for every signon.
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
1
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 MDH or from the
DTF database via the CCF or CCFII interface.
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
2
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
•
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)
Copyright © 2004 by The Depository Trust Company
3
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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
Type Indicator
Format/Pic
Position
Description
1 Character
1
Production/Test Indicator
1 Character
2
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
11 - 12
Allows many versions of the message type
with different record layouts.
User Reference Number
6 Characters
13 - 18
Reference number passed from the input
transaction or assigned by the application.
Not currently used.
Addressee ID
8 Characters
19 - 26
The ID of the User or other entity for
whom the transaction is being processed.
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
4
Value '' identifies an output message in
the new format. (Important for MDH Users
who retrieve messages currently
available.) Value '?' identifies a back-end
reject.
'P' for production, 'T' for test messages.
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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)
'*'
(1)
|T/P
|(1)
|Type
|(6)
|Suffix
| (2)
|Version
|(2)
|User
|Ref#
|(6)
| Addressee
| ID
| (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 40byte 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)
?
(1)
|
|T/P
|(1)
|
|Type
|(6)
|
|Suffix
|(2)
|
|Version
|(2)
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
|User
|Ref#
|(6)
5
|Addressee
|ID
|(8)
Application
Data
(Max 1384)
for CCF
Error
Codes
(40)
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 000001 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)
Copyright © 2004 by The Depository Trust Company
6
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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.
MDH Users send this request as a set of parameters in the type '07' block (Data Request Block).
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
7
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
Acceptable Values in the Request for Message Retrieval:
Request
RQ
File Control Number
YYYDDDS
Message Number
NNNNNN
Range
RRRRRR
AD
YYYYDDDS
000001-999999
000000-999999
00000000
000000
000000-999999
OP
YYYYDDDS
000001-999999
000001-999999
OD
YYYYDDDS
000001-999999
000001-999999
3.2 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:
Total
Data
Length
(4)
Interface
Control
Block
(x)
•
Message
1
Length
(4)
Message 1
MDS
Prefix
(20)
..
..
..
Message N
Length
(4)
MDS
Prefix
(20)
Message
N
The Interface Control Block is required by the communication interface. It is 66
bytes for MDH, 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 MDH maximum block length (with
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
8
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 1474.
Messages have the identical format for CCF/CCFII and MDH. There are two possible
message types:
3.3 Output Message
MDS
prefix
(20)
Transaction Header (26)
|
|T/P
|(1)
'*'
(1)
|
|Type
|(6)
|
| Suffix
| (2)
|
|Version
|(2)
|User
|Ref#
| (6)
|Addressee
| ID
|(8)
Application Data
(Max. 1384)
for CCF
3.4 Back-end Reject Message
Input Transaction
MDS
prefix
(20)
Transaction Header (26)
?
(1)
|
| T/P
| (1)
|
|Type
| (6)
|
|Suffix
|(2)
|
|Version
|(2)
|User
|Ref#
|(6)
|Addressee
|ID
|(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)
0012
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
Message 1
Length
(4)
0008
9
Message 1
(4)
'END'
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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)
0022
0018
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
Interface Control Block
Description
Refer to Section 2.03.12 for CCF.
Refer to Section 2.03.13 for CCFII.
Refer to Section 2.03.11 for MDH.
MDS Prefix
1 - 20
Refer to Section 2.04.3.
Transaction Header
1 - 26
Standard Transaction Header. Refer to Section
2.04.2. 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)
Copyright © 2004 by The Depository Trust Company
10
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
3.9 Format of the Back-end Reject Message
Field
Format/PIC
Position
Interface Control Block
Description
Refer to Section 2.03.12 for CCF.
Refer to Section 2.03.13 for CCFII.
Refer to Section 2.03.11 for MDH.
MDS Prefix
1 - 20
MDS PREFIX. Refer to Section 2.04.3.
Transaction Header
1 - 26
Standard Transaction Header. Refer to Section
2.04.2. 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.
N+1 N+40
Reason for rejection.
5 error responses in the form:
- 4-byte field identifier
- 4-byte error code
Error Response
40 Characters
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':
'R':
'U':
'Y':
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
14 - 14
Value ' - '
Message Sequence
Number
6 Numeric
15 - 20
Message sequence number; unique sequence
number for destination ID and MDS file.
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
11
current day original message
current day reprint
current day requested out-of-sequence
prior day
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 000001 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 000001 in the next 'AD' request.
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
12
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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)
Copyright © 2004 by The Depository Trust Company
13
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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.
4.1.1 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
AD00000000000000000000
//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)
Copyright © 2004 by The Depository Trust Company
14
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
FUNCTION=CDSC,DDIN=INPUT,DDOUT=OUTPUT
//
4.1.2 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
AD00000000000000000000
//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
//
4.1.3 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
004-126, 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)
Copyright © 2004 by The Depository Trust Company
15
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
4.3 CCF Output Block Format
Field
Format/PIC
CCF Interface Control
Block
Position
Description
01 - 22
Block Type
1 Character
01
Binary value x '08'.
CCF Flags
1 Character
02
Value x '80' for the last block.
Filler
3 Characters
03 - 05
Not Used; binary zeros.
Sequence
Number
8 Numeric 9(8)
Comp
06 - 09
Block sequence number within the
transmission, used by CCFUSER.
Filler
5 Characters
10 - 14
Binary zeros.
File Control
Number
8 Characters
15 - 22
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 1478.
Message-1-length
4 Numeric
1-4
Length of the message following this field
plus 4. Maximum value is 1474.
MDS Prefix
20 Characters
1 - 20
Contains message sequence number *
Message-1
N Characters
1-N
Refer to Section 2.04.3.
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)
Copyright © 2004 by The Depository Trust Company
16
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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)
Copyright © 2004 by The Depository Trust Company
17
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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
PSW Field
Character
01 - 03
Record Identifier (ALWAYS "PSW")
Signon ID
Character
04 - 09
User Signon ID. Left justified, blank filled.
Password Field
Character
10 - 15
Data Encryption Password assigned by DTC.
Function Name
Character
16 - 21
Function requested: must be CDSC. Left
justified, space filled.
Numeric
22 - 24
Transmission ID. Non-zero value; Zero filled.
Transmission ID
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
18
Description
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 8byte File Control number:
Field
Format/PIC
Position
CCFII
Interface Control Block
File control
number
Description
01 - 08
8 Characters
01 - 08
MDS File Control number in
YYYYDDDS format where:
YYYY: year
DDD: julian day
S: session number
Block-Data-length
4 Numeric
09 - 12
Length of the data following this field
plus 4. Maximum value is 1478.
Message-1-length
4 Numeric
13 - 16
Length of the message following this
field plus 4. Maximum value is 1474.
MDS Prefix
20 Characters
17 - 36
Contains message sequence number
Message-1
? Characters
37 - ?
Refer to detailed message layout in
Request To Retrieve Messages.
4 Numeric
?-?
Length of the message following this
field plus 4.
? 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 BlockData-Length field.
• • •
• • •
Message-N-length
Message-N
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)
Copyright © 2004 by The Depository Trust Company
19
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
6
CCFII Error Message Output Record
If errors occur during processing, one error record is transmitted indicating the problem
encountered.
Field
Format
Position
Record Type
3 Characters
01 - 03
Always ERR
Signon ID
8 Characters
04 - 11
User signon ID; right justified, zero
filled.
Filler
8 Characters
12 - 19
Not used, filled with spaces.
Date
6 Characters
20 - 25
Processing date.
Function Name
6 Characters
26 - 31
CDSC
3 Numeric
32 - 34
Transmission ID set by the User.
Filler
2 Characters
35 - 36
Not used, filled with spaces.
Error Code
3 Characters
37 - 39
Refer to Section 2.04.17 for a list of
possible errors.
Filler
5 Numeric
40 - 44
Not used, filled with zeros.
Start time
6 Numeric
45 - 50
Time the transmission arrived.
End time
6 Numeric
51 - 56
Time the transmission ended.
Transmission ID
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
20
Description
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 2.03.10.)
RQ
(Refer to "Request To Retrieve Messages," Section 2.04.3.)
/*
where:
HHMMSS
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
MMDDYY
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:
POS 05 - 74:
POS 75 - 80:
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
data length increased by 4
first 70 bytes of message block, padded with spaces if the
block is shorter than 70 bytes
NUMBERING SEQUENCE
21
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
Remaining records:
POS 75 - 76:
POS 77 - 80:
record number '01'
block number
POS 01 - 74:
74-byte segment of message block, segment padded with
spaces
NUMBERING SEQUENCE
record number starting with '02'
block number
POS 75 - 80:
POS 75 - 76:
POS 77 - 80:
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
22
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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
Record ID
3 Characters
1-3
Sign-on ID
8 Characters
4 - 11
Function Requested
6 Characters
12 - 17
Always CDSC.
Transmission Date
6 Numeric
18 - 23
Date of transmission (in DDMMYY format)
Transmission Time
6 Numeric
24 - 29
Time of transmission (in HHMMSS format).
6 Numeric
30 - 35
Number of blocks returned in this
transmission.
8 Numeric
36 - 43
Number of 80-byte records in the file,
without Header and Trailer.
31 characters
44 - 74
Reserved field (spaces) for future use.
6 Numeric
75 - 80
Numbering Sequence. Used as data integrity
check.
HDR ===> 000000
TLR ===> 999999
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
23
Description
Always 'HDR' or 'TLR'.
User signon ID.
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 (8+4+4+200+4+200)
•
2nd block: the 'END' message; length = 20 (8+4+4+4)
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:
2
5
77778
123...........4..........4...............67890
HDR......................................00000
0424......................................010001 1st blk:
..............................................020001
..............................................030001
..............................................040001
..............................................050001
..............................................060001
0024..........
010002 2nd blk:
TLR.......................................999999
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
24
1-70
71-144
145-218
219-292
293-366
54+20 spaces
20+50 spaces
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 2.03.10.)
RQ
(Refer to "Request To Retrieve Messages," Section 2.04.3.)
/*
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.
10.1 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 5249 of the first record and positions 1-249 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:
POS 05 - 249:
data length increased by 4
first 245 bytes of message block, padded with spaces
if the block is shorter than 245 bytes
POS 250 - 255: NUMBERING SEQUENCE
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
25
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
POS 250 - 251: record number '01'
POS 252 - 255: block number
Remaining records:
POS 01 - 249: 249-byte segment of message block, last segment
padded with spaces
POS 250 - 255: NUMBERING SEQUENCE
POS 250 - 251: record number starting with '02'
POS 252 - 255: block number
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
26
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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
Record ID
3 Characters
01 - 03
Always 'HDR' or 'TLR'.
Signon ID
8 Characters
04 - 11
User signon ID.
Function Requested
6 Characters
12 - 17
Always CDSC.
Transmission date
6 Numeric
18 - 23
Date of transmission (in DDMMYY
format).
Transmission Time
6 Numeric
24 - 29
Time of transmission (in HHMMSS
format).
6 Numeric
30 - 35
Number of blocks returned in this
transmission.
8 Numeric
36 - 43
Number of 255-byte records in the file,
without Header and Trailer.
206 characters
44 - 249
Reserved field (spaces) for future use.
6 Numeric
250 - 255
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
27
Description
Numbering Sequence. Used as data
integrity check.
HDR ===> 000000
TLR ===> 999999
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 2.04.5:
•
1st block: two output messages; length = 420 (8+4+4+200+4+200)
•
2nd block: the 'END' message; length = 20 (8+4+4+4)
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:
1
2222222
2
7
4555555
1234 ........ 4 ...........5.............9012345
HDR .........
0424 ........
...............
0024 ........
TLR ..........
.............
.............
.............
.............
.............
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
..............000000
..............010001
..............020001
..............010002
..............999999
28
header
1st blk:
2nd blk:
trailer
1 - 245 data
175 + 74 spaces
20 + 225 spaces
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 2.03.10.)
RQ
(Refer to "Request To Retrieve Messages," Section 2.04.3.)
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
29
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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)
Copyright © 2004 by The Depository Trust Company
30
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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
2.03.10.)
RQ
(Refer to "Request To Retrieve Messages," Section 2.04.3.)
15
MDH Interface
MDH Users are already familiar with the message queue concept and the interactive way of
receiving data from DTC.
Currently, MDH 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 MDH Users use the MDLS function. This
function accepts the request in the format described in Section 2.04.3, Request To
Retrieve Messages, and gives access to the current and prior days messages.
All MDH 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.
15.1 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
Block Type
2 Characters
01 - 02
Value 07
Time-stamp
6 Characters
03 - 08
Time received (in HHMMSS format).
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
31
Description
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
User ID
8 Characters
09 - 16
User signon, numeric (00002199)
or alphanumeric (G0000123).
2 Numeric
17 - 18
Entered by sender from Type 02 logon
response.
4 Characters
19 - 22
Internal to MDH.
38 Characters
23 - 60
Value Spaces.
Function Requested
4 Characters
61 - 64
Value 'MDLS'.
Request Type
2 Characters
65 - 66
Value 'AD', OP or OD.
File Control Number
8 Characters
67 - 73
YYYYDDDS
Starting Message
Number
6 Numeric
75 - 80
Numeric: 6 digits.
Maximum Number To
Deliver
6 Numeric
81 - 86
Numeric: 6 digits.
Individual User Number
LU6.2-TERMID
Filler
15.2 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 MDH User has the following format:
Field
Format/PIC
MDH Interface
Control Block
Position
Description
01 - 66
Block Type
2 Characters
01 - 02
Value 08
Time-stamp
6 Characters
03 - 08
Time received in HHMMSS format.
User ID
8 Characters
09 - 16
User signon, numeric (00002199) or
alphanumeric (G0000123).
Individual User
Number
2 Numeric
17 - 18
Internal to MDH.
LU6.2-TERMID
4 Characters
19 - 22
Internal to MDH.
Filler
30 Characters
23 - 52
Value Spaces
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
32
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
Field
Format/PIC
Position
53 - 60
Description
File Control
Number
8 Characters
Response Code
1 Character
Response Reason
1 Character
62 - 62
A:
B:
C:
D:
E:
F:
G:
M:
N:
Transactions In
Block
4 Numeric
63 - 66
Number of messages returned in this block.
Block-DataLength
4 Numeric
67 - 70
Length of the data following this field plus
4.
Message-1Length
4 Numeric
71 - 74
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
?-?
MDH 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.
61 - 61
MDS File Control number in the format
YYYYDDDS.
A:
R:
accepted
rejected
Not signed on
Past cutoff
Not in 'MDLS' function
Invalid range request
Function name not 'MDLS'
Invalid request type
Invalid File Control Number
Message Delivery is quiesced
File Control Number is not prior day for
OP request
P: MDH is down
• • •
• • •
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
33
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 1234.
1. 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 00001234/02.
•
10 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):
AD00000000000000000000
As a result, two CCF blocks are returned to the User:
-
Block 1 (858 bytes)
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
MDS prefix
std header
Appl data
Msg 2 length
MDS prefix
header
appl data
( 14) ..............
( 8) 19932870
( 4)0836
( 4)0204
( 20) O 0000123402-000001
( 26) *PTYPE-A0101AAAAAA00001234
(154) ..........................
( 4)0204
( 20) O 0000123402-000002
( 26) *PTYPE-A0101BBBBBB00001234
(154) ..........................
Msg 3 length
MDS prefix
header
appl data
( 4) 0424
( 20) O 0000123402-000003
( 26) *PTYPE-B010100000100001234
(374) ..........................
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
34
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
-
Block 2 (END block):
CCF Int cntl blk ( 14) ..............
File cntl num
( 8) 19932870
Data length
( 4) 0012
Msg 1 length
( 4) 0008
text
( 4) END
The User de-blocks and processes the data. Message number 000003 from File 19932870
was the last one received. The next transmission starts with message number 000004. The
new request should be as follows:
AD19932870000004000000
•
2 p.m. Eastern Time
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 1234.
•
5 p.m. Eastern Time
One more Type-B message is created for User 1234.
2. Day 2 - Friday
•
9 p.m. Eastern Time
One TYPE-A message is created for User 1234 and sent to destination 00001234/02.
•
11 p.m. Eastern Time
User 1234 logs on and executes the CDSC function with the 'AD' request prepared
yesterday:
AD19932870000004000000
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)
Copyright © 2004 by The Depository Trust Company
35
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
-
Block 1 (714 bytes):
CCF int cntl blk ( 14)
..............
File cntl num
( 8) 19932870
Data length
( 4) 0692
Msg 1 length
( 4) 0264
MDS prefix
( 20)
Y 0000123402-000004
header
( 26)
*PTYPE-C010100001500001234
appl data
(174)..........................
err. codes
( 40)
..........................
Msg 2 length
( 4) 0424
MDS Prefix
Y 0000123402-000005
header
( 26)
*PTYPE-B010100000100001234
appl data
(374)..........................
-
Block 2 (230 bytes):
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
MDS prefix
header
appl data
-
( 14) ..............
( 8) 19932880
( 4)0208
( 4)0204
( 20) O 0000123402-000001
( 26) *PTYPE-A0101CCCCCC00001234
(154) ..........................
Block 3 (END block)
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
text
( 14) ..............
( 8) 19932880
( 4)0012
( 4)0008
( 4) END
The User de-blocks and processes the data. Message number 000001 from File 19932880
was the last one received. The next transmission should start from message number
000002. The new request is:
AD19932880000002000000
•
2 p.m. Eastern Time
User 1234 logs on to pick up today's messages starting from message number 000002. The
request sent is:
AD19932880000002000000
In response, the User gets the None block because no messages were created since the last
transmission.
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
36
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
-
Block 1 (NONE block):
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
text
( 14) ..............
( 8) 19932880
( 4)0022
( 4) 0018
( 14) NONE0000123402
3. Day 3 - Monday
•
9 a.m. Eastern Time
One TYPE-A message and three TYPE-B messages are created for User 1234. All four
messages are sent to destination 00001234/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:
AD19932880000002000000
All messages created on Monday are sent back in two blocks followed by the End block.
-
Block 1 (1078 bytes):
CCF int cntl blk
File cntl num
Data length
Msg 1 length
MDS prefix
header
appl data
Msg 2 length
MDS prefix
header
appl data
Msg 3 length
MDS prefix
header
appl data
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
37
( 14) ..............
( 8) 19932910
( 4)
1056
( 4)
0204
( 20)
Y 0000123402-000001
( 26)
*PTYPE-A0101EEEEEE00001234
(154) ..........................
( 4)
0424
( 20)
Y 0000123402-000002
( 26)
*PTYPE-B010100030000001234
(374) ..........................
( 4)
0424
( 20)
Y 0000123402-000003
( 26)
*PTYPE-B010100040000001234
(374) ..........................
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
-
Block 2 (230 bytes):
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
MDS prefix
header
appl data
-
Block 3 (END block)
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
text
Note:
( 14) ..............
( 8) 19932910
( 4)
0208
( 4)
0424
( 20)
Y 0000123402-000004
( 26)
*PTYPE-B010100050000001234
(374) ..........................
( 14) ..............
( 8) 19932920
( 4)
0012
( 4)
0008
( 4)
END
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:
AD19932910000005000000
•
2 p.m. Eastern Time
Two TYPE-A messages are created for User 1234.
5. Day 5 - Wednesday
•
9 a.m. Eastern Time
Two TYPE-B messages are created for User 1234.
•
11 a.m. Eastern Time
User 1234 logs on to DTC to retrieve all undelivered messages with the request:
AD19932910000005000000
The Transmission is unsuccessful because yesterday's file (Tuesday's file with control
number 19932920) 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)
Copyright © 2004 by The Depository Trust Company
38
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
AD00000000000000000000
The transmission is now successful and two TYPE-B messages are sent back:
-
Block 1 (874 bytes):
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
MDS prefix
header
appl data
Msg 2 length
MDS prefix
header
appl data
-
( 14) ..............
( 8) 19932930
( 4)0852
( 4)0424
( 20) O 0000123402-000001
( 26) *PTYPE-B010100010000001234
(374) ..........................
( 4) 0424
( 20) O 0000123402-000002
( 26) *PTYPE-B0101000200
(374) ..........................
Block 2 (End block)
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
text
•
( 14) ..............
( 8) 19932930
( 4)0012
( 4)0008
( 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:
OP19932910000005000000
One block with TYPE-A messages created on Tuesday and the End block are sent back:
-
Block 1 (874 bytes):
CCF int cntl blk
File cntl num
Data length
Msg 1 length
MDS prefix
header
appl data
Msg 2 length
MDS prefix
header
appl data
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
39
( 14) ..............
( 8) 19932920
( 4)0852
( 4)0424
( 20) Y 0000123402-000001
( 26) *PTYPE-B0101GGGGGG00001234
(374) ..........................
( 4)0424
( 20) Y 0000123402-000002
( 26) *PTYPE-B0101HHHHHH00001234
(374) ..........................
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
-
Block 2 (END block)
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
text
Note:
( 14) ..............
( 8) 19932920
( 4) 0012
( 4) 0008
( 4) END
Only Tuesday's file (control number 19932920) 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:
AD19932910000001000003
The starting message number is one and the request is limited to three messages. Control
number 19932910 points to Monday's file.
The return transmission consists of two blocks:
-
Block 1 (1078 bytes):
CCF Int cntl blk
File cntl num
Data length
Msg 1 length
MDS prefix
header
appl data
Msg 2 length
MDS prefix
header
appl data
Msg 3 length
MDS prefix
header
appl data
-
( 14) ..............
( 8) 19932910
( 4)1056
( 4)0204
( 20) Y 0000123402-000001
( 26) *PTYPE-A0101EEEEEE00001234
(154) ..........................
( 4)0424
( 20) Y 0000123402-000002
( 26) *PTYPE-B010100030000001234
(374) ..........................
( 4)0424
( 20) Y 0000123402-000003
( 26) *PTYPE-B010100040000001234
(374) ..................................
Block 2 (End block)
CCF header
File cntl number
Data length
Msg 1 length
text
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
( 14) ..............
( 8) 19932910
( 4) 0012
( 4) 0008
( 4) END
40
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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)
Copyright © 2004 by The Depository Trust Company
41
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 17-22 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)
Copyright © 2004 by The Depository Trust Company
42
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
•
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 00001 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)
Copyright © 2004 by The Depository Trust Company
43
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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 80character 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)
Copyright © 2004 by The Depository Trust Company
44
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
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)
Copyright © 2004 by The Depository Trust Company
45
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
•
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)
Copyright © 2004 by The Depository Trust Company
46
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
•
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)
Copyright © 2004 by The Depository Trust Company
47
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
17.1 Return Codes with New Associated Reason Codes and Messages
Return Code 4/8 - Function Level Error
Reason 122 -- Message delivery system is down
•
CCF1101
FUNCTION SELECTION UNSUCCESSFUL: MESSAGE DELIVERY
SYSTEM IS DOWN
Reason 123 -- 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 124 -- 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 125 -- Unable to process the request for the CDSC function.
•
CCF1110
APPLICATION ERROR: CDSC: REQUESTED FILE (xxxxxxxx) IS
NOT AVAILABLE
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
48
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
•
CCF1113
APPLICATION ERROR: CDSC: NOT ALL FILES NECESSARY TO
PROCESS THE REQUEST ARE AVAILABLE
Reason 126 -- CDS transmission interrupted.
•
CCF1114
APPLICATION ERROR: CDSC: MESSAGE DELIVERY SYSTEM
CAME DOWN
Interface Control Manager (Messaging Output)
Copyright © 2004 by The Depository Trust Company
49
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
18
Example Of CF2 Errors
The table below lists all possible error codes.
Error Code
111
Error Description
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)
Copyright © 2004 by The Depository Trust Company
50
January 2004
CCF/
CCF II/
MDH
THE DEPOSITORY TRUST COMPANY
Error Code
603
Error Description
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)
Copyright © 2004 by The Depository Trust Company
51
January 2004