View source for Category:File Operations

==File Types: Display, Internal And External==

Business Rules differentiates between three different file types: [[Display Files|display]], [[Internal Files|internal]] and [[External Files|external]]. Each of these file types facilitates different kinds of programming tasks. This section provides a comparison of the different file types and should help you in determining which is the best file type for a particular task.

Communications files are not specifically addressed in this section because they are considered a type of display file. For information about the special characteristics of communications files, see the [[OPEN communications]] statement and [[Communications]].

Cross platform I/O is now supported.  This means you can read and write data and indexes on both Intel and Risc platforms from either platform.

Also see [[File Types Comparison]] for more information.

===Long File Names===
When you specify a file name or a font name there is a tendency to enclose it in quotes, especially if it contains embedded spaces. DON'T do so in OPEN statements.

In the case of file names, single quotes are permitted as part of the name such as 'Mary's letter to Jim'. BR forwards the fully quoted name to the operating system. If double quotes are used, Windows will reject the name as invalid. If single quotes are used they will be regarded as part of the name.

As for font names, the quotes are also passed to the operating system, in which case it won't find the font and will use the next best alternative (usually the default). No error is generated because BR doesn't know it is invalid until the window is opened, and font selection is quite forgiving.

The only time you should enclose a file name with embedded spaces in quotes in BR is for commands like COPY or DIR.

==Display Files==
{{:Display Files}}

==Internal Files==
{{:Internal Files}}

==External Files==
{{:External Files}}

===File Processing: New, Use, Replace Parameters===
The NEW, USE and REPLACE parameters, along with an independent default, are available in the Business Rules display, OPEN internal and OPEN external statements. These parameters indicate whether the file being opened is to be newly created or whether it should be an existing file. This section describes the actions of each of the four options. Each of the four options (NEW, USE, REPLACE and the default) follows a two-level action plan, as described in the chart below:

[[Image:NewUseReplace.png|450px]]

In short, the USE and REPLACE parameters will open a file whether the file already exists or not. Errors will be generated by NEW and by the default of using the old file if their first action is unsuccessful. These errors (4150 and 4152) can be trapped using the IOERR error condition. IOERR may either be coded at the end of the OPEN statement or in an ON IOERR statement that gets executed before the OPEN statement.

The following paragraphs describe each of the four options in detail:

;DEFAULT:
When the default is selected, Business Rules attempts to use an existing file. If the specified file does not exist, error code [[4152]] results. Selecting the default is different from selecting the USE parameter in that USE will create a new file (rather than generate an error) if its attempt to open an existing file fails.

;NEW:
When the NEW parameter is specified, Business Rules attempts to create a new file. If a file under the specified name already exists, the attempt will fail and error code [[4150]] will result.

;USE:
When the USE parameter is specified, Business Rules attempts to use an existing file. If an existing file by the specified name does not exist, however, Business Rules creates a new file.

;REPLACE:
When the REPLACE parameter is specified, Business Rules first attempts to create a new file. If this is unsuccessful because a file by the specified name already exists, Business Rules will free the existing file and then create a new file under the same name. Business Rules will not warn the user that it is replacing an existing file when REPLACE is used.

;I/O with the [[TRANSLATE]]= parameter<br>
The TRANSLATE= parameter is available in four of the Business Rules OPEN statements (for display, internal, external and communications files). This optional parameter allows the translation of data to or from another collating sequence.

===About Collating Sequence===
Internally, all computers represent letters of the alphabet, punctuation marks and even digits according to an arbitrary numbering scheme. Two of the most popular coding schemes are ASCII (American Standard Code for Information Interchange) and EBCDIC (Extended Binary Coded Decimal Interchange Code). Probably the most common use of the TRANSLATE= capability is translating files between ASCII and EBCDIC.

An example of the difference between ASCII and EBCDIC is that the uppercase letters A, B and C are represented by 65, 66 and 67 respectively in ASCII; but in EBCDIC, they are 193, 194 and 195. Also, in ASCII, the blank or space character is represented by the number 32 while in EBCDIC it is number 64. Although all systems that currently run Business Rules the ASCII coding scheme, some computer systems (including most IBM mainframe computers) use EBCDIC.

===Enhancements===
Cross platform I/O is now supported.  This means you can read and write data and indexes on both Intel and Risc platforms from either platform.  

Files larger than 2GB are supported. The maximum file size is 4611,686,018,427,387,903 bytes. This will handle a lot of recipies.

[[OPTION]] 33 must be on to invoke this feature. It has been tested using TCP/IP only. We expect NetBui and some versions of IPX to fail above 2GB. This option will fail in Windows 95, 98 and ME.

OPTION 33 is now supported in Linux. Therefore we will be numbering
Linux releases ending with the digit 3 (e.g. 4.03, 4.13).

