Nathan,
I recently became acquainted with a Canadian company that is signing up dental offices throughout Utah. They are running cloud services based who knows where?
But "where" doesn't matter. The point is that they understand the economies of scale of the cloud services business model, and that dental offices are eager to get rid
of their in-house systems because they are not in that line of business. Dentists want to use technology, not manage it. Managing technology is not their core
competence.
They better be concerned about the where. Just because it is "cloud" does not relieve them of privacy requirements. HIPPA et all still apply.
Gary Monnier
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, March 13, 2012 10:53 AM
To: RPG programming on the IBM i / System i
Subject: Re: the RPG problem - adrift in the PC-web wind
From: Steven Spencer
Our system runs a food importer impeccably.
You've been raising concerns about a lack of PC integration since last July at least, and previously admitted to various gaps in your platform. But that's not my main point. I'd like you to start thinking in terms of running many food importers impeccably, instead of just one. Because if you don't, somebody else will, and the applications that you're supporting in the S/36 environment will probably be retired within a few years by another vendor that understands the cloud computing business model and technology associated with it.
I recently became acquainted with a Canadian company that is signing up dental offices throughout Utah. They are running cloud services based who knows where? But "where" doesn't matter. The point is that they understand the economies of scale of the cloud services business model, and that dental offices are eager to get rid of their in-house systems because they are not in that line of business. Dentists want to use technology, not manage it. Managing technology is not their core competence.
If you were to buy a model 720 today and connect 20-40 concurrent users to it you'd probably run your CPU pretty much all day long at 1-2% utilization. We need to start thinking in terms of hosting hundreds or even thousands of users on 720's.
Regarding PC integration, there has been an on-going discussion on Linkedin about various ways to generate Excel spreadsheets under IBM i. The number of alternative solutions actually surprised me. We use RPG to generate Excel spreadsheets, Word documents, email, PDF documents, HTML reports. For our daily backups, we generate encrypted .zip files and FTP them to an offsite linux server, instead of backing up to tape.
You may not be thinking in terms of mobile computing now, but get and iPad or an iPhone and your outlook will change. ERP vendors are adding handheld applications to their legacy suites. More and more organizations are demanding them.
Before you can use tooling to generate mobile applications, your first step must be to externally define your physical files, and learn how to create SQL views.
I have to admit that IBM is investing a lot more in cross-platform languages and interfaces and related tooling, but it is not too hard to learn how to create HTML templates, and scan and replace field markers, using RPG. You'd probably be surprised just how well suited RPG is for generating formatted output, whether that be HTML, XML, JSON, or whatever.
I noticed this week that our daily backups include over 3,000 HTML templates which we use in more than 400 web applications.
-Nathan
<stevenspencer@xxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Cc:
Sent: Tuesday, March 13, 2012 9:31 AM
Subject: Re: the RPG problem - adrift in the PC-web wind
Hi Folks,
Steven
I see no purpose in working with RPG and the jambalaya of EGL, or
CGI and PHP, or Java and this and that. Or Open Access
and the three vendors.
Steven
Let me add that the context of this was new, fresh projects. In terms of enhancement and maintenance and support of existing systems, the RPG environment is fine. However, I am not a big fan of the modernization route of RPG-ILE followed by ... whatever. It all seems so unnecessary, it has multiple steps in many cases, and is a ton of work for excellent functioning, "legacy" systems that happen to run a company superbly.
If you can achieve the same results of modernization with simply using a 4GL directly on iSeries data, why not (whether in DB2 or
QS36F) ? And IBM never supplied the web and PC interface to RPG, so you ultimately have to do .. something. The alternatives are 4GL, or only web-PC interface languages added to your RPG, or semi-kludge (not meant to be offensive) fixes like Open Access.
The 4GLs tend to incorporate the web-PC interface into their basic engine, so I do believe they have a conceptual advantage over the attempts to help along the RPG with the last few years of jambalaya. In other words, you end up with a single-unit programming environment for new projects.
Incidentally, Joe could indicate whether, when he develops a new app with EGL, he uses RPG at all, and if so, precisely where he moves back to RPG. Apologies if that has been asked a few times before, but it would help in evaluating the relationship. Maybe you end up using RPG as a .... "report program generator" :) .
Nathan
It might help if readers knew more about where you're coming from in
order to clarify your meaning. If I recall correctly you developed an
RPG II ERP system with internally described screens and files and have
managed to earn a living maintaining it for something like the past 30
years for small customer base. Now it appears that your product is
increasingly being marginalized and apparently adrift while facing a
PC-Web wind. Is that a reasonable conclusion on my part?
Steven
See above. Unless you felt you had a superb private toolkit of progam generators or templates, or were copying over an existing app as a starting point, why would you develop a new app in RPG instead of a 4GL ? This is not meant combatively, but sincerely. Is there a reason ?
And if you are not going to develop new apps in RPG, and have a base of RPG running in ancient mode, why would you spend a year's worth of man-time to "modernize" the RPG. (e.g. All the way up to RPG-ILE with external screens.) What is the big gain.
Joe Pluta makes a solid pitch for that 4GL being EGL (and yes, that has longevity in the same manner like Lansa, Magic, and WinDev, if you know of others that really have that full implementation without too much language complication, share away) . And we might see other ports of long-range 4GLs to be comfortable running on iSeries. We do see many attempts in the SQL inquiry-type products, but they can get bogged down in things like the Java interface internals of communication, so that while they work, they do not place a moderate-tech end-user in a very comfortable position. That is, they were not designed for direct support of iSeries in the way that iSeries utilities are (or program systems like MRC and NGS). There is a vast difference in installation and long-term support concerns. EGL does not have that negativity, I gather, being now more or less a native iSeries install. My point is that the only products of real interest are those that have many years of native iSeries support.
John E. makes some points about EGL being late to the party, and I think that is appropriate, and he mentions the architectural concerns of the 4Gl being in a sense data driven. EGL came to the party after a number of IBM iSeries hesitation, and the Visual RPG failure, and it brought together an unusual marriage of environments. Joe supports it nicely, others tend to be a bit skeptical, but I agree that it sounds like it needs a fair shake as a 4GL alternative and may give it a look-see. Incidentally, Joe, please indicate whether you know if the EGL data dictionary really cares about the data being in DB2 or flat file QS36F.
Nathan
If so, then you should be given some credit for a legacy product that
has withstood the waves of change during the past 30 years. But you
should also give some credit to IBM and the RPG compiler team for the
longevity of your product.
Steven
Yep, I agree. The RPG compiler is rock solid. I can debug anything even with the ancient print debugger (which often seems more effective than interactive). The language is well matched with the control language and the OS. That is why it was such a shame that IBM never did the direct and proper attempt at enhancing RPG direct to the net and PC.
Nathan
You shouldn't complain that IBM has not provided a completely
seamless modernization path for it, or complain about the cost of 3rd
party alternatives. It appears to me that you've already gained
remarkable value from your relatively small investment.
Steven
In terms of current analysis, I think this is a bit of a non sequitur. I still tell the execs that the "new system" alternatives from the golf course friends are pie in the sky, and would like cost many $$ for nothing. (And they understand.) Our system runs a food importer impeccably. However that does not mean I have to avoid the plain truth about the lacks in RPG. The point is ... I am not even going to go to RPG-ILE because I still end up largely dead-ended, even after a ton of work, even with all sorts of tools. What IBM did was incomplete. Joe argues for EGL, an IBM-friendly 4GL, filling the gap, I say that 4GLs in general fill the gap. Some techies love to show what they can do in their personal implementation of CGI, PHP, Java or other tools, but I think that is only sensible for an enterprise set-up where they really like having the programming group with a wide range of overlapping PC-web skills. e.g. If they are doing a bunch of website development independent of the iSeries.
Nathan
And you should show more respect for how the IBM i platform and the RPG
language have evolved over the past 30 years while you and your
customer base chose to continue operating within the confines of the
S/36 environment.
Steven
Well, if I came off as disrespectful, I will apologize. The fact that I can run the code from 25 years back perfectly today is truly amazing, and it gives a system that is up 24/7 and runs a medium size business with a relatively small crew. However, again, I do believe that IBM missed the boat on moving forward.
Nathan
It would really surprise me if your customers didn't chose some cloud
offering providing support for tablets and mobile phones, while
retiring your RPG II code base sometime within the next 5 years. IBM i
and RPG are well positioned to play a role in what is quickly becoming
a post-PC, cloud services era. But legacy systems are not.
Steven
Tablets and mobile phones are not our issue, however, and I do not think that has a lot to do with the overall discussion, which is more simply .. modernization, web-friendly, PC-integration-friendly, and new development easy. If IBM had made RPG a full-orbed language, then RPG templates and code-generators and 4GL shells would be in the marketplace. IBM did not, thus all the discussion about EGL, open access, the web languages, and robust 4GLs running on iSeries data.
Feel free to tell me what I am missing.
Steven Spencer
Queens, NY
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
