This is a printable page that lists frequently asked questions and answers for Expedite Base for Windows.

Return to the FAQs question page.

What is the difference between Expedite for Windows and Expedite Base for Windows?

The highlights of each licensed program are listed below:

     Expedite Base for Windows

• Supports TCP/IP and asynchronous connections to Information Exchange
• Supports most Information Exchange commands to provide the following functions: send and receive files, list and delete files in your mailbox, cancel files sent, request an audit trail, update an alias table, and work with libraries
• Provides a command-line interface for batch files

     Expedite for Windows

• Supports TCP/IP connections to Information Exchange
• Provides C and Java programming interfaces to enable interactive access to your Information Exchange mailbox
• Supports Information Exchange commands to send and receive files, list files in the mailbox, and delete files from the mailbox
• Provides a graphical interface  [Return to questions]

If you have any two versions of Expedite installed on the same system, you must be careful not to use the same Information Exchange account and user ID with more than one of the installations, and to take special precautions to manage session recovery across the separate installations.

The presence of SESSION.FIL indicates a session is in checkpoint recovery state. Do not start a session with one version if there is a SESSION.FIL file associated with another version using the same Information Exchange account and user ID.

Both Expedite and Information Exchange maintain session information. If you start a session with the installation that is not in checkpoint recovery state, this new session will cause Information Exchange to delete its previous session information so it can proceed with the new session. The installation in checkpoint recovery state will be unrecoverable. [Return to questions]

Can I install Expedite Base for Windows 4.7.1 in the same directory as an earlier version?

You can install Expedite Base for Windows Version 4.7.1 in the same directory or on the same system as any Expedite Base for Windows 4.x version.

You do not need to make any changes to applications that use Expedite Base for Windows 4.x unless you want to take advantage of features in Expedite Base for Windows 4.7.1. Your BASEIN.PRO and BASEIN.MSG scripts will work with Version 4.7.1. You should not erase IEBASE.PRO. [Return to questions]

I have an earlier version of Expedite Base for Windows, and I want to take advantage of TCP/IP dial communications. What do I need to do?

Install and configure a supported TCP stack on your system; refer to "System requirements" on the Overview page. Install Expedite Base for Windows 4.7.1 in the same directory as any 4.x version. Then, configure the AT&T Licensed IP Dialer, being sure to save the password. In your BASEIN.PRO file, specify a TCPCOMM command with your dial profile name in the DIALPROFILE parameter. Change your COMMTYPE value on the TRANSMIT command to C. You are now ready to communicate using TCP/IP.  [Return to questions]

Why are there two profile files: BASEIN.PRO and IEBASE.PRO?

As Expedite reads your BASEIN.PRO file, it writes the values to its own file, IEBASE.PRO. This is a fixed-format file that contains the permanent record of your profile information. Your application should not write to this file, or rely on the format of the file to be consistent from release to release.

Using BASEIN.PRO, you can easily create and modify IEBASE.PRO without knowing the fixed format of IEBASE.PRO and without having to encrypt passwords. While you may not encrypt passwords in BASEIN.PRO, the passwords are stored encrypted in IEBASE.PRO for you. You can erase BASEIN.PRO and rely on IEBASE.PRO for password security.

You can create BASEIN.PRO and run Expedite to create or modify the profile information. As long as your PROFILERC in BASEOUT.PRO shows a 00000 return code, you know that your IEBASE.PRO file was updated, and you can erase BASEIN.PRO. If PROFILERC is not 00000, then you have a syntax error in BASEIN.PRO that must be corrected before you can proceed.

You should not erase IEBASE.PRO, because it is the permanent record of your profile. To modify fields in IEBASE.PRO, use BASEIN.PRO.   [Return to questions]

How do I delete fields from the profile?

It is important to remember that removing a command or parameter from BASEIN.PRO does not change IEBASE.PRO. If you want to use BASEIN.PRO to delete a value from IEBASE.PRO, you must specify that value as blank in BASEIN.PRO.

Example: Assume that you have already created a BASEIN.PRO and have run Expedite. There are two PHONEx parameters on your DIAL command. You erased BASEIN.PRO, but now you want to delete PHONE2. Create BASEIN.PRO with only the following command:

        DIAL PHONE2( ) DIALCOUNT2( );

After you run Expedite and see that the PROFILERC is 00000 in BASEOUT.PRO, erase the BASEIN.PRO file. Expedite will no longer dial the second phone number.
[Return to questions]

What if I prefer not to delete BASEIN.PRO?

