Revised August 2025
DEVICE=devn basedir/
DEVICE=devn:[p,pn] dir/
DEVICE = devn:[] dir
The DEVICE directives allow you to map DevPPN filespecs to Unix- or Windows-style directories. The devn part of the DevPPN filespec (known as the "logical disk") consists of a three or four alphabetic character device name, followed by a one to three digit unit number, up to a maximum combined length of 6 characters (e.g. DSK0 or BACK99). The p and pn components are each one to three digits, ranging from 1-999 for p and 0-999 for pn. Note that although the the DevPPN logical disk is by convention all upper case, in actual usage, DevPPN filespecs are entirely case INsensitive; XYZ37:MyFile.DAT and xyz37:myfile.dat are equivalent.) The case sensitivity of the basedir or dir, on the other hand, depends on the host operating system, but by convention is typically all lower case.
There are three variations of this mapping:
| • | The first, and most common, maps a DevPPN-style logical disk (e.g. DSK1) to a base directory path (e.g. /vm/miame/dsk1/). The trailing slash on basedir/ is mandatory. The PPN equivalents are then set up as subdirectories of this base directory using the format <base directory>/######, corresponding to devn:[###,###]. So for example if DSK1 maps to /vm/miame/dsk1/ then DSK1:[1,4] would map to /vm/miame/dsk1/001004. Note that the trailing colon, required to separate the devn from a filename or [p,pn] or in other contexts to identify a token as a devn instead of a filename, is omitted from this version of the DEVICE syntax. |
| • | 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:[p,pn]. The trailing slash on dir/ is mandatory. |
| • | The third variation is similar to the second but is reserved for logical devices that have no [p,pn] component associated with them. See the separate topic Devices without PPNs for a more thorough discussion. |
As an example, consider the following two DEVICE statements on a Unix-based host:
DEVICE=DSK1:[31,3] /usr/tmp/
DEVICE=DSK1 /vm/miame/dsk1/
Together, these statements would be used by A-Shell / MIAME to map the DevPPN specification dsk1:test.dat[31,5] onto the path /vm/miame/dsk1/031005/test.dat, and the DevPPN specification DSK1:TMPCMP.DAT[31,3] to /usr/tmp/tmpcpy.dat
The file name is always converted to lower case as part of the mapping operation. The case of the directory component depends entirely on the case of the basedir in the DEVICE statement (lower case by convention).
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 81 (72.8) 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 by an internal conversion subroutine known as fspec2host. To solve the file-inaccessibility problem, if the DevPPN specification passed to the conversion subroutine 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 72.8 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 (syntax two) and a default device definition for a given drive (syntax one), 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.
See Also
| • | "No-PPN" devices (syntax three) |
History
2025 April, A-Shell 7.0.1771: Add support for "No-PPN" devices.
