This section describes the specifications (requirements) for the SCP CMSDB-SMS/800 interface.
From each SCP, there shall be four socket connections to SMS/800 (two to each of the two Data Communication Manager (DCM) servers in SMS/800). Of the two connections to each SMS/800 DCM, one connection is for SCP Node messages and the other connection is for SCP CMSDB messages.
CMSDB messages shall be sent on CMSDB connections. NODE messages shall be sent on Node connections.
For information regarding connectivity to the SMS/800 machines at the Data Center, refer to the document titled: SMS/800 Network Connectivity Guide, written by the Data Center and viewable at Somos’ Portal.
- All SCPs must support regular Customer Records (CRs), Pointer records and Template records and send back responses to the SMS/800 platform as specified in section 7.1.
3.1 SCP Load
For the SCP Database Load process, the Data Center generates SCP Load files (one per NPA) containing Customer Records copied from SMS/800 platform. The SCP uses these files to load its database, and generates the SCP Load response files (one per NPA). The Customer Record updates for the SCP Incremental Load file and the corresponding responses for the SCP Response file are in the same format as messages received over the SMS/800-SCP data communication links.
The following specifies the data content and file attributes of both the SCP Incremental Load and SCP Response files.
a. Customer Records that are built as regular Customer Records or Pointer records can be sent in the same load file.
b. Pointer records will be included by the SMS/800 platform in the same load file as Customer Records.
c. Template records will be sent in a separate Load file from regular Customer Records and Pointer records.
3.1.1 SCP Load File Specifications
1. The application information is in ASCII format.
2. Records: The following tables contain a description of the three types of records generated by SMS/800, and the attributes of the file. The SCP Incremental Load file consists of the following:
a. One Header Record.
b. Multiple Update Customer Record (UPD-UCR) Records.
c. One Trailer Reco
d. The 'SCP-ID’ field in the Header Record is preassigned by the SMS/800
Administration Center.
e. The ‘TOTAL’ field in the Trailer Record contains the number of UPD-UCR records on the SCP Incremental Load file.
Header Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
1 |
4 |
SCP-ID |
Character |
e.g. UT01 (in ASCII) |
5 |
1 |
LOAD-TYPE |
Character |
Value:I (for Incremental Load) |
6 |
9 |
Filler |
Binary |
Value:Zero |
UPD-UCR Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
1 |
1 |
Sequence # |
Binary |
Sequence # |
2 |
1 |
More Data Flag |
Character |
Value: Y or N |
3 |
32000 |
UPD-UCR data |
see UPD-UCR section for details |
|
Trailer Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
1 |
5 |
EOF-MARKER |
Character |
Value: $$$$$ (in ASCII) |
6 |
4 |
TOTAL |
Binary |
Total Count of UPD-UCRs |
10 |
4 |
SUCCESS |
Binary |
Value: Zero |
14 |
4 |
FAIL |
Binary |
Value: Zero |
File Attributes |
|
Record Format: |
Variable Length |
Logical Record Length: |
32,006 |
3.1.2 SCP Load & Response Process:
A. In order to accommodate greater than 32K UPD-UCR records, the UPD-UCR will be segmented into 32,000 byte segments. Each record will contain a Sequence number and a ‘More Data Flag’. It is the responsibility of the SCP process to re-assemble the UPD-UCR message to form the complete message.
B. Please contact the Data Center before sending an SCP Load file to confirm with them the supported media format. Note: The Data Center sends the SCP load files (one file per NPA) to the SCP Owner/Operator using USB flash drive (tapes are no longer being used). The SCP Load Response files (one file per NPA) can be sent back to Data Center using USB flash drives or can be FTP’d to the Data Center.
C. Due to the volume of data in a load file, the data may be separated by NPA so that there is a separate load file per NPA. In the Template Feature, there will be a separate load file for the Template Records (routing templates).
D. Each file will be a flat file with 100 bytes fixed length records containing ASCII and binary dat
E. When an SCP upgrades to support the SMS/800 Template Feature, then the SCP owner/operator needs to coordinate with Software Support for Software Support to generate and send a load file with Templates records and a separate load file(s) with Pointer records.
F. The SCP Load process steps are as follows:
(a) Data Center runs the SCP Load jobs on the SMS/800 mainframe MVS system to generate SCP Load files (one file per NPA).
(b) The Data Center then copies the SCP Load files to USB flash drives and mails them to the SCP Owner/Operator.
(c) The SCP Owner/Operator needs to load its SCP database with the Load files. The SCP’s database Load process on the SCP needs to create Load Response files (one Response file per NPA).
(f) The SCP Owner/Operator sends their Response files to the Data Center via FTP or copies their Response files to USB flash drive(s) and mails the flash drive(s) back to Data Center.
3.1.3 SCP Load Response File Specifications
1. The application information is in ASCII.
2. Records: The following tables contain a description of the three types of records generated by the SCP, and the attributes of the file. The SCP Load Response file (abbreviated SCP Response file) consists of the following:
a. One Header Record.
b. Multiple Responses to each Update Call Processing Record (RSP-RCU).
c. One Trailer Reco
d. The ‘SCP-ID’ field on the SCP Response file must match the SCP-ID field on the SCP Load file.
e. The ‘TOTAL’ field in the Trailer Record contains the number of UPD-UCR records previously sent on the SCP Incremental Load file.
f. The ‘SUCCESS’ and FAIL fields on the Trailer Record contain a count of the number of SCP successful updates and SCP failed updates, respectively.
SCP Load Response File Records Layout:
Header Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
1 |
4 |
SCP-ID |
Character |
e.g. ZZ01 (in ASCII) |
5 |
1 |
LOAD-TYPE |
Character |
Value: I (for Incremental Load) |
6 |
17 |
Filler |
Binary |
Value: Zero |
Trailer Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
1 |
5 |
EOF-MARKER |
Character |
Value: $$$$$ (in ASCII) |
6 |
4 |
TOTAL |
Binary |
Total Count of UPD-UCRs |
10 |
4 |
SUCCESS |
Binary |
Count of Successful Updates |
For Multiple RSP-RCU Records: Refer to the RSP-RCU specification (in section 7.1.2) for the format of the RSP-RCU record.
Trailer Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
14 |
4 |
FAIL |
Binary |
Count of Failed Updates |
File Attributes |
|
Record Format: |
Fixed Length |
Logical Record Length: |
100 bytes |
Notes Regarding SCP Load Response Files:
A. Each record has data that is preceded with 2 bytes of binary zeros and padded at the end with binary zeros to make the record a total of 100 bytes.
B. The SCP software writes 8100 bytes of data (or 81 records) to file at a time. The load response file has an SMS Header record, followed by RSP-RCU records, and then an SMS Trailer reco
C. Each file will be a flat file with 100 bytes fixed length records containing ASCII and binary dat Please contact the Data Center before creating or sending any files to confirm the media format they support.
D. The SCP ID is preceded by two binary zeros and the SCP ID must start at column 3 (e.g., 00ZZ01 where in this example “ZZ01” is the SCP ID), and pad (enter) binary zeroes to fill-up exactly 100 bytes for this line (row).
E. The “RSP-RCU” is preceded by two binary zeros so that “RSP-RCU” starts at column 3 (i.e., 00RSP-RCU), and pad (enter) binary zeroes to fill-up exactly 100 bytes for this line (row).
F. Pad (enter) binary zeroes to make up 100 bytes for each line (row).
Example of the Load Response File Format:
00ZZ010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00RSP-RCU:2015-02-27,16-38-43-EST:::COMPLD,00::CRN=$..........,EFD="2011043041",ROR="BRX01";00000000
00RSP-RCU:2015-02-27,17-21-26-EST:::COMPLD,00::CRN=$..........,EFD=”2012031656”,ROR="BRT01";00000000
3.2 SMS/800-SCP Audit
One method of auditing between SMS/800 and a SCP site requires that SCP send to SMS/800 a file containing all Customer Records residing in the SCP and a separate file containing all Template Records residing in the SCP. SMS/800 will detect any discrepancies and will generate a SMS/800 mail message to the Help Desk (Resp Org BRSAC) mailbox when the audit job has completed. The following specifies the data content and file attributes of the SMS/800-SCP Audit file.
a. Customer records that are built as regular Customer Records or Pointer Records can be sent in the same audit/reverse audit file.
b. Pointer records will be sent from SMS/800 in the same file as with Customer Records.
c. Template records must be sent in a separate audit/reverse audit file from regular Customer Records and Pointer records.
d. Template records will not be sent to BX01 SCP.
3.2.1 SCP Audit File Specification
The application information is in ASCII. There are three different record types, Date Record, CLLI™ Code Record, and the Dialed# Record. There is no header or trailer record. The space character inside blank records should be represented as Hexadecimal 40.
Dialed # records within the Audit file must be sorted by Customer Record Number (CRN), in ascending order.
1. The SCP Audit file consists of the following, in the order specified below:
a. Two blank records
b. One Date Record
c. One blank record
d. One CLLI Code Record
e. 5 blank records
f. Number of Dialed# Records (Dialed# Records must be sorted by Customer Record Number (CRN), in ascending order).
g. blank record
2. For the Reverse Audit file, the SCP sends, in the file, a list of the Customer Records (CRs) in the SCP.
Audit File Records Layout:
Date Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
20 |
26 |
DATE |
Character |
Date and Time of Audit
Must begin in position 20. SMS/800 does not process positions 1-19. DD-MMM-YYYY HH:MM:SS:TTZZZ DD = 2-digit day-of-month (valid entries: 01-31)
MMM = 3-character month (valid entries: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC)
HH = 2-digit hour (valid entries: 00-23 )
MM = 2-digit minutes (valid entries: 00-59)
SS = 2-digit seconds (valid entries: 00-59)
TT = 2-digit tenths-of-seconds (valid entries: 00-59)
ZZZ = 3-character time zone (valid entries: BST, HST, YST, PST, MST, CST, EST, AST, NST). For ZZZ parameter in this data record, SMS/800 only looks at the 1st character (e.g., C for Central Time). |
CLLI Code Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
18 |
11 |
CLLI |
Character |
CLLI Code of SCP. CLLI code must begin in position 18. (SMS/800 does not process positions 1-17). |
Dialed# Record Layout |
||||
Position |
Length |
Name |
Data Type |
Notes |
1 |
12 |
Dialed# |
Character |
NPA-XXX-XXXX |
13 |
1 |
Unused |
Character |
Value: Blank (e.g., a space character) |
14 |
17 |
Effective Date/Time |
Character |
DD-MMM-YYYY HH:MM |
31 |
1 |
Unused |
Character |
Value: Blank (e.g., a space character) |
32 |
5 |
RESP ORG |
Character |
If Value: XXXXX, RESP ORG not stored in CMSDB |
File Attributes |
|
Record Format: |
Fixed Length Record |
Logical Record Length: |
100 bytes |
Notes Regarding Audit Files:
A. Each record has data that is preceded with 2 bytes of binary zeros and padded at the end with binary zeros to make the record a total of 100 bytes.
B. SMS/800 supports FTP method of Reverse Audit files from an SCP to SMS/800.
C. SMS/800 only supports the time zones listed in this specification, and GMT is not supported.
D. Each file will be a flat file with 100 bytes fixed length records containing ASCII and binary data. Please contact Data Center before creating or sending a file to confirm the media forma that the Data Center supports.
3.3 Graceful Shutdown Procedures
See SR-4959 for a discussion of TCP/IP shutdown procedures.