> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-comun-z-os-en/editran-sepa/descripcion-de-la-funcionalidad/uso-de-listas-de-ficheros-por-onesait-ecosystems-editran.md).

# Use of file lists by Editran

The product allows the transmission of multiple files in the same session.

To send:

* Some customers use a file list (ZTBGFCAR, see format Table 1) to perform the uploads, since their files have different names in each one. Therefore, they create a daily list of files for each presentation to be sent. This list is passed to the step prior to sending. Normally, in order to use a single procedure with all remotes, the dsname of the file list is formed with variables recognizable by the procedure (source, remote, and application).
* Other customers always use the same dsnames for the files to be sent (the content is different in each transmission), so they choose to indicate the dsname of the files to be sent in the product profiles themselves.

To receive:

* If nothing is indicated in the application's profiles, it downloads the received files with a default name
* If something is indicated in the application's profiles, it downloads the received files with the indicated name
* In all cases, the post-reception step, ZTBGLFE, provides the user with a file, which is a list of received and downloaded files (ZTBGFLFE, see format TABLE 2)

Table 1. Content of the ZTBGFCAR file, a fixed-length file of 80, whose contents are the application's send files and their characteristics. The content is as follows (one record per file):

<table data-header-hidden><thead><tr><th width="75.32501220703125" valign="top"></th><th width="197.1358642578125" valign="top"></th><th width="75.3250732421875" valign="top"></th><th width="67.9178466796875" valign="top"></th><th width="364.345458984375" valign="top"></th></tr></thead><tbody><tr><td valign="top">Level</td><td valign="top">Name</td><td valign="top">Length</td><td valign="top">Type</td><td valign="top">Description</td></tr><tr><td valign="top">1</td><td valign="top">File format</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top"><p>Application file format:</p><p>‘R’: Record, ‘M’: Modified</p></td></tr><tr><td valign="top">1</td><td valign="top">Source data language</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top"><p>Original language of the data:</p><p>‘A’: Ascii, ‘E’: Ebcdic, ‘B’: Binary</p></td></tr><tr><td valign="top">1</td><td valign="top">Translate on send</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top"><p>Language in which the data is sent:</p><p>‘A’: Ascii, ‘E’: Ebcdic, ‘N’: No translation</p></td></tr><tr><td valign="top">1</td><td valign="top">Compression</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top"><p>Compression:</p><p>‘F’ Compressed, ‘N’ Uncompressed</p></td></tr><tr><td valign="top">1</td><td valign="top">Filler</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top">Separation space</td></tr><tr><td valign="top">1</td><td valign="top">Physical name</td><td valign="top">74</td><td valign="top">Alphan.</td><td valign="top">Physical name of the application file</td></tr><tr><td valign="top">1</td><td valign="top">Filler</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top">Separation space</td></tr></tbody></table>

Table 2. Content of the ZTBGFLFE file (list of received files, which the post-reception procedure currently leaves), fixed-length 130. The content is as follows (one record per file):

<table data-header-hidden><thead><tr><th width="60.111083984375" valign="top"></th><th width="136.4322509765625" valign="top"></th><th width="71.3951416015625" valign="top"></th><th width="79.0123291015625" valign="top"></th><th valign="top"></th></tr></thead><tbody><tr><td valign="top">Level</td><td valign="top">Name</td><td valign="top">Length</td><td valign="top">Type</td><td valign="top">Description</td></tr><tr><td valign="top">1</td><td valign="top">File area</td><td valign="top">130</td><td valign="top">Alphan.</td><td valign="top"></td></tr><tr><td valign="top">2</td><td valign="top">Physical name</td><td valign="top">44</td><td valign="top">Alphan.</td><td valign="top">Physical name of the downloaded application file</td></tr><tr><td valign="top">2</td><td valign="top">Filler</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top">Separator dash</td></tr><tr><td valign="top">2</td><td valign="top">Presentation-end date</td><td valign="top">14</td><td valign="top">No.</td><td valign="top">Presentation end date-time in YYYYMMDDHHMMSS format</td></tr><tr><td valign="top">2</td><td valign="top">Loaded file type</td><td valign="top">4</td><td valign="top">No.</td><td valign="top"><p>Loaded or output file type</p><p>‘FIXED’</p><p>‘VBLE’</p><p>‘VEXP’</p><p>‘BINA’</p></td></tr><tr><td valign="top">2</td><td valign="top">Loaded data language</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top"><p>Language of the loaded data:</p><p>‘A’: Ascii, ‘E’: Ebcdic, ‘B’: Binary</p></td></tr><tr><td valign="top">2</td><td valign="top">Compression</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top"><p>Indicates whether the file was loaded with compression:</p><p>‘F’ Compressed, ‘N’ Uncompressed</p></td></tr><tr><td valign="top">2</td><td valign="top">Filler</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top">Reserve area</td></tr><tr><td valign="top">2</td><td valign="top">Source physical name</td><td valign="top">44</td><td valign="top">Alphan.</td><td valign="top">Physical name of the application file at source</td></tr><tr><td valign="top">2</td><td valign="top">App file bytes</td><td valign="top">12</td><td valign="top">No</td><td valign="top">Application file bytes</td></tr><tr><td valign="top">2</td><td valign="top">Record length</td><td valign="top">6</td><td valign="top">No</td><td valign="top">LRECL.</td></tr><tr><td valign="top">2</td><td valign="top">Filler</td><td valign="top">1</td><td valign="top">Alphan.</td><td valign="top">Reserve area</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-comun-z-os-en/editran-sepa/descripcion-de-la-funcionalidad/uso-de-listas-de-ficheros-por-onesait-ecosystems-editran.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
