Until now, I have only had to manage a single version of my programs, command files, data files, menus, etc. on my A-Shell development system. Now, I need to support a second set of these modules. Although both sets of programs, etc. evolved from the same source, each set is already highly customized and future customization should not affect the other set.

It seems to me that the best way to achieve this is to establish 2 independent A-Shell systems. But I have only one Linux server.

Furthermore, I would like the two A-Shell systems to be as parallel in structure as possible to make them easier to manage. For example, I would like to use the same ersatz.ini and logical device names on both systems.

I figure I can copy my /vm/miame directory tree structure to a new parent directory and set up different miame ini files to point to each parent. Then I can isolate the basic A-Shell modules and share them between both systems (thus requiring only 1 version of A-Shell to be installed on my server).

What I am not clear about is how to handle DSK0:. A-Shell places many of its files in DSK0: directories. I also place many CMD, DO, MNU, INI, LIT, etc. files in these directories. I now need to support two versions of my files (i.e., same names, but different content).

What do you recommend?

If I made any money from hardware, I'd suggest just buying a second system. But under the circumstances, I don't think that will be necessary.

I think you plan is basically right on. The "vm" in "/vm/miame/" was in fact intended to stand for "virtual machine" and be replaced by different codes for different "virtual machines" that you support.

Since the location of the ashell executable doesn't have to be tied to any particular directory, and since you can specify the miame.ini on the command line with the -i switch, you could just do a complete fresh installation of A-Shell in your parallel directory system (say, /v2/miame) and then create a couple of scripts to launch one version or the other, i.e.:

ashell1 script
--------------
/vm/miame/bin/ashell -i /vm/miame/miame.ini

ashell2 script
--------------
/vm/miame/bin/ashell -i /v2/miame/miame.ini

As you suggest, the /vm/miame/miame.ini file and the /v2/miame/miame.ini file can be the same except for the paths to the logical disks. (You might also define some extra logical disks to allow you to copy files between the two "virtual machines" while logged into either one.)

As for DSK0, I suggest using the alternate syntax of the DEVICE= statement for defining individual PPNs rather than entire logicals. This way you can share certain PPNs, perhaps [1,*] and [7,*] between the two systems and differentiate others, perhaps [2,2]. For example:

DEVICE=DSK0:[2,2] /v2/miame/dsk0/002002
DEVICE=DSK0 /vm/miame/dsk0/

In the above miame.ini excerpt, DSK0:[2,2]would be in the specified directory under /v2/miame, while the rest of DSK0: would be in the default directories under /vm/miame. (It processes the list from top to bottom, stopping on the first match, so you must put the PPN-specific DEVICE statements first.)

Of course this only helps to the extent that any of the directories on DSK0: are totally free of virtual-machine-specific files.

I suppose that it might be nice if A-Shell allowed you to change the search path for executables at runtime so that you could move all your CMD and DO files out of DSK0:[2,2] and into some other location.

On the other hand, the current [p,pn] and [p,0] will be searched for CMD/DO/RUN files if the file is not in DSK0:[2,2] or DSK0:[7,6], so that fact would presumably permit you to shift nearly all of your CMD/DO/RUN files off of DSK0. Which seems like a good general strategy. (How else would you be able to handle this under AMOS?)

As an aside, it is possible to use environment variables in the DEVICE definitions in miame.ini (surrounded by % characters) e.g.:

DEVICE=DSK1 %VMDIR%/dsk1/

This fact would allow you to have a single miame.ini file and just establish a different definition for the VMDIR (or whatever) environment variable beforehand.