The ŒFCREATE function creates a new component
file, and leaves it tied. The syntax
is:
FILENAME ŒFCREATE TIENO
FILENAME is a character vector specifying the name of
the file to create. The name may be specified in either of two ways. If the name contains a directory-separator
character (: / or \), it is treated as a full host path name, and you need to specify the file
extension explicitly, usually .aqf. Otherwise it is treated as basic file name
only, optionally preceded by a volume number 0 to 9, separated by one or more
spaces from the name. In the latter
case, the file is created in the directory 0 to 9 specified (the actual path is
set using the preferences dialog or ŒMOUNT),
and the file extension .aqf is added
automatically.
TIENO is an arbitrary non-zero integer to be used
in subsequent read/write operations to identify the file (the tie is
exclusive). The tie number must not currently be in use to tie another
file. Alternatively, you can provide a
tie number of 0, in which case APLX automatically allocates the next available
unused tie number, and returns it as the explicit result of the function.
For example, suppose APLX is running on a Windows machine
and the ŒMOUNT table is set
(either under program control or using the Preferences dialog) so that library
0 is in c:\temp and library 1 is in m:\budget\current:
2 30†ŒMOUNT '' c:\temp m:\budget\current
You could create a new file called RUN3
in c:\temp as
follows (no directory separator character appears in the name, so it is taken
as a simple file name in library 0):
'RUN3' ŒFCREATE 2
(Using a left argument of '0 RUN3' would be equivalent). The file is created, and then exclusive-tied
on tie number 2, so you can write to it immediately:
ŒFNUMS 2 ŒTS ŒFWRITE 2
The full operating-system path would be c:\temp\RUN3.aqf.
In this second example, the user has specified 0 as the tie number, so APLX
allocates and returns the next available tie number. The file is created in library 1, so the full operating-system
path would be m:\budget\current\RUN4.aqf:
'1 RUN4' ŒFCREATE 0 3 ŒFNUMS 2 3
In this third example, a full path name has been supplied, with an explicit tie number
of 8, so we now have three files tied:
'c:\temp\RUN4.aqf' ŒFCREATE 8 ŒFNUMS 2 3 8 ŒFNAMES RUN3 1 RUN4 C:\TEMP\RUN4.aqf
(Under Linux or AIX, the full path name might be something
like /usr/tmp/RUN4.aqf. Under MacOS, it might be something like Macintosh HD:temp:RUN4.aqf).
Note that, if you specify a full file name, you can use any
file extension (or none). However, we
recommend that you always use .aqf for
APLX ŒFxxx component files. If you do not use the .aqf
extension, your component files will not show up in ŒFLIB, and you will not be able to access
them using the library-relative syntax.
In Client-Server implementations of APLX, the front-end which implements the user-interface (the "Client") runs on one machine, and the APLX interpreter itself (the "Server") can run on a different machine. The two parts of the application communicate via a TCP/IP network. Typically, the Client will be the APLX front-end built as a 32-bit Windows application running on a desktop PC, and the Server will be a 64-bit APLX64 interpreter running on a 64-bit Linux or Windows server.
In such systems, you can specify whether the file should be accessed on the Client or the Server machine. You do this by preceding the file name with either an Up Arrow † to indicate that the file should be accessed on the Client, or a Down Arrow ‡ to indicate that it should be accessed on the Server. If you do not specify, the default is that the access takes place on the Client. This is true either if you specify the full path name in the ŒFCREATE call, or via the ŒMOUNT table.
If you are running both 32-bit and 64-bit versions of APLX, then it is possible to share component files between the two architectures, but there are some special points you should be aware of. See the introduction to the ŒFxxx Component File System for details.