LEXIS-NEXIS ____________________________________________________ EDGAR DISSEMINATION SERVICE SUBSCRIBER DOCUMENTATION _________________________________________________________________ _ Release 4.1 April, 1995 TABLE OF CONTENTS 1. INTRODUCTION 2. LEVEL 1 BROADCAST SERVICE 3. LEVEL 1 TAPE SERVICE 4. LEVEL 2 TAPE SERVICE 5. DISSEMINATION DATA STREAM 5.1 Record Layout 5.2 File Format 5.3 Data Format 5.4 Corrections to Data 5.5 Audit File 6. CONFIRMATION FILE TECHNICAL SPECIFICATIONS 7. ERROR RECOVERY PROCEDURES 7-1 Error situations 7.2 Retransmission processing APPENDIX A: Level 1 Format for Public Dissemination APPENDIX B: Public Dissemination Fields Description APPENDIX C: Document Type Definition APPENDIX D: Public Document Fields Description APPENDIX E: Submission Types APPENDIX F: Document Types APPENDIX G: State/Country Codes APPENDIX H: Standard Industrial Clasification(SIC) Codes APPENDIX I: Correction Examples APPENDIX J: Level II Tape Subsets APPENDIX K: Data Usage Matrix APPENDIX L: Broadcast Subscriber Test Plan & Router Management 1. INTRODUCTION EDGAR is the Electronic Data Gathering, Analysis and Retrieval System established by the Securities and Exchange Commission (SEC). EDGAR allows companies to make required filings to the SEC via direct transmission, diskette, or magnetic tape. The data to be exchanged between the EDGAR host and the Dissemination Subsystem fall into the following categories: Public documents from live filings accepted by the SEC EDGAR system (including Post Acceptance Corrections); Audit Files; Confirmation Files. The EDGAR host will forward the public accepted filings electronically over a dedicated communication link to the Dissemination Subsystem operated and maintained by Lexis-Nexis based on the output Document Type Definition (DTD). As defined in the Protocol Specification, each file transmitted either online or via tape, consists of a control block and a filing block. The control block is a 256 byte fixed format uncompressed section of binary & ascii text. The filing block is defined by the DTD in this document and its contents are described in more detail in the rest of this document. At the end of each day, an Audit file will be transmitted by EDGAR. The Audit File will contain information on all files which had been transmitted from EDGAR to the Dissemination Subsystem during the current business day. The Audit file is the official record of what EDGAR has sent to the Dissemination subsystem for that business day, and will be utilized by Dissemination to reconcile against what has been received by the Dissemination subsystem. A Confirmation File is then transmitted to EDGAR from the Dissemination Subsystem. The purpose of the Confirmation File is to allow Dissemination to specify processing status for each of the filings transmitted from EDGAR to the Dissemination Subsystem as noted in the Audit File. Any files listed in the Audit file which were not successfully received by Dissemination are flagged as such in the Confirmation file flag and will be retransmitted by EDGAR to Dissemination. Lastly, an End of Business Day transaction will complete the electronic processing for that day and the session will be closed. This document contains an SGML DTD which defines the public dissemination stream in such a way that the data stream can be unambiguously verified using an SGML parser. In addition, a tag list, tag description, and data usage matrix (DUM), have been provided to give easily readable descriptions of the data stream and to provide additional information about conditional relationships between tags which are not always apparent from the DTD. In accordance with the SEC EDGAR contract, Lexis-Nexis, as the dissemination subcontractor, is offering several data services through the EDGAR Dissemination Service. Live filings on the operational EDGAR system began July 15, 1992. There were approximately 450 voluntary filers who had also participated in the EDGAR Pilot Service. In February 1993 the SEC adopted Interim EDGAR Rules and set the dates for additional filer phase-in as follows: Group/Approximate '33 Act '40 Act Phase-In Date Companies Companies Cumulative CF-01/ April 1993 240 250 490 CF-02/ July 1993 +753 +450 1,693 CF-03/ Oct 1993 +749 2,442 CF-04/ Dec 1993 +1000 3,442 **Twelve Month Congressionally Mandated Test Period** CF-05/ Jan 30, 1995 +1499 +800 5,741 CF-06/ Mar 06, 1995 +1497 +800 8,038 CF-07/ May 01, 1995 +1499 +800 10,337 CF-08/ Aug 07, 1995 +1496 11,833 CF-09/ Nov 06 1995 +1499 +800 14,132 CF-10/ May 06, 1996 +808 ____ 14,940 Total 11,040 3,900 The EDGAR Dissemination Service hours of operation are 8:00 a.m to 10 p.m. For questions or additional information, please call: EDGAR Dissemination Customer Service 1-800-542-9246 2. LEVEL 1 BROADCAST SERVICE The Level 1 Broadcast Service allows a subscriber to elect to receive all public filings as a broadcast stream of data. The Level 1 subscriber to this option is required to take delivery of the data F.O.B. at the Lexis-Nexis Dissemination facility. The subscriber choosing this option will be required to provide one of the following; a series of 56KB lines, a fractional T1 line, or a dedicated T1 line, as well as line termination equipment such as a multiplexer that will terminate on dedicated communications ports on the Dissemination Service platform. The subscriber will also need to provide like DSU's at both ends of the communication line and any routers needed. It is also recommended that the subscriber provide a spare DSU at the GEIS facility in the event the installed DSU fails. All equipment and configurations must also be approved by the Lexis-Nexis Dissemination Company. After approval, the subscriber's broadcast receipt process will undergo testing insure that all necessary criteria relating to connectivity and broadcast receipt are met. The Dissemination test process is designed to execute the Test Plan (detailed in Appendix L) with the subscriber on a test dissemination system. Once complete, the subscriber will be moved to the production Dissemination server to receive "live" data in a "test mode" while dissemination personnel monitor their operation. The subscriber will remain in a "test mode" for one week. The subscriber is then defined as in "production", or moved back to the test dissemination environment for further testing and evaluation. Test tapes, with examples of live data, are available to assist the subscriber with their evaluation and testing processes. If the subscriber chooses a 56kb configuration, it is anticipated that for the peak filing period during the year up to seven 56KB lines will be required. It will be the responsibility of the subscriber to install the additional lines necessary for peak periods. The broadcast service currently uses either the X.25 or the TCP/IP communications protocol for the broadcast data stream. The X.25 protocol supports the 56kb configuration, and the TCP/IP will support bandwidth up to a T1 circuit. Documentation for either the X.25 or the TCP/IP protocols is available upon request. At some point, the Broadcast Service will be delivering compressed data and the broadcast subscriber will receive source code for decompressing the data. Also as part of the subscription agreement the subscriber will receive up to 5 hours of technical consultation to assist in establishing communications links, how to receive the data, and in testing the subscriber. In order to accommodate subscribers who wish to receive these filings in tape format as a backup, overnight delivery service will be provided to these subscribers at a reduced- cost option. In the event of an outage or broadcast problem, backup tapes for the business day will be automatically shipped to the subscriber. 3. LEVEL 1 TAPE SERVICE The Level 1 Tape option of the Dissemination Service allows a subscriber to elect to receive all public filings on tape. Daily tapes would include all filings received by the Dissemination Service (or begin to be received by the Dissemination Service) by 5:30 p.m. ET each business day. The subscriber may choose to receive filings processed on either 3480 or 8mm cartridges At some point the Level 1 Tape Service will be delivering compressed data and the subscriber will receive source code for decompressing the data. Also, as part of the subscription agreement the subscriber will receive up to 5 hours of technical consultation to assist in processing the data. The Level 1 tape service became available with the first live filings on the operational system in July of 1992. See Appendix E for a list of all submission types included in EDGAR. 4. LEVEL 2 TAPE SERVICE The Level 2 Tape Service allows a subscriber to elect to receive one or more of eight SEC-specified subsets of public filings on tape. Daily tapes would include all filings in each subset received or being received by the Dissemination Service by 5:30 p.m. ET each business day. Tapes will be processed the same business day and shipped to customers by overnight courier. At some point the Level 2 Tape Service will be delivering compressed data and the subscriber will receive source code for decompressing the data. Also, as part of the subscription agreement the subscriber will receive up to 5 hours of technical consultation to assist in processing the data. Subset 1: Periodic filings by companies on the New York Stock Exchange: Forms 10-K, 10-Q, 8-K, 10 and all Definitive Proxies. Subset 2: Periodic filings by companies on the American Stock Exchange: Forms 10-K, 10Q, 8-K, 10 and all Definitive Proxies. Subset 3: Periodic filings by companies traded on NASDAQ: Forms 10-K, 10-Q, 8-K, 10 and all Definitive Proxies. Subset 4: Ownership Reports: Schedules 12-D, 14D, 14D- 9, 13-G, 13-E1, 13-E3, and 13-E4 plus Form 13-FE & 13-FE/A. Subset 5: Annual and quarterly reports of all companies pursuant to the Securities Exchange Act of 1934: Forms 10-K and 10-Q. Subset 6: Securities Act of 1933 Registration Statements to include: S-1, S-2, S-3, S-4, S-6, S- 8, S-11, S-20, N-1, N-1A, N-2, N-3, N-4, N-5, N- 8A, N-14, F-1, F-2, F-3, F-4, F-6, and related form types. Subset 7: Annual and quarterly reports of all companies pursuant to the Securities Exchange Act of 1934: Forms 10-K and 10-Q plus Preliminary & Definitive Proxies. Subset 8: Periodic reports filed under the Investment Company Act of 1940: Forms NSAR-A, NSAR-B and NSAR-U. For the first three (3) subsets, if the referenced filing has not been flagged as belonging to an exchange, the filing is assumed to belong to each of the three (3) subsets. See Appendix J for a complete list of submission types in each subset. 5. DISSEMINATION DATA STREAM 5.1 Record Layout Both Level I and Level II subscriptions are available in either 3480 or 8mm cartridge formats. For both tape services the Submission information has been stored on cartridge tape with the following specifications: IBM Standard Label or ANSI Standard Label ASCII or EBCDIC Character Sets 3480 cartridge or 8mm cartridge Record length: 32,760 Tape Combinations Label Type Character Set 3480 Cartridge IBM/ANSI ASCII/EBCDIC 8mm Cartridge IBM/ANSI ASCII/EBCDIC 8 mm cartridge tape subsystems are available in the 8500 format. An 8500 tape drive will be required by the subscriber in order to read the data. The 8500 handles 300 MB to 5.0 GB. 5.2 File Format Level 1 and Level 2 tapes are in stream file, multi-volume format. Level 1 tapes contain 2 files, one containing the submission data and the other containing an audit file with information about the submissions on the tape. Level 2 tapes contain at a minimum 2 files. One file contains the submission information for the subset selected and the second file contains the audit information. In the case where a subscriber elects more than one subset, the tape will contain one file of the submission information and one of the audit information for each subset. Within the file, each submission is immediately preceded by a Control Block. The Control Block is a 256-byte block that identifies the associated submission by providing key information. At some point in the future when the data is compressed, the Control Block will remain uncompressed thereby saving the receiver from decompressing and parsing the submission in order to obtain information about it. Fields in the control block are blank padded and blank filled where appropriate. The fields are described in the following table in their exact order. FIELD SIZE (BYTES) DESCRIPTION Accession Number 20 EDGAR accession number Submission type 10 Form type of submission Filing Company Name 60 Conformed filing company name Subject Company Name 60 Conformed subject company name Filing Date 8 Date the filing was received by EDGAR The format is YYYYMMDD. Acceptance Date 8 Date the filing was accepted by E DGAR. Format is YYYYMMDD. Acceptance Time 6 Time (ET) at which the filing was accepted by EDGAR. Format is HHMMSS. Build Time 6 Time (ET) at which the filing was built on EDGAR. The format is YYYYMMDD:HHMMSS. Reserved 6 Priority 1 Submission priority set by EDGAR. The format is binary. Values are: 3 - post-acceptance correction 4 - low 8 - medium 12 - high 16 - high priority company Public Flag 1 Flag is always 1. Transaction type 1 An indicator describing the transaction type. Format is binary. Values are: 1 - submission 2 - retransmission 3 - correction 4 - deletion 5 - filing transfer 6 - document transfer SRO distribution 4 A listing of the SROs to list which the submission is sent. The format is a binary bitmap (bits and types ordered right- to-left) More than one bit may be set. Bit values are: 1 - AMEX 2 - BSE 3 - CBOE 4 - CSE 5 - MSE 6 - NASD 7 - NYSE 8 - PHLX 9 - PSE 10 - SSE Reserved 65 5.3 Data Format The data from the EDGAR system which will be available from the Dissemination Subsystem fall into the following categories: Y public documents from filings accepted by the SEC EDGAR system (including post-acceptance corrections and post-acceptance deletions), and Y Audit files. The submission header for filings provides tagged data which identifies both filer and filing information for the documents included in the submission. There may be multiple documents associated with the submission. Each document will have its own document specific header with tagged data identifying document information. The first tag of each submission will be and the last tag of each submission will be . Individual documents within a submission will be designated with a tag and the end of the document with . The structure of a submission can be represented as: submission 3 UAA 3 3 3 3 3 filer filer filer doc 1 doc 2 doc 3 3 3 3 3 3 3 UA UA UA text text text filing filing filing filing filing filing values values values values values values Most of the tagged data appears at the top of the submission prior to the text of the filing. The text of a document is indicated by the tag and marks the beginning of the official filing. Appendix A is a complete list of submission header data elements and document header data elements. Submission headers vary from submission type to submission type and not all data elements will be present in each submission. The list indicates which elements are required, optional or repeatable under the tagging scheme. Appendix B provides detailed information on the tagged data including a description of the value, length of the field, data characteristics, format and limits. 5.3.1 Financial Data Tabular data are included in the text of many documents. Tables wider than 80 characters will be tagged with the tags. Tables less that 80 characters wide may be tagged at the filer's discretion. Wide tables also have tagging requirements for the stub , column and caption portions. Individual pieces of data are tagged within the table with the appropriate tag. A list of acceptable financial tags is available in Appendix A. Note that filers generally use a word processing package to prepare their filings. Tables prepared utilizing control characters in the word processing package may lose their structure in the conversion to ASCII for transmission to the SEC. 5.3.2 Document Type Definition (DTD) Appendix C is a copy of the Document Type Definition (DTD). The DTD defines the rules that apply Standard Generalized Markup Language (SGML) to the markup of a particular type of submission. The DTD is available in electronic form upon request. 5.3.3 Submission and Form Types Appendix E provides a list of the public forms which are valid for the submission type value. Appendix F provides a list of the public forms which are valid for the document type value. Frequently a general form type will have a number of variations. For example, these are 5 variations on the form 10-K. 10-K Basic 10-K 10-KT 10-K filed by a company in transition due to a change in the end of the fiscal year NT 10-K 10-K filed late (not timely (NT)) NTN10-K Notice to file a late 10-K 10KSB 10-K filed by a small business In addition most form types may be amended by the filer in which case the revised submission is designated by a /A following the submission type, i.e. 10-K/A, 10KSB/A. 5.3.4 CIK Numbers The CIK or Central Index Key is a unique company identifier assigned by the SEC. Occasionally it is necessary for the SEC to send test filings through the Dissemination data stream. Those filings are identified by 3 test CIKs of 0000350001 or 0000828912 or 0000849486. These filings should also include language immediately following the tag which reads: "SPECIMEN-NOT AN OFFICIAL FILING" 5.4 Corrections to Data From time to time after the acceptance of a filing, corrections to that filing must be made. If a filer chooses to change or correct data within the text of a document, after it has been accepted by EDGAR and subsequently disseminated, the filer must submit an amendment to the filing which is processed and treated as if it were a new filing. A separate accession number is assigned to the submission and the value would reflect the original form type followed by /A. For example, an amendment to a 10-K would have 10-K/A in the field. Amendments to filings will be disseminated in the same manner as any other submission. There are occasions when the SEC must correct or change a piece of submission header data after the document has been disseminated. Five types of post-acceptance corrections submissions occur in the dissemination data stream. These are: Y filing correction Y filing transfer Y same accession # Y filing deletion Y document transfer In these cases the submission header and all associated document headers will be redisseminated with corrected data. Additional tags indicating will appear immediately following the tag at the start of the submission header. Following each tag is a tag which provides the date and time of the dissemination of the post- acceptance correction by EDGAR. There may also be additional tags marking the correction. The text of the submission will not be redisseminated. The number of filers in a single submission can vary from one upwards, depending on the type of submission. The number of filing values per filer can vary from zero to two and be different for each filer in a submission. The number of documents can also vary. Post-acceptance changes to a submission can affect both the overall structure of a submission shown above and can also change the values of fields in each part of the structure. 5.4.1 Filing Correction The filing correction only affects the values of fields within the submission structure and does not change the structure itself. Values for the following tags may be changed in a filing correction: , , , , , , , and . The dissemination file for the correction of a filing contains the submission header and all the document headers. There is no document text in the file. The document headers and text for this submission are unchanged by this type of transaction. The number and types of registrants, identified by , , and tags is unchanged. The number of file numbers, identified by tags, is also unchanged. However, the information within these nests, as well as the information for the whole submission may have changed and replaces the information previously disseminated. The tag values which can change are identified in the data usage matrix. The only tags in this type of post-acceptance correction not found in a normal submission dissemination file are the and tags at the start of the submission header. The tag values which are specified in the correction submission replace the tag value for the corresponding tag in the original submission. Thus the changes can be identified by comparison with the existing data held for that submission or all the data can be replaced by that in the correction submission header file. Note that in any type of post-acceptance correction, including the three defined in the following sections, a tag is present and any tag value defined as changeable in the Data Usage Matrix may have changed. 5.4.2 Filing Deletion The dissemination file for the deletion of all or part of a submission contains the submission header and all the document headers. There is no document text in the file. The document headers and text for this submission are unchanged unless the whole submission is deleted, when all documents and their text are also deleted. A filing deletion can represent the deletion of an act/file number, the deletion of a registrant or the deletion of a submission. The basic tagging structure to identify deletion transactions will have: Y a tag immediately following the tag; Y a tag immediately following the tag; Y a tag following either the tag, or a , , , tag or a tag. If the tag follows the tag then the whole submission is deleted. If the tag follows a , , or then that registrant is deleted. If the tag follows a tag then that file number/act is deleted. In all cases the rest of the submission header will be formatted as for a normal dissemination submission file. Examples of the file format and the changes in the structure of the submission for each of the three types of deletions are shown in Appendix I. 5.4.3 Filing Transfer The dissemination file for the transfer of a file-number/act from one registrant to another contains the submission header and all the document headers. There is no document text in the file. The document headers and text for this submission are unchanged unless the whole submission is deleted, when all documents and their text are also deleted. A filing transfer can produce several results from the perspective of dissemination of the filing: Y a filing values nest transferred from one registrant to a newly created registrant and the original registrant remains; Y a filing values nest transferred from one registrant to a newly created registrant and the original registrant is deleted; Y a filing values nest transferred from one registrant to an existing registrant and the original registrant still remains; Y a filing values nest transferred from one registrant to an existing registrant and the original registrant is deleted. The filing values nest is shown as deleted within the nest for the old registrant and as an addition within the nest for the new registrant. Thus the following tags are used: Y , after the tag of the filing values nest within the new registrant nest; Y , after the tag of the filing values nest within the old registrant nest; Y , after the /// tag of a registrant newly created to contain a transferred filing values nest; Y , after the /// tag of a registrant deleted because its last filing values nest is transferred to another registrant; Y , after the /// tag of a registrant which now contains a different number of filing values nests because one is transferred to or from another registrant. Note that the number of file number/acts after the filing transfer transaction remains the same, but the number of registrants can increase, decrease, or remain the same. The portion of the submission header before the first registrant tag is formatted as for a normal submission except for the addition of the and tags. The order of the various old and new registrant and filing value nests is not defined, but each registrant nest will appear only once and all filing value nests (deleted or added) will appear within that nest. Examples of the file format showing each of the tags used for filing transfer transactions and the submission structure changes represented by those tags are shown in Appendix I. 5.4.5 Document Transfer The dissemination file for the transfer of a document from one document type to another contains only the submission header and document headers. There is no document text in the file. Each document for which the document type has changed will occur in the file as a document nest containing the old information and a tag, and a document nest containing the new information and a tag. In addition, such submissions will have a tag immediately following the tag and a tag immediately following the tag. An example of the file format is shown in Appendix I. 5.5 Audit File The purpose of the audit file is to provide the receiver of disseminated public filings detailed information about the data on the dissemination tapes or at the end of the Broadcast day. The audit file will be the last file on the Level 1 tape or in the case of multiple Level 2 subsets will follow each of the appropriate subsets. There are audit entries for submissions, filing, corrections, filing deletions, filing transfers, and document transfers. Level 1 and 2 tape contain all filings received or are in the process of being received by the Dissemination Service at 5:30 each business day. An audit file will be built to reflect what is on the tape. The audit file for the Broadcast Subscriber is the audit file which was received from the SEC by dissemination. Description of Tags used in the Audit File DATA ELEMENT: AUDIT SUBMISSION TAG: DESCRIPTION: Denotes beginning of Audit Submission Entry. This tag is used only in submission transactions. LENGTH: Tag only. END TAG: DATA ELEMENT: AUDIT CORRECTION TAG: DESCRIPTION: Denotes beginning of Audit Post Acceptance Correction filing correction entry. LENGTH: Tag only. END TAG: DATA ELEMENT: AUDIT DELETION TAG: DESCRIPTION: Denotes the beginning of Audit Post Acceptance Correction filing deletion entry. LENGTH: Tag only. END TAG: DATA ELEMENT: AUDIT FILING TRANSFER TAG: DESCRIPTION: Denotes the beginning of Audit Post Acceptance Correction filing transfer entry. LENGTH: Tag only. END TAG: DATA ELEMENT: AUDIT DOCUMENT TRANSFER TAG: DESCRIPTION: Denotes the beginning of Audit Post Acceptance Correction document transfer entry. LENGTH: Tag only. END TAG: DATA ELEMENT: SEC ACCESSION NUMBER TAG: DESCRIPTION: Unique identifier for a submission. Required LENGTH: 20 CHAR: Alpha-numeric DATA ELEMENT: PUBLIC TAG: DESCRIPTION: Denotes public audit entry Submission or Post Acceptance Correction entry. Optional, required for public submissions and post-acceptance corrections. LENGTH: Tag only. DATA ELEMENT: SEC CHARACTER COUNT TAG: DESCRIPTION: EDGAR Dissemination file character count. Required LENGTH: 8 CHAR: Numeric DATA ELEMENT: SEC TIME STAMP TAG: DESCRIPTION: Timestamp when dissemination file was created by EDGAR. This timestamp should match with the timestamp included in the dissemination file. Required for each of the four types of post- acceptance correction audit entries. LENGTH: 15 CHAR: Date/Time FORMAT: YYYYMMDD:HHMMSS Every audit file entry will consist of one and only one of , , , , OR together with the corresponding end tag. Between these two tags will be an SEC Accession Number and SEC Character Count tag and their tag values. For the four post-acceptance correction tags there will also be an SEC time stamp tag with its tag value. For all audit file entries representing public submissions or post-acceptance corrections, there will be a Public tag. Examples of Audit Entries. Audit Entry for 1111111111-92-002002 3993 19920110:090817 Audit Entry for 1111111111-92-002002 3993 19920110:090817 1111111111-92-002002 3993 19920110:090817 1111111111-92-002002 3993 19920110:090817 1111111111-92-002002 3993 19920110:090817 6. Confirmation File Technical Specifications The purpose of the Confirmation File is to provide feedback to EDGAR on the dissemination status of output filings. For each filing received by the Dissemination Subsystem, a Confirmation Entry is written to the Confirmation File. A confirmation entry consists of a number of tags and data, describing the status of the dissemination file. Transactions Submission Post Acceptance Correction -filing correction -filing deletion -filing transfer -document transfer Description of Tags used in the Confirmation File DATA ELEMENT : Confirm TAG : DESCRIPTION : Denotes beginning of Confirmation Entry LENGTH : Tag Only END TAG : CHARACTERISTIC : NA LIMITS : NA FORMAT : NA DATA ELEMENT : SEC Accession Number TAG : DESCRIPTION : Unique Identifer for a submission. LENGTH : 20 CHARACTERISTIC : Alpha-Numeric LIMITS : NA FORMAT : NA DATA ELEMENT : SEC Build Timestamp TAG : DESCRIPTION : The time at which the original dissemination or post-acceptance correction file was built Matches the from the control block of the dissemination file and from the audit file entry. LENGTH : 15 CHARACTERISTIC : Date/Time LIMITS : YYYYMMDD:HHMMSS FORMAT : NA DATA ELEMENT : File Status TAG : DESCRIPTION : Denotes Status of dissemination file. LENGTH : 2 CHARACTERISTIC : Alpha-Numeric LIMITS : See SUBMISSION STATUS DESCRIPTION FORMAT : NA SUBMISSION STATUS DESCRIPTION The status consist of two characters. The first character indicates the transaction type that is being confirmed. The following transactions are allowed: Character Transaction S Submission P Post-acceptance correction correction D Post-acceptance correction deletion T Post-acceptance correction filing transfer X Post-acceptance correction document transfer The second character indicates the status of the transaction. The following status codes are allowed: Code Description Future Action * Dissemination file received correctly. None E Number of characters in the Dissemination Re-transmit dissemination file. file and the Audit entry for the dissemination file do not match. A Audit entry not received, but Dissemination Should not occur- contact Lexis- file successfully received today Nexis if it does. F Audit entry received, but no corresponding Re-transmit dissemination file Dissemination file successfully received. If successfully rec'd from S7 7 Error Recovery Procedures Error situations for Dissemination files sent from EDGAR to Dissemination fall into three categories: Transient online communications errors; Non-transient protocol errors Audit file mismatch errors; Data content error. Each of these error types is handled in a defined way during the operation of the EDGAR/Disemination link. This section describes those defined procedures. 7.1 Error situations Transient online communication errors will generally result in the abort of a file transfer and the automatic resend of that file. Such errors should be sufficiently rare that a transient error resulting in a protocol violation will not occur. If this should happen, however, the session will be aborted and restarted automatically. Non-transient protocol violations are due to software/specification errors and require manual intervention. Such errors should be extremely rare in a production environment and could result in communications being unavailable until software changes are made. Audit file mismatch errors such as non-matching byte counts and missing/lost files will result in an appropriate notation being made in the confirmation file. This may cause a retransmission of that file. If this is unsuccessful, manual intervention is required to determine the cause of the failure. The dissemination file may be provided on tape in most circumstances. In the case that software changes cause a valid dissemination file to be unavailable on tape, a decision will be agreed between EDGAR and Dissemination on the means to provide that file once that fault has been corrected. Data content error is due to software or specification errors. These will require manual intervention to determine the exact cause and solution. Once the problem has been corrected a method will be agreed between EDGAR and Dissemination on how to make the correct dissemination files available to Dissemination. This will be by tape or over the electronic link. 7.2 Retransmission processing There are five types of dissemination files built by EDGAR during normal processing: Submission, containing an original filing, which consists of a submission header, a document header of each public document, and the text of each document; Correction, when submission header information changes, which contains only the new submission header and each of the document headers; Deletion, when all or part of a submission is deleted, which contains the submission header and each of the document headers, including the deleted portions, with the deleted portions marked by delete tags; Filing transfer, when a filing is moved from one CIK to another, which contains submission header and each of the document headers, with both the old filer tag nest and the new filer tag nest, marked with the appropriate transfer tags; Document transfer, whereby a document is moved from one form type to another, contains the submission header and public document header- including both the old and new document headers. It will also be marked with the appropriate transfer tags. Each of the last four types of files contains a tag to identify that it is not an original submission, and may also contain other tags indicating deletions or transfer within the submission. They also contain a build timestamp identifying the date/time when the file was constructed by the EDGAR disseminator application. Every dissemination file is transmitted with a control block, which identifies the type of file (from the five listed above), the accession number and the build timestamp ( also other information). This information is used to uniquely identify the file in the audit and confirmation files used for reconciliation at the end of the business day. When a confirmation file entry indicates that a file may not have been correctly received, that file is retransmitted to Dissemination. The retransmission is of the exact file which failed and includes the original control block.