Re: Hmmmm.....$1 Billion -- MIDRANGE-L

On Fri, 4 Mar 2005 14:18:20 -0500, Wilt, Charles <CWilt@xxxxxxxxxxxx> wrote:
> > -----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.

The VB users would have been happy to remain on the PC Lan  system we
pulled that VB program out of, forcing them to use the as400 based
system of the company I worked for, the company that bought them out!

> 
> 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.

putting aside the fact that we had to work with what we had, that
management was not going to rewrite the as400 system that had been 15
years in the making, I dont think you appreciate the technical
difficulties of spawning secondary jobs and syncronizing the activity
of not just the client and server applications, but now a 3rd batch
job spawned that runs in parallel with the interactive job.  not easy!

> 
> 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, you are saying you would do a rewrite instead of working with
what you have?  I am happy for you that you have the budget necessary
for that approach.  In my experience the incremental change option is
most commonly selected.  Which is why the argument that you, Joe and
IBM are making that everying should be done with data queues and batch
jobs does not fly in the real world.   The programmer needs as many
options as possible.

-Steve