> 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-iseries-en/administracion-y-operacion/functional-features-of-onesait-editran-5.3.1/general-features.md). # General features In native mode 5.3.1, there are also general functions, specified in the profiles of the presentation sessions, and specific functions, determined by the converters used. General functions include, among others: * Subenvironment: In Profiles, it is possible to generate a General Local Environment and as many Secondary Local Environments (Subenvironments) as desired. In other words, we can present ourselves to other clients as several Entities * Ability to process from 1 to 99999 emission application files with fixed-length records. * A presentation session can use up to 20 editran transmission sessions, so the identification of the presentation application may not match that of the transmission application defined in editran. This also occurs in compatibility mode, although in this case there is only one transmission session in a presentation session. 6 alphanumeric characters are used for the transmission application. * The emission application information can be subjected to several optional presentation functions, such as cryptography, compression, CRC calculation and EBCDIC/ASCII translation, and is loaded into a single buffer or into up to 20 specific buffers, depending on the number of transmission sessions specified and the chosen splitting criterion. The records in the buffers are loaded completely with continuous character strings and with control information that allows remote Editran 5.3.1 to perform the presentation operations in reverse. * The presentation session number is tracked between two endpoints, so it is incremented with successive exchanges. This number will be passed to the "exchange session number" in the sending and receiving buffers, so transmission will not be allowed if it does not match at both ends. * The application will transmit to the remote side using the transmission sessions specified in local Editran, which must match those defined in remote Editran. In these transmission sessions, the presentation functions to be performed by the application could be defined, cryptography, compression and/or CRC, but it would not make much sense if they have already been carried out in the interface. * At the remote end, the information will be received in a matrix buffer or in up to 20 specific ones depending on the transmission sessions used. This information will include header data so that remote Editran 5.3.1 can check that the options used by the sender are consistent with those of the receiver, and information about the characteristics of the received information. The information in the reception buffer or buffers is unloaded into a single application reception file or into as many files as those used in the emission load at the other end, after having performed the presentation functions in reverse. Structure of the Emission and Reception Buffers Structure of the Buffer Files of an indexed file with a key length of 12, which is the Record Sequence Number (12 digits, consecutive and starting at number 1; number 0 is the Buffer File Control record). The physical record length of the Buffer can be 252 or 4050 for compatibility with different platforms and interfaces. Starting with editran versions 5.2, the physical record length of the Buffer will be 4050. The Control Record, whose key is the SESSION and Sequence Number is 0, contains the following data: * KEY: 12 bytes. * RESERVED-FOR-IGA: 26 bytes of BINARY ZEROS. * N-RECORDS-SENT: 12 bytes with the number of records already sent. * N-TOTAL-RECORDS: 12 bytes with the number of data and synchronization records in the buffer file. * N-RECORDS-CONFIRMED: 12 bytes with the number of records already confirmed by the receiver. * FULLY-TRANSMITTED: 1 byte indicating whether the entire file has been transmitted ("Y") or not ("N"). * RESULT-CODE: 2 bytes indicating the last event that occurred with this file (synchronization error, successful transmission, or total error). * TRANSMISSION-DATE: 6 bytes with the figures for the transmission start date in day/month/year format. * TRANSMISSION-TIME: 6 bytes with the figures for the transmission start time in hour/minute/second format. * LAST-CONFIRMATION-DATE: 6 bytes with the figures for the date of the last synchronization or end of transmission in day/month/year format. * LAST-CONFIRMATION-TIME: 6 bytes with the figures for the time of the last synchronization or end of transmission in hour/minute/second format. * BUFFER-STATUS: 1 byte indicating whether the file is available for editran ("Y"), for the Application Interface or User Procedure ("N"), or for neither ("I"). * RESERVED: 28 bytes reserved for future use. * CREATION-DATE: 6 bytes with the figures for the date the file was created by the Application Interface or User Procedure in day/month/year format. * CREATION-TIME: 6 bytes with the figures for the time the file was created by the Application Interface or User Procedure in hour/minute/second format. * LAST-INSERTION-DATE: 6 bytes with the figures for the date of the last data load or unload of the file by the Application Interface or User Procedure in day/month/year format. * LAST-INSERTION-TIME: 6 bytes with the figures for the time of the last data load or unload of the file by the Application Interface or User Procedure in hour/minute/second format. * COPY-IN-RECEPTION1: 24 bytes. * FILLER1: 12 bytes of BINARY ZEROS. * LAST-SYNC-SENT-REC-KEY: 12 bytes corresponding to the Sequence Number of the Sent Synchronization Record. * LAST-SYNC-CONFIRMED-REC-KEY: 12 bytes corresponding to the Sequence Number of the Confirmed Synchronization Record. * LAST-EXCHANGED-SYNC-KEY: 12 bytes corresponding to the Sequence Number of the Confirmed Synchronization Record of the previous Transmission. * FILLER2: 12 bytes of BINARY ZEROS. * EXCHANGE-SESSION-NUM: 4 bytes indicating the Transmission Sequence Number (which makes it possible to track the sequence of transmissions carried out, avoiding transmission losses and duplicates). * COPY-IN-RECEPTION2: 6 bytes. * Remaining: 4 or 3798 bytes without meaning The FILLER fields (1 and 2) are old fields used by the totals control application and which editran V2.2 and V3.1 no longer support. The Data Records, whose key is the SESSION and the Record Sequence Number (correlative from 1 to the Total Number of Records in the transmission), can have two different formats depending on whether it is a Data record or a Synchronization record, when the SESSION uses the Application Synchronization facility (Totals Control type or Batch or Application Synchronization). The fields are as follows: * KEY: 24 bytes. * Application Synchronization Record. * RESERVED HEADER: 2 bytes. * SYNCHRONIZATION HEADER: 12 bytes with synchronization information. * BUFFER RECORD TYPE: 1 byte indicating synchronization record or X'01' for Batch or Application Synchronization. * REST OF HEADER: 23 bytes; for Batch or Application Synchronization it contains user information. * SYNCHRONIZATION DATA: 202 or 4000 bytes with the user information. * Data Record. * DATA: 4038 bytes with the user information. The Logical and Physical Name of the Buffer File can be whatever is desired, and this name is one of the SESSION parameters. --- # 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-iseries-en/administracion-y-operacion/functional-features-of-onesait-editran-5.3.1/general-features.md?ask=&goal= ``` `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.