RE: Hmmmm.....$1 Billion

[michael@xxxxxxxxxxxxxxxxxx]

"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! )"

Why would you want to do it that way? What was the advantage? Why not
just have the VB program pull the data from the database and do
whatever you want? What was gained by having the subfile exist at the
same time on both systems?

I must be denser than normal today...


> -------- Original Message --------
> Subject: Re: Hmmmm.....$1 Billion
> From: "Steve Richter" <stephenrichter@xxxxxxxxx>
> Date: Fri, March 04, 2005 12:52 pm
> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> 
> On Fri, 4 Mar 2005 11:31:30 -0500, Wilt, Charles <CWilt@xxxxxxxxxxxx> wrote:
> > >
> > > It is not that simple Charles.  Once the user signs on to the
> > > interactive subsystem there are all of these restrictions, ( multi
> > > threading, 5250 limitations )  which make it almost theoretically
> > > impossible to give the user the interactive usage of the system that
> > > they want.
> > >
> > > Which means you have to scrap interactive entirely and start from
> > > where? I understand the whole Java / client access thing but that all
> > > entails a large framework that I have to buy into.    I want to code
> > > .NET front ends to the as400.  It is all doable and a lot of fun to
> > > work on, but there is a lot of infrastructure that the programmer is
> > > responsible for in that setting. There is also a real question of how
> > > secure are your connections between the client and server.   When your
> > > server program on the as400 listens on a private port on the 400 for a
> > > private data stream from the PC client, how sure are you that that
> > > link is secure?
> > >
> > > The interactive subsystem provides a secure framework from which
> > > programs can run.  IBM should enhance the interactive subsystem so it
> > > works in the client / server setting.
> > >
> > > -Steve
> > 
> > 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.
> 
> > 
> > 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.
> 
> > 
> > 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
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.