Re: java and the interactive subsystem

[Steve Richter <stephenrichter@xxxxxxxxx>]

On 8/23/05, Jon Paris <Jon.Paris@xxxxxxxxxxxxxx> wrote:
>  >> The fact it is not must be because of limitations in the interactive
> subsystem.
> 
> That's one heel of a leap of logic!

thanks! 

> 
> The answer is probably a lot simpler.  How about:
> 
>  - Java is slow relative to RPG

advantage fat client, no?  managed code is clearly superior to the
traditional rpg and C memory model.  but it needs the horsepower of
the fat client to run it.

>  - RPG has excellent native support for subfiles etc.

java/c# is perfect for subfiles.  the user presses f13=repeat the
option to the end of the list - where do you store all those options?
the .net arraylist would work very nicely. the "C" recio functions
handle display files.  my guess is java classes that JNI'ed down to
those recio functions would encapsulate subfile logic very well.

>  - IBM charges a hefty price for interactive cycles
>  - A lot more iSeries programmers know RPG than Java

where I am now, working on a large 570, RPG is discouraged.  The
prefered language for the 6-8 programmers is sql procedures.   If Java
could do the job as a general purpose language on this 2000 cpw
system, why would it not be considered?

>  - Most people don't want new green screen apps - they want browser

or they are jumping from one to the other.  the two data entry apps I
wrote this month were green screen.  at the user's request ( data
entry of a lot of catalog request postcards ).   Where the new apps
are a mix of green screen, sql procedures and web - java would be
preferred.  That is how c# is used in .NET shops.

that is why I am claiming the interactive subsystem restrictions on
the 400 is what is holding back the acceptance of Java.  As a managed
code language it is too good not to be used.

-Steve