Atalla Boxcar Reference Guide

Transcription

1 Atalla Boxcar Reference Guide Abstract This document describes Boxcar, its interface to the Atalla Network Security Processor, and the parameters used to start, initialize, and configure the Boxcar process. Boxcar supports all Atalla NSP models that have an Ethernet TCP/IP interface. This release is available through the HP NonStop eservices portal. It runs exclusively on HP Integrity NonStop servers. Product Version Boxcar Version T0409H01-AAJ Part Number Published May

2 Document History Part Number Product Version Published T0409H01 June T0409H01AAG March T0409H01AAH October 2007 New and Changed Information A new parameter has been added, see BOXCAR-LOGMSGWRITEINTERVAL. If the value specified for the BOXCAR-RECV-DEPTH parameter is less than one or greater than 4047, the default value of 4047 will be used. 2

3 Boxcar Overview Boxcar is a process that runs in a HP Non-Stop server. It is designed to improve the overall efficiency of communication between host application process(es) and Atalla NSPs that support Ethernet TCP/IP communications. Boxcar acts as a funnel for transactions, accepting commands from a large number of application processes and sending them to available sockets on the Atalla NSP. Boxcar provides an interface to one Atalla NSP. Multiple NSPs would each have their own Boxcar process running on the HP Non-Stop server. Boxcar is a Non-Stop context free server application. The ability to be context free comes from the I/O buffer design, and allows more efficient Boxcar operation, as it is not necessary to maintain and checkpoint contexts for each Boxcar opener. Boxcar maintains the contexts of application processes in a buffer using a multi-threaded process to increase communication efficiency. Boxcar sends a command to the first open, available socket. Boxcar can send up to a maximum of 14 commands simultaneously. When all sockets are busy, Boxcar queues subsequent commands in a buffer, up to a maximum of 4047 commands, and thereby effectively supports up to 4047 opens. Boxcar does not perform any error checking on the command syntax that a host application is sending to the Atalla NSP. The Atalla NSP is responsible for formatting and returning error codes in response to any invalid or improperly formatted commands. This off- loads bookkeeping tasks from Boxcar and improves its efficiency. By default, Boxcar requires 133 MB of swap space to start, if sufficient disk space is not available, boxcar will abend. Software Installation Boxcar (product ID T0409) is distributed as an independent product (IP), follow the installation instructions provided on the CD-ROM. Initialization Log Boxcar is started and initialized via an obey file. Initialization includes opening the log file or process, establishing the socket connections, and sending an echo command to each socket. The obey file is also used to establish the Boxcar runtime configuration. See Sample Obey File. When the Boxcar process is started, it first attempts to open a log. The Boxcar log can be a disk file or a process. The log is opened first so any subsequent error conditions can be recorded. If the log cannot be opened, a fatal error is generated and Boxcar abends. When Boxcar starts, it logs the configuration information and the status of its backup process. It also sends commands <1101#>, <9A#ID#>, and <9A#KEY#> to the Network Security Processor to obtain configuration information. The responses to these commands are recorded in the log. 3

4 During operation, Boxcar status and error messages are written to the Boxcar log. By default, messages are written using a waited write operation. Certain messages can be written using a no-waited write operation, see BOXCAR-LOGMSGWRITEINTERVAL. Error responses generated by the Network Security Processor in response to invalid commands, are not logged by Boxcar, they are returned to the host application process. If the Boxcar log file fills up, an error 45 will be written to $0 whenever Boxcar attempts to write a message to its log file. To prevent this situation, increase the MAXEXTENTS parameter on the log file. Queue Depth Boxcar, using a no-waited write operation, creates a log entry whenever a queue depth of two or more incoming requests, is cleared. The log entry states time when the queue was cleared, how long the queue lasted, and the maximum number of incoming requests that were queued. The example log entry below indicates that Boxcar queue depth reached or exceeded 2 at 17:22:12, the queue cleared at 17:24:22 and the maximum number of incoming queued requests was 6. \CHIP.$BOXB: 30APR :24:22 Queue Depth = 6, cleared in 2 mins, 10 secs and 0 ms. 4

