ftp replacement scripts user guide• 3 to 6 gb hard disk space • ftp replacement scripts software...

FTP Replacement Scripts User Guide

February, 2002

Copyright © 2002 Electric Reliability Council of Texas. All Rights Reserved.

TOC-i, 2/22/2002

FTP Replacement Scripts User Guide

Table of Contents

Preface 1 User Guide Conventions 1-1 Confidentiality Notice 1-1 Copyright/Trademark Notice 1-1 FTP Replacement Scripts Overview 2 The ERCOT Hub 2-1 The FTP Replacement Scripts Solution 2-1 FTP Replacement Script Implementation 2-2 What Functions Are Outside the Scope of the Scripts? 2-2 System Prerequisites 3 Minimum System Configuration 3-2 Directory Structure 3-4 Backup Requirements 3-6 ERCOT-Specific Configuration Information 3-7 Installation 4 Installation Guidelines 4-2 Uninstalling the Software 4-16 GnuPG Encryption/Decryption Overview 4-22 Windows NT/2000 – Generating the Key Ring (Public Key and Private Key) 4-23 Windows NT/2000 – Importing ERCOT’s Key 4-25 Windows NT/2000 – Signing ERCOT’s Key 4-26

Windows NT/2000 – Updating the Trust Relationship 4-27 UNIX – Generating the Key Ring (Public Key and Private Key) 4-28 UNIX – Importing ERCOT’s Key 4-30

UNIX – Signing ERCOT’s Key 4-31 UNIX – Updating the Trust Relationship 4-32

Functionality 5 FTP Replacement Scripts Overview 5-2 How Will the Replacement Scripts Work? 5-3 Transport-Only Processes and Transport With Encryption Processes 5-3 Transport-Only Functionality Overviews 5-4 Transport with Encryption Functionality Overviews 5-10 The Log File 5-16

TOC-ii, 2/22/2002

Encryption/Signing Basics 6 How Does Encryption/Decryption Work? 6-2 Encryption and Signing Using the FTP Replacement Scripts 6-4 Decryption and Verification Using the FTP Replacement Scripts 6-6 How Does Secure Transmission Work? 6-7 How Does HTTPS Protocol Work? 6-7 Using the Scripts 7 Constructing Valid Command Lines 7-2 Document IDs 7-3 Three Types of SEND Commands 7-3

Using Parameters 7-5 Running Scripts 7-13

Transport-Only - Using the SEND Script to Perform Uploads 7-13 Transport-Only - Using the RECEIVEALL Script to Perform General Downloads 7-14 Transport-Only-Using the DOWNLOAD Script to Perform Archive Downloads 7-15

Transport With Encryption/Decryption-Using the SEND Script to Perform Uploads 7-16 Transport With Encryption/Decryption-Using the RECEIVEALL Script to Perform General Downloads 7-17 Transport With Encryption/Decryption-Using the DOWNLOAD Script to Perform Archive Downloads 7-17

Troubleshooting 8 Troubleshooting Tools 8-2 Using the Log File 8-3 Using LogViewer 8-7

What Are Application Error Codes? 8-9 Types of Errors 8-9 Exit Codes 8-11

Application Error Codes Table 8-12 Contacting ERCOT 9 When to Call 9-2 Reporting ERCOT Server Outages 9-2 Contact Number 9-2 Appendix A - Configuring PGP A Configuring the PGP.CFG File for the FTP Replacement Scripts A-2 Sample PGP.CFG File A-3 Other PGP Configuration Recommendations A-11

1-1, 2/22/2002

FTP Replacement Scripts User Guide Preface

Welcome to your FTP Replacement Scripts User Guide! This set of documents should provide the information, explanations, and step-by-step procedures for you and your staff to successfully understand and use the FTP Replacement Scripts software. This section includes the following topics:

• User Guide Conventions • Confidentiality Notice • Copyright/Trademark Notice

User Guide Conventions

We hope you find this book informative and easy to use. Here are a few guidelines on how the information is presented:

• Each chapter is represented by a numbered section.

• Each section is divided into topics.

• Each section gives an overview and explains what topics will be covered.

• Screen names and field entries are in bold type for emphasis.

• NOTES and REMINDERS are inserted when needed, and are always in bold, blue type.

Copyright/Trademark Notice

Copyright 2002, Electric Reliability Council of Texas. All rights reserved. All product names and company names herein are the property of their respective companies. Use in binary form, without modification, is permitted provided that the following conditions are met. Electronic redistributions must include:

• The ERCOT copyright notice shown here, • An acknowledgement that “This product includes software developed by the Electric

Reliability Council of Texas (http://www.ercot.com/),” and

1-2, 2/22/2002

• A statement that the names “ERCOT” and “Electric Reliability Council of Texas” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, ERCOT’s 24-hour Helpdesk may be contacted at (512) 248-6800.

2-1, 2/22/2002

Overview

This section provides a brief explanation of the FTP Replacement Scripts and related features. It includes the following topics: • The ERCOT Hub • The FTP Replacement Scripts Solution • FTP Replacement Script Implementation • What Functions Are Outside the Scope of the Scripts?

The ERCOT Hub

As part of the deregulated energy marketplace in Texas, The Electric Reliability Council of Texas (ERCOT) operates a “transaction clearinghouse” used to exchange business data transactions between Market Participants (MPs) in the Texas Choice Program. Under the current clearinghouse structure, the ERCOT hub uses FTP (File Transfer Protocol) data exchange techniques to send and receive MP business transactions. The system can be visualized as a wheel, with the ERCOT server as the hub and MP mailboxes as spokes on the wheel. A “push-pull” technique is currently used to transfer data to/from the ERCOT hub to MP mailboxes: MPs use FTP scripts to push and pull data to their mailboxes located on ERCOT’s hub. Many MPs have concerns about the future viability of this system. FTP technology can be unreliable and error-prone. One group of MPs, the Texas Data Transport Work Group (TDTWG), has suggested that existing FTP scripts should be replaced by GISB (Gas Industry Standards Board) EDM (Electronic Delivery Mechanism) technology. GISB EDM software is currently used by MPs for their point-to-point transaction data exchange. GISB EDM software has several drawbacks. The primary problems are that it does not support mailboxing based on pull techniques and the next version of GISB EDM, which will contain security enhancements required by ERCOT, is still in development. In a recent study conducted on the FTP and GISB EDM approaches, ERCOT concluded that neither solution meets the needs of ERCOT. As a result, ERCOT began a project to replace the current FTP scripts.

The FTP Replacement Scripts Solution

The FTP Replacement Scripts will meet ERCOT’s strict requirements for security and reliability. In addition, the scripts will be cost-effective for small MPs and make it easy for MPs to audit and track transaction status. In the proposed solution, new FTP scripts based on a hybrid “push/pull” data transfer technique are used. MPs may either send (push) or retrieve (pull) data using ERCOT’s mailboxing system. Additionally, ERCOT will support the next version of GISB EDM, which contains additional security features not available in the current GISB EDM standard, version 1.5.

2-2, 2/22/2002

Since the FTP Replacement Scripts will be available prior to the next version of GISB EDM, they will enhance data security and reliability for MPs during this interim period. When the next version of GISB EDM is available, ERCOT will allow MPs to communicate with ERCOT using this technique.

FTP Replacement Script Implementation

The new push/pull data transfer technique, while similar to data transfer techniques used in the existing FTP scripts, will be based on the ebXML standard. The new scripts provide the benefits of a Secure Sockets Layer (SSL) to provide encryption and privacy, and will also provide formal support for XML transactions and unique message identifiers to track XML data, as required by ERCOT. In addition, the scripts will support Open PGP (Pretty Good Privacy) software. At project completion, ERCOT will provide the FTP Replacement Scripts free of charge to new MPs and to existing MPs who request the scripts. MPs who require GISB EDM version 1.5 and its enhancements may choose to implement the replacement scripts and or upgrade to GISB EDM when it becomes available. These benefits will be available to MPs who choose to upgrade their FTP scripts:

• Security risks will be reduced or eliminated and reliability will be improved.

• Auditing features will be available to enhance transaction tracking and logging.

• Processing will be streamlined, with fewer points of failure.

• Testing and implementation will be simplified.

• Expensive privacy software (PGP) will be replaced with Gnu Privacy Guard (GnuPG).

• “Push” and “pull” data transfer techniques will both be available—so that the needs of both small and large MPs are satisfied.

What Functions Are Outside the Scope of the Scripts?

The FTP Replacement Scripts software does not have the ability to provide cryptographic key management or task scheduling/looping.

3-1, 2/22/2002

System Prerequisites

This section provides an overview of the minimum hardware and software configuration required to use the FTP Replacement Scripts. It includes the following topics: • Minimum System Configuration • Directory Structure • Backup Requirements • ERCOT-Specific Configuration Information

3-2, 2/22/2002

Minimum System Configuration

Hardware Minimum hardware requirements for Windows NT/2000 and UNIX systems on the client side of the FTP Replacement Scripts system are shown below.

Windows NT/2000 Requirements Main System for Windows NT/2000:

• An Intel PC with a Pentium III Processor

UNIX Requirements Main System for UNIX:

• IBM RS/6000 General System Requirements Input Devices:

• Keyboard • Mouse

Memory: • 512 MB RAM

Storage: • 3 to 6 GB Hard Disk Space • FTP Replacement Scripts software uses 20 MB of the 36 GB Hard Disk Space • CD-RW/CD ROM (required only if using a CD for FTP Replacement Scripts

installation) Video:

• 17" Monitor • X-Windows or MS Windows-Compatible Video Adapter

Network: • Ethernet • TCP/IP • Internet Access

Operating System Software The minimum operating software requirements for the client side of the FTP Replacement Scripts system are shown below. Note that Java Runtime software is not required since InstallAnywhere software performs the required Java Runtime functions.

For Windows NT/2000 Systems:

• Windows 2000 Professional or Server Operating System with Service Pack 2 or higher

• Windows NT with Service Pack 6 or higher For UNIX Systems, when running PGP e-business server version 6.5 or GnuPG version 1.0.6:

• AIX 4.3 or later

3-3, 2/22/2002

Privacy Software If the FTP Replacement Scripts will be used to perform cryptographic functions using PGP or GnuPG, the cryptographic software must be installed on the same machine where the FTP Replacement Scripts software resides, but does not have to be in the same logical drive (C: or D:) or folder as the scripts software. NOTE: Both of these software packages are optional and are used only if the scripts software will provide encryption/decryption and verification/signing. If the FTP Replacement Scripts will not be performing cryptographic functions (in a transport-only installation) the cryptographic software may be installed anywhere, including on a network drive. PGP Requirements (optional):

• PGP e-business server version 6.5 with Command Line Capability

• Refer to your PGP documentation for any additional PGP requirements GnuPG Requirements (optional):

• GnuPG version 1.0.6

3-4, 2/22/2002

Directory Structure

Recommended directory structures and system snapshots for the client side of the FTP Replacements Scripts are shown below and on the following page. SEND Directory Structure ARCHIVE

/SEND LOG REJECT /SEND SEND

SEND Directory Structure Snapshot:

DOWNLOAD Directory Structure ARCHIVE /OUT /REPORTS LOG OUT RECEIVED

/BAD /OUT /REPORTS

REJECT

/BAD /OUT /REPORTS

DOWNLOAD Directory Structure Snapshot:

3-5, 2/22/2002

RECEIVEALL Directory Structure ARCHIVE

/BAD /OUT /REPORTS

LOG RECEIVED

/BAD /OUT /REPORTS

REJECT /BAD /OUT /REPORTS

RECEIVEALL Directory Structure Snapshot:

NOTE: In the RECEIVEALL structure, the subfolders /OUT, /REPORTS, and /BAD are created when ERCOT sends files from its corresponding folders during a RECEIVEALL command. These folders will mirror the structure of the corresponding ERCOT folders. So, if ERCOT changes folder names and you perform a RECEIVEALL, your folder names will change to match ERCOT’s folder names. Note that files will be appended to your folders as they are received from ERCOT; files are never overwritten unless a received file has the same name as an existing file in your folder.

3-6, 2/22/2002

Archive Directory Contents As shown in the snapshot below, all files in the ARCHIVE directory will be “paired” when privacy software (PGP or GnuPG) is used (Transport with Encryption/Decryption version of the FTP Replacement Scripts). For example, in the case of a text file, one file will have the .edi extension and the companion file will have the .edi.pgp extension. The file with the .edi.pgp extension is encrypted; the other file is unencrypted. Note that the .pgp extension is always added regardless of whether PGP or GnuPG privacy software is used.

Backup Requirements

Administrators should take all steps necessary to prevent data loss. ERCOT’s general recommendations are outlined below.

Archive Directories ERCOT recommends that Administrators keep “archive” directories on separate hard drives from those used to send and receive data with ERCOT. It is also strongly recommended that Redundant Array of Inexpensive Disks (RAID) technology be used on the “archive” directories as well as the directories used to send and receive data with ERCOT.

Backup Schedules Administrators should perform backups on a regular basis. Backed up data should be stored offline (on magnetic tape, CD ROM, etc.). ERCOT strongly recommends that offline backups be created at least weekly, and preferably daily, in order to prevent data loss.

Redundant Backup Facilities Administrators should also ensure that there are adequate redundant backup facilities available to prevent downtime. It is recommended that backup communication lines be in place in the event of a communication failure. Additionally, administrators should maintain spare equipment to be used as a hot failover in the event of a catastrophic failure of the main processing system used to communicate with ERCOT.

3-7, 2/22/2002

ERCOT-Specific Configuration Information

ERCOT DUNS Number 183529049

ERCOT’s URL for Message Broker https://b2b.ercot.com:44337/servlet/b2b/ebxml-100

4-1, 2/22/2002

Installation

This section describes the FTP Replacement Script installation procedures. During installation, GnuPG version 1.0.6 may also be installed. If you are using PGP for encryption/decryption, or if you already have GnuPG version 1.0.6 installed on your system, you can skip the installation option provided to install GnuPG software. If PGP privacy software is used, refer to your PGP system documentation for proper installation procedures. Installation procedures for the FTP Replacement Scripts are straightforward. First, request your Installation Package from the ERCOT Helpdesk. Then run the executable installation file to install the software and create the proper directories and databases. If you are installing GnuPG as part of your installation package, refer to the appropriate “Encryption/Decryption Overview” topic to review the processes for generating your key ring, importing ERCOT’s key, signing the key and updating the trust relationship. This section includes the following topics:

• Installation Guidelines • Uninstalling the Software • GnuPG Encryption/Decryption Overview

GnuPG - Windows NT/2000 GnuPG Platform • Windows NT/2000 - Generating the Key Ring (Public Key and Private Key) • Windows NT/2000 - Importing ERCOT’s Key • Windows NT/2000 - Signing ERCOT’s Key • Windows NT/2000 - Updating the Trust Relationship GnuPG - UNIX GnuPG Platform • UNIX - Generating the Key Ring (Public Key and Private Key) • UNIX - Importing ERCOT’s Key • UNIX - Signing ERCOT’s Key • UNIX - Updating the Trust Relationship

4-2, 2/22/2002

Installation Guidelines

Minimum system configuration guidelines are detailed in Section 3 – System Prerequisites. Prior to performing these procedures, verify that the minimum configuration is present. In addition, you’ll need these items to complete installation: • FTP Replacement Scripts Installation Package available from the ERCOT Helpdesk

(including a CD if you are installing the scripts from an executable on the CD) • A supported system on which you are installing the FTP Replacements Scripts software NOTE: Prior to performing installation, review the Misc and Docs folders on the installation CD for the ERCOT public key, documentation and other information. At the root level of the CD, a readme.txt file lists all known issues. This section describes FTP Replacement Scripts installation procedures for both transport-only and transport with encryption/decryption scenarios. As part of the FTP Replacement Scripts installation, GnuPG may be installed. Transport with Encryption/Decryption Installation Guidelines For transport with encryption/decryption software installation, there are 3 installation scenarios.

Scenario Steps

Encryption/Decryption Software (PGP or GnuPG) is already installed

• If PGP is used, verify that the installed version of PGP is the e-business server version 6.5 or higher with Command Line Capability. Then follow the steps in the Appendix A topic “Configuring the PGP.CFG File for the FTP Replacement Scripts.”

• If GnuPG is used, verify that the installed version 1.0.6 or higher.

• Install the FTP Replacement Scripts software using procedures in the topic “FTP Replacement Scripts Installation,” and selecting “no” in the Install GnuPG screen.

PGP Encryption/Decryption Software must be installed

• Install PGP e-business server version 6.5 or higher with Command Line Capability software according to the instructions provided with the software. Then follow the steps in the Appendix A topic “Configuring the PGP.CFG File for the FTP Replacement Scripts.”

• Install the FTP Replacement Scripts software using procedures in the topic “FTP Replacement Scripts Installation,” and selecting “no” in the Install GnuPG screen.

GnuPG Encryption/Decryption Software must be installed

• Install the FTP Replacement Scripts software using procedures in the topic “FTP Replacement Scripts Installation,” and selecting “yes” in the Install GnuPG screen.

• Follow the procedures in the topic “GnuPG Encryption/Decryption Overview” for Windows NT/2000 or UNIX after performing installation.

4-3, 2/22/2002

There are two platforms used for the FTP Replacement Scripts installation: Windows NT/2000 and UNIX. Both installation procedures are outlined in the topics which follow.

Windows NT/2000 FTP Replacement Scripts Installation For FTP Replacement Script installation on the Windows NT/2000 platform: 1. Using your ERCOT-provided installation package, follow the ERCOT guidelines to begin

installation. The steps here show installation performed via CD. 2. Place the ERCOT-provided installation CD in your CD ROM drive. Navigate to the CD ROM

drive and look for the installation shortcut in the Windows folder, shown below.

3. Double-click the install.exe shortcut. The installation process will begin and the

InstallAnywhere window shown below displays.

4. When the InstallAnywhere process has completed, the FTP Replacement Scripts Introduction window displays.

4-4, 2/22/2002

5. As directed, quit all programs before proceeding. Click Next to display the License Agreement window. Read the agreement and select the I accept the terms of the License Agreement button to proceed with installation. If you do not accept the terms of the agreement, the installation process will end.

6. Click Next to begin installation. The Choose Install Folder window displays.

4-5, 2/22/2002

7. Click Next to choose the C:\Program Files\FTPReplacementScripts folder for installation or click Choose to display the Browse for Folder window. If you browse for a folder to install into, make your selection and click OK to exit the Browse for Folder window. To reset the installation directory back to the default of C:\Program Files\FTPReplacementScripts, click Restore Default Folder.

8. When the appropriate installation folder has been selected, click Next. The Install GnuPG window displays.

9. To Install GnuPG version 1.0.6, select Yes; otherwise, select No. Then click Install. If you have selected Yes, the Choose a Folder window displays. Go to step 10. Otherwise, skip to step 12 to complete installation without installing GnuPG software.

4-6, 2/22/2002

10. Click Next to choose the C:\GNUPG folder for installation or click Choose to display the Browse for Folder window. If you browse for a folder to install into, make your selection and click OK to exit the Browse for Folder window. To reset the GnuPG installation directory back to the default of C:\GNUPG, click Restore Default Folder.

4-7, 2/22/2002

11. When the appropriate installation folder has been selected, click Next. The Important Information window displays information regarding the licensing of Gnu Privacy Guard. ERCOT is providing Gnu Privacy Guard as a convenience and at no cost in accordance with the Gnu Public License. Read the information about GnuPG and click Next to continue with installation.

12. When the appropriate installation folder has been selected, click Next. The Pre-Installation Summary window displays. If you are installing GnuPG, the summary includes the installation directory selected for the GnuPG software. Click Install to continue the installation.

4-8, 2/22/2002

13. The Installing FTP Replacement Scripts window displays, showing progress as the installation proceeds.

14. When the Install Complete window displays, click Done to exit. The InstallAnywhere window will display to indicate that the installation is finishing up. As recommended, restart your system by navigating to the Start menu bar, selecting Shut Down – Restart and then clicking OK.

4-9, 2/22/2002

15. Installation is complete after you restart your system. If you have installed GnuPG, refer to the topic “GnuPG Encryption/Decryption Overview” for Windows NT/2000 after performing installation. A troubleshooting tool, LogViewer, is installed along with the scripts. Refer to Section 8 – Troubleshooting for complete LogViewer information.

4-10, 2/22/2002

UNIX FTP Replacement Scripts Installation For FTP Replacement Script installation on the UNIX platform: 1. Using your ERCOT-provided installation package, follow the ERCOT guidelines to begin

installation. The steps here show installation performed via CD. 2. Place the ERCOT-provided installation CD in your CD ROM drive and mount the CD ROM

using SMIT or the mount command. Once the CD ROM has been mounted, change your working directory to where you mounted the CD ROM, e.g. /cdrom.

3. From the # prompt, type./install.bin –i awt and press ENTER. The installation process will begin. A series of messages display (beginning with Preparing to install… and ending with Launching installer…) and the FTP Replacement Scripts Introduction window displays.

4. As directed, quit all programs before proceeding. Click Next to display the License Agreement window. Read the agreement and select the I accept the terms of the License Agreement button to proceed with installation. If you do not accept the terms of the agreement, the installation process will end.

4-11, 2/22/2002

5. Click Next to begin installation. The Choose Install Folder window displays with a default installation folder of /MPCS.

4-12, 2/22/2002

6. Click Next to choose the /MPCS folder for installation or click Choose to display the Select a Folder window. If you browse for a folder to install into, make your selection and click Select to exit the Select a Folder window. To reset the installation directory back to the default of /MPCS, click Restore Default Folder.

7. When the appropriate installation folder has been selected, click Next. The Install GnuPG window displays.

8. To Install GnuPG version 1.0.6, select Yes; otherwise, select No. Then click Install. If you have selected Yes, the Choose a Folder window displays. Go to step 9. Otherwise, skip to step 12 to complete installation without installing GnuPG software.

4-13, 2/22/2002

9. Click Next to choose the /GNUPG folder for installation or click Choose to display the Select a Folder window. If you browse for a folder to install into, make your selection and click Select to exit the Select a Folder window. To reset the GnuPG installation directory back to the default of /GNUPG, click Restore Default Folder

10. When the appropriate installation folder has been selected, click Next. The Important Information window displays information regarding the licensing of Gnu Privacy Guard. ERCOT is providing Gnu Privacy Guard as a convenience and at no cost in accordance with the Gnu Public License. Read the information about GnuPG and click Next to continue with installation.

4-14, 2/22/2002

11. When the appropriate installation folder has been selected, click Next. The Pre-Installation Summary window displays. If you are installing GnuPG, the summary includes the installation directory selected for the GnuPG software. Click Install to continue the installation.

12. The Installing FTP Replacement Scripts window displays, showing progress as the

installation proceeds.

4-15, 2/22/2002

13. When the Install Complete window displays, click Done to exit. The InstallAnywhere window will display to indicate that the installation is finishing up. Use the unmount command prior to removing the Installation CD.

14. Installation is complete. If you have installed GnuPG, refer to the topic “GnuPG Encryption/Decryption Overview” for UNIX after performing installation. A troubleshooting tool, LogViewer, is installed along with the scripts. Refer to Section 8 – Troubleshooting for complete LogViewer information.

4-16, 2/22/2002

Uninstalling the Software

There are two supported platforms that the FTP Replacement Scripts may be uninstalled from: Windows NT/2000 and UNIX. Both uninstall procedures are outlined here.

NOTE: Unlike the FTP Replacement Scripts software, GnuPG cannot be uninstalled by removing it via the Add/Remove Programs window. To remove GnuPG from your system, you must manually delete the GnuPG folder and its contents from your system. Performing a Windows NT/2000 Uninstall 1. From the Start menu bar, select Settings – Control Panel – Add/Remove Programs. The

Add/Remove Programs window displays. Scroll through the programs to locate the FTP Replacement Scripts program.

2. Select this program and click Change or Remove Programs or the Change/Remove button.

3. The system will display the Uninstall FTP Replacement Scripts window. Click Uninstall to proceed.

4-17, 2/22/2002

4. A second Uninstall window displays as individual components are being uninstalled. When the uninstall is complete, the Uninstall FTP Replacement Scripts – Uninstall Complete window displays, as shown below.

4-18, 2/22/2002

NOTE: If GnuPG was installed as part of the FTP Replacement Scripts software installation, a message displays on this window indicating “Unable to remove directory: C:\GNUPG.” This is not an error message and may be ignored. It simply indicates that Add/Remove Programs could not be used to uninstall GnuPG. A screen sample is shown below. If GnuPG was installed manually (not as part of the FTP Replacement Scripts installation), this message will not display. If data was added to the folder where the FTP Replacement Scripts software was installed, a similar message will display indicating the data was not removed by the uninstaller.

5. Click Quit. The Add/Remove Programs window redisplays with the FTP Replacement Scripts software listing deleted.

4-19, 2/22/2002

6. Close the Add/Remove Programs window by clicking Close. The InstallAnywhere window

will display to indicate that additional post-installation cleanup is being performed. The uninstall is complete.

4-20, 2/22/2002

Performing a UNIX Uninstall 1. Go to the directory where the FTP Replacement Scripts software is installed (MPCS in our

example). At the # prompt, type ./MPCS/UninstallerData/Uninstall MPCS –i awt and press ENTER.

2. The system will display the Uninstall FTP Replacement Scripts window. Click Uninstall to proceed.

3. A second Uninstall window displays as individual components are being uninstalled. When the uninstall is complete, the Uninstall FTP Replacement Scripts – Uninstall Complete window displays, as shown below.

4-21, 2/22/2002

NOTE: If GnuPG was installed as part of the FTP Replacement Scripts software installation, a message displays on this window indicating “Unable to remove directory: /GNUPG.” This is not an error message and may be ignored. It simply indicates that this uninstaller could not uninstall GnuPG. A screen sample is shown below. If GnuPG was installed manually (not as part of the FTP Replacement Scripts installation), this message will not display. If data was added to the folder where the FTP Replacement Scripts software was installed, a similar message will display indicating the data was not removed by the uninstaller.

4. Click Quit. The uninstall is complete.

4-22, 2/22/2002

GnuPG Encryption/Decryption Overview

The FTP Replacement Scripts software uses GnuPG (Gnu Privacy Guard) software to encrypt and digitally sign transactions transmitted between your organization and ERCOT. To provide the information to enable this secure communication, your organization must:

• Install the GnuPG program, and • Set up the trust relationship parameters The FTP Replacement Scripts installation kit may be used to install GnuPG. Alternatively, MPs may install GnuPG using the installation procedures described on the GnuPG website, http://www.gnupg.org. To set up the trust relationship parameters, use the procedures shown here for the Windows NT/2000 or UNIX platforms. Specific topics include:

• Generating the Key Ring, Importing ERCOT’s Key, Signing ERCOT’s Key and Updating the Trust Relationship on the Windows NT/2000 platform, and

• Generating the Key Ring, Importing ERCOT’s Key, Signing ERCOT’s Key and Updating the Trust Relationship on the UNIX platform

Conventions for GnuPG Commands Throughout this section, you will be entering commands to set the parameters for GnuPG. Please note the following conventions: • All GnuPG commands must be in lower case. • In the command examples in the following topics, a caret (^) below the line (subscript)

indicates that you are to enter a space into the command.

• Allow your commands to line wrap based on the margins of your monitor. Do not press ENTER (line return) before the end of a command string.

• Use the up arrow key ( ) to repeat a previous command.

4-23, 2/22/2002

Windows NT/2000 - Generating the Key Ring (Public Key and Private Key)

Generating the key ring (i.e., the public key and private key pair) creates the public and private key and “signs” the keys (i.e., validates the authenticity/ownership of the keys); populates the public-key directory with data; creates a backup of the public key; and creates a random seed file (see Step 6) for further encrypted identification.

1. Make sure you are in the gnupg home directory, e.g. “C:\GNUPG:”

2. Using GnuPG, create your private/public key pair by typing the following command: c:\gnupg\gpg

^--gen-key

Note that the following entries display to indicate that the private (secret) key (the “secring”) and the public key (the “pubring”) have been created:

gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: c:/gnupg/secring.gpg: keyring created gpg: c:/gnupg/pubring.gpg: keyring created

3. Define the key pair.

3.1. Press ENTER to select the default key kind (1) DSA and ElGamal (this default type includes signature and encryption functionality).

Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) Your selection? 1

