On MPE/iX systems, ACUCOBOL-GT can handle references to files, groups, and accounts in the traditional MPE syntax, e.g., FILE1.PUB.SYS. When an ACUCOBOL-GT program attempts to access a KSAM file, the runtime expects the filename to be in MPE syntax. The runtime treats the filenames of other file types differently.
If the file being accessed is not a KSAM file, the runtime first assumes that the filename is in Hierarchical File System (HFS) syntax. For example, if FILE1.PUB.SYS is referenced in your program, the runtime looks in the current directory for a file named "FILE1.PUB.SYS". If the file is not found, the runtime assumes that the filename is in traditional MPE/iX syntax. It then converts the name to HFS syntax and tries again to find the file. For example, FILE1.PUB.SYS is converted to /SYS/PUB/FILE1.
In addition to ACUCOBOL-GT's built-in method of establishing filename aliases via the runtime configuration file, ACUCOBOL-GT also supports file aliases created with the MPE/iX "FILE" command. See File Name Assignments for more information. FILE equations and runtime configuration file entries provide a simple and flexible way to map logical names to physical files.
If you plan to migrate your application to another host and your application makes use of FILE equations, unless you will use an MPE emulator on the new host you will have to use other methods to accomplish file attribute specification and filename aliasing. Precisely what is required will vary depending on the host operating system. ACUCOBOL-GT always supports the following mechanisms:
If you plan to deploy your application with our thin client technology, there is an additional consideration. Frequently, thin client applications are initiated with a common (shared) runtime configuration file. However, this approach prevents unique users from getting unique environment settings (such as those provided by FILE equates). A recommended solution is to prepare unique runtime configuration files for every user (or group of users), and to place those configuration files on the application server. The program is then modified to get the name of the user on startup and to then load the appropriate configuration file using the C$CONFIG library routine.