5 Example log file The following is an example of a Boxcar log file after a successful startup: \BLOPS.$BOXB: 30APR :46:52 BOXCAR VERSION 2.7 STARTED \BLOPS.$BOXB: 30APR :46:52 Open $0 log Successfully \BLOPS.$BOXB: 30APR :46:52 BOXCAR-LOGMSGWRITEINTERVAL = 30 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-LOGFILE = BOXLOG \BLOPS.$BOXB: 30APR :46:52 BOXCAR-BACKUPCPU = 1 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-DEVICE-NAME = \BLOPS.$BOXB: 30APR :46:52 BOXCAR-DEVICE-TYPE = 32-1 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-CRLF-REQUIRED = NO \BLOPS.$BOXB: 30APR :46:52 Atalla NSP Option 23 will be enabled per your request. ( NSP responses with no CR/LF ) \BLOPS.$BOXB: 30APR :46:52 BOXCAR-RECV-DEPTH = 4047 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-MAXSOCKET-OPENS = 14 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-SOCKET-RESET-LEVEL= 200 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-ETHERNET-PORT = 7000 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-TCPIP-PROCESS-NAME = $ZTC0 \BLOPS.$BOXB: 30APR :46:52 TCPIP PROCESS = $ZTC0 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-SOCKET-TIMEOUT = 100 \BLOPS.$BOXB: 30APR :46:52 BOXCAR-MAX-FLATSEG-SIZE = \BLOPS.$BOXB: 30APR :46:52 OBTAINED POOL OF SIZE \BLOPS.$BOXB: 30APR :46:52 SEND : <101#023E#> \BLOPS.$BOXB: 30APR :46:52 RECV : <201#Y#> \BLOPS.$BOXB: 30APR :46:52 Successfully Enabled option 23 on the Atalla device at IP address \BLOPS.$BOXB: 30APR :46:52 SEND : <9A#ID#> \BLOPS.$BOXB: 30APR :46:52 RECV : <AA#V1BMVR#A9100,Import="P",Export="P"#4,S,S#00#10#31,32,#5E# #93,99,9A,9E,9F##101,105,106,107,108,109#113####335#########> \BLOPS.$BOXB: 30APR :46:52 SEND : <1101#> \BLOPS.$BOXB: 30APR :46:52 RECV : <2101#HP Atalla 5

6 A9100-AKB Version: 3.60C, Date: Feb , Time: 15:43:34#80F4#0#> \BLOPS.$BOXB: 30APR :46:52 SEND : <9A#KEY#> \BLOPS.$BOXB: 30APR :46:52 RECV : <AA#1000#MFK1#B196#T#PMFK1#8792#D#######> \BLOPS.$BOXB: 30APR :46:52 BOXCAR DEVICE HAS BEEN INITIALIZED \BLOPS.$BOXB: 30APR :46:52 Boxcar established 14 of 14 sockets on on port 7000 \BLOPS.$BOXB: 30APR :46:52 BOXCAR Backup Process Created OK \BLOPS.$BOXB: 30APR :46:52 BOXCAR Backup Process Initialized. Boxcar Backup Process If you specify a backup process using BOXCAR-BACKUPCPU, Boxcar starts the backup process and does a FILE_OPEN_CHKPT on all files opened by BOXCAR, $RECEIVE, the Boxcar log, and the Atalla NSP, it then CHECKPOINTXs the data stack. If there are errors on any of these operations, Boxcar writes an error message to the Boxcar log and abends. If a non-existent CPU, or if a CPU that is down, has been specified, Boxcar logs the error, logs that it is not running as a non-stop process and continues without a backup process. If the backup process was not created because the CPU was down, when that CPU is later restored, Boxcar receives a CPU up message and attempts to create the backup process. If a socket connection to the NSP fails to open when the Boxcar backup process takes over, the Boxcar process will try five times to open the socket connection. A delay of four seconds is added to each attempt to open the socket. The first attempt will occur after one second. The second attempt will occur after five seconds. The third attempt will occur after nine seconds. The fourth attempt will occur after 13 seconds. The final attempt will occur after 17 seconds. Sending an Echo Command to each socket After opening the configured number of sockets, Boxcar attempts to communicate with each open socket by sending it an echo command. If a communications error occurs or the response is not correct, Boxcar resends the command two additional times. If Boxcar is still unable to communicate with the socket, it closes the socket, logs the error, and tries the next socket. If Boxcar is unable to communicate with any sockets, it logs the error and terminates. Carriage Return Line Feed appended to the NSP response See BOXCAR-CRLF-REQUIRED. 6

