Conference 7.286::atarist

    note that DLIB12.ARC should read DLIBS12.ARC.
    ...howard
    

There is a bug in HCC that caused it to hang when I tried to port it to VMS.
This bug looks like it SHOULD cause it to hang everywhere else too, but some
sort of crazy luck has allowed it to work so far on the Atari.  So, if you
find yourself rebuilding from source, you should make this change:


	In GUNK.C.  I found the VMS version of HCC would
	loop indefinitely on your basic "hello world" program on account
	of this problem.  Around line 911, the following routine was
	missing a final "return( 0)", such that it would return trash to
	gunk1(), which would interpret it as TRUE, and therefore prevent
	gunk() from ever exiting.

	    m_fldas(np)
	    NODEP np;
	    {
		    if (np->g_type != E_BIN)
			    return 0;
		    if (np->g_token == '=' && isfield(np->n_left))
			    return 1;
		    return( 0);
	    }

	I sent a nice letter to the authors with this correction.

    I've problems to unarc the stuff. Where is an actual version of
    arc for the ST and for VMS ?
    
    Regards J�rgen
    

I describe a VMS version of ARC in
	PRNSYS::DUA1:[LOMICKAJ.HOBBY.ST]XFERINTRO.TXT,
which was posted in this conference as 52.3.  I have used this version to
dearc the Sozobon compiler with no problems.  You could dearc on VMS with this
and download the resulting parts.

I ran my Z80 assembler through this compiler and it worked fine.  Except
for it's lack of GEM support, I would recommend this compiler for general 
use.
 

    Note 52.3 tells you where to get ARC and CVTARC for VAX/VMS. ARC
    for the ST and VMSSWEEP (a version of ARC) for VAX/VMS can be copied
    from-
    	LEDDEV::DISK$USER9:[WALLACE.PUBLIC.ST]ARC.TTP, ARC.DOC
    	LEDDEV::DISK$USER9:[WALLACE.PUBLIC.ST]VMSSWEEP.EXE
    
    Note that this ARC for the ST may not be the latest version, it
    just happened to be what I could find already on the net.
    
    I de-arced the SOZOBON files on the ST with no problem. NOTE: There
    are ARChives within the ARChives in this case so there is a fair
    amount of de-ARCing to do.
    
    	

Merry Christmas Atari fans - I have ported HCC, TOP, JAS, and LD to VMS.
You can get them from:

	PRNSYS::RELEASED_TOOLS:[SCC]HCC.EXE,TOP.EXE,JAS.EXE,LD.EXE

These are VMS based versions of the Sozobon C compiler, optimizer,
assembler, and linker.  With these programs, you can construct
executable images for your Atari without leaving VMS.

Bugs:
-----
Floating point constants are generated wrong.  It writes VAX G-float
form into the object file instead of Motorola Fast Floating Point
format.  (You can guess why.)

Compatibility notes:
--------------------
The .o files generated by JAS, as well as the executable images
generated by LD, are compatible with those generated on the Atari, and
like the rest of Sozobon, are (supposed to be) compatible with those
generated by Alcyon C.

File transfer notes:
--------------------
The binary files read and generated by the VMS version of these tools
is the STREAM_LF file.  What this means to you is that if you are using
STRANSF or KERMIT to move files between the VAX and the Atari, you must
use CVTARC to get the files converted between VAR 510 and STREAM_LF form.

If you upload a .O or .A file, be sure to "$ CVTARC U filename".  Before
you download a .O, .TTP, o .PRG, be sure to "$ CVTARC V filename".

Sources:
--------

I've got them, and will give them out by request.  I haven't organized
the stuff into a "release" yet.

Example:
--------

Put all these .EXE files in a directory, along with DSTART.O and DLIBS.A from
the original DLIBS12 archive, and CVTARC.EXE.  Define a logical name
SCC$LIB that references this directory.

Then try this:

$ hcc :== $scc$lib:hcc.exe
$ top :== $scc$lib:top.exe
$ jas :== $scc$lib:jas.exe
$ ld :== $scc$lib:ld.exe
$ cvtarc :== $scc$lib:cvtarc.exe
$ copy sys$input hello.c
main()
    {
    char a[ 100];

    printf( "Hello world!\n");
    printf( "Press RETURN to exit.\n");
    gets( a);
    }