==Format Specifications==
[[Format specifications]] tell Business Rules the form that a particular data field will be in. A format specification is required whenever data is input into or output from a program. It is also required with the full screen processing statements. Format specs are not required in the following situations: with unformatted internal files, with all display files, and when unformatted PRINT statements are used.

Not all format specifications are alike in their uses. Some can be used with internal and external files, but not with display files. Some can be used only with full screen formatting. And some format specifications behave differently depending on whether they are used for input or output.


===B Format Specification===
{{:B}}

===BL Format Specification===
{{:BL}}

===BH Format Specification===
{{:BH}}

===C Format Specification===
{{:C}}

===CC Format Specification===
{{:CC}}

===CL Format Specification===
{{:CL}}

===CR Format Specification===
{{:CR}}

===CU Format Specification===
{{:CU}}

===D Format Specification===
{{:D}}

===DT, DH and DL Format Specification===
{{:DT}}

===FMT Spec===
{{:FMT}}

===G Format Specification===
{{:G}}


===GF Format Specification===
{{:GF}}

===GL Format Specification===
{{:GL}}

===GU Format Specification===
{{:GU}}

===GZ Format Specification===
{{:GZ}}

===L Format Specification===
{{:L}}

===N Format Specification===
{{:N}}

===NZ Format Specification===
{{:NZ}}

===PD Format Specification===
{{:PD}}

===PIC Format Specification===
{{:PIC}}

===S Format Specification===
{{:S}}

===V Format Specification===
{{:V}}

===VL Format Specification===
{{:VL}}

===VU Format Specification===
{{:VU}}

===ZD Format Specification===
{{:ZD}}

===Unformatted File Operations===
====Applications====
:READ, REREAD, WRITE, REWRITE

====Description====
Reading and writing to internal files can be done without using a FORM statement and is called unformatted file I/O. Data records which are written without a FORM statement must contain extra control characters that specify the number of data items in the record and the length of each data item in the record.

====Benefits====
Unformatted I/O is useful for reading and writing to files that contain control information such as company name, date of last posting, etc. Some additional benefits are as follows:
#) The lengths of the fields can be freely changed.
#) Fields may be added to the end of the record without affecting the statements that read the record.
#) If lengths of variables differ, the variable field length aspect of unformatted I/O often results in a larger number of fields per record than would be possible with formatted I/O.
#) Unformatted I/O is faster than formatted I/O.
#) Formatted and unformatted records may be mixed in a file, but this is not recommended.

====Drawbacks====
The control codes used for unformatted I/O increases the record length. Sorts on unformatted files are usually not possible because data fields are not in a fixed position.

====Sample usage====
The following is an example of unformatted I/O which reads a table of G/L accounts and totals from a control file:

 00030 OPEN #1: "NAME=CONTROL", INTERNAL,INPUT,RELATIVE
 00040 DIM ACCOUNT$(10), TOTAL(10)
 00050 READ #1,REC=5: MAT ACCOUNT$, MAT TOTAL

Using formatted I/O to achieve similar results as above would require a change to line 50 and the addition of line 60, as follows:

 00050 READ #1,USING 60,REC=5: MAT ACCOUNT$, MAT TOTAL
 00060 FORM 10*C 8,10*L

====Record structure====
Each time an unformatted record is written or rewritten with unformatted I/O, every item in the record must be output. The [[WRITE]] and [[REWRITE]] statements start at the beginning of the record and output variables in a specific format.

The first two bytes in an unformatted record are in B (binary) format and contain a count of the number of fields in the record (see the example below). The next byte in the record identifies the length of the field that immediately follows it. The record continues with a pair of fields (the length followed by the data field) for each field in the I/O statement.

When string variables are longer than 255 characters, Business Rules assumes they will be followed by a two-byte field that contains the string length. Numeric variables are output in D floating point format and require eight bytes. When reading numeric variables in an unformatted record, the length of the field must be eight bytes, or a formatting error (0726) will occur. 

The following statement generates the sample record format below it:

 00040 WRITE #1: "XXX",55,"YY",100,200

[[Image:UnformattedRecord.png]]

====Technical considerations====
:1.) The field length for string variables is determined by the string length being written (the value returned by the LEN function), not the defined length.
:2.) All previous variables must be read before a variable in the middle of an unformatted record can be read. The statement READ #1: X$,X$,X$, when referring to a record created by the following program line, would cause the system to read "XXX" and 55 before accessing "yy":

 00040 WRITE #1: "XXX",55,"YY",100,200

In the above example, X$ would contain "YY" at the end of the read. The two previous fields are read into X$, but each value is replaced by the next. Note that the numeric variable can be read into a string field, as can be done with formatted I/O.

:2.) B1 fields represent field length, which is limited to 127 characters. Internally, B1 fields are unsigned. B1 fields greater than 127 will show up as negative.