3.2. Press ENTER to select the default key size 1024 bits. DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What keysize do you want? (1024) Requested keysize is 1024 bits

3.3. For the time period that the key should remain valid, enter 2Y (for two years) and confirm this entry by entering Y (for yes).

Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 2y Key expires at 02/22/04 11:17:12 Is this correct (y/n)? y

4-24, 2/22/2002

You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <[email protected]>" Real name: Market Participant Name Email address: [email protected] Comment: ERCOT Keys You selected this USER-ID: "Market Participant Name (ERCOT keys) <[email protected]>"

4. As shown above, define the user ID to identify the key. Enter a real name, an e-mail address, and comments that describe the key; enter (O)kay to accept your User ID when prompted.

5. The system will prompt you to enter a passphrase, but do not enter one. Instead, press ENTER twice without making any entries.

NOTE: When you press ENTER, warnings or instructions may display. Disregard them.

6. The GnuPG software will now display some characters on the screen while the keys are being generated. When your keys have been created the software will display:

public and secret key created and signed.

7. List the keys to confirm this operation. c:\gnupg>gpg

^--list-keys

8. Verify the list results. c:/gnupg/pubring.gpg -------------------- pub 1024D/21891B17 2002-02-04 Market Participant Name <ERCOT Keys> <[email protected]> sub 1024g/EE7DF952 2002-02-04 [expires: 2004-02-22]

9. Record your key ID in a safe place. In the example above, the key ID is 21891B17. The sub key ID may be disregarded.

4-25, 2/22/2002

Windows NT/2000 - Importing ERCOT’s Key

The ERCOT key must be imported from ERCOT in order for the FTP Replacement Scripts software to successfully send transactions to ERCOT and receive transactions from ERCOT. The addition of a second public key to your GNUpg home directory (c:\gnupg) creates a trust relationship, evidenced by the trustdb.gpg file (see Step 3).

1. Obtain ERCOT’s public key.

2. Use the import command to set up ERCOT’s public key: c:\gnupg>gpg

^--import

^c:\gnupg\ERCOTPubKey.gpg

3. Review the import results. gpg: key F6DF65D9: public key imported gpg: c:/gnupg/trustdb.gpg: trustdb created gpg: NOTE: secret key E44242D2 is NOT protected. gpg: Total number processed: 1 gpg: imported: 1 <RSA 1>

NOTE: The addition of the imported ERCOT public key creates a trust relationship database, indicated by the trustdb.gpg file in line 2 of your import results.

4. List the keys to confirm this operation. c:\gnupg>gpg

^--list-keys

5. Verify the list results; you should see ERCOT’s public key in the displayed list. pub 1024D/E44242D2 2002-02-22 Market Participant Name(ERCOT Keys) <[email protected]> sub 1024g/9D1EB958 2002-02-22 [expires: 2004-02-22] pub 1024D/F6DF65D9 2002-02-08 ERCOT-pub-key sub 1024g/BD465286 2002-02-08 [expires: 2004-02-22]

4-26, 2/22/2002

Windows NT/2000 - Signing ERCOT’s Key

Signing the ERCOT key signifies your receipt and trust of the key.

1. Sign ERCOT’s key with the sign key (sign-key) command. c:\gnupg>gpg

^--sign-key

^ERCOT-pub-key-UserId

NOTE: You must use the real name or key ID of ERCOT’s public key in place of ERCOT-pub-key-UserId. Step 4 in the previous topic shows how to list the key ID.

2. Indicate your acceptance of the results by signing the key with a Y (yes) response. Are you really sure that you want to sign this key with your key: "Market Participant Name (ERCOT Keys) <[email protected]>" Really sign? y

4-27, 2/22/2002

Windows NT/2000 - Updating the Trust Relationship

