RE: Hmmmm.....$1 Billion

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Steve Richter
> Sent: Friday, March 04, 2005 12:53 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Hmmmm.....$1 Billion
> 
> > 
> > What??
> > 
> > This makes absolutely no sense.
> 
> Joe Pluta is have a bad influence on you Charles.  There is no reason
> to disparage someones comments on this list.

I'm not intending to disparage you.  I'm simply saying that your comments made 
no sense to me.

Perhaps I'm simply not understanding, feel free to elaborate.

> 
> > 
> > There's no special about the "interactive" subsystem, 
> QINTER.  Subsystem simply provide a way to segregate 
> workload.  You can run batch jobs in QINTER and you can run 
> 5250 jobs in QBATCH.
> > 
> > Interactive on the 400 simply means the job uses 5250.
> > 
> > If 5250 is to restrictive, then move on to thick or thin 
> client.  Would your users really prefer the type of 
> functionality you are asking for in a green-screen 
> application vs. a GUI?
> 
> I wrote an application which allowed the user to select from a subfile
> and auto task switch to a VB program on the PC, passing the subfile
> data to the VB application.  Then when the user was done in the VB
> program, data and control would return to the green screen subfile.  
> I made a good living off of that program!   The problem was that it
> was a dead end.  The green screen subfile screen was locked while the
> user was in the VB application.  The users wanted enhancements, they
> wanted to do work in both the green screen and the VB program, but it
> was technically impossible to do what they wanted.

But there no reason why you couldn't have rolled all the functionality into a 
VB app.  My guess is your users would have been happy with a pure VB app rather 
than the VB/green screen hybrid.

Or if you really wanted to keep the VB/green-screen hybrid, you could have 
designed or redesigned the OS/400 app to handle it.  The only reason the green 
screen had to wait is because that's the way to designed it.  Had your 
application started a batch job to handle the communication between the green 
screen and the VB app, you'd be able to do what you want.

In a scenario such as you describe, multi-threading provides _no_ benefits over 
multi-process on the iSeries.

Let's look at the benefits of threads on other machines.
1) Shared address space
2) lower context switching time
3) faster start-up/termination

Now on the iSeries, threads don't provide benefits 1 & 2.  Single-level Store 
provides an address space shared across all process (jobs) in the system. As an 
added benefit of SLS, context switching involves basically 1 instruction (GOTO) 
as opposed to the 1,000s of instructions other systems need to switch between 
processes.

So that leaves faster start-up/termination, definitely of benefit, which is why 
threads were added to support for example HTTP.  But with your app, you'd just 
be starting one process and leaving it running for a considerable length of 
time.  So it doesn't really matter.

> 
> > 
> > There's nothing inherently secure about interactive 5250.  
> In fact, I'd argue the opposite.  You can't secure 5250 
> unless you are using 5250 emulation and SSL.  How is that any 
> different than SSL between your custom server and client?
> 
> > 
> > IBM is doing its best to kill off 5250, they are not going 
> to make the enhancements you are asking for.
> > 
> 
> To use your language Charles, that is a decision that on its face
> makes no sense.   Why were my users not able to get the functionality
> the wanted from the VB / RPG Subfile combo I describe above?  ( and
> why was I not able to make more money in the process! )
> 
> take care,
> 
> -Steve

I'd agree that 5250 is useful, and I don't like the fact that IBM is killing it 
off (not to mention punishing those who still use it).  But the world has 
spoken, character based applications are out and GUI is in.

How many hits has IBM taken because the perceived nature of the iSeries is old, 
outdated green screens?  Why would IBM waste money enhancing the green-screen 
that "nobody" wants to use?

Why would you keep the VB/RPG hybrid?  If I were show three competing products:
1) Strictly green screen
2) Strictly GUI
3) Hybrid green screen/GUI

I've never pick option 3 assuming equivalent capabilities.  In the product you 
describe, which due the graphics couldn't be done in green-screen, I'd never 
pick a hybrid over a strict GUI implementation.  I can't think of any user that 
would.

Charles