> 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-cics-en/definition-and-management-of-buffer-files/description.md).

# Description

## Specific <a href="#toc149127349" id="toc149127349"></a>

Contains a single transmission session.

It only needs to be defined to CICS since it is editran/G who defines and deletes it.

Editran manages concurrency between batch and CICS processes, keeping it closed to CICS when editran/G uses it and preventing it from being modified in batch when editran/P uses it.

It is the buffer to use whenever possible because, since it contains data for a single session, it is a non-shared resource; therefore, the session it belongs to does not have to compete for it with other transmission sessions either at load/unload time or at transmission time.

Its only drawback is having to define one buffer file in CICS for each transmission session.

In any case, it is highly recommended to use this type of buffer for sessions with a large amount of data or with some urgency in their transmission.

## Matrix SHR (3,3) <a href="#toc149127350" id="toc149127350"></a>

It can contain more than one transmission session.

It is convenient for it to be physically defined by the user; in any case, editran/G defines it if it does not exist.

It is used simultaneously by both batch processes and CICS processes. To make this concurrency possible, it must be defined as SHR (3,3), so VSAM transfers responsibility for process concurrency control to the application.

Editran performs this concurrency control through system ENQ-DEQ, not allowing it to be used by more than one process at a given moment.

Its great advantage is that it is not necessary to define a buffer file in CICS for each transmission session, but a single definition can serve a large number of them.

Its drawback is that the processes of the transmission/presentation sessions must wait for one another, with the consequent delay in processing.

To minimize the need for these processes to wait for one another, it is recommended that a matrix buffer be assigned to sessions whose processes are unlikely to be concurrent.

These buffers are recommended for installations with a large number of transmission sessions, with sessions containing a small volume of data for each one, or that are not concurrent with one another.&#x20;

## Unattended <a href="#toc149127351" id="toc149127351"></a>

It can contain more than one transmission session.

It is necessary to define it to CICS and it must be physically defined by the user.

Since it is defined as SHR (2,3), it cannot be modified from two processes simultaneously. In this case, it is the user who is responsible for preventing concurrency between batch processes and between these and CICS processes. In other words, it can only be used by one batch process at a time and when CICS transactions are using it, it cannot be updated in batch.

Editran/G does not "allocate" or "deallocate" this type of buffer, so it must be included in the procedure to be executed with the ddname: TAMPON01.

If there are more sessions to load or prepare for reception, it is not possible to directly request transmission or reception since this function opens the buffer file to CICS directly and the next transmission or reception request would find the file open to CICS. In other words, you must request loading or reception initialization. If you want to take the initiative in the transmission, the transmission or reception request will be made when the sessions are in sending or receiving state.

It has the advantage of containing several transmission sessions and that at the moment of sending/receiving the transactions associated with the different transmission sessions can access the file simultaneously, provided that the control interval managed by VSAM is respected.

It has the drawback of not supporting concurrent batch processes with one another or with CICS processes and of requiring strict control by the user.

It is recommended when the load/initialization process for receiving the sessions is unique and at a different time from transmission. Subsequent processes may be simultaneous as long as the buffer data is not to be deleted at the end of the process.  &#x20;

## Matrix SHR (2,3) <a href="#toc149127352" id="toc149127352"></a>

It can contain more than one transmission session.

It is necessary to define it to CICS and it must be physically defined by the user.

Since it is defined with SHR (2,3), it can only be modified by one batch process and must be closed to CICS during that process. It can be used by several CICS transactions concurrently.

Concurrency between batch processes and CICS must be controlled by the user. Concurrency between CICS transactions is controlled by CICS itself and VSAM.

They have the same advantages and drawbacks as Unattended buffers, with the difference that in this case it is not necessary to specify the buffer in editran/G procedures since they are "allocated" and "deallocated" in the process.

## EXCI <a href="#toc149127353" id="toc149127353"></a>

Recommended. It can contain more than one transmission session.

It is necessary to define it to CICS and it must be physically defined by the user. It also requires the definition of two EXCI connections, one public and one private.

Defined as SHR (2,3), used simultaneously by several processes, but always from the CICS region, either from editran/P or editran/G via EXCI, for which the CICS region must be started.

Process concurrency is the responsibility of CICS and VSAM. With this system, the degree of concurrency of both editran/P and editran/G processes is considerably increased.

Its advantage is that only a few files need to be defined to CICS and that concurrency is optimized by CICS and VSAM.

Its drawback is having to define the EXCI connections and needing CICS to be started in order to process the buffers in editran/G.&#x20;

## Public <a href="#toc149127354" id="toc149127354"></a>

This type only makes sense in the sending process.

Contains more than one transmission session.

Its data structure is different from the rest of the buffers. It contains as many control records as transmission sessions it has associated and a single set of data records that belong to each of the transmission sessions.

Editran/P transmits the same set of data in all transmission sessions.

Editran/G does not handle this type of file, so it must be loaded by a user application.

Concurrency control is the same as in the matrix buffer.

## Recommendations <a href="#toc149127355" id="toc149127355"></a>

The most optimal approach is not to define a buffer for each transmission (specific), since this forces us to increase the number of buffers as we increase our customers.

Matrix and EXCII buffers are identical in terms of content; the only difference is that in the former, simultaneous accesses (JCL-CICS) are resolved through enq-deq by program, whereas in the latter this problem is resolved by VSAM (since JCL opens a connection to CICS and works on the file in a CICS transid). For the above reasons, the use of EXCII files is much more recommended.

Perhaps a fairly optimal system would be:

1. For sessions with very large or critical transmissions, define a specific buffer.
2. For the rest, define n EXCII buffers, for sending and receiving. Assign a certain EXCII buffer to sessions whose load-unload-transmission does NOT overlap in time. Remember to define EXCII with a space size appropriate to the number of transmission sessions you have and to the space occupied by their application files. Remember to maintain this type of file (reorg).


---

# 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-cics-en/definition-and-management-of-buffer-files/description.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.