Updating the trust database creates a trust relationship between the two keys (your organization's and ERCOT’s) in the trust database (trustdb.gpg) that was created when you signed ERCOT’s key.

1. Update the trust relationship with the update trust database (update-trustdb) command:

c:\gnupg>gpg^--update-trustdb

2. Look for the following results: gpg: NOTE: secret key E44242D2 is NOT protected. gpg: 2 keys processed

NOTE: If the key relationship was previously updated, the message you receive will indicate the previous update.

3. Execute an armor output (-a –o) command to create an ASCII-armored (-a) output file (-o) for export.

NOTE: The syntax of the armor and the output commands requires only one dash (-). c:\gnupg>gpg

^-a

^-o^c:\gnupg\yourutility.gpg

^ --export

^[email protected]

4. E-mail the resulting output file (i.e., yourutility.gpg) to the ERCOT administrator.

4-28, 2/22/2002

UNIX - Generating the Key Ring (Public Key and Private Key)

Generating the key ring (i.e., the public key and private key pair) creates the public and private key and “signs” the keys (i.e., validates the authenticity/ownership of the keys); populates the public-key directory with data; creates a backup of the public key; and creates a random seed file (see Step 6) for further encrypted identification. 1. Add the generate key command (gen-key) to the home directory prefix:

# gpg^--homedir

^[chosen directory]

^--gen-key

2. Note that the following entries display to indicate that the private (secret) key (the “secring”) and the public key (the “pubring”) have been created:

gpg: /root/.gnupg/secring.gpg: keyring created gpg: /root/.gnupg/pubring.gpg: keyring created

NOTE: /root/.gnupg/ will be replaced with your chosen home directory

3. Define the key pair.

3.1. Press ENTER to select the default key kind (1) DSA and ElGamal (this default type includes signature and encryption functionality).

Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (3) ElGamal (sign and encrypt)

Your selection? 1

3.2. Press ENTER to select the default key size 1024 bits. DSA keypair will have 1024 bits. About to generate a new ELG-E keypair.

minimum keysize is 768 bits default keysize is 1024 bits

highest suggested keysize is 2048 bits What keysize do you want? (1024) Requested keysize is 1024 bits

3.3. For the time period that the key should remain valid, enter 2Y (for two years) and confirm this entry by entering Y (for yes).

Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years

Key is valid for? (0) 2y Key expires at 06/22/03 11:17:12 Is this correct (y/n)? y

4-29, 2/22/2002

You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <[email protected]>" Real name: Market Participant Name Email address: [email protected] Comment: ERCOT Keys You selected this USER-ID: "Market Participant name (ERCOT Keys) <[email protected]>"

4. As shown above, define the user ID to identify the key. Enter a real name, an e-mail address, and comments that describe the key; enter (O)kay to accept your User ID when prompted:

5. The system will prompt you to enter a passphrase, but do not enter one. Instead, press ENTER twice without making any entries.

NOTE: When you press ENTER, warnings or instructions may display. Disregard them.

6. Look for the message: public and secret key created and signed.

7. List the keys to confirm this operation. # gpg

^--homedir

^[chosen directory]

^--list-keys

8. Verify the list results. pub 1024D/E44242D2 2001-06-22 ERCOT Market Participant Name (ERCOT Keys) <[email protected]> sub 1024g/9D1EB958 2001-06-22 [expires: 2004-02-22]

9. Record your key ID and identifying information. In the example the key ID is E44242D2. The sub key ID may be disregarded.

4-30, 2/22/2002

UNIX - Importing ERCOT’s Key

The ERCOT key must be imported from ERCOT in order for the FTP Replacement Scripts software to successfully send transactions to ERCOT and receive transactions from ERCOT. The addition of a second public key to your GnuPG home directory creates a trust relationship, evidenced by the trustdb.gpg file (see Step 3).

1. Obtain ERCOT’s public key.

2. Use the import command to set up ERCOT’s public key in your home directory: #gpg

^--homedir

^[chosen directory]

^--import

^ERCOT-PubKey.gpg

3. Review the import results. gpg: key F6DF65D9: public key imported gpg: /root.gnupg/trustdb.gpg: trustdb created gpg: NOTE: secret key E44242D2 is NOT protected. gpg: Total number processed: 1 gpg: imported: 1

NOTE: The addition of the imported ERCOT public key creates a trust relationship database, indicated by the trustdb.gpg file in line 2 of your import results.

4. List the keys to confirm this operation. #gpg

^--homedir

^[chosen directory]

^--list-keys

5. Verify the list results. You should see ERCOT’s public key in the displayed list. pub 1024D/E44242D2 2001-06-22 Market Participant Name (ERCOT Keys) <[email protected]> sub 1024g/9D1EB958 2002-02-22 [expires: 2004-02-22] pub 1024D/F6DF65D9 2002-02-22 ERCOT-pub-key sub 1024g/BD465286 2002-02-22 [expires: 2004-02-22]

4-31, 2/22/2002

UNIX - Signing ERCOT’s Key

Signing ERCOT’s key signifies your receipt and trust of the key.

1. Sign ERCOT’s key with the sign key (sign-key) command. #gpg

^--homedir

^[chosen directory]

^--sign-key

^ERCOT-pub-key-UserId

NOTE: You must use the real name or key ID in place of ERCOT-pub-key-UserId. Step 4 in the previous topic shows how to list the key ID.

2. Indicate your acceptance of the results by signing the key with a Y (yes) response. Are you really sure that you want to sign this key with your key: "Market Participant Name (ERCOT Keys) <[email protected]>" Really sign? y

4-32, 2/22/2002

UNIX - Updating the Trust Relationship

Updating the trust database creates a trust relationship between the two keys (your organization's and ERCOT’s) in the trust database (trustdb.gpg) that was created when you signed ERCOT’s key.

1. Update the trust relationship with the update trust database (update-trustdb) command:

#gpg^--homedir

^[chosen directory]

^--update-trustdb

2. Look for the following results: gpg: NOTE: secret key E44242D2 is NOT protected. gpg: 2 keys processed

NOTE: If the key relationship was previously updated, the message you receive will indicate the previous update.

3. Execute an armor output (-a –o) command to create an ASCII-armored (-a) output file (-o) for export.

NOTE: The syntax of the armor and the output commands requires only one dash (-). #gpg

^--homedir

^[chosen directory]

^-a

^-o^yourutility.gpg

^ --export

^[email protected]

4. E-mail the resulting output file (i.e., yourutility.gpg) to the ERCOT administrator.

5-1, 2/22/2002

Functionality

The FTP Replacement Scripts provide all the required functionality to exchange files with ERCOT. The complete package consists of scripts, binary programs and libraries that implement encryption functions. All software is based on ERCOT’s push-pull protocol. This section provides an overview of how the FTP Replacement Scripts work. This section includes the following topics:

• FTP Replacement Scripts Overview • How Will the Replacement Scripts Work? • Transport-Only Processes and Transport With Encryption Processes • Transport-Only Functionality Overviews • Transport With Encryption Functionality Overviews • The Log File

5-2, 2/22/2002

FTP Replacement Scripts Overview

The FTP Replacement Scripts were developed using a “client-server” approach. The scripts—for SEND, RECEIVEALL and DOWNLOAD—are provided to the Market Participants and this forms the “client” side of the package. The “server” side of the package, performing ERCOT server-related file transport functions, resides at ERCOT. The client side of the FTP Replacement Script software provides the capability to: • Encrypt and digitally sign data files.

• Decrypt and verify digital signatures on data files.

• Send encrypted/signed files to ERCOT’s hub system.

• Retrieve encrypted/signed files from ERCOT’s hub system

• Maintain audit logs (via a Log file) with detailed tracking information of all files sent, received and processed.

• Log activities related to sending and receiving status, including any errors encountered, when an activity start/ends, and interim progress points (e.g. receiving response from server, sending request to server, etc.).

• Report failures to administrators immediately upon detection.

• Prevent sending incomplete files.

• Function seamlessly with all firewalls, packet filters, transparent- and application-based proxy servers, net nanny’s, caching servers and SSL accelerators.

• Maintain an archive of files sent and received.

• Recover/retrieve files from archive.

• Support SSL (Secure Sockets Layer) sessions.

• Support use of wildcards for upload.

5-3, 2/22/2002

How Will the Replacement Scripts Work?

ERCOT will provide Market Participants with the scripts described here to replace the original FTP scripts provided by ERCOT. The new scripts will contain the functionality needed to encrypt/sign, decrypt/verify, send (push) and receive (pull) data files with ERCOT’s Mailboxing Hub. The specific commands provided in the scripts include:

• SEND – Used to upload files from the Market Participant to the Market Participant’s mailbox on the ERCOT server.

• RECEIVEALL – Used to pull files from the Market Participant’s mailbox on the ERCOT server.

• DOWNLOAD – Used to pull a single file that has been archived on the ERCOT server. After Market Participants construct valid command lines using the scripts, they will be able to send and receive data from ERCOT. SEND, RECEIVEALL and DOWNLOAD command lines are described fully in Section 7 – Using the Scripts.

Transport-Only Processes and Transport With Encryption Processes

There are two main “versions” of the SEND, RECEIVEALL and DOWNLOAD commands—a “Transport-Only” version (without encryption/decryption) and a Transport with Encryption/Decryption version. Overviews of both processes are shown in this section. Transport-Only For all Transport-Only script versions, the Market Participant provides his own file encryption/decryption prior and after transporting files and does not require the PGP or Gnu PG encryption/decryption functionality provided in the FTP Replacement Scripts. Transport With Encryption/Decryption For Transport with Encryption/Decryption script versions, the Market Participant requires the encryption/decryption functionality provided in the FTP Replacement Scripts. There are two encryption/decryption software packages used: PGP (Pretty Good Privacy) and GnuPG (Gnu Privacy Guard). The command parameters used for these two encryption systems differ slightly and are detailed in Section 7 – Using the Scripts.

5-4, 2/22/2002

Transport-Only Functionality Overviews

For SEND Transactions That Are Passed Through: The general process for SEND transactions without encryption (passed-through transactions) is shown in the graphic below.

Market Participant ERCOT

SEND Command(Without Encryption)

ERCOT Server

SEND Command Executed*

DIR DIrectory

SEND Function Performed. File(s)SENT to the MP’s Mailbox /IN

File(s) to be SENTare Placed in the DIR

Directory Named by the MP

* Note:The SEND command may send a singlefile, a group of files specified by awildcard, or an entire directory.

MP’s Mailbox /IN

1 2

Files Are Moved to the MP’s ARCHIVEDirectory Named by the MP

3Is Error

Returned?Yes

No

ARCHIVE DIrectory

4

REJECT DIrectory

4A

Failed File is Moved to the MP’sREJECT Directory and UploadingContinues for Other Files

4B

Is This A FatalError?

Yes

No

For Fatal Errors,Processing Stops

ProcessingStops

4

As shown above, the SEND command “uploads” data files to ERCOT’s Hub System. Successful file transmissions are recorded in a Log file stored on the Market Participant’s computer. When a delivery failure occurs, an error notification is sent to the e-mail address specified in the -EML parameter entered by the MP in the SEND command. The SEND function is capable of processing:

• A single file,

• Multiple files (using wildcard specifications), or

• An entire directory of files Market Participants indicate the files to send by specifying the directory path and filenames (or wildcards) via a command line parameter called -DIR. See Section 7 – “Using Scripts,” for more information about the -DIR parameter.

5-5, 2/22/2002

SEND Errors When SEND is used to send an entire directory of files or a group of files selected by wildcards to the ERCOT server, the server software still acknowledges delivery of each file individually. A single file upload is considered complete (successful) when the ERCOT server responds to the SEND with a positive delivery acknowledgement indicating a successful status. NOTE: Any acknowledgement containing a status other than success causes an error notification to be sent to the administrator contact specified by the -EML parameter in the SEND script. The e-mail notification is sent immediately after discovering the failure. Three general error conditions can result in a failed file transfer. All are described below. Refer to Section 8 – Troubleshooting for error code information and troubleshooting guidelines.

Command Line Errors

Occur when: • Not enough parameters are present in the command line (a critical

parameter is missing, for example). • A bad or incorrect parameter is present. Result in: • The corresponding exit status code being placed in the Log file.

Communication Failures

Occur when: • The ERCOT FTP Replacement Scripts software is unable to connect

to ERCOT’s server, or • The file upload aborts before the FTP Replacement Scripts client

software receives a delivery acknowledgement from the server. Result in: • The file remaining in the DIR directory until a successful transfer

occurs.

ebXML Errors

Occur when: • The ERCOT server responds to a client’s SEND request with a

delivery acknowledgement containing an Error. Result in: • Removal of the file from the DIR directory. • For any non-fatal errors, the file will be moved from the DIR directory

to the REJECT directory.

5-6, 2/22/2002

For RECEIVEALL Transactions That Are Passed Through: The general process for RECEIVEALL transactions without decryption (passed-through transactions) is shown in the graphic below.


RECEIVEALL Command(With No Decryption)

ERCOT Server

RECEIVEALL CommandExecuted

Archive DIrectory/OUT/BAD/REPORTS

DIR Directory/OUT/BAD/REPORTS

Files are Downloaded from the Mailbox Directories Into the Corresponding ARCHIVE Directories

Decrypted Files are Copied to the CorrespondingDIR Directory Folders.

MP’s Mailbox:/OUT/BAD/REPORTS

Command Sent to the ERCOT Server tocheck the MP’s Mailbox /OUT, /BAD and

/REPORTS Directories for Files1

2

3

4

The RECEVEALL command retrieve all files currently stored in the Market Participant’s /OUT, /BAD and /REPORTS folders on the ERCOT server. Retrieved files are stored in the Market Participant’s directory specified by the user in a command line parameter called -DIR corresponding to the directory that the file was received from. NOTE: Any acknowledgement containing a status other than success causes an error notification to be sent to the administrator contact specified by the -EML parameter in the RECEIVEALL script. The e-mail notification is sent immediately after discovering the failure. Three general error conditions can result in a file retrieval failure. All are described below and on the following page. Refer to Section 8 – Troubleshooting for error code information and troubleshooting guidelines.

Command Line Errors



5-7, 2/22/2002



to ERCOT’s server, or • The file download aborts before the FTP Replacement Scripts client

software completes the download. Result in: • Files remaining in the Market Participant’s /OUT, /BAD and

/REPORTS folders directory on the ERCOT server until a successful transfer occurs.

ebXML Errors

Occur when: • The ERCOT server responds to a client’s RECEIVEALL request with a

delivery acknowledgement containing an Error. Result in: • Notification of the administrative contact. • Download of the next file.

5-8, 2/22/2002

For DOWNLOAD Transactions That Are Passed Through: The general process for DOWNLOAD transactions without decryption (passed-through transactions) is shown in the graphic below.


DOWNLOAD Command(With No Decryption)

ERCOT Server

DOWNLOAD CommandExecuted

ARCHIVE DIrectory

DIR DIrectory

Specified File is Downloaded from the ERCOTServer to the MP’s ARCHIVE Directory Root.

File is Copied to the DIR Directory Specified inthe DOWNLOAD Command

Command Sent to the ERCOT Server1 2

3

4

The DOWNLOAD command retrieves a specific ARCHIVE file for the Market Participant on the ERCOT server. The retrieved file is stored in the MP’s directory specified by the user in the command line parameter called -DIR. NOTE: Any acknowledgement containing a status other than success causes an error notification to be sent to the administrator contact specified by the -EML parameter in the DOWNLOAD script. The e-mail notification is sent immediately after discovering the failure. Three general error conditions can result in a failed file transfer. All are described below and on the following page. Refer to Section 8 – Troubleshooting for error code information and troubleshooting guidelines.

Command Line Errors


parameter is missing, for example). • A bad or incorrect parameter is present.

Result in: • The corresponding exit status code being placed in the Log file.

5-9, 2/22/2002




software completes the download. Result in: • The file remaining in the Market Participant’s ARCHIVE folder

directory on the ERCOT server until a successful transfer occurs.

ebXML Errors

Occur when: • The ERCOT server responds to a client’s DOWNLOAD request with a

delivery acknowledgement containing an Error. Result in: • An e-mail being sent to the administrator contact defined in the –EML

parameter immediately after discovering the failure.

5-10, 2/22/2002

Transport With Encryption Functionality Overviews

For SEND Transactions With Encryption: The general process for SEND transactions with encryption is shown in the graphic below.


SEND Command(With Encryption)

ERCOT Server

SEND Command Executed*

DIR DIrectory

SEND and Encryption FunctionPerformed. Encrypted File(s) SENT

to the MP’s Mailbox /IN

File(s) to be SENTare Placed in the DIR Directory

Named by the MP

* Note:The SEND command may send a singlefile, a group of files specified by awildcard, or an entire directory.

MP’s Mailbox /IN

1 2

3Is Error

Returned?

No

ARCHIVE DIrectory

4

Yes

REJECT DIrectory

Is This A FatalError?

No

For Fatal Errors,Processing Stops

ProcessingStops

Yes

4A

4B

4

Unencrypted and Encrypted FilesAre Moved to the MP’s ARCHIVEDirectory Named by the MP

Encrypted and Unencrypted Filesare Moved to the MP’s REJECTDirectory and UploadingContinues for Other Files

As shown above, the SEND command “uploads” data files to ERCOT’s Hub System. Successful file transmissions are recorded in a Log file stored on the Market Participant’s computer. If encryption fails for a file, all processing stops. When a delivery failure occurs, an error notification is sent to the e-mail address specified in the -EML parameter entered by the MP in the SEND command. The SEND function is capable of processing:

• A single file, • Multiple files (using wildcard specifications), or • An entire directory of files Market Participants indicate the files to send by specifying the directory path and filenames (or wildcards) via a command line parameter called -DIR. See Section 7 – “Using Scripts,” for more information about the -DIR parameter.

5-11, 2/22/2002

SEND Errors When SEND is used to send an entire directory of files or a group of files selected by wildcards to the ERCOT server, the server software still acknowledges delivery of each file individually. A single file upload is considered complete (successful) when the ERCOT server responds to the SEND with a positive delivery acknowledgement indicating a successful status. NOTE: Any acknowledgement containing a status other than success causes an error notification to be sent to the administrator contact specified by the -EML parameter in the SEND script. The e-mail notification is sent immediately after discovering the failure. Four general error conditions can result in a failed file transfer. All are described below. Refer to Section 8 – Troubleshooting for error code information and troubleshooting guidelines.

Command Line Errors





to ERCOT’s server, or • A file upload aborts before the FTP Replacement Scripts client

software receives a delivery acknowledgement from the server. Result in: • Files remain in the DIR directory until a successful transfer occurs.

ebXML Errors

Occur when: • The ERCOT server responds to a client’s SEND request with a

delivery acknowledgement containing an Error. Result in: • Removal of the file from the DIR directory. • For any non-fatal errors, the file will be moved from the DIR directory

to the REJECT directory.

Encryption Errors

Occur when: • Encryption fails for any file that is part of the SEND request. Result in: • All processing stopping.

5-12, 2/22/2002

For RECEIVEALL Transactions With Decryption: The general process for RECEIVEALL transactions with decryption is shown in the graphic below.


RECEIVEALL Command(With Decryption)

ERCOT Server

RECEIVEALL CommandExecuted

Archive DIrectory/OUT/BAD/REPORTS

DIR Directory/OUT/BAD/REPORTS

Encrypted Files are Downloaded from the Mailbox Directories Into the Corresponding ARCHIVE Directories

Decrypted Files are Copied to the Corresponding DIRDirectory Folders.

Decryption Function Performed

MP’s Mailbox:/OUT/BAD/REPORTS

Command Sent to the ERCOT Server tocheck the MP’s Mailbox /OUT, /BAD and

/REPORTS Directories for Files1

2

3

4

7

Does DecryptionFail?

No

YesFile is Copied to the REJECT Directory andDecryption/Processing Continues for Other Files

5

Decrypted and Encrypted Files AreRetained in the ARCHIVE Directory.

6

/REJECT Directory

The RECEVEALL command retrieves all files currently stored in the Market Participant’s /OUT, /BAD and /REPORTS folders on the ERCOT server. Each retrieved file will be stored in the MP’s directory specified by the user in a command line parameter called -DIR corresponding to the directory that the file was received from. If decryption fails for a file, the failed file is copied to the REJECT directory and the download continues for additional files. NOTE: Any acknowledgement containing a status other than success causes an error notification to be sent to the administrator contact specified by the -EML parameter in the SEND script. The e-mail notification is sent immediately after discovering the failure.

5-13, 2/22/2002

Four general error conditions can result in a file retrieval failure. All are described below. Refer to Section 8 – Troubleshooting for error code information and troubleshooting guidelines.

Command Line Errors






software completes the download. Result in: • Files remaining in the Market Participant’s /OUT, /BAD and

/REPORTS folders directory on the ERCOT server until a successful transfer occurs.

ebXML Errors

Occur when: • The ERCOT server responds to a client’s RECEIVEALL request with a


Decryption Errors

Occur when: • Decryption fails for any file that is part of the RECEIVEALL request. Result in: • The failed files being copied from the ARCHIVE directory into the

REJECT folder. • Downloading continuing for any additional files.

5-14, 2/22/2002

For DOWNLOAD Transactions With Decryption: The general process for DOWNLOAD transactions with decryption is shown in the graphic below.


DOWNLOAD Command(With Decryption)

ERCOT Server

DOWNLOAD CommandExecuted

ARCHIVE DIrectory

DIR DIrectory

Specified File is Downloaded from the ERCOTServer to the MP’s ARCHIVE Directory Root

Decrypted and Encrypted File is Retained inthe ARCHIVE Directory.

Command Sent to the ERCOT Server

Decryption Function Performed

1 2

3

4

6

Does DecryptionFail?

No

Yes Failed File is Copied to the REJECT Directory

ProcessingStops

5

Decrypted File is Copied to the DIRDirectory Specified in the DOWNLOAD Command.

7

REJECT Directory

The DOWNLOAD command retrieves a specific ARCHIVE file for the Market Participant on the ERCOT server. Each retrieved file will be stored in the directory specified by the user in a command line parameter called -DIR. If decryption fails for this file, the failed file is copied to the REJECT directory and the processing stops. NOTE: Any acknowledgement containing a status other than success causes an error notification to be sent to the administrator contact specified by the -EML parameter in the SEND script. The e-mail notification is sent immediately after discovering the failure.

5-15, 2/22/2002

Four general error conditions can result in a file retrieval failure. All are described below. Refer to Section 8 – Troubleshooting for error code information and troubleshooting guidelines.

Command Line Errors






software completes the download. Result in: • The file remaining in the Market Participant’s ARCHIVE folder

directory on the ERCOT server until a successful transfer occurs.

ebXML Errors

Occur when: • The ERCOT server responds to a client’s DOWNLOAD request with a


Decryption Errors

Occur when: • Decryption fails for the file in the DOWNLOAD request. Result in: • The failed file being copied from the ARCHIVE directory into the

REJECT folder.

5-16, 2/22/2002

The Log File

A system-generated “Log file” is used to log any activity that occurs on the Market Participant’s (client) side of the FTP Replacement Scripts. The location of the Log file is identified by the –LOG command parameter and may be set to any location that the Market Participant requires. To understand how the scripts work, and as a basis for system troubleshooting, it is important that Market Participants understand how to interpret the Log file. For additional information about the Log file, refer to the topics “Using the Log File” and “Using LogViewer” in Section 8 – Troubleshooting. These topics show a typical Log file, explain the file’s structure and detail the file’s data elements. They also describe the LogViewer tool. This valuable troubleshooting tool is provided with the FTP Replacement Scripts software and is used to display the Log file in an easy-to-read format.

6-1, 2/22/2002

Encryption/Signing Basics

This section provides an overview of the basic processes used when the FTP Replacement Scripts software is used to perform encryption/decryption and verification/signing for the client. It also describes HTTPS protocol used to provide secure document transmission. This section includes the following topics:

• How Does Encryption/Decryption Work? • Encryption and Signing Using the FTP Replacement Scripts • Decryption and Verification Using the FTP Replacement Scripts • How Does Secure Transmission Work? • How Does HTTPS Protocol Work?

6-2, 2/22/2002

How Does Encryption/Decryption Work?

As part of ERCOT’s strict requirements for data transport, all sensitive information passed from Market Participant mailboxes to the ERCOT server must be passed over a secure connection. The FTP Replacement Scripts make this high level of security possible. Encryption/decryption processes—either provided by the FTP Replacement Scripts or performed by the customer’s own privacy software—combined with digital signing and verification, create exchange processes that meet ERCOT’s standards.

Encryption and Decryption Overview The optional encryption and decryption software packages used with the FTP Replacement Scripts, PGP and GnuPG, function in a similar way. Both use the idea of a “key ring” system. On the key ring are public and private keys; both keys have a specific role when encrypting and decrypting documents.

Key Type Who Has Access Where Stored MP’s Private Key Accessible only to the Market Participant

MP’s Public Key Exchanged freely with ERCOT

ERCOT’s Private Key Accessible only to the ERCOT

ERCOT’s Public Key Exchanged freely with the Market Participant

In key ring directory.

Complementary keys, called a key pair, maintain secure data transport. Only you have access to your private key, but to correspond with other privacy software users you need a copy of their public keys and they need a copy of yours—you exchange keys, in other words. For ERCOT and Market Participants, the Market Participants first create a key ring with their private and public keys. Their public key is then exported to ERCOT and ERCOT imports the MP’s public key. ERCOT, in turn, exports their public key to the Market Participant and the Market Participant’s imports ERCOT’s public key provided with the software. ERCOT and the Market Participant never exchange their private keys, however. Public Key Repository An ERCOT server contains a key repository to store public keys for all Market Participants. This public key repository is used to encrypt and decrypt files exchanged between ERCOT and the Market Participant. Likewise, the public key repository on the Market Participant’s side is used to encrypt and decrypt files exchanged between the Market Participant and ERCOT.

6-3, 2/22/2002

Visualizing the Key Ring System A public key may be thought of as an open safe. When the Market Participant encrypts a document using a public key, that document is put in the safe, the safe is shut, and the lock snaps shut. The corresponding private key can reopen the safe and retrieve the document. In other words, only the person who holds the private key can open a document encrypted using the associated public key. Using this model, Market Participants who require encryption and decryption with their FTP Replacement Scripts require both public and private keys. If the Market Participant wants to encrypt a document they are sending to ERCOT, they encrypt it using ERCOT’s public key, and ERCOT decrypts it with their private key. If ERCOT wants to send the Market Participant a document, the ERCOT server encrypts it using the Market Participant’s public key, and the Market Participant decrypts it with their private key.

The Extra Security Layer To add extra security, ERCOT additionally requires that all sensitive information be encrypted using ERCOT’s public key and the public key of the sender (for recovery purposes) and digitally signed with the private key of the sender. The FTP Replacement Scripts version providing encryption/decryption automatically adds this extra security with no user intervention required. To encrypt a document using PGP or GnuPG with the FTP Replacement Scripts, the Market Participant must use the public key of the intended recipient, ERCOT, as well the Market Participant’s own MP public key. After encrypting the document using both public keys (his own and ERCOT’s), the document is compressed for additional security. NOTE: To decrypt a file sent with this “double encryption,” ERCOT uses its private key. With the “double encryption” process, MPs can still decrypt files in case they must prove what they sent. If the sent documents were encrypted using ERCOT’s public key only, MPs would not be able to decrypt their documents if required—only ERCOT would be able to decrypt them.

6-4, 2/22/2002

Encryption and Signing Using the FTP Replacement Scripts

Encryption and digital signatures are both used for secure transmission of documents from Market Participants and ERCOT. The “digital signature” certifies and timestamps the MP’s document. If the document is modified after receiving the digital signature, subsequent verification of the signature will fail. A digital signature can serve the same purpose as a hand-written signature with the added benefit of being tamper-resistant. Key Integrity When you distribute your public key, you are distributing the public components of your master and subordinate keys as well as user IDs. Distributing this material alone is a security risk since it is possible for an attacker to tamper with a key. The public key can be modified by adding or substituting keys, or by adding or changing user IDs. By tampering with a user ID, attackers could potentially change a user ID’s e-mail address to have e-mail redirected to themselves. By changing one of the encryption keys, attackers would also be able to decrypt these redirected messages. Digital signatures provide a solution to this problem. When data is signed by a private key, the corresponding public key is bound to the signed data. In other words, only the corresponding public key can be used to verify the signature and ensure that the data has not been modified. A public key can be protected from tampering by using its corresponding private master key to sign the public key components and user IDs, thus binding the components to the public master key. Signing public key components with the corresponding private master signing key is called self-signing, and a public key that has self-signed user IDs bound to it is called a certificate. The FTP Replacement Scripts use self-signing to provide this extra security level. Encrypting and Signing Documents To encrypt and sign a document using PGP or GnuPG with the FTP Replacement Scripts, the Market Participant uses their public key and ERCOT’s public key to encrypt the document. Then, they digitally sign the document using their private key and the file is sent to ERCOT. When the encrypted document arrives at the ERCOT server, it can only be decrypted by the ERCOT private key.

Market Participant ERCOTEncryption and Digital Signing

ERCOT Server

PublicKey

PrivateKey

PublicKey

PrivateKey

File is Encrypted Using the MP’s PublicKey and ERCOT’s Public Key* and File is Digitally

Signed Using the MP’s Private Key

File is Decrypted Using ERCOT’s PrivateKey and the Signature is Verified Using the

MP’s Public Key

* With the “double encryption” process (using both the MP’s publickey and ERCOT’s public key, MPs can still decrypt files in casethey must prove what they sent. If the sent documents wereencrypted using ERCOT's public key only, MPs would not be ableto decrypt their documents if required. Only ERCOT would beable to decrypt them.

6-5, 2/22/2002

In summary, Market Participants use their own public key and ERCOT’s public key to:

• Encrypt files prior to transmission And Market Participants use their private key to:

• Digitally sign documents they send to ERCOT Encryption/Decryption Rules In the FTP Replacement Scripts Software, encryption and signing processes performed by PGP and GnuPG are compliant with the standards as defined in the OpenPGP Internet specification RFC2440. These rules must be followed by Market Participants using the scripts for encryption/decryption:

• Market Participants must generate public/private key-pairs with a 1024-bit key length. • Market Participants must have only one public key active at any time.

6-6, 2/22/2002

Decryption and Verification Using the FTP Replacement Scripts

To decrypt a document that ERCOT sends to the Market Participant, the Market Participant first decrypts the document using their private key. Then, after decryption, the Market Participant verifies ERCOT’s digital signature on the document using ERCOT’s public key.

Market Participant ERCOTDecryption and Verification

ERCOT Server

PublicKey

PrivateKey

PublicKey

PrivateKey

File is Decrypted Using the MP’s Private Keyand the File’s Digital Signature is Verified

Using ERCOT’s Public Key

* With the “double encryption” process, ERCOT encrypts filesusing both the MP’s public key and ERCOT’s public key.

File is Encrypted Using ERCOT’s Public Keyand the MP’s Public Key* and File is Digitally

Signed Using ERCOT’s Private Key

In summary, Market Participants use their ERCOT public key to:

• Verify ERCOT’s digital signature And Market Participants use their private key to:

• Decrypt documents ERCOT sends to them

6-7, 2/22/2002

How Does Secure Transmission Work?

The FTP Replacement Scripts are structured to assure secure transmission of all sensitive information exchanged between Market Participants and ERCOT. Secure transmission of documents messages requires these primary components:

• Encryption of the document so that only the intended recipient and the encrypting party may read it.

• Digital signing of the document so that the sender identity and data integrity may be verified.

• A secure connection between Market Participant senders and recipients, which, together with logon identification and password entry for the sender, provides access control and authenticates the identity of the sending party.

How Does HTTPS Protocol Work?

The new scripts use HTTPS protocol (HTTP combined with a Secure Sockets Layer (SSL)) encryption for sensitive information exchange. HTTPS adds privacy to transactions and protects the Market Participant’s logon ID and password. As an example of HTTPS security, think of a credit card submission to a Web server. To start this process, a customer browses a web site and places items in an on-line shopping cart. This step is generally performed without a need for security. When the customer is ready to check out and provide a credit card number to the server, security is required. The system must accept the credit card number and assure the customer that they are submitting the number to the correct server (alleviating fears that someone has set up a fake site to steal credit card information) and that the order was actually received by the server (alleviating fears that an order has been silently blocked by an attacker).

HTTPS Protocol in the FTP Replacement Scripts In the scripts software, just as in the credit card submission application, HTTPS protocol provides a secure connection between ERCOT and Market Participants and assures both parties that the right connection has been made. The HTTPS approach is simple: The client makes a connection to the server, negotiates an SSL connection, and then transmits its HTTP data, including username and password information, over the encrypted SSL application data channel.

6-8, 2/22/2002

HTTPS Connection Rules The following rules are followed for any HTTPS connection initiated through the scripts:

• ERCOT’s Clearinghouse Hub must have a valid X.509 Digital ID installed on the server.

• Supported X.509 Certificates/Certification Authorities (used to verify the identity of the ERCOT server and to encrypt the Market Participant’s communication session) include: VeriSign Global Server ID (see the VeriSign website at http://www.verisign.com for more

information), or Self-Signed Certificates, using ERCOT as the self-signing Certification Authority

• Senders are not required to have a client-side Digital ID.

• Communications between Market Participants and the ERCOT hub must use 128-bit SSL-encrypted HTTP sessions (HTTPS).

• The HTTPS Connection is through a secure port number.

Basic Authorization and SSL (Secure Sockets Layer) To use the FTP Replacement Scripts, all HTTP systems within ERCOT must support, at a minimum, SSL version 3.0 using a minimum key size of 128 bits for symmetric cryptographic algorithms and a key size of 2048 bits for asymmetric cryptographic algorithms (e.g. public key). Presently, only servers are required to implement Digital Certificates. In the future, clients may be required to implement Digital Certificates for authentication purposes during the establishment of a SSL connection. During the establishment of an SSL connection, ERCOT servers are also required to present a Digital Certificate as part of the SSL handshake. All ERCOT servers must use HTTP Basic Authentication (usernames and passwords) (ref: RFC 2617) for access control. Any party that fails to provide a valid username/password pair in the Authorization header of an HTTP request when sending a message will be rejected with an error response. Sensitive username/password data may only be passed over an established SSL connection with a server that is known to belong to ERCOT.

7-1, 2/22/2002

Using the Scripts

This section describes, in detail, the scripts used for FTP replacement. Three basic commands are used in the scripts: SEND, RECEIVEALL and DOWNLOAD. These commands function as described below: • SEND uploads files from the Market Participant to the Market Participant’s mailbox on the

ERCOT server.

• RECEIVEALL pulls files from the Market Participant’s mailbox on the ERCOT server.

• DOWNLOAD pulls a single file that has previously been downloaded and is now archived on the ERCOT server.

In this section, we will familiarize you with the methods used to construct command lines and use command parameters effectively. We also provide sample scripts and instructions for running the scripts. You will learn how to “mix and match” commands and parameters to create your own unique command lines. This section includes the following topics: • Constructing Valid Command Lines • Document IDs • Three Types of SEND Commands • Using Parameters • Running Scripts

Transport-Only • Transport-Only - Using the SEND Script to Perform Uploads • Transport-Only - Using the RECEIVEALL Script to Perform General Downloads • Transport-Only - Using the DOWNLOAD Script to Perform Archive Downloads Transport with Encryption/Decryption • Transport with Encryption/Decryption - Using the SEND Script to Perform Uploads • Transport with Encryption/Decryption - Using the RECEIVEALL Script to Perform

General Downloads • Transport with Encryption/Decryption - Using the DOWNLOAD Script to Perform

Archive Downloads

7-2, 2/22/2002

Constructing Valid Command Lines

On the Windows NT/2000 or UNIX platforms, FTP Replacement Scripts software commands may be run from any directory on the given system. To understand how command lines are structured, you must first understand the terminology for Tokens, Commands, Parameters and Values: • Token: All the "pieces" in a command separated by spaces are called tokens. • Command: SEND, DOWNLOAD or RECEIVEALL • Parameter: -FR, -TO, etc. • Value: <filename> such as D:\FTP_FILES\FROM_ERCOT\LOG\log.txt Typical Command Line The command, parameter and value tokens in a typical command line are identified below. Command

SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\TO_ERCOT\LOG\013102log.txt-UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100-DIR D:\FTP_FILES\TO_ERCOT\SEND -ARC D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND-REJ D:\FTP_FILES\TO_ERCOT\REJECT\SEND

Parameter Value

SEND, RECEIVEALL and DOWNLOAD Commands As examples, command lines are shown here for SEND, RECEIVEALL and DOWNLOAD. These commands are basic to the FTP Replacement Scripts and one of them must always be the first token in a command line. The command lines shown here have multiple parameters and values. Depending on your site, the values on your own command lines may be different. SEND Example MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\TO_ERCOT\LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\TO_ERCOT\SEND -ARC D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND -REJ D:\FTP_FILES\TO_ERCOT\REJECT\SEND -MTA pop.mpcompany.com -EML [email protected] -CRY GPG -EXE D:\GNUPG\gpg.exe -RNG D:\GNUPG -KEY 0xD83B5E02 -SGN 0xB42D9E02

RECEIVEALL Example MPCS RECEIVEALL -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\FROM_ERCOT\LOG\ 013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b /ebxml-100 -DIR D:\FTP_FILES\FROM_ERCOT\RECEIVED -ARC D:\FTP_FILES\FROM_ERCOT\ARCHIVE -REJ D:\FTP_FILES\FROM_ERCOT\REJECT -MTA pop.mpcompany.com -EML john.smith@mpcompany. com -CRY GPG -EXE D:\GNUPG\gpg.exe -RNG D:\GNUPG -KEY 0xD83B5E02 -SGN 0xB42D9E02

7-3, 2/22/2002

DOWNLOAD Example MPCS DOWNLOAD [email protected] -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\FROM_ERCOT\LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\FROM_ERCOT\ RECEIVED\OUT -ARC D:\FTP_FILES\FROM_ERCOT\ARCHIVE\OUT -REJ D:\FTP_FILES\FROM_ERCOT\ REJECT\OUT -MTA pop.mpcompany.com -EML [email protected] -CRY PGP -CPP pgppass123 -EXE D:\PGPNT\pgp.exe

Document IDs

Document IDs are required whenever a DOWNLOAD is performed. Although document IDs are related to files, they are not the same as filenames. Throughout the FTP Replacement Scripts system, document IDs will remain constant even though the filenames related to document IDs may change. For this reason, document IDs, rather than filenames, are used whenever a specific document must be downloaded from the ERCOT server. To locate a document ID, look in the Log file. In the Log file snippet shown below, the document ID is [email protected]. DOWNLOAD [email protected] FileName: file1.edi.pgp C:\FTP_FILES\FROM_ERCOT\LOG…

Refer to Section 8 – Troubleshooting for Log file information. Remember that document IDs are case-sensitive and must be entered exactly as they are found in the Log file.

Three Types of SEND Commands

When using a script to perform a SEND, you may send a single file, a group of files, or an entire directory. Samples of the specific scripts used to accomplish these SENDs are outlined below:

Type of SEND Command Line Details

Sending a Single File

As shown in the command below, -DIR D:\FTP_FILES\ TO_ERCOT\SEND\20020117.edi performs a SEND for 20020117.edi in the SEND directory on the D: drive. MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\ TO_ERCOT\LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\TO_ERCOT\SEND\20020117.edi -ARC D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND -REJ D:\FTP_FILES\ TO_ERCOT\REJECT\SEND -MTA pop.mpcompany.com -EML [email protected]

Sending Multiple Files

Using Wildcards

As shown in the command below, -DIR D:\FTP_FILES\SEND\ *.edi performs a SEND for all files with the .edi extension in the SEND directory on the D: drive. MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\ TO_ERCOT\LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\TO_ERCOT\SEND\*.edi -ARC D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND -REJ D:\FTP_FILES\ TO_ERCOT\REJECT\SEND -MTA pop.mpcompany.com -EML [email protected]

7-4, 2/22/2002

Type of SEND Command Line Details

Sending an Entire Directory

As shown in the command below, -DIR D:\FTP_FILES\OUT performs a SEND for the entire contents of the OUT directory on the D: drive. MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\ TO_ERCOT\LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\OUT -ARC D:\FTP_FILES\TO_ERCOT\ARCHIVE\ SEND -REJ D:\FTP_FILES\TO_ERCOT\REJECT\SEND -MTA pop.mpcompany.com -EML [email protected]

For a complete listing of command parameters and their usage, refer to the next topic, “Using Parameters.”

7-5, 2/22/2002

Using Parameters

A complete listing of valid parameters is shown in the table below. Note that bolded parameters are required in every command line. Parameters in regular fonts are optional.

General Guidelines These general guidelines should be noted: • If a parameter is mistakenly entered twice (such as –UID user1 –UID user2), an error will

result. • If you include a parameter, it must have a value. • The –DIR parameter can use multiple values successfully. • If two values are given for one parameter (with the exception of –DIR) an error will result. An

example would be mistakenly entering –UID user1 user2. A message will indicate that either –UID has two values or user2 is an invalid parameter.

Valid Parameters

Parameter Usage Required Parameters

-FR From DUNS -TO To DUNS -UID User ID for basic auth (ERCOT-provided) -PWD Password for basic auth (ERCOT-provided) -URL URL (https://b2b.ercot.com:44337/servlet/b2b/

ebxml-100) -LOG Log File -ARC Archive Directory -REJ Rejection Directory -DIR Designates where the files will be pulled from or pushed

to. E-Mail-Related Optional Parameters

-MTA Mail Server -EML E-mail Address

Encryption-Related Optional Parameters -CRY Encryption/Decryption Method (“PGP” or “GPG”) -RNG Key Ring Directory -KEY Encryption Key ID -EXE Encryption/Decryption PGP or GnuPG .EXE File location -SGN Sign Key ID -CPP Crypt Pass Phrase -PXH Proxy Host

7-6, 2/22/2002

Command and Parameter Details The paragraphs which follow detail information for required and optional commands and parameters.

Command and Parameter Details Table

Required Commands and Parameters

SEND, DOWNLOAD or

RECEIVEALL

One of these commands must always be the first token in the command line. As examples, command lines can only begin with: SEND <parameter> DOWNLOAD <doc ID> <parameter> RECEIVEALL <parameter>

Notes • SEND perform file uploads from the Market Participant to the Market Participant’s mailbox on the ERCOT server.

• DOWNLOAD pulls a single file that has previously been downloaded and is now archived on the ERCOT server. Note that the file, identified as a “Doc ID,” is case-sensitive and is located in the Log file. Refer to Section 6, Using the Scripts, for more information.

• RECEIVEALL pulls multiple files from the Market Participant’s mailbox on the ERCOT server.

• One of these commands must always be the first token in the command line.

• If SEND or RECEIVEALL is the first token, then the second token must be a parameter.

• If DOWNLOAD is used, then second token must be a document ID and the third token must be a parameter.

From DUNS

The format is: -FR <DUNS number> where: <DUNS number> indicates the DUNS number of the Market Participant that the file(s) will be sent or received from.

Notes • Used to indicate the DUNS number that file(s) will be sent or received from.

To DUNS

The format is: -TO <DUNS number> where: <DUNS number> indicates the DUNS number of the Market Participant that the file(s) will be sent or received to.

Notes • Used to indicate the DUNS number that file(s) will be sent or received to.

7-7, 2/22/2002

Required Commands and Parameters (Continued)

User ID for Basic Authentication

The format is: -UID <user ID> where: <user ID> indicates the user ID used to authenticate the user on the ERCOT server.

Notes • User IDs are provided by ERCOT for each Market Participant.

Password for

Basic Authentication

The format is: -PWD <password> where: <password> indicates the password associated with the user ID used to authenticate the user on the ERCOT server.

Notes • Passwords are provided by ERCOT for each Market Participant.

Universal

Resource Locator (URL)

The format is: -URL <location> where: <location> indicates the actual ERCOT URL associated with the sending and receiving of files.

Notes • A typical URL would be: https://b2b.ercot.com:44337/servlet/b2b/ebxml-100

LOG FILE

The format is: -LOG <filename> where: <filename> indicates the file where the day’s events are logged. The filename must point to a file, not a directory. If the file does not exist, the system will attempt to create any missing parent directories and create the file. If this attempt fails, an error will be generated.

Notes • A typical log file name will be D:\FTP_FILES\LOG\ log20020116.txt indicating the year and day for the log file.

7-8, 2/22/2002


ARCHIVE DIRECTORY

The format is: -ARC <directory> where: <directory> indicates the directory where the file(s) will be archived.

Notes • When you send a file, the original and encrypted file will be sent to the Archive directory.

• If a file with the same name is already present in the Archive directory, it will be overwritten.

• A typical directory name will be D:\FTP_FILES\FROM_ERCOT\ ARCHIVE.

• The subdirectory name for FROM_ERCOT will be \OUT, \BAD or \REPORTS.

REJECTION DIRECTORY

The format is: -REJ <directory> where: <directory> indicates the directory where the rejected files will be placed. If the directory does not exist, the system will attempt to create the directory. If this attempt fails, an error will be generated.

Notes • A typical directory name will be D:\FTP_FILES\FROM_ERCOT\ REJECT.

• When sending a file and an Error List is returned (ERCOT rejects a file sent by the Market Participant): 1. The FTP Replacement Scripts software moves the rejected file to

the Reject directory. 2. An e-mail will be sent to the MP’s e-mail address indicated in the

command line. 3. An error is logged. 4. Processing continues.

• The ebXML error generated when sending a file lists the error codes that have been placed in the transaction’s transport header.

• If decryption fails when receiving a file: 1. The FTP Replacement Scripts software sends the file to the

Reject directory. 2. Processing continues.

7-9, 2/22/2002


DIR The format is: For DOWNLOAD or RECEIVALL Commands: -DIR <directory> where: <directory> indicates the directory where files will be downloaded or received. For SEND Commands: -DIR <directory> where: <directory> indicates the directory containing the files that are going to be sent. If an indicated directory does not exist, an error will be generated.

Notes • A typical directory name will be D:\FTP_FILES\FROM_ERCOT or D:\FTP_FILES\TO_ERCOT.

• No spaces are allowed in file names. • Refer to the topic “Directory Structure” in Section 3 – System

Prerequisites for more information about directories related to the DIR parameter.

Optional E-Mail Related Parameters

MAIL INFO

The format is: -MTA <server name> and -EML <e-mail address> where: <server name> indicates the server for the mail system. <e-mail address name> indicates an individual e-mail address. These parameters are used together. If one is used, the other must also be used to correctly identify the mail server location (-MTA) and the e-mail address (-EML).

Notes • This name and address is used as a send/receive point for error e-mails. If an e-mail address is not included, you will not be notified of send/receive errors.

• A typical server name will be mail.company.com. • A typical e-mail address will be [email protected].

7-10, 2/22/2002

Optional Encryption-Related Parameters

ENCRYPTION/ METHOD

The format is: -CRY <encryption method> where: <encryption method> is PGP or GPG, if used.

Notes • If the encryption method is not used in the command line, the default is transport-only.

• If encryption is used, you must also use the following encryption parameters as applicable:

–RNG, –EXE, –KEY, and –SGN are used for GnuPG when performing SENDs.

–RNG and –EXE are used for GnuPG when performing DOWNLOADs or RECEIVEALLs.

–EXE, -CPP, –KEY and –SGN are used for PGP when performing SENDs.

–EXE and –CPP are used for PGP when performing DOWNLOADs or RECEIVEALLs.

KEY RING

DIRECTORY (Applies to GnuPG

Only)

The format is: -RNG <directory> where: <directory> is the key ring directory.

Notes • A typical directory name will be d:\gnupg. • If GnuPG is used for encryption, then -RNG must be used. An error

will be raised if –RNG is not present.

ENCRYPTION EXECUTABLE (Applies to PGP

and GnuPG)

The format is: -EXE <filename> where: <filename> is the encryption software’s executable file name and location.

Notes • A typical executable name and location for PGP will be D:\pgpnt\pgp.exe.

• A typical executable name and location for GnuPG will be D:\gnupg\gpg.exe.

• If the –CRY parameter is used in the command line, then -EXE must also be present. An error will be raised if –EXE is not present.

7-11, 2/22/2002

Optional Encryption-Related Parameters (Continued)

ENCRYPT KEY ID

(Applies to PGP and GnuPG when

performing SENDS only)

The format is: -KEY <key ID> where: <key ID> is the recipient’s key ID.

Notes • A typical encrypt key identification number for GnuPG will be 234AC49C.

• A typical encrypt key identification number for PGP will be 0xD83B5E02.

• If the –CRY parameter is used in the command line, then -KEY must also be present. An error will be raised if –KEY is not present.

SIGN KEY ID

(Applies to PGP and GnuPG when

performing SENDS only)

The format is: -SGN <sign key ID> where: <sign key ID> is the sender’s key ID.

Notes • A typical sign key identification number for PGP will be 0xD85B8E05.

• A typical sign key identification number for GnuPG will be 0xB42D9E02.

• If the –CRY parameter is used in the command line, and you are performing a SEND, then -SGN must also be present. An error will be raised if –SGN is not present.

• When downloading files, -SGN is not required; it will be ignored if present.

CRYPT PASS

PHRASE (Applies to PGP)

The format is: -CPP <phrase> where: <phrase> is the user-defined encryption password phrase.

Notes • If the –CRY parameter is used in the command line, and you are performing a SEND, DOWNLOAD or RECEIVEALL using PGP, then -CPP must also be present. An error will be raised if –CPP is not present.

• When using GnuPG for encryption, -CPP is not required; it will be ignored if present.

7-12, 2/22/2002

Optional Encryption-Related Parameters (Continued)

PROXY HOST The format is: -PXH

Notes • This is client-specific. See your IT manager or system administrator for more information.

7-13, 2/22/2002

Running Scripts

General steps for using the SEND (used to perform uploads), RECEIVEALL (used to perform general downloads) and DOWNLOAD (used to perform a single file archive download) commands are shown in the following paragraphs. SEND, RECEIVEALL and DOWNLOAD commands are divided into two main categories: Transport-Only and Transport with Encryption/Decryption. NOTE: Your location may require slightly different command sequences than the ones shown here. Most of the command line differences stem from site-specific encryption practices. Some files will need encryption prior to sends, pulls or downloads, while sites that perform their own encryption will perform sends, pulls or downloads without using encryption software.

Transport-Only - Using the SEND Script to Perform Uploads

Steps for using the SEND command to perform transport-only uploads are shown below and on the following page. When the SEND command is used, three possibilities exist for selecting files to upload. You may:

• Send an entire directory of files • Send files matching your wildcard specifications (*.txt, for example, to move all .txt files) • Send a single file REMINDER: If your site has its own method for running scripts (batch file, etc.) refer to those guidelines for invoking the commands shown here. NOTE: After a successful SEND, uploaded files are moved to the Market Participant’s ARCHIVE directory. If a file with the same filename already exists in the ARCHIVE directory, it will be overwritten.

Uploading Encrypted Files 1. From the command prompt, enter a SEND command line similar to the one below, using

detailed information in the previous topic, “Using Parameters.”

MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\TO_ERCOT\LOG\ 013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/ servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\TO_ERCOT\SEND -ARC D:\FTP_FILES\ TO_ERCOT\ARCHIVE\SEND -REJ D:\FTP_FILES\TO_ERCOT\REJECT\SEND

2. Press ENTER to execute the command. The SEND command will execute for the named files. If an error message displays, refer to “Troubleshooting,” section 8.

Uploading Archived File(s) That Are Encrypted If the file(s) you are uploading has a .pgp suffix (indicating that it is already encrypted), or if you want to perform the upload and not encrypt the file(s), use the SEND command steps shown below. 1. Move to your archive directory (/ARCHIVE). 2. Copy the file(s) you wish to upload from the archive directory to your working send directory

(/SEND).

7-14, 2/22/2002

3. Enter a SEND command line similar to the one shown below. This command will move all of the files in the working outbox directory but will not perform encryption. As required, use the detailed information in the previous topic, “Using Parameters.” MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\TO_ERCOT\LOG\ 013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/ servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\TO_ERCOT\SEND -ARC D:\FTP_FILES\ TO_ERCOT\ARCHIVE\SEND -REJ D:\FTP_FILES\TO_ERCOT\REJECT\SEND

4. Press ENTER to execute the command. The SEND command will execute for the named file(s). If an error message displays, refer to “Troubleshooting,” section 8.

Transport-Only - Using the RECEIVEALL Script to Perform General Downloads

General steps for using the RECEIVEALL command to pull files from the Market Participant’s mailbox on ERCOT are shown below. The RECEIVEALL command line shown here is for files that will be passed through. REMINDER: If your site has its own method for running scripts (batch file, etc.) refer to those guidelines for invoking the commands shown here. NOTE: After a successful RECEIVEALL, downloaded files are moved to the Market Participant’s ARCHIVE directory. If a file with the same filename already exists in the ARCHIVE directory, it will be overwritten.

Pulling Files That Will Pass Through 1. From the command prompt, enter a RECEIVEALL command line similar to the one below.

For detailed information, refer to the topic “Directory Structure” in section 3 – System Prerequisites, and to the Valid Parameters table in the previous topic, “Using Parameters.”

MPCS RECEIVEALL -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\FROM_ERCOT\ LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/ servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\FROM_ERCOT\RECEIVED -ARC D:\FTP_FILES\FROM_ERCOT\ARCHIVE -REJ D:\FTP_FILES\FROM_ERCOT\REJECT

2. Press ENTER to execute the command. The RECEIVEALL command will execute for the named files. If an error message displays, refer to “Troubleshooting,” section 8.

7-15, 2/22/2002

Transport-Only - Using the DOWNLOAD Script to Perform Archive Downloads

General steps for using the DOWNLOAD command to pull a single file that has previously been downloaded and is now archived on the ERCOT server are shown below and on the following page. The DOWNLOAD command line shown here is for files that will be passed through. The file to be pulled will be identified with a specific document ID. NOTE: To locate a document ID for DOWNLOAD, look in the Log file. In the Log file snippet shown below, the document ID is [email protected]. DOWNLOAD [email protected] FileName: file1.edi.pgp C:\FTP_FILES\FROM_ERCOT\LOG…

Refer to Section 8 – Troubleshooting for Log file information. Remember that document IDs are case-sensitive and must be entered exactly as they are found in the Log file. REMINDER: If your site has its own method for running scripts (batch file, etc.) refer to those guidelines for invoking the commands shown here. NOTE: After a successful DOWNLOAD, the downloaded file is moved to the Market Participant’s ARCHIVE directory. If a file with the same filename already exists in the ARCHIVE directory, it will be overwritten.

Downloading a File That Will Pass Through 1. From the command prompt, enter a DOWNLOAD command line similar to the one below.

For detailed information, refer to the topic “Directory Structure” in section 3 – System Prerequisites, and to the Valid Parameters table in the previous topic, “Using Parameters.”

MPCS DOWNLOAD [email protected] -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\FROM_ERCOT\LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\ FROM_ERCOT\RECEIVED\OUT -ARC D:\FTP_FILES\FROM_ERCOT\ARCHIVE\OUT -REJ D:\FTP_FILES\FROM_ERCOT\REJECT\OUT

2. Press ENTER to execute the command. The DOWNLOAD command will execute for the named file. If an error message displays, refer to “Troubleshooting,” section 8.

7-16, 2/22/2002

Transport with Encryption/Decryption - Using the SEND Script to Perform Uploads

Steps for using the SEND command to perform uploads with encryption/decryption are shown below and on the following page. When the SEND command is used, three possibilities exist for selecting files to upload. You may:

• Send an entire directory of files • Send files matching your wildcard specifications (*.txt, for example, to move all .txt files) • Send a single file REMINDER: If your site has its own method for running scripts (batch file, etc.) refer to those guidelines for invoking the commands shown here. NOTE: After a successful SEND, uploaded files are moved to the Market Participant’s ARCHIVE directory. If a file with the same filename already exists in the ARCHIVE directory, it will be overwritten.

Uploading Files that Need Encryption 1. From the command prompt, enter a SEND command line similar to the one below, using

detailed information in the previous topic, “Using Parameters.” This command identifies a SEND command for files that will be encrypted using PGP.

MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\TO_ERCOT\LOG\ 013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/ servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\TO_ERCOT\SEND -ARC D:\FTP_FILES\ TO_ERCOT\ARCHIVE\SEND -REJ D:\FTP_FILES\TO_ERCOT\REJECT\SEND -MTA <mailserver>-EML <e-mailAddress> -CRY PGP -CPP <pgpPassword> -EXE d:\pgpnt\pgp.exe -KEY <encryptKey> -SGN <signKey>

2. Press ENTER to execute the command. The SEND command will execute for the named files. If an error message displays, refer to “Troubleshooting,” section 8.

Uploading Archived File(s) That Need Encryption If you are uploading file(s) that do not have a .pgp suffix (indicating they are not encrypted), and you wish to perform the upload with encryption, use the command steps shown below. 1. Move to your archive directory (/ARCHIVE). 2. Copy the file(s) you wish to upload from the archive directory to your working send directory

(/SEND). 3. From the command prompt, enter a SEND command line similar to the one below. This

command will move all of the files in the working outbox directory and will perform encryption. As required, use the detailed information in the previous topic, “Using Parameters.”

MPCS SEND -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\TO_ERCOT\LOG\ 013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/ servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\TO_ERCOT\SEND -ARC D:\FTP_FILES\ TO_ERCOT\ARCHIVE\SEND -REJ D:\FTP_FILES\TO_ERCOT\REJECT\SEND -MTA <mailserver>-EML <e-mailAddress> -CRY PGP -CPP <pgpPassword> -EXE d:\pgpnt\pgp.exe -KEY <encryptKey> -SGN <signKey>

4. Press ENTER to execute the command. The SEND command will execute for the named file(s). If an error message displays, refer to “Troubleshooting,” section 8.

7-17, 2/22/2002

Transport with Encryption/Decryption - Using the RECEIVEALL Script to Perform General Downloads

General steps for using the RECEIVEALL command to pull files from the Market Participant’s mailbox on ERCOT. The RECEIVEALL command line shown here is for files that will be encrypted/decrypted. REMINDER: If your site has its own method for running scripts (batch file, etc.) refer to those guidelines for invoking the commands shown here. NOTE: After a successful RECEIVEALL, downloaded files are moved to the Market Participant’s ARCHIVE directory. If a file with the same filename already exists in the ARCHIVE directory, it will be overwritten.

Pulling A File That Need to be Decrypted 1. From the command prompt, enter a RECEIVEALL command line similar to the one below.

For detailed information, refer to the topic “Directory Structure” in section 3 – System Prerequisites, and to the Valid Parameters table in the previous topic, “Using Parameters.” This command identifies a RECEIVEALL command for files that will be encrypted using GnuPG. MPCS RECEIVEALL -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\FROM_ERCOT\ LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/ servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\FROM_ERCOT\RECEIVED -ARC D:\FTP_FILES\FROM_ERCOT\ARCHIVE -REJ D:\FTP_FILES\FROM_ERCOT\REJECT -MTA <mailserver> -EML <e-mailAddress> -CRY GPG -EXE d:\gnupg\gpg.exe -RNG d:\gnupg

2. Press ENTER to execute the command. The RECEIVEALL command will execute for the named files. If an error message displays, refer to “Troubleshooting,” section 8.

Transport with Encryption/Decryption - Using the DOWNLOAD Script to Perform Archive Downloads

General steps for using the DOWNLOAD command to pull a single file that has previously been downloaded and is now archived on the ERCOT server are shown below and on the following page. The DOWNLOAD command line shown here is for files that will be encrypted/decrypted. The file to be pulled will be identified with a specific document ID. NOTE: To locate a document ID for DOWNLOAD, look in the Log file. In the Log file snippet shown below, the document ID is [email protected]. DOWNLOAD [email protected] FileName: file1.edi.pgp C:\FTP_FILES\FROM_ERCOT\LOG…

Refer to Section 8 – Troubleshooting for Log file information. Remember that document IDs are case-sensitive and must be entered exactly as they are found in the Log file. REMINDER: If your site has its own method for running scripts (batch file, etc.) refer to those guidelines for invoking the commands shown here. NOTE: After a successful DOWNLOAD, the downloaded file is moved to the Market Participant’s ARCHIVE directory. If a file with the same filename already exists in the ARCHIVE directory, it will be overwritten.

7-18, 2/22/2002

Downloading a File That Needs to be Decrypted 1. From the command prompt, enter a DOWNLOAD command line similar to the one on the

following page. For detailed information, refer to the topic “Directory Structure” in section 3 – System Prerequisites, and to the Valid Parameters table in the previous topic, “Using Parameters.” This command identifies a DOWNLOAD command for files that will be decrypted using GnuPG.

MPCS DOWNLOAD [email protected] -TO <ToDuns> -FR <FromDuns> -LOG D:\FTP_FILES\FROM_ERCOT\LOG\013102log.txt -UID username3 -PWD pass -URL https://b2b.ercot.com:44337/servlet/b2b/ebxml-100 -DIR D:\FTP_FILES\ FROM_ERCOT\RECEIVED\OUT -ARC D:\FTP_FILES\FROM_ERCOT\ARCHIVE\OUT -REJ D:\FTP_FILES\FROM_ERCOT\REJECT\OUT -MTA <mailserver> -EML <e-mailAddress> -CRY GPG -EXE d:\gnupg\gpg.exe -RNG d:\gnupg

2. Press ENTER to execute the command. The DOWNLOAD command will execute for the named file. If an error message displays, refer to “Troubleshooting,” section 8.

8-1, 2/22/2002

Troubleshooting

Whenever an error occurs in the FTP Replacement Scripts during processing, an application error code specific to the software is generated and saved to the Log file. The Log file is the primary troubleshooting tool used with the FTP Replacement Scripts software. This section describes how to interpret and resolve errors and other system messages reported in the Log file. In addition, this section describes the command-line tool provided with the FTP Replacement Scripts software, the LogViewer Tool. LogViewer is recommended whenever you must view and interpret the Log file. This section includes the following topics:

• Troubleshooting Tools • Using the Log File • Using LogViewer • What Are Application Error Codes? • Types of Errors • Exit Codes • Application Error Codes Table

8-2, 2/22/2002

Troubleshooting Tools

Troubleshooting tools are provided to all Market Participants using the FTP Replacement Scripts as part of their basic software installation. The primary troubleshooting tools are the Log file and LogViewer. Learning to understand and use these tools is imperative for all Market Participants. Using the Log file and LogViewer, Market Participants will be able to perform much of their own troubleshooting and problem solving—as well as gain an understanding of how transaction processing works using the FTP Replacement Scripts. When viewing the Log file contents and using the LogViewer Tool does not lead to problem resolution, Market Participants will be instructed to contact their system administrator or the ERCOT 24-Hour Helpdesk for assistance.

Basic Troubleshooting Steps Basic troubleshooting steps for all FTP Replacement Script software problems are outlined below:

• Look at any e-mail messages you receive with error information.

• Examine the Log file, using the LogViewer Tool.

• Look up corresponding error codes using the codes shown in the topic “Application Error Codes Table.”

• Perform the recommended recovery action(s).

• Recheck the Log file if a command is re-executed. The Log File The FTP Replacement Scripts’ “Log file” records all system activities performed by the software during transaction exchange. This tool is described in the following topic, “Using the Log File.” Of particular interest to Market Participants viewing the Log file are activity messages indicating command success or application error codes returned by the client side of the FTP Replacement Scripts system. The topics “What Are Application Error Codes?” and “Application Error Codes Table” describe how to interpret and resolve errors and other system messages reported via the Log file.

The LogViewer Tool The command-line tool provided with the FTP Replacement Scripts software—the LogViewer—allows Market Participants to easily view the contents of the Log file and perform their own troubleshooting. Refer to the topic “Using LogViewer” for a complete discussion of how to run and interpret the information reported using this tool.

Error Codes All application error codes are posted in the Log file column named App Error. Exit status codes—a subset of the application error codes—are also posted for error conditions. Every exit status code results in an action performed by the FTP Replacement Scripts software. Refer to the topics “What Are Application Error Codes?” and “Application Error Codes Table” for a complete breakdown of error codes, their meanings and associated recovery actions.

8-3, 2/22/2002

Using the Log File

The Log file is used by the system to log any activity that occurs on the Market Participant’s (client) side of the FTP Replacement Scripts software. The location of the Log file is identified by the –LOG command parameter and may be set to any location that the Market Participant requires. To understand how the scripts work, it is important that Market Participants know how to interpret the Log file. The paragraphs which follow show a typical Log file and explain the file’s structure and data elements. The Log file contents may be displayed in an easy-to-read format using the LogViewer Tool. For information about this tool, refer to “Using LogViewer” following this topic. In most cases, Market Participants will want to use LogViewer to interpret their Log file during troubleshooting.

8-4, 2/22/2002

Log File Sample A typical Log file is shown below. In the table on the following page, all Log file data elements are described. The first element described in the table, Time Stamp, is located at the left of this file. The final element described in the table, Comment, is located at the far right of this file. NOTE: All data elements are separated by a vertical bar (|), or “pipe.” 2002-02-07 15:28:12,364|INFO|||||||||NULL|20020207032812_143@LAW2KN002||20020207032812_143@LAW2KN002|||183529049|959595957||Session/CreateRQ||Receiving response from server 2002-02-07 15:28:14,117|INFO|||||||||NULL|20020207032812_143@LAW2KN002||20020207032812_143@LAW2KN002|||183529049|959595957||Session/CreateRQ||Response received from server 2002-02-07 15:28:14,117|INFO|||||||||NULL|20020207032812_143@LAW2KN002||20020207032812_143@LAW2KN002|||183529049|959595957||Session/CreateRQ||Acknowledgement Timestamp 2002-02-07 16:09:57.0 2002-02-07 15:28:14,117|INFO|||||||||[email protected]|20020207032812_143@LAW2KN002||20020207032812_143@LAW2KN002|||183529049|959595957||Session/CreateRQ||Sending file: D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP2002-02-07 15:28:14,117|INFO|||||||||[email protected]||||||183529049|959595957||Upload/Request|D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|Open the transport 2002-02-07 15:28:14,147|INFO|||||||||[email protected]|20020207032814_447@LAW2KN002||20020207032814_447@ LAW2KN002|||183529049|959595957|| Upload/Request|D:\FTP_FILES\ TO_ERCOT \SEND\ESPFrame1.ISFLT.PGP|Sending request to server 2002-02-07 15:28:14,147|INFO|||||||||[email protected]|20020207032814_447@LAW2KN002||20020207032814_447@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|Request sent to server 2002-02-07 15:28:14,147|INFO|||||||||[email protected]|20020207032814_447@LAW2KN002||20020207032814_447@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|Receiving response from server 2002-02-07 15:28:15,499|INFO|||||||||[email protected]|20020207032814_447@LAW2KN002||20020207032814_447@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|Response received from server 2002-02-07 15:28:15,499|INFO|||||||||[email protected]|20020207032814_447@LAW2KN002||20020207032814_447@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|Acknowledgement Timestamp 2002-02-07 16:09:59.0 2002-02-07 15:28:15,499|INFO|||||||||[email protected]|20020207032814_447@LAW2KN002||20020207032814_447@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|File has been sent 2002-02-07 15:28:15,499|SUCCESS|||||||||||||||183529049|959595957|SEND||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|File Successfully Sent 2002-02-07 15:28:15,499|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|File copied to D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND\ESPFrame1.ISFLT.PGP 2002-02-07 15:28:15,499|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|File deleted 2002-02-07 15:28:15,499|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame1.ISFLT|File copied to D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND\ESPFrame1.ISFLT 2002-02-07 15:28:15,499|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame1.ISFLT|File deleted 2002-02-07 15:28:15,499|INFO|||||||||[email protected]|20020207032814_447@LAW2KN002||20020207032814_447@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame1.ISFLT.PGP|Sending file: D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP 2002-02-07 15:28:15,509|INFO|||||||||[email protected]||||||183529049|959595957||Upload/Request|D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|Open the transport 2002-02-07 15:28:15,509|INFO|||||||||[email protected]|20020207032815_52@LAW2KN002||20020207032815_52@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|Sending request to server 2002-02-07 15:28:15,509|INFO|||||||||[email protected]|20020207032815_52@LAW2KN002||20020207032815_52@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|Request sent to server 2002-02-07 15:28:15,509|INFO|||||||||[email protected]|20020207032815_52@LAW2KN002||20020207032815_52@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|Receiving response from server 2002-02-07 15:28:16,630|INFO|||||||||[email protected]|20020207032815_52@LAW2KN002||20020207032815_52@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|Response received from server 2002-02-07 15:28:16,630|INFO|||||||||[email protected]|20020207032815_52@LAW2KN002||20020207032815_52@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|Acknowledgement Timestamp 2002-02-07 16:10:00.0 2002-02-07 15:28:16,630|INFO|||||||||[email protected]|20020207032815_52@LAW2KN002||20020207032815_52@LAW2KN002|||183529049|959595957||Upload/Request|D:\FTP_FILES\ TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|File has been sent 2002-02-07 15:28:16,630|SUCCESS|||||||||||||||183529049|959595957|SEND||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|File Successfully Sent 2002-02-07 15:28:16,630|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|File copied to D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND\ESPFrame3.ISFLT.PGP 2002-02-07 15:28:16,630|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame3.ISFLT.PGP|File deleted 2002-02-07 15:28:16,630|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame3.ISFLT|File copied to D:\FTP_FILES\TO_ERCOT\ARCHIVE\SEND\ESPFrame3.ISFLT 2002-02-07 15:28:16,630|INFO|||||||||||||||||||D:\FTP_FILES\TO_ERCOT\SEND\ESPFrame3.ISFLT|File deleted 2002-02-07 2002-02-07 15:28:16,630|INFO|||||||||[email protected]||||||183529049|959595957||Session/CloseRQ||Open the transport

8-5, 2/22/2002

Log File Data Structure The Log file is pipe delimited—separated by vertical bars in an actual file—and contains the following data elements. To use this table effectively, you may wish to refer to your own Log file and move through its data elements one by one. NOTE: Most lines in your Log file will not contain every data element shown here. Certain data elements apply only to specific situations—such as a SEND.

Data Element Name From Left to Right Description

Time Stamp Indicates the date and time of the activity, in YYYY-MM-DD HH:MM,SSS format.

Status Indicates the type of activity; includes INFO, ERROR, SUCCESS and WARN (warning).

Source ID If an error occurred, this indicates the function associated with the error.

App Error Indicates an application error code, such as: -150. See the topic “Application Error Codes Table” for a listing of error codes.

App Error Desc Indicates an application error code description corresponding to the App Error above. In this sample, the error description corresponding to the exit status code of -150 is: Error while receiving with protocol.

Source Error Indicates the underlying system error, if applicable. Error lists will also be logged here.

Source Desc Indicates the description of the source failure.

Post Office ID N/A

MailBox ID N/A

Folder Type N/A

Conversation ID Indicates the identifier for the “conversation” held between the MP’s system and the ERCOT server. A typical conversation ID will be denoted by CID: [email protected] and will be populated with NULL before a conversation is started.

Message ID Indicates the message identifier for the transaction. A typical message identifier will have a time stamp at the beginning and will resemble this: MID: [email protected].

RefToMessage ID Message identifier generated by the server in response to the Message ID above.

Attachment ID Indicates the system-generated attachment identifier for the transaction. A typical attachment identifier will have a time stamp at the beginning and will resemble this: [email protected].

8-6, 2/22/2002

Data Element Name From Left to Right Description

Doc ID Indicates a unique document identifier assigned by the system. A typical document ID is: [email protected].

Service ID N/A

Duns To Duns number of the “To” party, such as 183529049.

Duns From Duns number of the “From” party, such as 848484842.

Command Contains the command executed (SEND, RECEIVEALL, DOWNLOAD).

Service Action Contains an identifier to denote the type of action performed. This may be a Service/Action pair such as Session/CreateRQ, Upload/Request, Download/Response, etc.

Filename Name of file that the action (such as SEND or DOWNLOAD) is being performed on.

Comment

Additional comments about the related file/transaction. Typical comments may resemble the ones shown below: Starting a session with Session/CreateRQ Acknowledgement Timestamp 2002-02-05 16:36:08.0 Getting the contents of folder: * Open the transport Send request to server Receiving response from server

8-7, 2/20/2002

Using LogViewer

A command-line based software tool is included as part of the FTP Replacement Scripts software—the LogViewer Tool. Use the LogViewer Tool to help simplify troubleshooting by aiding in the display and interpretation of the Log file. Log file entries that are normally separated by a pipe (|) are displayed using LogViewer in an easy-to-read format. In addition, the LogViewer Tool may be used to search for specific data entries, such as transaction activity involving a specific file or occurring during a specific time frame.

LogViewer Tool Parameters To see the available LogViewer command line options, enter log after your command prompt or Log (case-sensitive) after your ./MPCS UNIX prompt. A screen resembling the one below displays.

Displaying the Log File Using the LogViewer To display specific information from your Log file using LogViewer, use command lines similar to the examples shown below and on the following page. NOTE: When using Windows, copy the path for the log file directly into the log command line by typing log and then dragging and dropping the file from the Explorer view into the command line. Then, enter any required parameters. log c:\FTP_FILES\log\20020130.txt –F pgp –SD 2002-01-10 –ED ALL

Where: C:\FTP_FILES\log\2002130.txt indicates the path to the log file -F pgp indicates that only files with pgp in the filename of the given log will be searched for, –SD 2002-01-10 indicates that log entries prior to the Start Date should be ignored, and –ED ALL indicates that log entries up to and including the End Date should be displayed. A value of “ALL” will display all log entries.

8-8, 2/20/2002

OR log c:\FTP_FILES\log\20020130.txt –F pgp –SD “2002-01-10 13:10:00” –ED ALL

Where: C:\FTP_FILES\FTP_FILES\2002130.txt indicates the path to the log file -F pgp indicates that only files with pgp in the filename of the given log will be searched for, –SD “2002-01-10 13:10:00” indicates that the timestamp for the search should start at the indicated start date and time (quotation marks are required due to the space between the date and time), and –ED ALL indicates that the timestamp for the end date includes any date and time.

Log File Contents Viewed with LogViewer Contents of a typical Log file displayed both through LogViewer and without LogViewer are shown below. The log viewer displays one log entry per screen. Press ENTER to page through each record in the log file; press CTRL+C to exit LogViewer and return to the command line. The ---Next Entry--- divider separates information corresponding to lines in the Log file.

Log File Displayed Through LogViewer

Same Log File Information Displayed Without LogViewer 2002-02-07 15:28:12,364|INFO|||||||||NULL|20020207032812_143@LAW2KN002||20020207032812_143@LAW2KN002||| 183529049|959595957||Session/CreateRQ||Request sent to server 2002-02-07 15:28:12,364|INFO|||||||||NULL|20020207032812_143@LAW2KN002||20020207032812_143@ LAW2KN002||| 183529049|959595957||Session/CreateRQ||Receiving response from server

8-9, 2/20/2002

What Are Application Error Codes?

Whenever an error occurs it is given an application error code specific to the FTP Replacement Scripts software. In some cases, a source error code is also generated; source error codes reflect any underlying error causing the problem. For example, when decryption for a file fails an application error of –52 (Decryption for file failed) is given. The underlying source error code could be CryptoException -1 (Invalid file), CryptoException -11 (Non-existing key error), etc. Not all errors have related source error codes. For a complete list of application error codes, refer to the topic “Application Error Codes Table.” A typical error code shown in the ERROR line in a sample Log file is shown below. For additional information about the Log File, refer to the previous topics, “Using the Log File” and “Using LogViewer.”

Error Message Showing 503 Application Error Code

ERROR Line in Log Application Error Code Source Error Code

Types of Errors

Two basic error code categories are used to describe errors with the FTP Replacement Scripts software: fatal errors and non-fatal errors. Both error types are logged in the Log file. Within the category of fatal errors, there are recoverable and non-recoverable conditions. To understand how Log file error statuses relate to application errors and exit codes, refer to the graphic below along with the following paragraphs.

Error Code Relationships

Log File Error Status Resulting Error CorrespondingExit Code

ERRORFatal, Recoverable, orFatal, Non-Recoverable, orNon-Fatal

+_

NOTE: If the program finishes, but one or more non-fatal errors occurred during processing a -900 error will be logged. In addition, an error e-mail message will be returned with

additional error codes in the “comment” section of the e-mail.

(Multiple non-fatal errors logged as -900)

8-10, 2/20/2002

Fatal Errors Fatal errors indicate that the program encountered a condition that caused it to abort. An e-mail is sent to the address in the –EML and –MTA parameters (if supplied). If the program is sending files, all files that have not yet been sent will remain in the –DIR directory. Then the program will exit with a non-zero exit code. Non-Fatal Errors Non-fatal errors indicate that the program encountered an error, but the error did not cause the program to abort. If a non-fatal error occurs for a file the system is trying to send, it will move the file to the –REJECT directory and continue with the next file. If the program finishes, but one or more non-fatal errors occurred during processing a fatal error (-900) will be logged. (A sample e-mail with -900 error information is shown below.) After the error is logged in the Log file, an e-mail is sent to the address in the –EML and –MTA parameters (if supplied), notifying the recipient that the program finished but there were non-fatal errors. A summary of the non-fatal errors is included in the comment section of the e-mail. Sample e-mail messages containing error information are shown below:

Duns To: 183529049 Duns From: 848484842 Time Stamp: Wed Feb 13 09:32:29 MST 2002 Activity: ERROR App Error: -404 App Error Desc: Transport Exception DocumentID: File: Comment: Command: SEND Service Action: Session/CreateRQ Source Error: HttpStatus-404 Source Desc: Not Found

Duns To: 183529049 Duns From: 848484842 Time Stamp: Wed Feb 13 12:15:49 MST 2002 Activity: ERROR App Error: -900 App Error Desc: Program finished but there were errors, check entire log for more details DocumentID: File: Command: RECEIVEALL Service Action: Source Error: Source Desc: Comment: Non Fatal Errors -207 - Non-fatal Error List. -207 - Non-fatal Error List. -999 - DocId LVCLoader_test1.pgp_21320023210_28749665 was unable to be downloaded due to an error.

8-11, 2/20/2002

Exit Codes

When the program finishes it sets the exit code to indicate success or failure. If the program finishes successfully, it will return a 0. If there is an error, it will return the corresponding application error code. If the exit code is a negative number, a non-recoverable error occurred. User intervention will likely have to occur before the program will be able to finish successfully. If the exit code is a positive number, a recoverable error occurred. It is possible that retrying the program later will fix the problem. Communication failures are examples of recoverable errors.

8-12, 2/20/2002

Application Error Codes Table

This topic details all application error codes and associated recovery actions. There are three basic recovery actions:

• Make command line changes and retry the command • Contact your System Administrator • Contact the ERCOT 24-Hour Helpdesk

NOTE: The descriptions shown in the Description field below could be different from actual messages displayed in the Log file.

Application Error Code Descriptions

App Error Code Description Recovery Action

Fatal, Unrecoverable Errors Parsing Validation Errors -1 Parameter does not have a value. For the parameter in error, add a value.

Re-execute the command. -2 Parameter supplied more than one

value or invalid token. For the parameter in error, remove a value if more than one is supplied. If the token is invalid, correct it and re-execute the command.

-3 Parameter supplied more than once. Remove the extra parameter. Re-execute the command.

-4 Required parameter not supplied. Add the required parameter. Re-execute the command.

-5 Invalid command. SEND, DOWNLOAD or RECEIVEALL should always be the first command.

Make sure that SEND, DOWNLOAD or RECEIVEALL is the first command. Re-execute the command.

-6 Download file not supplied. Supply a valid download file and location. Re-execute the command.

-7 Unable to set Log file. Make sure that valid values are used for the –LOG parameter and that a file exists for recording log data. Re-execute the command.

-8 Parameter value for file is a directory. This check is performed by the system. Replace the existing parameter value with a valid file value. Re-execute the command.

-9 Parameter value for file is not found and the path could not be created.

This check is performed by the system. If the system cannot create the specified file-directory structure, verify that the file exists and enter the correct filename and path. Re-execute the command.

8-13, 2/20/2002


Fatal, Unrecoverable Errors (Continued) -10 Parameter value for a directory is a

file. This check is performed by the system. Replace the existing parameter value for a file with a valid directory value. Re-execute the command.

-11 Parameter value for a directory is not found and could not be created.

This check is performed by the system. If the system cannot create the specified directory structure, verify that the directory exists and enter the correct directory location. Re-execute the command.

-12 Parameter value for Cryption is invalid. Check entries for all Cryption parameters. Make required changes and re-execute the command.

-15 A conditional required parameter is missing. (A conditional parameter is one that is required when a corresponding parameter is used.)

Supply the required conditional parameter. Re-execute the command.

-16 Less than 3 tokens supplied. Supply the missing tokens. Re-execute the command.

Encryption Errors -50 Encryption for a file failed. Failure was

due to a bad key, bad password, etc. Check the Log file for detailed information. Check encryption error by referring to Section 7 – Using Scripts, or to PGP or GnuPG documentation. Make required changes, if applicable, and re-execute the command. If the problem persists, contact the ERCOT Helpdesk.

-51 I/O error occurred while trying to encrypt a file. This could include the errors: File not found, couldn’t create output, etc.

Check the Log file for detailed information. Make required changes, if applicable, and re-execute the command. If the problem persists, contact the ERCOT Helpdesk.

Other Errors -90 API attempted to run a command

without setting either To, From, UserInfo or URL.

If you are programming with the API, you must set the To, From, UserInfo and URL before calling any other methods.

-91 API attempted to run a command without a valid ConversationID. API needs to call a CreateSession first.

If you are programming with the API, you must set the CreateSession before uploading or downloading a file.

-99 Unknown Host error while getting domain.

Check the Log for detailed information. Make required changes, if applicable, and re-execute the command. If the problem persists, contact the ERCOT Helpdesk.

8-14, 2/20/2002


Fatal, Unrecoverable Errors (Continued) File Errors -101 I/O Error while attempting to move to

Archive/ Rejection folders. Contact the ERCOT Helpdesk.

-103 While exiting on another error, the system was unable to delete encrypted files that were not yet sent.

The system was unable to clean up the directory for encrypted files. Contact the ERCOT Helpdesk.

Protocol Errors -150 Error in protocol for SEND. -151 Error in protocol for RECEIVEALL. -155 Response did not contain an Error List

or Acknowledgement.

Contact the ERCOT Helpdesk.

Payload Errors -200 The number of documents is not a

valid number. -201 The number of documents for a

Directory Request does not match the documents returned.

-202 SessionControlResponse status on a CreateRS is not found or has an invalid value.


-205 Non-recoverable, fatal Error List error. Check the Log file for detailed information. Make required changes, if applicable, and re-execute the command. If the problem persists, contact the ERCOT Helpdesk.

ebXML Errors -220 “From” in Response does not match

the “To” in Request. -221 “To” in Response does not match the

“From” in Request. -222 The “ConversationID” in Response

does not match. -223 “RefToMessageID” in Response does

not match “MessageID” in Request. -224 “Action” in Response does not match

with “Action” in Request -225 “Service” in Response does not match

“Service” in Request. -299 Unexpected Payload error. This could

be because the system can’t find an attribute, payload is missing, etc.


8-15, 2/20/2002


Fatal, Unrecoverable Errors (Continued) HTTP Status Errors -400 Bad request. Contact the ERCOT Helpdesk. -401 Unauthorized. Check the –UID and –PWD parameters

in the command line. Make changes as applicable and re-execute the command. Contact the ERCOT Helpdesk if the problem persists.

-403 Forbidden. -404 Not found. -405 Method Not Allowed.

Retry the command, if possible. Contact the ERCOT Helpdesk if the problem persists.

-501 Not implemented. -505 HTTP version not supported. Contact the ERCOT Helpdesk.

Finished With Errors -900 Program finished but there were errors

present. Check the Log file for detailed information. Some files may not have been sent or downloaded.

Unexpected Errors -999 Unexpected error. Check the Log file for detailed

information. Make required changes, if applicable, and re-execute the command. If the problem persists, contact the ERCOT Helpdesk.

Fatal, Recoverable Errors Payload Errors 203 SessionControlResponse status on a

CreateRS is “rejected.” Check the Log file for detailed information. Make required changes, if applicable, and re-execute the command. If the problem persists, contact the ERCOT Helpdesk.

ebXML Errors 206 Recoverable, fatal Error List error. Check the Log file for detailed


HTTP Status Errors 500 Transport Error. 502 Server is not running. 503 Transport Error.


8-16, 2/20/2002


Non-Fatal Errors; Logged Only Cryption Errors -52 Decryption for file failed. -53 I/O error while trying to decrypt file.


File Errors -110 Zero length file on SEND. Check to see if the file was supposed to

contain data. Make file changes, if applicable, and re-execute the SEND command.

111 Could not read file on SEND. If the file is being written to while the SEND command is checking the directory, then this file will go in the next SEND command. Re-execute the SEND command.

-112 Sub-directory from ERCOT (OUT, BAD or REPORTS) during a RECEIVEALL command could not be created.

-113 Sub-directory from ERCOT (OUT, BAD or REPORTS) during a RECEIVEALL command was not an actual directory.


-115 No files were sent on the SEND command.

Verify that there were files to send. It is possible that your feeding system (translator) did not push files to the FTP Replacement Software directory.

Payload Errors -207 Non-fatal Error List error. Check the Log file for detailed


9-1, 2/22/2002

Contacting ERCOT

For routine system problems, your system administrator or helpdesk can provide assistance. When an ERCOT problem occurs, most likely due to an ERCOT-related system problem or server outage, refer to the contacts shown here. This section includes the following topics:

• When to Call • Reporting ERCOT Server Outages • Contact Number

9-2, 2/22/2002

When to Call

For issue tracking purposes, Market Participants should call ERCOT’s helpdesk whenever there are problems communicating with ERCOT. Hardware Problems For problems which appear to be related to hardware, perform these steps before contacting ERCOT:

• Check to see if the Internet connection is working properly. • Verify the Internet connection by pinging. Then contact the ERCOT 24-Hour Helpdesk at 1-512-248-6800. Software Problems For problems related to software that cannot be solved by your system administrator or network administrator, contact the ERCOT 24-Hour Helpdesk at 1-512-248-6800.

Reporting ERCOT Server Outages

To report an ERCOT server outage, contact the ERCOT 24-Hour Helpdesk at 1-512-248-6800.

Contact Number

For all other ERCOT-related problems, contact the ERCOT 24-Hour Helpdesk at 1-512-248-6800.

A-1, 2/22/2002

Appendix A

This section describes basic configuration guidelines for PGP when used with the FTP Replacement Scripts software. This section provides an overview of PGP only; refer to your PGP system documentation for all other information. This section includes the following topics:

• Configuring the PGP.CFG File for the FTP Replacement Scripts • Sample PGP.CFG File • Other PGP Configuration Recommendations

A-2, 2/22/2002

Configuring the PGP.CFG File for the FTP Replacement Scripts

PGP stores user-defined parameters in the configuration text file PGP.CFG. This configuration file enables the user to define flags and parameters for PGP, eliminating the need to define these parameters at the command line. Use PGP’s configuration parameters to enable PGP to work effectively with the FTP Replacement Scripts by setting the following parameters as shown below. Note that configuration parameters may be: assigned integer values, character string values, or on/off values; the type of value depends on the type of parameter. The following rules apply to the recommended configuration file settings shown below:

• PGP ignores blank lines.

• PGP also ignores characters that follow the comment character, #.

• Keywords are not case-sensitive. PGP also uses default values for the configuration parameters under these conditions:

• When configuration parameters are not defined.

• If the configuration file does not exist.

• If PGP cannot find the configuration file. PGP.CFG Requirements

PGP Parameter or Option Required Setting Signing Private Key DSA at 1024 bits

Encrypting Public Key El Gamal (ELG-E) at 1024 bits

Cipher Algorithm Triple DES (3DES)

Key Expiration 2 years

User ID name (organization) <e-mail address>

Message Digest Algorithm / Hash SHA

Compression must be used ZIP parameter option is preferred, in which compressed packets are compressed with RFC1951 DEFLATE

A-3, 2/22/2002

Sample PGP.CFG File # Configuration File for PGP # # Please see the manual for more details on each configuration value. The default value for each option is listed. # ------ ADKKEY ------ # Encrypt to an Additional Decryption Key (ADK). When this parameter is used, all generated keys have an ADK equal to the # value of ADKKEY, and everything encrypted to the user's key is also encrypted to the ADK key identified by this parameter. # # ADKKEY = <keyID> # For example, ADKKEY = "0xAB12C34D" # # ADKKEY = "" # ------ ARMOR ------ # If enabled, this parameter causes PGP to emit ciphertext or keys in ASCII-armored format suitable for transport through # email channels. Output files are named with the ".asc" extension. # # The configuration parameter ARMOR is equivalent to the "-a" command line option. If you intend to use PGP primarily for # email purposes, you should turn this parameter on (ARMOR=on). # # ARMOR = off # ------ BATCHMODE ------ # When the BATCHMODE flag is enabled on the command line, PGP does not ask any unnecessary questions or prompt for alternate # filenames. With BATCHMODE, PGP will respond with its own default responses. You cannot alter the responses. # # BATCHMODE = off # ------ CERT_DEPTH ------ # The configuration parameter CERT_DEPTH identifies how many levels deep you can nest trusted introducers. # # CERT_DEPTH = 4 # ------ CIPHERNUM ------ # Specifies which symmetric cipher PGP should use to encrypt the session key--IDEA, Triple-DES, CAST, or Twofish. # # Values are as follows: # IDEA = 1 # 3DES = 2 # CAST5 = 3 # Twofish = 10 # CIPHERNUM = 2

A-4, 2/22/2002

# ------ CLEARSIG ------ # Use the CLEARSIG parameter to generate a signed message that can be read with human eyes, without the aid of PGP. The # recipient must still use PGP to verify the signature. # # CLEARSIG = on # ------ COMMENT ------ # Displays a comment header in all armored output just beneath the PGP Version header. # # COMMENT = "" # ------ COMPATIBLE ------ # The configuration parameter COMPATIBLE enables user-interface compatibility with PGP 2.6.2. You may require this feature # for interoperation with scripts that parse the output or otherwise interact with PGP dialogs. # # COMPATIBLE = off # ------ COMPLETES_NEEDED ------ # The configuration parameter COMPLETES_NEEDED identifies the minimum number of completely trusted introducers required to # fully certify a public key on your public key ring. # # COMPLETES_NEEDED = 1 # ------ COMPRESS ------ # The configuration parameter COMPRESS enables or disables data compression before encryption. It is used mainly to debug # PGP. Under normal circumstances, PGP attempts to compress the plaintext before it encrypts it. Compression strengthens # security. Turning COMPRESS off therefore weakens your security. Thus, we recommend you do not change this setting. # # COMPRESS = on # ------ ENCRYPTTOSELF ------ # Instructs PGP always to add the recipient specified in the configuration parameter MYNAME to its list of recipients and # thus always encrypt to the predefined key as well as to any specified recipients. # # ENCRYPTTOSELF = off # ------ ENFORCEADK ------ # Forces encryption to any ADKs associated with a recipient's key. Use in conjunction with the ADKKEY parameter # (encrypting to a key with an Additional Decryption Key (ADK)). # # ENFORCEADK = off # ------ EXPORTABLE ------

A-5, 2/22/2002

# This is a shorthand for setting SIGTYPE=export. This makes the most sense if SIGTYPE is set to "non" and then # "+exportable" is used on the command line to override the non-exportable signature type. # # EXPORTABLE = on # ------ FASTKEYGEN ------ # Use to specify fast key generation. # # FASTKEYGEN = on # ------ FORCE ------ # To run PGP non-interactively from a UNIX shell script or MSDOS batch file, you can use the FORCE option to eliminate # interaction with PGP in the following two situations: # # When you decrypt a file that has a filename with the same name as another in the directory, FORCE causes PGP to overwrite # the original file without prompting. # # When you remove a key from a keyring (either public or private), FORCE removes the key without confirming the deletion. # # pgp +force <ciphertext_filename> # or: # pgp +force -kr <your_userID> # # FORCE = off # ------ GROUPSFILE ------ # Specifies the location of the PGP groups file, pgpgroup.pgr. # # Unix # GROUPSFILE = "<HOME>/.pgp/pgpgroup.pgr" # # Windows NT/2000 # GROUPSFILE = "<USERPROFILE>\Application Data\pgp\pgpgroup.pgr" # # Note: The <HOME> and <USERPROFILE> portions of the paths must be replaced with the value of the current environment # variables of the same names. # ------ HASHNUM ------ # Defines which hash algorithm PGP uses for signing. # # Values are as follows: # MD5 = 1 # SHA-1 = 2 # RIPEMD160 = 3 # HASHNUM = 2

A-6, 2/22/2002

# ------ INTERACTIVE ------ # Instructs PGP to ask for confirmation when you add a key file with multiple keys to your key ring. When this variable is # set to "on", PGP asks for confirmation for each key in the key file before adding it to your key ring. # # INTERACTIVE = off # ------ MARGINALS_NEEDED ------ # The configuration parameter MARGINALS_NEEDED identifies the minimum number of marginally trusted introducers required to # fully certify a public key on your public key ring. # # MARGINALS_NEEDED = 2 # ------ MYNAME ------ # The configuration parameter MYNAME specifies the default key ID to use when selecting a private key for making signatures. # If MYNAME is not defined, PGP uses the most recent private key you installed on your private keyring (secring.skr). You # should always specify MYNAME using the key's key ID, not user ID, to prevent a potential security risk. # # MYNAME = "" # ------ PAGER ------ # PGP's -m option lets you view decrypted plaintext output on your screen, one screen at a time, without writing the output # to a file. PGP includes a built-in page display utility. If you prefer to use a different page display utility, use the # PAGER parameter to identify the utility. The PAGER parameter specifies the shell command PGP uses to display a file. # # PAGER = "" # ------ PASSPHRASE-FD ------ # Use to transmit your passphrase from one program to another. When specified, PGP will try to read the passphrase from the # specified file descriptor. # # PASSPHRASE-FD = # ------ PASSTHROUGH ------ # If this is set to on and you are decrypting a lexical section not recognized by the parser, then processing is not ended # with an error. # # PASSTHROUGH = off # ------ PGP_MIME ------ # Use to specify compatibility with PGP-MIME. # # PGP_MIME = off # ------ PGP_MIMEPARSE ------

A-7, 2/22/2002

# Use to instruct PGP to try to parse MIME body parts. # PGP_MIMEPARSE = off # ------ PUBRING ------ # You may want to keep your public keyring in a directory separate from your PGP configuration file (that is, the directory # specified by your PGPPATH environment variable). Use the PUBRING parameter to identify the full path and filename for your # public keyring. # # Unix # PUBRING = "<PGPPATH>/pubring.pkr" # # Windows NT/2000 # PUBRING = "<USERPROFILE>\Application Data\pgp\pubring.pkr" # # Note: The <PGPPATH> and <USERPROFILE> portions of the paths must be replaced with the value of the current environment # variables of the same names. # ------ RANDOMDEVICE ------ # (UNIX only.) Identifies the system entropy pool, /dev/random. PGP tries to open this device to acquire entropy, and if # that fails, will try to acquire entropy from user keystrokes. # # RANDOMDEVICE = /dev/random # ------ RANDSEED ------ # The random number seed file, randseed.rnd, is used to generate session keys. You may want to keep your random number seed # file in a more secure directory or device (this file generally resides in the directory specified by your PGPPATH # environment variable). Use the RANDSEED parameter to identify the full path and filename for your random seed file. # # Unix # RANDSEED = "<PGPPATH>/randseed.rnd" # # Windows NT/2000 # RANDSEED = "<ALLUSERSPROFILE>\Application Data\Network Associates\pgp\randseed.rnd" # # Note: The <PGPPATH> and <ALLUSERSPROFILE> portions of the paths must be replaced with the value of the current # environment variables of the same names. # ------ RSAVER ------ # Specifies which version of RSA keys to use--RSA keys or RSA Legacy keys. # # RSAVER=3 # RSA Legacy keys. Enables RSA v3 key generation. RSA Legacy keys are compatible with previous versions of PGP. RSA Legacy # keys do not allow encryption subkeys and cannot be used as incoming ADKs. # # RSAVER=4

A-8, 2/22/2002

# Enables RSA v4 key generation. RSA v4 keys support subkeys and can be used as incoming ADKs. RSA v4 keys support all the # features of Diffie-Hellman/DSS keys. # # RSAVER = 3 # # ------ SDA ------ # Causes PGP to create self decrypting archives when the -c (conventional encryption) option is used. # # SDA = off # ------ SECRING ------ # You may want to keep your secret keyring in a directory separate from your PGP configuration file (that is, the directory # specified by your PGPPATH environment variable). Use the SECRING parameter to identify the full path and filename for your # secret keyring. # # Unix # SECRING = "<PGPPATH>/secring.skr" # # Windows NT/2000 # SECRING = "<USERPROFILE>\Application Data\pgp\secring.skr" # # Note: The <PGPPATH> and <USERPROFILE> portions of the paths must be replaced with the value of the current environment # variables # of the same names. # ------ SHOWPASS ------ # Causes PGP to echo your typing during passphrase entry. # # SHOWPASS = off # ------ SIGTYPE ------ # Applies a type to a signature on a key. Signature types are discussed below. # # SIGTYPE=export | non | meta | trusted # # Export. Exportable signatures can be exported to a certificate server so other users can view them. # # Non. Non-exportable signatures apply only to your signatures to a certificate server. # # Meta. Meta signatures (always non-exportable) bestow meta-introducer status on the key. Any key considered trusted by the # meta-introducer is considered a trusted introducer by you, and any key considered valid by the trusted introducer is # considered valid to you. #

A-9, 2/22/2002

# Trusted. Trusted signatures bestow trusted introducer status on the key. Any key considered valid by a trusted introducer # is considered valid to you. When you apply a 'trusted' type to a signature on a key, PGP prompts you to enter a domain in # which the key is trusted. # # SIGTYPE = export # ------ STATUS-FD ------ # Use to write status messages to an alternative output stream. This parameter allows status messages to be redirected to a # file descriptor. # # STATUS-FD = # ------ TMP ------ # Specifies the directory PGP uses for temporary scratch files. If TMP is undefined, the temporary files are written in the # current directory. If the shell environmental variable TMP is defined, PGP stores temporary files in the named directory. # # TMP = "" # ------ TEXTMODE ------ # Causes PGP to assume the plaintext is a text file, not a binary file, and converts the plaintext to canonical text before # encrypting it. Canonical text has a carriage return and a line feed at the end of each line of text. # # TEXTMODE = off # ------ TZFIX ------ # The configuration parameter TZFIX specifies the number of hours to add to the system time function to # get GMT. If your operating system does not give time in GMT, use TZFIX to adjust the system time to GMT. # # PGP includes timestamps for keys and signature certificates in Greenwich Mean Time (GMT). When PGP asks the system for the # time of day, the system should give the time in GMT. However, on some improperly configured systems, the system time is # returned in US Pacific Standard Time plus 8 hours. # # You should also make sure your system's timezone is configured correctly by setting the TZ environment variable. # # For Los Angeles: SET TZ=PST8PDT # For Denver: SET TZ=MST7MDT # For Arizona: SET TZ=MST7 # (Arizona does not use daylight savings time) # For Chicago: SET TZ=CST6CDT # For New York: SET TZ=EST5EDT # For London: SET TZ=GMT0BST # For Amsterdam: SET TZ=MET-1DST # For Moscow: SET TZ=MSK-3MSD # For Auckland: SET TZ=NZT-13 #

A-10, 2/22/2002

# TZFIX = 0 # ------ VERBOSE ------ # The VERBOSE variable controls the amount of detail you receive from PGP diagnostic messages. # # 0 - Displays only queries and errors (that is, prompts the user for input and displays errors when they occur) # # 1 - Normal default setting. Displays a reasonable amount of detail in diagnostic or advisory messages. # # 2- Displays maximum information, usually to help diagnose problems in PGP. Not recommended for normal use. # # VERBOSE = 1 # ------ WITH-COLONS ------ # The WITH-COLONS variable controls how the output of a key view (-kv option) is formatted. # # When you use the WITH-COLONS variable when viewing public and public/private key pairs, the output displays in the # following format: # # [pub|sec]:validity:key_size:key_algorithm:keyid:creation_date: # expiration_date:trust:username: # # WITH-COLONS = off # ------ WITH-DELIMITER ------ # The WITH-DELIMITER variable controls how the output of a key view (-kv option) is formatted. The delimiter can be set to # any character. For example, if you set the delimiter equal to a semi-colon (;), then the output would display in the # following format: # # [pub|sec];validity;key_size;key_algorithm;keyid;creation_date; # expiration_date;trust;username; # # WITH-DELIMITER = ""

A-11, 2/22/2002

Other PGP Configuration Recommendations

Where to Store your Keyring Files PGP stores your key pair in two files: the public portion is stored in pubring.pkr and the private portion in secring.skr.If you add another user’s public key to your keyring, it is stored in the public portion of the keyring. The files are created when you run PGP for the first time. Keyring files are stored within a subdirectory controlled by PGP. Using the Random Number Seed File PGP uses the data in the random seed file (randseed.rnd) when it generates session keys. randseed.rnd is created when you run PGP for the first time. When using the FTP Replacement Scripts, random seed file generation is transparent to the scripts.