$! If you're doing this interactively, hit ^Z here, if you extract this
$! into a comand file DCL will do the right thing.
$ hcc hello.c
$ top hello.s
$ jas hello.s
$ ld -o hello.ttp scc$lib:dstart.o hello.o scc$lib:dlibs.a
$ cvtarc v hello.ttp

and if you're using Whack:

$ stransf get hello.ttp hello.ttp

otherwise transfer it with Kermit.

Now go back to the ST and double-click on HELLO.TTP.  Pretty neat, eh?

I've taken the VMSified version of all the Sozobon stuff and made a
nice, neat, documented release of it all, and submitted it to the
toolshed (METOO::TOOLSHED,METOO::SW_TOOLS_CATALOG conferences).  If you
are interested in compiling code for the ST using the VAX, the files of
interest are PRNSYS::RELEASED_TOOLS:[SOZOBON]SOZOBON.VMS,SOZOBON.BACKUP

SOZOBON.VMS describes everything you need to know about installing the
compiler on VMS, invoking it, and should contain enough information so
that you can figure out how to rebuild it from sources.  It's built
against VMS V5.1-T2, so if you have an older version of VMS, you will
have to rebuild the executables.  (Fortuantely, that's as easy as
saying "MMS" in each of the source directories, and copying the result
to the BIN directory.)

SOZOBON.BACKUP is a VMS backup saveset that holds a directory structure
for the Sozobon software.  It's about 4000 blocks, but if you delete
[.SRC...]*.* and [.ARC]*.*, which are only needed if you intend to
recompile the compiler, it's down to just over 800 blocks.

Has anyone but me bothered to try this stuff out?  I got mail from one
guy in DEC Austrailia that is investigating using this compiler to write
firmare for communications products.

    I used SOZOBON to compile one program on the ST, haven't time to
    do anything else with it. I have not tried your VMS port of the
    compiler.
    
    	Ray

    I tried to compile and link "hello world" and failed. The linker
    couldn't find printf. It took me a while to persuade it find dstart.o
    too.
    
    All suggestions gratefully received.

I've been  testing  the Sozobon compiler on a few small programs, and apart
from floating point and no GEM support, it looks pretty good.

How does Sozobon  compare  to  the  other PD C compiler written by Mark
Johnson (MJC)?

Adrian

re: .9 (Nigel), if you are using the supplied "cc" that comes with the
kit to do your linking, "cc" will locate dstart.o and dlibs.a for you,
provided you installed the compiler according to the instructions in
section 8.1.3 of the manual.  (The libraries go in either "\sozobon\lib" of
the current drive, or the environment variable "LIB" from some sort of shell.)

If you are running LD directly, or running the VMS version, you have to
include dstart.o first on the command line, and dlibs last, and specify
their full path.  If you use the "packaged" VMS kit (SOZOBON.BACKUP),
the LD command line would look like

	LD -o hello.ttp SCC$ROOT:[LIB]dstart.o hello.o SCC$ROOT:[LIB]dlibs.a

Oh, and Nigel, if you want to port the compiler to Unix, it should be
nor more than a couple hours of work to get the VMS versions to run
there.  Most of the hard changes were big-endian to little-endian byte
swapping, and those are conditioned on MC68000.  The VMS stuff is
conditioned on #ifdef VMS, and occur in exactly the same spots that
would have to change for Unix.

Re: .10 (Adrian)  I've tried MJC, but I was not as impressed by the
environment he supplied, although MJC DOES incluide some minimal GEM
support.  I didn't compare quality of output, but I'm sure we would be
glad to hear of any comparisons you perform.  (MJC is descrived in
topic 115.)  Myself, I was too impressed with getting sources to
everything to even bother to continue looking at MJC.  I immediately
deleted all of MJC.  On the Atari, I have Mark Williams C, so I am
mostly interested in the cross-development possibilities of the VMS
version.

One thing I haven't yet tried is to use the .H files for GEM that come
Mark Williams C with the Sozobon compiler.  I'm hoping that this is all
that's needed for GEM support.

    Thanks Jeff. I have unwound and recomplied the VMS version and complied
    and linked "hello world" with it.
    
    MMS complained rebuilding HCC. It aborted when CC reported redundant
    #undef min and #undef max in GSUB.C The compilation succeeded but
    MMS obviously did not like the error code.
    
    I had problems recompiling AR because it did not occur to me to
    run SCC$LOGIN before the pieces were rebuilt (ar.h is in the include
    directory whose logical name is defined in scc$login).
    
    Why did you leave the link step out of SCC.COM? It's not important
    since you published an example in .11, but an example in sozobon.vms
    might be appropriate.
    
    Finally, when I said 'LD -o world world.o' it complained that printf
    was undefined. This suggestes that my LIB variable wasn't set right
    when I tried it on my ST.
    
    Don't hold your breath waiting for a UNIX port, but if you want
    one send me mail. It will move the job up my priority stack.
    
    p.s. What is involved in creating a gem library?

>    MMS complained rebuilding HCC. It aborted when CC reported redundant
>    #undef min and #undef max in GSUB.C The compilation succeeded but
>    MMS obviously did not like the error code.

I used VAX C V2.4-026.  I suspect you have the field test of V3?  I
didn't get this error.
    
>    I had problems recompiling AR because it did not occur to me to
>    run SCC$LOGIN before the pieces were rebuilt (ar.h is in the include
>    directory whose logical name is defined in scc$login).

I'll mention this in SOZOBON.VMS.
    
>    Why did you leave the link step out of SCC.COM? It's not important
>    since you published an example in .11, but an example in sozobon.vms
>    might be appropriate.

Well, if I put in running LD, I'd also have to put in a qualifier to
omit it in the case of building large systems out of modules, and that
brings in the whole issue of command line parsing, and so on, and so
on.  I'd like to make it a full "cc", but for me this wouldn't be an
economical use of my hacking time.
    
>    Finally, when I said 'LD -o world world.o' it complained that printf
>    was undefined. This suggestes that my LIB variable wasn't set right
>    when I tried it on my ST.

If you said "ld", you have to say
	ld -o world $(LIB)\dstart.o world.o $(LIB)dlibs.a
Now, "cc -o world world.o" should have worked.
    
>    Don't hold your breath waiting for a UNIX port, but if you want
>    one send me mail. It will move the job up my priority stack.

I don't need one for anything.  If I wanted an Ultrix version, I could
ship the sources to a nearby system here and make one, It's just that I
know that you use Unix systems more than you use VMS, and might have
something to gain by doing the port.  I thought I'd mention that the
port wouldn't be hard.
    
>    p.s. What is involved in creating a gem library?

