Re: Moving from Green screen app to GUI because of push back

We are on the web list discussing these options. The idea came up to use
YAJL or something else to spit out JSON and process it on the client side
with jQuery or something of the like. That way you can easily split up
development between business and presentation logic.

No "cost" except for the learning curve.

And for the record, you (Jon) said you used some software that was a couple
hundred bucks a year. My eRPG SDK toolkit is $280 a year, and you can
evaluate for free as long as you need (as with any of my software.). It
seems like maybe people think I charge like old school ISVs.. never have,
never will. Basically peanuts.

Even free software has a cost. Open source included. Support isn't always
free. Support is part of what you get included with any of my software.
Less for one year than most pay for cable or cell phone in a month. lol...


Bradley V. Stone
www.bvstools.com
MAILTOOL Benefit #8 <https://www.bvstools.com/mailtool.html>: Email Logging
- Each email that is sent out is logged with a delivery status. MAILTOOL
also tracks each of the recipients for each email as well as the
attachment(s) sent along with each email.

On Wed, Dec 13, 2017 at 3:39 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

It is not a question of _can_ you do it without third party tools Booth.

It is a question of value for money and how far you can go for the $.

There is a learning curve no matter what you do.

To me the biggest advantage of going beyond "roll your own" is that other
people have already made the mistakes for you. That alone is worth a lot of
money in time saving. IBM i shops reinvent the darned wheel way too often.

So what are the options? And the related "costs"? Well for example:

A) If I use raw CGI APIs I have next to nothing in the way of pre-canned
tools available to help me. There is also a real shortage of code samples
and other education. In order to use jQuery or other similar tools to
produce truly modern apps I have a very heavy learning curve.

B) If I use CGIDEV2 (or Brad's CGI package - although that has a cost
associated with it) I get some pre-canned tools and a bit more in the way
of tutorials etc. but using jQuery etc. still requires some significant
effort.

C) If I use PHP (I could also say Python or node.js or ...) I get lots of
education, massive numbers of pre-built tools (free and fee) that can save
me hours and hours of work. Ready access to staff who know how to program
for the web ... I can call back into my existing RPG logic, etc. etc. Many
of the tools will offer me an easy way into jQuery which brings me to ...

D) If I use a low-cost tool like PHPGrid on top of my PHP I can increase
my productivity by another order of magnitude and also get easy interaction
of jQuery capability into my apps. If you are interested in seeing PHPGrid
take a look at this article and then tell me how much RPG code it would
take to do this: http://ibmsystemsmag.com/ibmi/
developer/modernization/grid_tools <http://ibmsystemsmag.com/
ibmi/developer/modernization/grid_tools>

E) If I use Profound UI (or any off the many other tools in this arena) I
am buying into years of experience of building web apps in RPG using an
extended 5250 model so that I can readily take what I have and move it
forward. Does it cost $s ? Yes but you can test drive for free. I am far
from convinced that such products do actually cost $s in the long run - the
enhanced capabilities and RPG orientation make them reasonably easy to
learn and you become productive very quickly. I've seen this happen on
client sites with Profound, Lansa, Look, Rocket, and CNX to name just a few.

Any and all of these approaches can be used in combination. And I do. But
personally I would never go down to A or even B again. I might use a tool
like Renaissance or powerExt - which are CGIDEV2 "extensions" but if I'm
trying to modernize existing green screen apps then I'm going to start at C
and work upwards depending on my code base, available skills and depth of
pocket book. Most of the E level are worth every cent in my book - but if
the budget is really tight then I'd use a more conservative approach.

All of this of course ignores what might be considered a more important
aspect of modernization like the database but we're talking green screen
here so ...


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Dec 13, 2017, at 2:50 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

What would be an example of an application where you needed a

third-party product in order to modernize? I ask because I challenge that
idea. I believe we already have the tools. Right now. Today. and
yesterday.

On 12/13/2017 11:53 AM, mlazarus wrote:

Nathan,

You're only partially correct. The application would need to be

rewritten, to some degree. But, the additional cost of the add-on product
plus the additional development and testing overhead made it too expensive
an endeavor to undertake, from the clients' perspective.

I went through this at several medium to small clients. Had IBM

included and integrated this functionality into the OS I would have created
some standalone mini applications, or a parallel function to an existing
application, and let them get used to having *their* data displayed in a
real GUI, with additional functionality.

There is no way that they would shell out for an expensive tool (plus

the yearly maintenance!) just to try it out to see if they want to go in
that direction. There are other details in play, but that was a big part
of the decision.

The fact that we can get a GUI to display does not mean that this is

an inherently a GUI OS. It's not. IMHO, until IBM decides that it's
worthwhile investing in creating a fully integrated, modern interface as
part of the OS, this box will be perceived as old and dated. That's a
shame, because it's a real workhorse with many innovations and capabilities.

-mark

--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: http://amzn.to/2dEadiD

--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD