DEVICE=Devicename Pathname
DEVICE=Devicename:[Proj,Prog] Pathname
The DEVICE directives allow you to map DevPPN files to Unix- or Windows-style paths. There are two variations of this mapping operation.
| • | The first, and most common, maps an DevPPN-style logical disk (e.g. DSK1:) to a base directory (e.g. /vm/miame/dsk1/). The PPN equivalents are then set up as subdirectories of this base directory using the format <base directory>/pppnnn (corresponding to <logical disk:>[ppp,nnn]). |
| • | The second variation overrides the implicit PPN subdirectory scheme just described, by specifying a complete and explicit directory to be associated with a specific devn:[ppp,nnn]. |
As an example, consider the following two DEVICE statements:
DEVICE=DSK1:[31,3] /usr/include/
DEVICE=DSK1 /vm/miame/dsk1/
on a Unix-based machine. Together, these statements would be used by A-Shell / MIAME to map the specification dsk1:test.dat[31,5] onto the path /vm/miame/dsk1/031005/test.dat.
The file name is mapped onto lower case. Unix treats case as significant in filenames, whereas AMOS does not, so in keeping with the Unix norm all filenames must be converted to lower case regardless of the case used inside of your source programs or in arguments to LIT utilities (e.g. DIR.LIT).
However, the file specification DSK1:TSTCPY.CPY[31,3] would instead be mapped onto the pathname /usr/include/tstcpy.cpy, since it matches the first DEVICE statement.
Note that in both cases, the host pathname must terminate with a directory separator character. Failure to do this will cause unexpected results.
In Windows network environments, you can substitute UNC-style names (Universal Naming Convention) in place of the DOS drive letter in these DEVICE statements. For example:
DEVICE=DSK1 f:\vm\miame\dsk1\
DEVICE=DSK2 \\kahuna\ashell\dsk2\
In the first DEVICE directive, logical device DSK1: is defined as being on the F: drive (which presumably is a mapped network drive.) In the second, DSK2: is defined as being at a location defined by the share name "ashell" on the server named "kahuna". The advantage to the UNC approach is that it eliminates the need to map the same (or any) drive letter on each client workstation to the server, thus simplifying the setup of client workstations in a network. The only known downside to this approach is that due to a bug in Windows 95, SYSTAT will not be able to report the number of free blocks on any device which is defined this way. But this is a relatively minor concern, and the bug is fixed in later versions of Windows.
Although not recommended, if you insist on mapping DevPPN-style devices to directories that contain spaces, you can do so by enclosing the directory specification in quotes, as in this example:
DEVICE=XYZ0:[1,1] "C:\Program Files\COOL.STF\ZTERM For Windows\"
It should be noted that due to the automatic generation of pathnames from PPNs, and because DevPPN-style filenames are restricted to fourteen (10.3) characters (as well as the case problem under Unix) there are many files that cannot be accessed via an DevPPN file specification. This mapping of an DevPPN file specification (using the definitions described here) is performed by the fspec2host() function. To solve the file-inaccessibility problem, if the DevPPN specification passed to fspec2host() contains a directory separator character ( / or \ ) then no attempted mapping to a pathname takes place. Under A-Shell, programs could be written to directly manipulate any files on the system (file protection permitting), for example:
open #1,"c:\autoexec.bat", input
..
In order to access a file in the current working directory whose name doesn't fit the 10.4 limit, or which contains upper-case characters or no extension under Unix, then it is necessary to specify a path containing the current directory symbol ".", for example:
kill "./core"
The following special form of the DEVICE directive may be used to define a device that references user memory:
DEVICE=MEM: MEM:
Technically, you could use any device name for the logical name (the first MEM:) but the physical name (the second MEM:) must be MEM: (in upper case, with the colon on the end).
If you already have a PPN-specific MEM: or MEM0: device defined, then it must be defined first, i.e.:
DEVICE=MEM0:[1,1] /tmp
DEVICE=MEM: MEM:
Make sure there is no MEM: in your ersatz.ini file. (ERSATZ devices are processed first.) Obviously, if you are using the MEM: ersatz, you will want to make other arrangements. However, it you are too committed to using MEM: as an ersatz disk device, then you could use some other logical name to refer to user memory. For example, DEVICE=RAM: MEM: would define a logical device named "RAM:" which referred to the physical device MEM: (user memory).
Notes
Only those devices defined explicitly with a DEVICE line are allowable in an DevPPN file specification. All others will report Device does not exist or Invalid filename messages, depending on the context.
If the configuration file contains both full device/PPN definitions and a default device definition for a given drive, then the full device/PPN definitions must appear first.
Under Windows, the host pathname may include the drive letter and a colon at the start, followed by the full pathname beginning (and ending) with a directory separator character; or, it may use the UNC format \\server\sharename\path\.
Symbolic links
In the Unix environment it is possible to create symbolic links to directories such that a single directory might be accessible by two (or more) paths. To fully accommodate this situation, you may want to define the same DEVICE multiple times for the different names, so that in situations where A-Shell may need to translate from the native directory (or alias) to the DevPPN-style equivalent, it will find the native directory, regardless of which alias is being used. For example, if you have a symbolic link from /vm/sites/xyz to /vm/miame, then the following DEVICE statements might apply:
DEVICE=DSK0 /vm/miame/dsk0/
DEVICE=DSK0 /vm/sites/xyz/dsk0/
The first entry will be the one used whenever translating from an DevPPN-style spec to native; the second one would come into play only when reverse-translating from a /vm/sites/xyz/dsk0/... native directory back to DSK0:. See "Issue when using symbolic link" on the A-Shell forum for further details.
Caution
If you use DEVICE to define specific a specific PPN (as opposed to entire DSKs), make sure that the PPN so defined does not also exist in the location defined for the DSK. If you create a situation where the PPN exists twice, then DIR will display the files in both locations. This is a special case of a larger problem with DIR, in that DIR scans the raw directory, then for each entry found, tries to display it as if it were an DevPPN file, using a backwards translation from the raw directory spec to the DevPPN equivalent. This causes DIR to find things, both files and directories, that might otherwise not be quite what was intended by a particular set of DEVICE definitions. The only solution would be to then do another forward translation of the found DevPPN spec back to the native spec to compare when that native spec matched the one found by DIR, but that would slow DIR down considerably.
Examples
For both Windows and Unix, the host pathname may contain system environment variables, using the syntax %VAR%:
DEVICE=USR0:[1,1] %HOME%/
DEVICE=TMP0:[1,1] %TMP%\
DEVICE=DSK0 %MIAME%\dsk0\
The first example makes USR0:[1,1] map to the current user's home directory (assuming that the environment variable HOME was defined by the user's shell). Note that even though the normal syntax for environment variables under Unix is $VAR, A-Shell uses %VAR%.
The second example makes TMP0:[1,1] map to the user's TMP directory (in this case assuming that the TMP environment variable was defined on the PC, either for the machine or for the login user).
The last example illustrates that the environment variable can be combined with other static elements.
