There are a couple of issues here.
The main potential problem with creating symbolic links to directories used by the A-Shell DEVICE mapping system is that it's not easy to control or predict which version of the directory name the OS will supply to A-Shell when it tries to reverse-map the OS directory to the A-Shell directory.
In your example, depending on the context, the process's current login, or a file's directory, might be /vm/miame/dsk0/007006, or it might be /var/data/prairiefarmers/vm/miame/dsk0/007006. Depending on your DEVICE statements, one of those may be unrecognizable to A-Shell.
The second issue is related to that. The error message you are getting suggests that a new A-Shell instance is being launched in order to execute the XCALL AMOS, "APPEND..." command, but the new instance doesn't think the current directory is a valid A-Shell login directory (for the reason just stated).
For the XCALL
AMOS login issue, you could probably fix it by forcing AMOS to use the in-process mode (i.e. either specify a 1 for the 3rd parameter, or add
OPTIONS=AMOS_RUNSBR to the MIAME.INI).
The first issue may not really present any problems, and if it does, you might experiment with creating duplicate DEVICE statements (one for /vm and one for the symbolic link to it). Whichever version is listed first will be the one that is actually used for converting AMOS-style specs to native specs. The second version would only come into play for reverse translations from native to AMOS.
