Re: Weigh in on Fast400 . . .

jt,

A possible wrong choice of words on my part.  I'm not talking about some form of
hack to the OS or the compiler itself.  I'm thinking more along the lines of
RPG2.5 that was developed for the S/36 which added CALL/PARM long before IBM
made it available on the 236.

Now I don't know the gory details so I'm just making up names as I go here ....
let's say that a program that has a WORKSTN device in it causes the compiler to
include routines WSOPN, WSCLO, WSGET, WSPUT, etc. which is the necessary code to
have the program talk to the workstation controller.  What I am referring to is
a product that could be purchased, maybe, that would sit above the compiler and
substitute the above mentioned routines at compile time.

These substitute routines would not talk to the workstation controller but some
other server program that runs in batch yet performs the same function.  Your
application program would compile the same with or without the add on product.
ZERO CODE CHANGES!

So if you don't have this product, you compile and use dumb terminals, telnet,
emulation cards, etc., but if you do use this product, you recompile your
program and get rid of your dumb terminals and emulation cards.

I hope I explained myself better this time.

BTW, I've given thought to IBM compiler changes, but have a hard time
remembering when the last time a change was made to the compiler to support any
new functions of a WORKSTN device since scroll bars.  I seriously doubt that IBM
is spending any development dollars in that direction so don't see any compiler
changes in this regard in the near future.  But then again, I've been wrong
before. <g>

J. Kilgore

jt wrote:
>
<<snip>>
> >
> > If IBM can't/won't do this, possibly some really clever bunch of
> > people could
> > come up with a compiler patch so that any program with a WORKSTN
> > device would
> > use this patch to communicate with a WORKSTN controller emulator.
> >
> > just a thought...
>
> No patch needed... nor recommended.  I agree with Ed Fishel's views on
> that...  Similarly, I have avoided going down to MI, so far (not just
> because I don't know it very well) because it often just complicates things,
> for the perceived benefits it provides.