Re: Alternate file types for RUN ?

JF Mezei wrote:
Doug Phillips wrote:
Just keep separate directories and use f$getsyi to get arch_name and
assign the default or run and link-target path/searchlist in the
login.com accordingly.


Some of my programs are actually invoked with the RUN command without
any DCL before it.


So you can't build a "R*UN" wrapper, you mean? Okay, although I thought
of that I didn't suggest it.

I don't see how it changes your problem. From *where* are the programs
run? Your default directory or a logical directory? You can define
either as a search path. (surely you don't use hardcoded file specs,
sorry, I mean shirley:-)

You must build VAX images on the a VAX, and Alpha images on an Alpha.
You need to keep the two separate, and there's a way you can do it that
works now and many other ways that don't work now.

Common code base is fine, but you'd still need to do something
"special" to create the special extensions.

When you compile/build it, you rename the resulting .EXE into .EXE_VAX
or .EXE_ALPHA depending on what platform you used to build it. Then
whenener you would use this, the RUN command would automatically pick
the right image file because it woudln't find a .EXE and look for
alternate extension. This would have allowed the functionlaity of FAT
executables with only a minor change to the RUN command.

And why not just go all of the way and build file type associations?
Why limit yourself to architecture dependant exe's? Why tinker with
something that works if the problem can be solved without tinkering?

Using a search-list of runable extentions (which is what you're asking
for) would require:
1. changing the way VMS works.
2. an extra step during build to rename and/or give the exe the
correct extention. (you could use a logical/symbol combo to append to
the extension)

Using a search list of directories would require:
1. no change in VMS.
2. an extra step during build to place the exe into the correct
directory. (you could use a logical/symbol combo to define the
directory)

--------
$ show symb arch
ARCH = "VAX"
$ set default disk:[execs]
$ define App_execs disk:[execs],disk:[execs.exec_'arch']
$ set default App_execs
$ dir
Directory DISK:[EXECS]

ALPHA.DIR;1 RECIPES.COM;1 VAX.DIR;1

Total of 3 files.

Directory DISK:[EXECS.VAX]

CHOCOLATE.EXE;1

Total of 1 file.

Grand total of 2 directories, 4 files.

$!--------

$ show symb arch
ARCH = "ALPHA"
$...
$ dir
Directory DISK:[EXECS]

ALPHA.DIR;1 RECIPES.COM;1 VAX.DIR;1

Total of 3 files.

Directory DISK:[EXECS.ALPHA]

CHOCOLATE.EXE;1

Total of 1 file.

Grand total of 2 directories, 4 files.
--------

So that's the way I see it. Of course, I understand that you aren't
really looking for a simple solution to this simple problem; you're
wanting to dive into deeper waters. Still, explaining this method might
help someone else in the future.

******

.

Relevant Pages

  • Re: Great SWT Program
    ... extension you want to give the destination file. ... because they also cover all sorts of formats beyond graphics formats. ... position to set up the relevant command. ...
    (comp.lang.java.programmer)
  • Executable File Extensions in 4DOS (long)
    ... I give these scripts the extension .PL. ... command name) as the first word on the command line, ... or .BTM or .BAT to indicate a batch file. ... an executable extension if its name begins with a period. ...
    (comp.os.msdos.misc)
  • Re: Simple program not producing output
    ... Pasted the MSDN code into this code file. ... When to a command shell, located the exe. ... public static void PrintValues ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Simple program not producing output
    ... Pasted the MSDN code into this code file. ... When to a command shell, located the exe. ... public static void PrintValues ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Shell Functions and DOS executables
    ... I had to create a .BAT file that actually made the call to the exe, ... Dim wshExec As IWshRuntimeLibrary.wshExec ... I followed the above and the DOS command executes perfectly! ...
    (microsoft.public.vb.general.discussion)