7 Command Processing After Boxcar is started, initialized, and configured, it performs a READUPDATEX on $RECEIVE, then begins processing host application commands, sending and receiving commands and responses through the sockets, and replying to the host applications. Each time Boxcar receives an NSP command it updates a counter. When the counter is equal to 2000 times the value of BOXCAR-SOCKET-RESET-LEVEL, Boxcar attempts to restore any invalid sockets, and logs the number of sockets restored. The log entry below indicates no sockets were found in an invalid state. \CHIP.$BOXB: 25MAR :25:27 Number of Sockets restored in SOCKET_RESET_LEVEL = 0 Error Handling When a TCP/IP communications error occurs, Boxcar returns an error 311 to the host application. Boxcar closes the socket on the NSP and attempts to open a new socket connection on the NSP. It then continues to process other host applications commands and NSP responses. If Boxcar is not able to open a new socket, it will mark the socket as bad, and attempt to recover it when the BOXCAR-SOCKET-RESET-LEVEL value is reached. Below are some typical causes of an error 311 being returned to the host application. Boxcar received a zero length string from the TCP/IP process. Boxcar is unable to send the complete command to the NSP. Boxcar failed to receive a response from the NSP. Note. When the host application receives an error 311 it should retry the command. Recovering Sockets There are three conditions in which Boxcar will attempt to recover a socket. If Boxcar is not able to open a new socket, it will mark the socket as bad, and attempt to recover it when the BOXCAR-SOCKET-RESET-LEVEL value is reached. It will also attempt to recover any socket that has been in the receiving state for more than 10 minutes. BOXCAR will report the results of the socket recovery attempt as follows: Socket Recovery: # of Invalid sockets encountered = 3. Sockets restored from Invalid state = 3. Socket Recovery: # of Invalid sockets (in receiving state over 10 minutes) encountered = 2. Sockets recovered from Invalid Receiving State = 1. 7

8 Boxcar Parameter Definitions The following is a description of the Boxcar parameters, listed in alphabetical order. BOXCAR-BACKUPCPU Specifies the CPU number which runs the Boxcar backup process. This parameter is optional, if not specified, Boxcar does not run as a persistent process pair. BOXCAR-CRLF-REQUIRED This parameter is required, if not specified, Boxcar logs an error, and terminates. Set this parameter to YES if a Carriage Return and Line Feed (CRLF) characters should be appended to each NSP response. Set this parameter to NO if the CRLF characters should not be appended to each NSP response. Based on the value of this parameter Boxcar will send a command 101 to the NSP to set option 23 to either enable or disable the CRLF on the NSP s response. A log entry will be generated based on the value of this parameter. For example if this parameter is set to YES the following message will appear in the Boxcar log. Atalla NSP Option 23 will be disabled per your request. ( NSP responses with CR/LF ) Caution. If NSP option 23 is changed via the Secure Configuration Assistant (SCA) or via an NSP command 101 after the Boxcar process has started, you must stop and restart the Boxcar process prior to performing any other transactions using the SCA via the Atalla Secure Remote Manager (ASRM), or sending commands that contain responses greater than 1024 bytes or binary data. This ensures that Boxcar will correctly determine the status of NSP option 23. Failure to stop and start Boxcar after NSP option 23 has been changed may result in a situation where Boxcar will no longer process commands from host applications. BOXCAR-DEBUG-FILE <File name> This is the name of the debug file. The default value is blank meaning no debug file is used. Caution. This feature will significantly degrade performance so it should only be used when troubleshooting. It will record every command sent to the NSP and every NSP response, as such, there is a potential security implication when using this feature. It should be noted that significant disk space can be consumed by the debug file in high volume transaction environments. If this parameter is provided, Boxcar tries to open the debug file, and logs a message to the log file with the result of the OPEN operation on this file. This file must be an existing enscribe, unstructured file. When the file is full, an error 45 is logged to EMS, no further records are recorded. The debug file contains two types of records: 8

