Chapter 51: Working with Socket Server Jobs (SOCK)
Purpose: Use this menu option to create, review, and change the status of a socket server and async associated with a socket server.
Socket servers are used to send and receive data from one machine to another. The server manages communication between the machines, waiting for new information to send and “listening” for data to receive. This data is transmitted back and forth through a socket, or port, the point on each machine where the connection takes place, using a specified line to transmit the data.
A socket server can:
• send data to another system
• receive data from another system
• process the data using a specified inbound program, outbound program, or async
Outbound data: If the socket server is sending data to another system, you must define:
• where the data resides before it is sent to the other system
• the program that processes the data and sends it to the other system
• the maximum number of bytes that can be sent to the other system
Inbound data: If the socket server is receiving data from another system, you must define:
• the program that receives the data from the other system and determines where to place the data on this system
• where the data resides when it is received from the other system
• the maximum number of bytes that can be received from the other system
• optionally, an async to process and perform updates to the data
Required set up: Regardless if you are sending data, receiving data, or both, you must define:
• the job name of the inbound and/or outbound programs
• the port on your system the socket server is monitoring
• the library where the inbound and/or outbound programs reside
• The network address of the machine where you are sending or receiving data
In this chapter:
• On-line Authorization Socket Server and Async
• On-Line Authorization Outbound Processing
• On-Line Authorization Inbound Processing
• Work with Socket Server Jobs Screen
• Create Socket Server Jobs Screen
• Change Socket Server Job Screen
• Display Socket Server Job Screen
On-line Authorization Socket Server and Async
In order to perform on-line credit card authorizations, you must define a socket server and async to send and receive the authorizations and perform updates. You must also purchase the leased line used to transmit the data.
Important: At this time, Paymentech Online Processing Revision 4.0 is the only authorization service that supports on-line authorization using the socket server and async. The name of the socket server for Paymentech is PMT. If you are using Paymentech Online Processing Revision 6.0, you can process online transactions using CWIntegrate. See Paymentech Processing for additional information.
On-line authorization CWIntegrate communication: CWDirect uses the outbound queue processing and inbound queue processing defined for the on-line authorization integration layer process to transmit on-line authorizations between CWDirect and CWIntegrate for First Data Merchant Services. Note: CWDirect does not use the on-line authorization socket server program defined in Working with Socket Server Jobs when you are transmitting on-line authorizations to the service bureau via CWIntegrate; see Processing Authorizations and Deposits using CWIntegrate.
To send and receive authorizations, the Paymentech socket server and async must be active. The socket server and async are started in a subsystem on the iSeries, using the location defined in the Job description field. This subsystem contains 2 programs: a program to send the data (outbound data) and a program to receive the data (inbound data).
For more information:
• on-line authorization overview and required setup: Chapter 49: Performing Online Credit Card Authorizations
• method of communication between CWDirect and Paymentech: iSeries Duplex TCP/IP Socket Client II Programming Guide
How can I tell if the Paymentech socket server and async jobs are active? You can check the active jobs to verify that the Paymentech socket server and async jobs for on-line authorization are active.
• 2 socket server jobs should be active. 1 for incoming data, for example A123456IN, and 1 for outgoing data, for example A123456OUT.
• the number of active async jobs should match the number you defined in the # of inbound async jobs field for the Paymentech on-line authorization Async.
Note: If the Sockets program goes down prior to completing the authorization process for an order during order entry, and you then generate pick slips, the system checks for a pending authorization record before authorizing orders. If a pending authorization record is found, and is within the 2 days’ grace period, the system declines the order for pick slip generation; if the pending authorization is outside the 2 days’ grace period, the system declines the previous authorization and re-authorizes the order; the order is authorized only once.
Required values for Paymentech on-line authorization socket server and async: This table displays the required values for the socket server and async if you are using Paymentech. If you wish to use an authorization service other than Paymentech, a new socket server job will need to be created with the appropriate values.
Field |
Value |
PMT |
|
The description of the socket server job. Example: Paymentech On-Line Authorization. |
|
The job name of the socket server outbound and inbound programs located in the subsystem. Example: If the connection ID is A123456, the: • incoming data program is named A123456IN • outgoing data program is named A123456OUT |
|
Paymentech provides this value. Note: If you also process batch authorizations using a leased line, make sure the port number you define for batch authorizations is different from the port number you define for on-line authorizations. |
|
AAR0218 |
|
AUTHOUTDTQ |
|
221 |
|
AAR0217 |
|
AUTHINDTQ |
|
61 |
|
This is based on the version and environment you are using to perform on-line authorizations. Example: CWM40QDTA |
|
AUTH_ASYNC |
|
AAR0216 |
|
3 (default) Increase this number to handle larger volumes of orders. |
|
QZRDDCLT_Q (where Q represents the environment you are using to perform on-line authorizations). |
|
123.456.789.123 |
On-Line Authorization Outbound Processing
The Get On-Line Authorization program determines when information required to authorize a credit card is sent to the socket server. This program is called when you:
• press F9 to accept an order in order entry and the order contains a credit card that is eligible for on-line authorization.
• enter 9 to accept a batch at the Work with Order Batches Screen in batch order entry or press F9 to accept a batch at the Select Customer Sold To For Order Screen.
• enter 6 to authorize a credit card at the Enter Payment Methods Screen in order maintenance
What information is sent? The Get On-Line Authorization program sends this information to the socket server to send to the authorization service.
Value passed |
Description |
Company |
The company where you placed the order. |
Order number |
The order number that contains the credit card payment method requesting authorization. |
Authorization service record |
A code to identify the authorization service. |
Order payment sequence # |
The sequence number associated with this credit card payment method. |
Pay type |
The credit card pay type requesting authorization. |
Credit card number |
The credit card number defined for the credit card requesting authorization. Note: If you use credit card encryption, the system decrypts the credit card number before sending it to the service bureau; however, the credit card number is encrypted in the On Line Authorization file to provide additional security of credit card data. |
Expiration month |
The month this credit card is no longer valid. |
Expiration year |
The year this credit card is no longer valid. |
Card security presence |
Indicates to the authorization service whether a card security value (CID, CVV, CVC) is present on the credit card. If a card security presence exists for the credit card payment method, the authorization service performs card security identification. Valid values: 1 = card security value is present on the credit card. 2 = card security value is present on the credit card, but is illegible. 9 = card security value is not present on the credit card. |
Card security value |
The credit card’s security value. American Express: The card security value, or CID (card identification number), is a 4-digit number imprinted, not embossed, on an AmericanExpress credit card. The card security value displays above and to the right of the imprinted credit card number on the front of the card. Discover: The card security value, or CID (card identification number), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. VISA: The card security value, or CVV2 (card verification value), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. MasterCard: The card security value, or CVC2 (card validation code), is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. |
|
Reducing fraud: Authorization services use card security identification to help reduce fraud by verifying that the credit card is present at the point of sale and to ensure that the credit card data from the transaction matches the data stored by the authorization service for that card. Note: The system removes the card security value from an order when the order is accepted, even if an approved online authorization has not been received on the order. Card security processing is not available during batch authorization or deposit processing. |
Amount to authorize |
The dollar amount associated with the credit card requesting authorization. Alternate currency pricing: If the Use Alternate Currency Pricing (H89) system control value is set to Y and a currency code and conversion rate are defined in the Order Header Extended file, the alternate currency displays; otherwise, the local currency displays. See Paymentech Online Processing Revision 4.0 Record Layouts. |
Billing customer number |
The number of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing customer last name |
The last name of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing customer first name |
The first name of the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing address line 1 |
Address line 1 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing address line 2 |
Address line 2 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing city |
The city for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing state |
The state for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing zip |
The zip code for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing extra zip |
The zip code + 4 for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Billing country |
The country for the customer associated with the credit card. This is the bill to customer if one is defined; otherwise this is the sold to customer. |
Called by flag |
This flag indicates where the order was placed, for example, regular order entry or batch order entry. OE = order entry BI = batch invoice BR = batch regular EC = e-commerce (this is not currently implemented) |
On-Line Authorization file: When you send credit card information to the authorization service, the system also creates a record in the On-Line Authorization file.
Field |
Description |
Company |
The company where you placed the order. |
Order # |
The order number that contains the credit card payment method requesting authorization. |
Order payment method sequence # |
The sequence number associated with this credit card payment method. |
Sequence # |
The sequence number from the online authorization. |
The dollar amount associated with the credit card requesting authorization. This field is blank until an authorization response is received. |
|
The authorization response for this credit card. This field is blank until an authorization response is received. |
|
The card security (CID, CVV2, CVC2) response for this credit card. This field is blank until a card identification response is received. |
|
The number used to authorize the credit card. This field is blank until an authorization response is received. |
|
The date the credit card was authorized. This field is blank until an authorization response is received. |
|
Transaction sequence # |
The next available number defined in the Transaction sequence # number assignment value. |
Credit card # |
The credit card number defined for the credit card requesting authorization. Note: If you use credit card encryption, the credit card number in this file is encrypted to provide additional security of credit card data. |
The address verification response for this credit card. This field is blank until an AVS response is received. |
|
CID # |
The credit card’s identification number. |
Terminal # |
The last 4 digits of the order number associated with the credit card sent for authorization. |
*SENT |
|
Authorization service |
PMT (Paymentech) |
Paymentech Online Processing Revision 4.0 Record Layouts
This file displays the file layout of data sent to Paymentech for online authorizations. If you are using Paymentech Online Processing Revision 6.0, see the CWIntegrate CWDirect/Paymentech Integration Reference for record layouts.
Position (length) |
Data Type |
Field Name |
CWDirect Field |
Description |
Online Processing Detail Record |
||||
1 (1) |
A |
Record type |
P |
|
2 (1) |
N |
Format constant |
2 |
|
3-18 (16) |
A |
Merchant’s order number |
Order number from the Online Authorization file. This field is concatenated as: company#/order#/order payment method sequence#/sequence# |
This field ties the request by CWDirect to the response Paymentech provides. This number should be unique to the transaction and stored in the Deposit file. This field is left justified/blank filled. |
19-20 (2) |
A |
Method of Payment |
Paytype code from the Auth Service Paytype file. |
Valid values: AX = American Express/ Optima BE = Beneficial CB = Carte Blanche DC = Diners Club DI = Discover EC = Electronic Check GE = GECC JC = JCB MC = MasterCard SW = Switch/Solo VI = Visa This value is blank if the credit card is encrypted. |
21-39 (19) |
A |
Account number |
Credit card # from the Online Authorization file. |
Credit card or bank account number. This field is left justified and blank filled. If you use credit card encryption, the system decrypts the credit card number before sending it to the service bureau. |
40-43 (4) |
A |
Expiration date |
Expiration date from the Order Pay Method file. |
This field is in MMYY format. |
44-49 (6) |
N |
Division number |
Merchant ID number for the authorization service. The system uses the following hierarchy to determine the merchant ID number to send to Paymentech: • Merchant # from the CC Paytype Cross Ref file. • Merchant ID override from the Merchant ID Override file. • Merchant ID from the Authorization Service file. |
Assigned by Paymentech. |
50-61 (12) |
N |
Amount |
Amount authorized from the Online Authorization file. If the Use Alternate Currency Pricing (H89) system control value is set to Y and the order is associated with an alternate currency (a currency code and conversion rate are defined in the Order Header Extended file), the system converts the local amount to the alternate (foreign) amount and sends the alternate amount to Paymentech. |
Implied decimal, right justified, and zero filled. |
62-64 (3) |
N |
Currency code |
Currency code from the Order Header Extended file. If currency code is blank, use 840; otherwise match the authorization service currency from the Auth Service Currency file and populate this field with the appropriate code. |
The currency code for the transaction. Valid values: 124 = Canadian dollars 250 = French francs 280 = German marks 372 = Irish punts 392 = Yen 528 = Dutch guilders 826 = Pounds sterling 840 = U.S. dollars 978 = Euro |
65 (1) |
A |
Transaction type |
Indicates where the authorization transaction originated. • If the Internet order field in the Order Header file is set to I (internet order) or the order type matches the order type defined in the E-Commerce Order Type (G42) system control value, the transaction type is 7. The credit card must be VISA or MasterCard; otherwise the transaction type is 1. If the Internet order field in the Order Header file is blank (regular order), the transaction type is 1. |
Valid values: R = Retail merchant 1 = Single transaction mail/telephone order 2 = Recurring transaction 3 = Installment payment 5 = Secure electronic commerce transaction 6 = Non-authenticated SET transaction 7 = Non-SET Channel-encrypted 8 = Non-secure electronic commerce transaction |
66 (1) |
A |
Encryption flag |
Pass blanks |
Indicates whether the credit card is encrypted. Valid values: Blank = no encryption C = Citibank program F = FUSA program |
AVS with Telephone / Address Format Record |
||||
67-79 (13) |
A |
Filler |
Blanks |
Blank filled |
80 (1) |
A |
Format indicator |
|
Valid values: H = home (AVS with telephone format) W = work (AVS with telephone format) R = retail (Retail swipe format) K = ECP (Electronic check format) S = Switch (Switch card format) A carriage return indicates that this is the end of the record. |
81-94 (14) |
A |
Telephone number |
Telephone # of the Billing customer. Use the day # if one exists; otherwise, use the evening #. If a bill-to exists, this is the bill to phone #; if a sold-to exists, this is the sold to phone #. |
Displays in AAAEEENNNNXXXX format, where: AAA = Area code EEE = Exchange NNNN = Number XXXX = Extension |
95-124 (30) |
A |
Name text |
Billing customer name |
If a bill-to exists, this is the bill to customer name; if a sold-to exists, this is the sold to customer name. |
125-154 (30) |
A |
Address line 1 |
Billing address line 1 |
Street address |
155-184 (30) |
A |
Address line 2 |
Billing address line 2 |
Additional address information |
185-204 (20) |
A |
City |
Billing city |
City |
205-206 (2) |
A |
State |
Billing state |
State |
207-216 (10) |
A |
Zip code |
Billing zip |
Zip code If sending zip + 4, separate the 4 digit suffix with a hyphen. |
217 (1) |
A |
Card security presence |
Card security presence defined for the credit card payment method requiring authorization in the Order Payment Method file. |
Supported by VISA, Discover, MasterCard, and AmericanExpress only. Valid values: 1 = Card security value is present on card. 2 = Card security value is present on card, but is illegible. 9 = Card holder states that the card has no security value. See Credit Card Security Service (CID, CVV2, CVC2) for more information on card security processing. |
218-221 (4) |
A |
Card security value |
Card security value defined for the credit card payment method requiring authorization in the Order Payment Method file. Note: The system removes the card security value from an order when the order is accepted, even if an approved online authorization has not been received on the order. Card security processing is not available during batch authorization or deposit processing. |
Identifies the card security value provided by the cardholder. American Express: The card security value (CID) is a 4-digit number imprinted, not embossed, on an AmericanExpress credit card. The card security value displays above and to the right of the imprinted credit card number on the front of the card. The system passes all 4 positions of the card security value. |
|
|
|
|
Discover: The card security value (CID) is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. The system passes only the last 3 positions of the card security value. |
|
|
|
|
VISA: The card security value (CVV2) is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. The system passes only the last 3 positions of the card security value. |
|
|
|
|
MasterCard: The card security value (CVC2) is a 3-digit number in reverse indent printing located on the signature panel on the reverse side of the credit card following the account number. The system passes only the last 3 positions of the card security value. See Credit Card Security Service (CID, CVV2, CVC2) for more information on card security processing. Left-justified and blank filled. |
Retail Format Record |
||||
81 (1) |
N |
POS capability code |
|
This field defines the ability of the POS terminal or cash register. 2 = Magnetic stripe reader 9 = Keyed entry only |
82-83 (2) |
N |
POS entry mode |
|
This field indicates how the transaction was entered. 01 = Manually keyed 90 = Entire magnetic stripe read and transmitted |
84 (1) |
N |
Track indicator |
|
Track that was read: 1 or 2. |
85-160 (76) |
A |
Swipe data |
|
Actual data from the card swipe, left justified and blank filled. |
ECP Format Record |
||||
81-89 (9) |
N |
RDFI/blank ID |
|
Bank (RDFI or ABA) number from the check. |
Switch Format Record |
||||
81-84 (4) |
N |
Card start date |
|
MMYY format. |
85-86 (2) |
N |
Card issue number |
|
Right justified and blank filled. |
Once the authorization request has been sent to the authorization service, the socket server waits and “listens” for a response from the authorization service. The amount of time the system waits for an authorization is defined in the Response time field for the authorization service.
On-Line Authorization Inbound Processing
Once a response is received from the authorization service, the On-Line Authorization async updates the record in the On-Line Authorization file.
• the dollar amount authorized displays in the Authorization amount field.
• the authorization response received displays in the Vendor response 1 field.
• the card identification verification response received displays in the Vendor response 2 field.
• the address verification response received displays in the AVS result field.
• the authorization number displays in the Authorization # field if the credit card was approved. If the credit card was declined, this field remains blank.
• the date the card was authorized displays in the Authorization date field.
• the status in the Status of transaction field is updated to *UPDT.
Paymentech Online Processing Revision 4.0 return record layouts: This file displays the file layout of data received from Paymentech for on-line authorizations. The system updates the Authorization History file with this information.
Position (length) |
Data Type |
Field Name |
Description |
On-Line Processing Return Format Record |
|||
1 (1) |
A |
Record type |
T |
2 (1) |
N |
Format constant |
2 |
3-18 (16) |
A |
Merchant’s order number |
This field will tie the request by CWDirect to the response Paymentech provides. This number is unique to the transaction and stored in the Deposit file. This field is left justified and blank filled. |
19-21 (3) |
N |
Response reason code |
Result of action requested. |
22-27 (6) |
N |
Response date |
This field is in YYMMDD format. This date is stored in the Deposit file. |
28-33 (6) |
A |
Authorization/ verification code |
Issued by the bank or service establishment. This code is stored in the Deposit file. |
34-35 (2) |
A |
AVS/AAV response code |
Response to address verification request. The AVS/AAV response code is stored in the AVS response field in the Authorization History file. |
36 (1) |
A |
Card security value response |
Response to credit card security identification. Valid values: M (match) = The card security value indicated on the card matches the card security value in the secured database. N (no match) = The card security value indicated on the card does not match the card security value in the secured database. You should be cautious in processing credit cards with a card security response of N; the transaction is possibly a fraud. P (not processed) = The card security value was not processed due to communication errors. S (should be on card) = The card security value should be present on the card (this response applies to card security presence 9). |
|
|
|
U (unsupported by issuer) = The issuer of the credit card does not support card security identification. I (invalid) = The card security value is invalid. Do not process credit cards with a card security response of I; the transaction is possibly a fraud. The card security value response is stored in the Vendor response 2 field in the Authorization History file. |
37-55 (19) |
A |
Account number |
Unencrypted credit card number, returned for all transactions. This field is left justified and blank filled. |
56-59 (4) |
N |
Expiration date |
This date is in MMYY format and is returned for all transactions. |
60-61 (2) |
A |
Method of payment |
Valid values: AX = American Express/Optima BE = Beneficial CB = Carte Blanche DC = Diners Club DI = Discover (Novus) EC = Electronic Check GE = GECC JC = JCB MC = MasterCard SW = Switch/Solo VI = VISA |
Response is not received: If a response is not received from the authorization service before the time defined in the Response time field has elapsed, the system sends a response to order entry/maintenance indicating the time has elapsed.
Field |
Description |
Response flag |
T (time elapsed) |
Message line #1 |
blank |
Message line #2 |
blank |
Message line #3 |
blank |
Message line #4 |
blank |
Hold reason code |
blank |
Response code |
blank |
Authorization code |
blank |
Date |
blank |
Response is received: When a response is received from the authorization service, the system creates a record in the Authorization History file.
Field |
Description |
Company |
The company where you placed the order. |
Order # |
The order number that contains the credit card payment method requesting authorization. |
Sequence # |
The next available number defined in the Transaction sequence # number assignment value. |
Auth # |
The number used to authorized the credit card. |
Status |
A = Authorization approved D = Authorization declined |
Amount authorized |
The dollar amount associated with the credit card that has been authorized. |
Amount deposited |
The dollar amount associated with the credit card that has been deposited. This field should display blank. |
Authorization date |
The date the credit card was authorized. |
Sent date |
The date you sent the credit card information to the authorization service for authorization. |
Authorization number |
The number used to authorize the credit card. |
Authorization vendor response |
The authorization response for this credit card from the authorization service. The system looks at the Credit Card Vendor Response file to find a match to the vendor response code from the authorization service. |
|
If a vendor response match is found... The system passes these values to order entry/maintenance: • Response flag = R (received response) • Message line #1 (If a message line contains text, the system displays the Select Authorization Response Option Window.) • Message line #2 • Message line #3 • Message line #4 • Hold reason code • Response code • Authorization code • Date |
|
If a vendor response match is not found... The system passes these values to order entry/maintenance: • Response flag = U (undefined) • Message line #1 = blank • Message line #2 = blank • Message line #3 = blank • Message line #4 = blank • Hold reason code = AVS • Response code • Authorization code • Date |
Vendor response 2 |
The credit card security (CID, CVV2, CVC2) response for this credit card from the authorization service. The system looks at the Credit Card Vendor Response file to find a match to the card identification response code from the authorization service. If the card identification response is associated with a hold reason, the system places the order on AT hold and places the credit card payment method on hold. |
AVS response |
The address verification response for this credit card from the authorization service. The system looks at the Credit Card Vendor Response file to find a match to the AVS response code from the authorization service. If the AVS response is associated with a hold reason, the system places the order on AT hold and places the credit card payment method on hold. |
Work with Socket Server Jobs Screen
Purpose: Use this screen to create, change, start, or end a socket server and its associated async. You can use a socket server to send and receive data from one machine to another.
See On-line Authorization Socket Server and Async for more information on the processing the system performs when you use the Paymentech Online Authorization socket server and async.
How to display this screen: Enter SOCK in the Fast path field at the top of a menu or select Work with Socket Server Jobs from a menu.
MSR1191 DISPLAY Work with Socket Server Jobs 6/12/00 15:02:41
Opt Server Description Port Outbound Async Job Status Status
Type options, press Enter. 2=Change 4=Delete 5=Display 7=Start 8=End 11=Change Status 14=Start Async 16=End Async 17=Change Async Status
PMT PAYMENT TECH ON-LINE AUTHORIZATION 8343 *Active *Active Start: 6/12/00 8:22:11 KLETENDRE End..: 6/12/00 8:21:35 KLETENDRE
F3=Exit F6=Create F7=Start All F8=End All F12=Cancel |
Field |
Description |
Server (Socket server code) |
A code indicating the name of the socket server. Alphanumeric, 3 positions; display-only. |
Description (Socket server description) |
The description of the socket server. Alphanumeric, 40 positions; display-only. |
Port |
The port the socket server is monitoring. This port is used to send and receive data. Note: If you use the same port for more than one socket server, the system considers the first socket server you started as ACTIVE. Any other socket servers using the same port that you start after the first socket server are considered INACTIVE. This applies if you are using 2 versions of CWDirect or are using 2 environments of CWDirect, such as a test and production environment. You should define a unique port for each socket server in each version of CWDirect and in each environment in order in insure that each socket server you start is ACTIVE when you select to start it. |
|
Batch and on-line authorizations: If you define leased-line communication for batch authorizations and you are also using online authorizations, make sure the port number used for the leased-line in batch authorizations is different from the port number used for the leased-line in online authorizations. You define the port number used for batch authorizations in the Defining Authorization Services (WASV) menu option. Numeric, 5 positions; display-only. |
Outbound status |
The outbound status of the socket server. The outbound status indicates whether data can be sent to another system. ACTIVE = The socket server is up and running. In order to send and receive data, the socket server must be in an ACTIVE status. INACTIVE = The socket server is not running. Alphanumeric, 10 positions; display-only. |
Async job status |
The status of the async job associated with the socket server. The async status indicates whether data received from another system can be processed. ACTIVE = The Async is up and running. In order to process data, the Async must be in an ACTIVE status. INACTIVE = The Async is not running. Alphanumeric, 10 positions; display-only. |
Start (start date, time, and user) |
The date and time the socket server and async were last started and the user ID of the person who started them. Start date: Numeric, 6 positions (MMDDYY format); display-only. Start time: Numeric, 6 positions (HHMMSS format); display-only. Start user: Alphanumeric, 10 positions; display-only. |
End (end date, time, and user) |
The date and time the socket server and async were last ended and the user ID of the person who ended them. End date: Numeric, 6 positions (MMDDYY format); display-only. End time: Numeric, 6 positions (HHMMSS format); display-only. End user: Alphanumeric, 10 positions; display-only. |
Screen Option |
Procedure |
Create a new socket server and async |
Press F6 to advance to the Create Socket Server Jobs Screen. |
Change a socket server and async |
Enter 2 next to a server to advance to the Change Socket Server Job Screen. |
Delete a socket server and async |
Enter 4 next to a server to delete it. |
Display a socket server and async |
Enter 5 next to a server to advance to the Display Socket Server Job Screen. |
Start a socket server |
Enter 7 next to a server to start it. See Starting the Socket Server and Async. |
End a socket server |
Enter 8 next to a server to end it. See Ending the Socket Server and Async. |
Change the status of a socket server |
Enter 11 next to a server to change its status. |
Start an async |
Enter 14 next to an async to start it. See Starting the Socket Server and Async. |
End an async |
Enter 16 next to an async to end it. See Ending the Socket Server and Async. |
Change the status of an async |
Enter 17 next to an async to change its status. |
Start all socket servers and asyncs |
Press F7. See Starting the Socket Server and Async. |
End all socket servers and asyncs |
Press F8. See Ending the Socket Server and Async. |
Create Socket Server Jobs Screen
Purpose: Use this screen to create a socket server job and its associated async.
How to display this screen: Press F6 at the Work with Socket Server Jobs Screen.
MSR1193 ENTER Create Socket Server Jobs 6/12/00 15:47:22
Socket Description Connection ID Port Outbound Program OutBound DataQueue Outbound DataQueue Length Inbound Program Inbound DataQueue Name Inbound DataQueue Length
DataQueue library
Async Job Name Async Program Name # of Async Jobs
F3=Exit F12=Cancel |
Field |
Description |
A code indicating the name of the socket server. Alphanumeric, 3 positions. Create screen: required. Change screen: display-only. |
|
The description of the socket server. Alphanumeric, 40 positions; optional. |
|
The job name of the socket server outbound and inbound programs located in the subsystem. The ID should be 1 uppercase alpha character followed by 6 numerals. Example: If the connection ID is A123456, the: • incoming data program is named A123456IN • outgoing data program is named A123456OUT The test ID should be different from the live ID. Alphanumeric, 7 positions; optional. |
|
The port the socket server is monitoring. This port is used to send and receive data. Note: If you use the same port for more than one socket server, the system considers the first socket server you started as ACTIVE. Any other socket servers using the same port that you start after the first socket server are considered INACTIVE. This applies if you are using 2 versions of CWDirect or are using 2 environments of CWDirect, such as a test and production environment. You should define a unique port for each socket server in each version of CWDirect and in each environment in order in insure that each socket server you start is ACTIVE when you select to start it. |
|
|
Batch and on-line authorizations: If you define leased-line communication for batch authorizations and you are also using online authorizations, make sure the port number used for the leased-line in batch authorizations is different from the port number used for the leased-line in online authorizations. You define the port number used for batch authorizations in the Defining Authorization Services (WASV) menu option. Numeric, 5 positions; optional. |
The name of the program that connects to the port and is used to process the data sent to another system. Alphanumeric, 10 positions; optional. |
|
The place where data sits waiting to get sent to another system. The data waits until the outbound program sends the data to another system. Alphanumeric, 10 positions; optional. |
|
The maximum number of bytes that can be sent to another system using this queue. Numeric, 5 positions; optional. |
|
The name of the program that connects to the port and is used to process the data received from another system. This program places the data received from another system into the associated inbound dataqueue. Alphanumeric, 10 positions; optional. |
|
The place where data received from another system is located. The data waits in this location until the async program processes the data. Alphanumeric, 10 positions; optional. |
|
The maximum number of bytes that can be received into this queue from another system. Numeric, 5 positions; optional. |
|
The library where both the inbound and outbound data queues reside. This is based on the version and environment you are using to send and receive data using a socket server. Example: If you are in CWDirect version 4.0 in the Q environment, the dataqueue library would be CWM40QDTA. Alphanumeric, 10 positions; required. |
|
The name of the async job used to process data received from another system. Alphanumeric, 10 positions; optional. |
|
The name of the program used to process the data received from another system. This program takes data from the inbound dataqueue to process. Alphanumeric, 10 positions; optional. |
|
The number of async jobs started when you start the async. The number of async jobs determines the volume of data that can be processed at a given time. Increase this number to handle larger volumes of data. Numeric, 3 positions; optional. |
|
The name of the subsystem where the inbound and outbound programs reside. Note: This field only displays on the Change Socket Server Job screen. Alphanumeric, 10 positions; optional. |
|
The network address of the machine where you are sending data. Note: This field only displays on the Change Socket Server Job screen. Example: 123.456.789.123 Numeric, 12 positions; optional. |
Starting the Socket Server and Async
To start a single socket server: Enter 7 next to a socket server at the Work with Socket Server Jobs Screen and press Enter. The status of the socket server changes to ACTIVE.
To start a single Async: Enter 14 next to an Async at the Work with Socket Server Jobs Screen and press Enter. The status of the Async changes to STARTED and then to ACTIVE.
To start all Asyncs: Press F7 at the Work with Socket Server Jobs Screen. The status of the Async jobs change to STARTED and then to ACTIVE.
Note: In order to start a socket server or Async, the socket server or Async must be in an INACTIVE status.
Ending the Socket Server and Async
To end a single socket server: Enter 8 next to a socket server at the Work with Socket Server Jobs Screen and press Enter. The status of the socket server changes to INACTIVE.
To end a single Async: Enter 16 next to an Async at the Work with Socket Server Jobs Screen and press Enter. The status of the Async changes to ENDING and then to INACTIVE.
To end all Asyncs: Press F8 at the Work with Socket Server Jobs Screen. The status of the Async jobs changes to ENDING and then to INACTIVE.
Note: In order to end a socket server or Async, the socket server or Async must be in an ACTIVE status.
Change Socket Server Job Screen
To change: Enter 2 next to a socket server at the Work with Socket Server Jobs Screen to advance to the Change Socket Server Job Screen.
You can change any field on this screen except the Server field. See Create Socket Server Jobs Screen for field descriptions.
Display Socket Server Job Screen
To display: Enter 5 next to a socket server at the Work with Socket Server Jobs Screen to advance to the Display Socket Server Job screen. You cannot change any information on this screen. See Create Socket Server Jobs Screen for field descriptions.
| Chapter 50: Performing Batch Authorization (SATH) | Contents | SCVs | Search | Glossary | Reports | XML | Index | Chapter 52: Printing the Online Credit Card Authorization List (PATL) |
SO04_11 CWDirect 18.0 August 2015 OTN