If you do not wish to erase BASEIN.PRO after a session, Expedite will simply use it to recreate IEBASE.PRO. [Return to questions]

Example:
Assume you have created your IEBASE.PRO successfully by creating BASEIN.PRO and running Expedite. You have erased your BASEIN.PRO file, and you have been running Expedite for a while. Now it is time to change your INPASSWORD.

Create a BASEIN.PRO file and write your new password to the NINPASSWORD parameter on the IDENTIFY command. Note that NINPASSWORD is the only field you need.

         IDENTIFY NINPASSWORD(&*(#^%$!) ... ; 

If you specified ENCRYPT(Y) in your original profile, then you must specify the new password as encrypted.

After Expedite runs, and the PROFILERC is 00000 in BASEOUT.PRO, erase your BASEIN.PRO file. The password has been changed. It does not matter whether you had a successful session or not, your IEBASE.PRO file has been updated with the new password and Expedite handles the rest. Expedite moves the NINPASSWORD to the INPASSWORD field in IEBASE.PRO and sets NINPASSWORD to blank. If there is a restart problem and Expedite cannot determine if the password was changed, it keeps a record of the old password and makes the correct decisions the next time it runs. Note that even if you did not connect to the network, if your PROFILERC was 00000, you must still erase the BASEIN.PRO file so that Expedite does not attempt to change the password again. [Return to questions]

What if I do not erase BASEIN.PRO?  How do I change passwords then?

In your BASEIN.PRO file, specify NINPASSWORD on the IDENTIFY command:

   IDENTIFY INPASSWORD(inpass1)  NINPASSWORD(inpass2) ... ;

The next time Expedite runs, it will attempt to change the password. After Expedite completes, if PROFILERC is 00000, then check IEBASE.PRO (column 25) to see if the field (8 characters) is blank. Even if the PROFILERC is 00000, the password may not have been changed if there was a problem connecting to Information Exchange, or if an error occurred while starting a session or changing the password. If the field at column 25 is blank, you can be sure Expedite successfully changed the password even if other session errors did occur.

Once Expedite changes the password, you must update BASEIN.PRO to move NINPASSWORD to INPASSWORD and remove NINPASSWORD from BASEIN.PRO. If the IEBASE.PRO field is not blank, then leave NINPASSWORD and INPASSWORD fields as they are and run Expedite again until the field is blank. If you do not wish to erase BASEIN.PRO after a session, Expedite will simply use it to recreate IEBASE.PRO. [Return to questions]

What is the format of IEBASE.PRO?

Remember that your application should never write to IEBASE.PRO. Following is the format of the first few fields in IEBASE.PRO that you can use to examine the password fields:

Account, User ID, and Password fields for IEBASE.PRO

[Return to questions]

Expedite Base for Windows provides several different options for session recovery.  How do I know which one to choose?

To select a checkpoint level to meet your needs, you need to understand how Information Exchange uses checkpoints, or commits. Information Exchange does not deliver a file until it is completely committed. That is, if the session breaks and the file is partially sent, Information Exchange does not deliver the partial file. Instead, Information Exchange waits until you resume the session and either cancel the partially sent file, or transmit the remaining characters from the file.

By default, Expedite uses checkpoint-level session recovery. With this type of recovery, Expedite takes checkpoints during the session after a certain number of characters are transmitted. The number of characters between commits is determined by your commit data setting on the transmit profile command. This is the most efficient way to do recovery. [Return to questions]

What about file-level recovery?

It may be desirable for a file to be committed in its entirety rather than in segments; for example, when sending EDI data with multiple envelopes in a single file, the envelopes are sent as individual files. Using check-point level recovery, partial envelopes may be committed when the session is interrupted. This is not an issue if you resume the session and complete it, but if you need to reset the session and complete it at a later time, it may be easier to use file-level recovery.

Resetting the session indicates to Information Exchange that any partially committed files should be discarded, and that a new session will be started. See the chapters on "Sending and receiving files" and "Sending and receiving EDI data" in the Expedite Base for Windows Programming Guide for more information on resetting the session.

Using file-level recovery, each EDI envelope is committed after it is sent. If the session is reset, you need to remove the envelopes from the file that are committed (by examining the baseout.msg file sent records).  The remaining envelopes can be sent in another session. [Return to questions]

What is the advantage of user-level recovery?

User-level recovery may be preferable if you want all the envelopes in a file (or a group of files specified on several send commands) delivered to the recipients when the session is successful, or none delivered when the session is interrupted.

User-level recovery allows you to control exactly when Expedite should do a commit when sending data. Place a COMMIT command in BASEIN.MSG after the send command where you want the commit to occur.

In this scenario, specify a commit command in the BASEIN.MSG file after the SENDEDI command so that if the session is interrupted while sending the data, none of the files will be delivered. Information Exchange delivers the files only if all the data is sent and the commit command is processed. [Return to questions]

What is the advantage of using session-level recovery?

Session-level recovery is preferable if you want all the files transmitted during the session, or none delivered if the session is interrupted. You may also select session-level recovery if you are sending small amounts of data during a session, and "dial and dump" suits your needs. Recovering a session-level session is easy because you simply run Expedite again.

There are other considerations for recovering sessions. For more information, refer to the chapters on "Sending and receiving files" and  "Sending and receiving EDI data" in the Expedite Base for Windows Programming Guide. [Return to questions]

How can I check my scripts for errors without connecting to Information Exchange?

Expedite provides a CHECK command line argument that you can use to check your scripts for syntax errors. [Return to questions]

How do I use data compression with Expedite Base for Windows?

Both the sender and receiver must have the TDAccess (formerly Comm-Press) product installed on their systems. The sender and receiver may have different systems, but can still communicate using the Expedite and TSAccess products. For more information about TDAccess products, see the bTrade, Inc. Web site at www.btrade.com.

Once the required products are installed, the sender specifies COMPRESS(Y) on the SEND or SENDEDI commands. Expedite will invoke the compression routines to compress the data before sending it. On the receive side, Expedite will automatically call the decompression routines to expand the data.

For more information about using the compression and decompression routines with Expedite, refer to the appendix on "Using data compression," in the Expedite Base for Windows Programming Guide. [Return to questions]

How can I associate an acknowledgment with a file that I sent?

When Expedite sends a file, it generates a unique identifier for the file and writes it in the BASEOUT.MSG file on the SENT record in the UNIQUEID parameter. When Information Exchange generates an acknowledgment, this identifier is included in the acknowledgment information. [Return to questions]

Expedite Base for Windows provides a text file, display.scr, which contains simple commands for displaying messages on the Expedite Base for Windows main window. You can modify this file to display messages in the message logging area of the main window.  The format of the file is the same as the format for BASEIN.MSG. Refer to the chapter on "Expedite Base for Windows Main Window" in the Expedite Base for Windows Programming Guide. [Return to questions]

Are the PICTURE and STATUS parameters still valid?

The PICTURE and STATUS parameters for the SESSION command in BASEIN.PRO no longer perform any function in regard to the display. No matter what value they are given in BASEIN.PRO, the program will default to a Y value for display purposes. The value of STATUS, however, does impact other programs. If STATUS is set to N in BASEIN.PRO and another program launched Expedite Base for Windows, then that program will not receive status information during a transmission. If STATUS is set to Y, then the program will receive status information. [Return to questions]

Can I use Microsoft Visual Basic 6.0 to write an interface to Expedite Base for Windows?

Expedite Base for Windows ships with an ActiveX control and a sample Visual Basic executable. The ActiveX control implements interapplication messaging with Expedite Base for Windows. Using the ActiveX control from a Visual Basic application, you can launch and quit Expedite Base for Windows as well as start and stop sessions. You can also receive status messages from Expedite Base for Windows. [Return to questions]

Is Expedite Base for Windows a 16- or 32-bit application?

Expedite Base for Windows Version 4.7.1 is a 32-bit application. You can use it with a 32-bit application, and you can use the Expedite interapplication messages for displaying status or controlling the operation of Expedite Base. [Return to questions]

How do I know when Expedite Base for Windows completes a session without using the interapplication status messages?

When Expedite Base completes a session, it writes the return code to a file named BASEFINI. Before your application starts Expedite Base, it should erase this file if it exists. Once your application starts Expedite Base, your should then wait until Expedite Base writes the BASEFINI file before it starts processing the BASEOUT.MSG file or any data sent or received. [Return to questions]

Does Expedite Base for Windows support data encryption over the TCP/IP connection?

When used with SSL for TCP/IP communication through the Internet or the AT&T MDNS network, Expedite Base for Windows supports data encryption. When used over the standard TCP/IP network through AT&T, data encryption is not used. [Return to questions]

This information is available in two places:

• On the PKI Web site at: http://pki.services.ibm.com/expedite.
• In the Expedite_IKEYMAN_setup.pdf guide found with your Expedite root directory or on this Web site on the Installation Instructions page. Follow the steps outlined in this document to export a certificate generated from the PKI services web site and to create KDB file used by Expedite Base program for doing SSL via TCP/IP communication.
  [Return to questions]