9 1. The command, in format: System name. Boxcar process name: Date Time, Socket Identifier, Command. 2. The response from the NSP, in format: System name. Boxcar process name: Date Time, Socket Identifier, Response. BOXCAR-DEVICE-NAME Specifies the IP address of the Atalla NSP. This parameter is required, if not specified, Boxcar logs an error, and terminates. Do not use leading zero(s) in an IP address octet. For example is incorrect, use instead. BOXCAR-DEVICE-TYPE Specifies the device type and subtype for the Boxcar process. This parameter is optional the default value is device type 15, subtype 3. To change the value of device and subtype specify the new device type followed by a dash (-) followed by the subtype. For example to set device type to 30 and the subtype to 10 the statement would be: BOXCAR-DEVICE-TYPE BOXCAR-ETHERNET-PORT Specifies the port number for Atalla NSP. This parameter is optional, if not specified default the value 7000 will be used. BOXCAR-LOGFILE Specifies the name of an existing enscribe, unstructured file, or process. This parameter is required, if not specified, Boxcar logs an error, and terminates. BOXCAR-LOGMSGWRITEINTERVAL Specifies the number of seconds between attempts to write queued message cancellations or Queue Depth messages to the Boxcar log file. It also controls the type of write operation Boxcar uses to write queued message cancellation messages to its log, and also what actions Boxcar takes when its log file is full. This parameter is optional, if not specified default the value 0 will be used. The minimum value is 0. The maximum value is 2,147,483,647. If this parameter is not present or its value is zero, Boxcar will log individual queued message cancellation messages using a waited write operation. Queue depth messages will be written using a no-waited write operation every time the queue is cleared. When the Boxcar log file is full, Boxcar will use a waited write operation to log an error 45 to $0 for every message it would normally write to its log file. When this parameter contains a positive value, in the range specified above, Boxcar will perform the following actions in response to these four events: 9

10 When Boxcar receives a Queued Message Cancellation message it uses the value specified in LOGMSGWRITEINTERVAL to start a timer. While the timer is running, Boxcar counts the number of these messages it receives. When the timer expires, Boxcar uses a no-waited write operation, with depth of one, to record in its log file the number of queued message cancellation messages it has received during this interval. If during this attempted write operation there is another write in process, Boxcar will start another timer and continue counting queued message cancellation messages. This process continues until Boxcar is successful in writing to its log file. When the number of incoming requests exceeds the number of sockets Boxcar has opened on the Network Security Processor, Boxcar queues incoming requests, and monitors the depth of the queue and its duration. When the queue clears, Boxcar uses a no-waited write operation, with a depth of 1, to write a queue depth message to its log file. If during this attempted write operation there is another write in process, Boxcar will use the value specified in LOGMSGWRITEINTERVAL to start a timer. While the timer is running, any additional queue depth messages will be discarded. When the timer expires, Boxcar will attempt to write the queue depth message again. This process continues until Boxcar is successful in writing this message. Boxcar uses a no-waited write operation, with a depth of 1, to write to $0. If during this attempted write operation there is another write in process, Boxcar will use the value specified in LOGMSGWRITEINTERVAL to start a timer. While the timer is running, any additional messages to be written to $0 are discarded. When the timer expires, Boxcar will attempt to write the next message to its log file. This process continues until Boxcar is successful in writing this message. When Boxcar receives an error 45 (file full) on an attempt to write a message to its log file, it will discard the message, write an error 45 to $0, and use the value in LOGMSGWRITEINTERVAL to start a timer. Any subsequent log file messages that Boxcar generates while this timer is running are discarded. After the timer expires, Boxcar will attempt to write the next message to its log file. If the log file is no longer full, the write will be successful. If the file is still full, Boxcar starts the LOGMSGWRITEINTERVAL timer again. While the Boxcar log file is full, Boxcar will write one error 45 message to $0 per hour. This process continues until Boxcar is successful in writing messages to its log file. BOXCAR-MAX-FLATSEG-SIZE This parameter is optional, it can be used to specify the size of a swap space for commands and responses. If this parameter is not specified Boxcar will use the maximum size of 133 MB. Boxcar requires approximately 32,000 bytes of swap space to store a command or response for each requestor. The maximum number of requestors allowed by Boxcar is defined by BOXCAR-RECV-DEPTH, the default and maximum is