Well, you need to know the data structures used in the GEM calls, and
you have to have a set of macros that convert GEM and AES calls into
the appropriate TRAP's.  I think most of the capability is there.  The
documentation indicates that at least one GEM application has been
written in Sozobon C already.  I would very much like to be able to
demonstrate using GEM from Sozobon C at the January 31 Abacus meeting,
so I will be looking into this.  I think GEM support is excluded because
the requisite header files hold an Atari copyright.  At what point does
re-entering this information from other copyrighted reference material
become a violation?  I certainly don't know.

    It turns out that the problems I had at home were due to a faulty
    download of dlibs.a
    
    First, it works better than MJC in that a program I had up under
    UNIX would never work with MJC and worked with SOZOBON. The critical
    issues were the use of routines that returned longs. The other thing
    I did was compile curses into a library and had the demo work first
    time.
    
    Things that give me trouble with SOZOBON are :-
    	I keep getting malloc failures running cc under gulam with a
   		164k  ram disk in a 640k system.
    	The distribution barely fits on a single sided disk. (I'm
	        anticipating a second, double sided additional drive
    		or I'd give up at this point).
    	Despite following the instructions, I can't get PATH, INCLUDE
    		or LIB environment variables to work.
    	I want (need) to see the source to dstart.o
    
    re .13
    	VMS is very low priority in our shop. We run VMS 4.x and some
    arbitrary standard version of VAX C.
    
    	I've been looking at the gem.h and gem.c supplied with MJC and
    comparing them with a copy of GEM.TXT I found somewhere out there.
    The set of routines is incomplete (I'll post a list of missing routines
    later) and the implementation looks to be more complicated than
    a simple header file.
    
    	If I can get what was there to work, I'll post the library and
    header file. Unless someone else gets there first, of course.
     

Yes, this weekend I tried the same approach - stealing from MJC's GEM.C to
make a GEM interface for Sozobon.  I got frustrated after realising that it
would not be trivial, and then played Elite for four hours.  (The Beam Laser
is a much better weapon, but I'm still "clan" and "harmless".)

Expanding GEM.C to cover all the GEM calls seems easy enough,
once you get the basic stuff to work.  It also looks to be a bit more
streamlined that what Mark Williams C does for GEM calls.

The source to DSTART.O is DSTART.S, which is in the SRC.ARC that's in DLIBS.ARC.
You can use VMS ARC to fetch it without waiting all day for your floppy drive.

I was able to use the environment variables PATN, LIB and INCLUDE
successfully by using the BATCHMON program that comes as part of the
distriution, so I know the code works.  I also think I was able to get
it to work from the Mark Williams "msh" shell.  Perhaps the shell you use
uses a different mechanism for environment variables than DLIBS?

In any case, with such limited disk space, I recommend that you do your
compiling on the VAX and download the result.

    In my freebie area I have uploaded GEM.A GEM.H CURSES.A and CURSES.H
    
    The curses library has been tested, I forget were I got it but it
    does have someones copyright string in it. It worked for me.
    
    The gem stuff is a conversion of the gem.c distributed with MJC
    however, I have made major changes to it to make it compatible
    with SOZOBON. At this point, all I have done is build the library.
    I have no handy gem demo source to try it with so I would like to
    know if I got it right. Alternatively, give me access to some demo
    source and I'll experiment until it works or I have no hair left.
    
    Sometime soon I will put the sources into arc files and upload them
    for your pleasure and edification.                               
    
    My freebie area is hjuxb::sys$userdisk:[haslock.doom]
    

Thanks Nigel, I have a "small" demo program that I will be presenting at the
next Abacus meeting that I would very much like to be able to compile with
Sozobon C.  I'll look at what you've got so far and see if I can figure out
what the next step is.

    This is a non progress report. I have run a number of test programs
    with extremely variable results. There are also a number of gaps
    in the set of supported functions.
    
    I now have a copy of the Abacus GEM Reference book and am finding
    holes and errors in it. Fortunately, they are mostly in different
    places to the holes and errors in gem.c. There are still routines
    that are not covered by either source.
    
    Specifically, the book says that you need to call appl_exit after
    v_clsvwk but does not list the function anywhere. Can someone post
    or mail me a definition of this function. The other open area is
    with the subfunctions of VDI 5.
    
    I came across a reference to VDIQ and AESQ libraries on USENET.
    Sadly, the originator has not responded to a request for more
    information.
    
    The other exercise is that of rationalizing the header files. I
    have made very little progress with this, too.
    
    I have hopes of making progress this week but I'm not prepared to
    bet on myself just yet.
    

    Here is the info for appl_exit() from the MWC manual:
    
    appl_exit - AES function (libaes)
    	Exit from an application
    
    	#include <aesbind.h>
    	int appl_exit()
    
    
    It has no parameters and returns an a pass/fail status. Zero is
    returned if an error occurred and a number greater than zero if
    there was no error.
    
    It frees the AES structure and the handle associated with the process.
    It DOES NOT terminate program execution. You'll still need to use
    return(), exit(), or fall out the bottom of your program (ugh!)
    
    Dan
    

This message  was posted to comp.sys.atari.st recently.  Does anybody have
access to the GEMQ or GEMFAST packages?

- Adrian

Posted by: decwrl!ucbvax!agate!bionet!csd4.milw.wisc.edu!nic.MR.NET!shamash!com50!bungia!orbit!pnet51!steve
Organization: People-Net [pnet51], Minneapolis, MN.
 
[email protected] (Chris Moore) writes:
>Are there any PD gem libraries available for the Sozobon C
>compiler?  If the answer is yes, where can such a library
>be obtained?  I have access to Genie so that would be best
>for me.  I have searched through the ST round table without
>much success.
>
As I mentioned in my posting of dastart.s the other day, there are TWO free
GEM libraries that will work with Sozobon C. Don Farmer's GEMQ has been out
for a year or two; Ian Lepore's GEMFAST has been out for a couple of days and
should show up on GEnie Real Soon Now.
 
I have Ian's bindings in my directory here at pnet51, which is accessible to
the public via PC-Pursuit. [M]odify your login to use binary transfers, choose
[V]arious disk utilities, [A]ttach to the "steve" directory, and [G]et the
file.
 
I can mail it to the comp.bin moderator if someone will give me the address.
 
UUCP: {rosevax, crash}!orbit!pnet51!steve
ARPA: [email protected]
INET: [email protected]
  -----------
  -or-
  [email protected]
  "A member of STdNET -- the ST Developers' Network"

    re .19
    
    This is what I know already. What I need to know is what is supposed
    to be in the appl_exit routine. Obviously it is an aes call, so
    what is the opcode and does it need any arguments?
    
    re.20
    
    This is the message I saw, replied to and have had no response to.
    
    Last night I tried the first two assembler examples from the book.
    In both cases the programs ran but did nothing to the screen and
    did not wait for console input. Any suggestions anyone, before my
    frustration level makes me quit.
    

I got a new book on ST programming last Friday, "The Concise Atari ST
68000 Programmer's Reference Manual". by Katherine Peel, published (in
the UK, of course) by Glentop.  I would recommend this book over/in
addition to the Abacus book any day of the week.

On page 5.7, it has:

		     parameters
		  | int  |   addr |
	  opcode  in  out in   out
APPL_EXIT  19     0    1   0    0
		  int_out( 0) = 0_error
                                >0_o'k

 There are more books in the same series. AES and VDI. They seem to be
 more to the point than the Becker/Abacus books and with fewer lies.

 Theo

    re .22 & .23
    Great, where do I order copies from?
    
    Currently, I'm getting a bus error in appl_init. This is strange
    because it used to work.

Do you have friends in England?  They might be able to find them more
easily. I heard at the Abacus meeting last night that ordering these
books can take a LONG time.

    Re: .24
    
    Show keyword/full reveals:
    
     BOOKS                57.0
    
    So if you look at note 57.0 you will get some pointers to books.
    
    						-Dave

    Finally, an endorsement for GEMFST01.ARC.
    
    I took this from USENET yesterday and tested it last night. The
    documentation says that it is supposed to be distributed with source
    but that hasn't shown up on USENET yet.
    
    I looked at the GEMQ libraries but the AES section is unusable without
    a datastructure that I do not have. I will extract some of the
    useful code from the utilities module that appears to replicate
    some MWC routines the Jeff used in VIEWFILE.C. I also want to add
    linea routines so that I can compile a VIEWFILE with Sozobon.
    
    The other piece needed is a modified DSTART module that will work
    either as a .PRG or as a .ACC
    
    GEMFST01.ARC is in HJUXB::SYS$USERDSK:[HASLOCK.DOOM]

    Courtesy of USENET there is now a floating point library for SOZOBON.
    I have not tested it or even looked at the sources.
    
    	HJUXB::SYS$USERDSK:[HASLOCK.DOOM]FPLIB10*.*
    
    I have also seen a few bug reports for dLibs. The compiler/assembler
    apparently fails on btst instructions. This affect memcpy and related
    routines.
    
    Being busy I have only saved these messages on my UNIX box and not
    tried to update anything. Nag me if you need any of this soon. The
    gemfast routines are also reported to have been revised but I do
    not have new copies.
    

    
    
    
    
    
    Hy Nigel!
    
  >>    <<< Note 340.16 by HJUXB::HASLOCK "Nigel Haslock @ Manalapan,NJ" >>>
  >>                       -< useable curses and gem(?) >-
  >>
  >>  In my freebie area I have uploaded GEM.A GEM.H CURSES.A and CURSES.H
  >>  
  >>  The curses library has been tested, I forget were I got it but it
  >>  does have someones copyright string in it. It worked for me.
    
    Last night I copyed CURSES.A and CURSES.H. to my \LIB and my \INCLUDE
    directory. Everything looks fine but it didn't work.
    Now my Questions: 
    
     - Curses, is this the same as UNIX Curses ?
     - Do you have anny doc files ?
     - Do you have examples written in "C" 
    
    Manny Thanx
                      Roland_from_W_GERMANY
    
    

    Re .29
    
    Hi,
    
    Could you be more specific about what didn't work?
    
    Curses is UNIX curses and is documented is the AT&T Manuals, the
    VAX System V manuals and (very badly) in the VMS C Manual.
    
    I have a trivial sample program. I was trying to port wanderer but
    I got distracted by my other hobbies.
    
    Can you post or mail me your source so that I can try to debug it
    for you. I used to be able to speak German so reply in your preferred
    language.
    
    	Nigel
    

    
    There are hints in the User Reference document about futures
    such as development shell, debug tool, Gem support etc. These would make
    this good package even better.
    
    Does anyone have any news on updates to the Sozobon package?
    
    Brian

A month or so ago an updated version of the assembler (and I think the
optimizer?) were posted on usenet. The post included a note that the author
was working on a new full release of Sozobon. I can't recall the time frame he
gave for the next release but it was at least a few months away.

For GEM support you still need to use one of the seperate PD GEM libraries
(GEMFAST is one of them). However in the next release of Sozobon one of those
PD GEM libraries (I think GEMFAST) will be bundled in the distribution.

Sorry this all sounds kind of vague but I don't have the posting on the VAX to
refer to.

	Ray

    
    Yes, I've tried the GEMFAST library - it works fine with SOZOBON.
    
    I'd appreciate it if you would keep a lookout for the new release.
    
    BTW: What about writing .ACC's - doesn't that require a special
    start-up file?
    
    Brian
    

There is C source code for a MC68000 series debugger in
PRNSYS::RELEASED_TOOLS:[NEW68000].  There has been no attempt to port
this to the ST environment.  I don't know how hard it would be.
Might make a nice Christmas vacation project for a suitably motivated hacker.

    
    PRNSYS::RELEASED_TOOLS: is no longer a valid translation..
    
    Is the SOZOBON C compiler still available,if so what is the
    current disk.
    
    
    Thanks Chris Chandler.
    

I just tried a directory of PRNSYS::RELEASED_TOOLS:[SCC] and it works fine.

	Ray

PRNSYS::RELEASED_TOOLS:[SOZOBON] is the correct place to look for the
VMS version of the Sozobon C cross compiler for the Atari ST.  The .ARC
fils in [SCC] are good fir the ST, but you should ignore the .EXE's.

By the way, Chris's problem is that JOCKEY:: has the wrong address for
PRNSYS::.   PRNSYS:: is 5.199.

    
    Jeff,
    
    	Is the PRNSYS::RELEASED_TOOLS:[SCC] Directory still OK?  I've
    	tried to access it and get told the directory doesen't exist.
    
    							Tnx,
    
    							   Rich

Try RELEASED_TOOLS:[SOZOBON] instead.

    
    	Jeff,
    
    		Thanks - I'll go from there (I did have a different 
    	reply here, but deleted it after reading sozobon.vms.
    
    					Thanks for your efforts,
    
    						Rich
    

    I've looked all over for this compiler and have not been able to find
    it.  My computer does not recognize the PRNSYS::RELEASED_TOOLS:[SCC]
    directory.  Is there anywhere else I can find it?? 
    
    Also, what's this thing like?? Does it support any gem routines like
    windows and menus??  Is pretty much standard stuff (i've only taken a
    course in ANSI C on unix)?  Are there any better compilers out there?
    
    thanks
    
    Andrew
    

    
    andrew,
    
    	Try checking in
    
    		Dweezl::Atari$Dsk:sozo*.* 
    
    	Dweezl is 17.252  and the Sozobon stuff should be there for the
    Atari.
    
    							Rich

    I have a question. Do you need a hard disk for sozobon or is there a
    way you can split the files between multiple disks?  Will it work with
    512K?  And, what are the files I need (I noticed something like
    sozobon_old.arc)?
    
    thanks
    Andrew

I have a demo disk that I gave out at WAACE last year that - when you
booted the floppy and double-clicked on VIEWFILE.BAT, it would rebuild
the VIEWFILE GEM application from sources, using only stuff available on
that floppy disk.

So, although you have to be a little bit crafty, it can be done.  Both
bulding of GEM applications, and runnong on floppies only.

AD:: is in Hudson?  I'd be glad to send you the disk.  Perhaps you an
show up at a NaVAUS meeting and find out more?

PRNSYS is address 5.199, if you have old tables, you may have PRNSYS in
area 6, or not have it at all.  Also, the directory is SOZOBON, not
SCC. Try using  Directory PRNSYS::RELEASED_TOOLS:[SOZOBON], or 5319::
instead of PRNSYS::.

The SOZOBON version I have actually can be run on VMS as a set of
cross-development tools.  It generates .PRG files directly on VMS, that
you can download to the ST and run there.