RE: Weigh in on Fast400 . . .

Hate to throw a sticky wicket into the mix.  The SEPT would work fine, but
SPECIAL files already include that capability.

BTW, James, what you described is exactly what I'm talking about.  MI is one
approach, SPECIAL files is another...  There are advantages and
disadvantages to each, but either can be used to accomplish something like
this.

I misunderstood what you meant by "patch".  I thought you were talking about
PCHPGM or something.  I, too, occasionally catch myself saying words like
"patch", "fix", and "debug" to my clients...  When, of course, I actually
mean "enhance"...;-)

Thanks for your all's reply.

jt



> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of James W. Kilgore
> Sent: Thursday, November 08, 2001 4:16 PM
> To: midrange-l@midrange.com
> Subject: Re: Green screen replacement. Was: Weigh in on Fast400 . . .
>
>
> There you go! Now if we were politicians we could proudly
> announce that we have
> a solution at hand and are forming a committee to look into this "your own
> routines" business as soon as we get appropriate funding. <vbg>
>
> Leif Svalgaard wrote:
> >
> > A time-honored way of doing this is to recognize that WSOPN and friends
> > go through entries in the System Entry Point Table (SEPT). Make a copy
> > of the SEPT in your process, replace the entry pointers to WSOPN etc
> > with pointers to your own routines, and you are there.
> >

> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of James W. Kilgore
> Sent: Thursday, November 08, 2001 3:50 PM
> To: midrange-l@midrange.com
> Subject: 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.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>