11 To determine an appropriate value for the MAX-FLATSEG-SIZE parameter multiply the number of requestors by 32,000. For example if the BOXCAR-RECV-DEPTH is set to 255 the MAX-FLATSEG-SIZE parameter should be set to or higher. If this parameter is set to a value that is too small Boxcar will abend at startup. BOXCAR-MAXSOCKET-OPENS Specifies the maximum number of sockets that Boxcar can open on a NSP. This parameter is optional, if not specified the default value 14 is used. The minimum value is 1, the maximum value is 14. It is possible (although not recommended) to have multiple Boxcar processes communicating with the same Atalla NSP. In this case, make sure that the total number of sockets opened by the Boxcar processes do not exceed the maximum number of available NSP sockets. BOXCAR-RECV-DEPTH Specifies the Receive Depth value for $RECEIVE. The Receive Depth value is the number of READ UPDATEs that a process can perform before being required to REPLY to the requester. This parameter is optional, if not specified, the default value 4047 is used. The maximum value is When the number of incoming requests to Boxcar exceeds the receive depth an error 74 is logged. BOXCAR-SOCKET-RESET-LEVEL Specifies the frequency which Boxcar will check for, and attempt to restore, invalid sockets. The value specified, which is multiplied by 2000, is the number of commands received by Boxcar before it will attempt to restore any invalid sockets. The parameter is optional, if not specified, the default value 500 (1,000,000 commands) is used. The maximum value is 2,147,483,647. BOXCAR-SOCKET-TIMEOUT Specifies the time, in hundredths of seconds, for a socket open to complete. This parameter is optional, if not specified, the default value 1000 (10 seconds) is used. BOXCAR-TCPIP-PROCESS-NAME Specifies the TCP/IP process used to communicate with the NSP.This process is the one used by the specific Ethernet controller to which the NSP is attached. Use this parameter instead of a TACL define to specify the TCP/IP process associated with the Ethernet controller. If this parameter is not specified, and if the TACL define TCPIP^PROCESS^NAME is not specified, Boxcar will abend. 11

12 Table 1. Boxcar Parameters (page 1 of 2) Command Default Description BOXCAR-BACKUPCPU Specifies the CPU that runs the Boxcar backup process. If not specified, the Boxcar process does not run as a persistent process pair. BOXCAR-CRLF-REQUIRED Used to specify if a Carriage Return and Line Feed (CRLF) characters should be appended to each NSP response. YES = append CRLF NO = do not append CRLF If not specified, Boxcar logs an error and terminates. BOXCAR-DEBUG-FILE This is the name of the debug file. Only use this parameter for troubleshooting, it significantly degrades performance. BOXCAR-DEVICE-NAME Specifies the IP address of the NSP. If not specified, Boxcar logs an error and terminates. BOXCAR-DEVICE-TYPE 15-3 Specifies the device and subtype.the device and subtype must be separated by a dash character. BOXCAR-ETHERNET-PORT 7000 Specifies the port number for the NSP. BOXCAR-LOGFILE Establishes the name of the Boxcar log file or log process name. If not specified, Boxcar logs an error and terminates. BOXCAR-LOGMSGWRITEINTERVAL 0 Controls how often messages certain types of messages are logged. BOXCAR-MAX-FLATSEG-SIZE 133MB This parameter can be used to specify a smaller swap space, which is used by Boxcar to store commands and responses. BOXCAR-MAXSOCKET-OPENS 14 Specifies the maximum number of socket opens that can be performed on an NSP. If Boxcar is unable to open any sockets, it logs an error and terminates. BOXCAR-RECV-DEPTH 4047 Used to change the Receive Depth value, $RECEIVE, from the default value of The maximum allowed value is

13 Table 1. Boxcar Parameters (page 2 of 2) Command Default Description BOXCAR-SOCKET-RESET-LEVEL 500 Specifies the frequency which Boxcar will check for, and attempt to restore, invalid sockets. The value specified, which is multiplied by 2000, is the number of commands received by Boxcar before it will attempt to restore any invalid sockets. Setting this value to a low value will increase overhead and degrade Boxcar performance. BOXCAR-SOCKET-TIMEOUT 1000 Specifies the time, in hundredths of a second, for a socket open to complete. BOXCAR-TCPIP-PROCESS-NAME Specifies the TCP/IP process used to communicate with the NSP. If this parameter is not specified, Boxcar will use the default TCP/IP process for the terminal used to start Boxcar. If no default TCP/IP process has been specified for the terminal, Boxcar logs an error and terminates. Note. The following Boxcar parameters are no longer supported and must not be used: BOXCAR-A7K-HDR, BOXCAR-A7K-IMAGE, BOXCAR-CLEAR-NLCHECK, BOXCAR-DOWNLOAD-A7K, BOXCAR-NO-INIT, BOXCAR-RESPONSE-MODE, BOXCAR-TAPECOM-DELAY, BOXCAR-TAPECOM-INFILE, BOXCAR-TAPECOM-OUTFILE, and BOXCAR-WCOUNT. 13

14 Modifying the Obey File Edit the obey file to match your host system (for example, primary and backup CPUs, device IP address, and number of sockets). Create a separate obey file for each NSP; one Boxcar process for each NSP, see Boxcar Parameter Definitions. Table 2 shows an example of an obey file. Note. To prevent application time-outs the priority of the Boxcar process should be set slightly below the priority of the TCP/IP process that controls the NSP. For example if the TCP/IP process is set to 190, the Boxcar process priority should be set to 189. If the Boxcar process is not started in the same system as the NSP, the Boxcar process name must be limited to six characters, including the $. If the Boxcar process name is six characters including the $, the statement used to start the Boxcar process must contain an in, out, and term parameters. Table 2. Sample Obey File CLEAR ALL PARAM PARAM BOXCAR-BACKUPCPU 1 PARAM BOXCAR-DEVICE-NAME PARAM BOXCAR-ETHERNET-PORT 7000 PARAM BOXCAR-LOGFILE logbox PARAM BOXCAR-CRLF-REQUIRED yes PARAM BOXCAR-MAX-FLATSEG-SIZE PARAM BOXCAR-MAXSOCKET-OPENS 14 PARAM BOXCAR-RECV-DEPTH 4047 PARAM BOXCAR-SOCKET-TIMEOUT 1000 PARAM BOXCAR-TCPIP-PROCESS-NAME $ZTC0 Comment create log file fup create logbox, type e, rec 200, block 4096, & maxentents 100, ext 10 run boxcaro /name $box1, nowait, cpu 0, pri 160/ 14

15 Executing the Obey File Once the obey file is modified, execute the obey file. In the example below the modified obey file is called STRTBOX. At the TACL prompt, type the following including the space: TACL> obey strtbox Note. If you renamed the obey file, be sure to type the name of your new obey file. VPROC information Binder timestamp: 30APR :03:46 Version procedure: T8432H02_21MAY2008_CRTLNSE_ABN Version procedure: T8432H02_21MAY2008_CCPLMAIN Version procedure: T0409H01_15MAY2009_H01AAJ TNS/E Native Mode: runnable file Contacting Atalla Technical Support Before contacting Atalla Technical Support, please read this document. Many of the common product questions are covered in this guide. If you are still unable to find answers to your questions, contact Atalla Technical Support. Atalla Technical Support s normal working hours are 8 am to 5 pm, Pacific Standard Time, Monday through Friday. Atalla Technical Support provides assistance for customers and field personnel who have questions or problems with the installation, setup and use of Atalla equipment or products. When requesting support, please have the following information available as it will enable us to efficiently answer your question or solve the problem you are encountering: Type and model of Atalla equipment Version of NSP software Boxcar software version (use the VPROC command to obtain this information) Type of system it is attached to or installed in (include operating system version) Exact nature of the problem. Provide as much detail as possible Customers can contact Atalla Technical Support by: By atalla.support@hp.com By telephone: (U.S. only) or (outside U.S.) 15

16 24-hour Support Atalla Technical Support provides 24-hour emergency coverage through the Global Mission Critical Solution Center (GMCSC). Use this service for Atalla product and system emergencies that occur after normal working hours or on weekends and U.S. holidays. Questions about Atalla product installation and setup are supported during normal working hours. Within the U.S. the GMCSC can be contacted by calling: Customers outside the U.S. can obtain GMCSC contact information from this URL: 16