For years we have been hearing of its demise, even IBM tried to drive a stake through it’s heart with the much fangled Java? but ye old 5250 emulation, also known as green screen, and the programs written to run on it just won’t die.
After eleven years as an administrator, programmer and manager using the AS/400 and now the IBM i Power System, I still hear that frequently murmured phrase; green screen what? Frankly people need to realize that to do things the right way it’s about using the right tool for the job.
It’s not new, cool and it is definitely not sexy. The CIO might not like to talk about it at the IT steering committee meetings, but the character based green screen programs excel particularly when it comes to heads down data entry which typify most development on the IBM i. That is just a fact.
Do you want something flashy and alluring or something that actually works?
Now I fully admit there are times when creating a program with a web based interface is the best method to deploy, like an application for customers or dealers to place an order via the Internet. A web browser is what they are used to and have come to fully expect when online placing orders.
Could you imagine the nightmare of trying to buy your favorite novel if Amazon’s ordering process was built using green screen? I thought not, and neither do customers, vendors and business partners.
Likewise you can administer many aspects of the system using i Navigator, and for some stuff It’s a great program with many added benefits over 5250. But can you imagine trying to use Dedicated Service Tools to replace a failed component or ending a runaway job using a web faced system where the whiz-bang toolbar of the month keeps crashing the browser or conflicting with version of Java installed.
These are extreme examples to prove a point, when it comes to working with jobs I will take the Work With Active Jobs command on good old green screen any day. It’s quick, efficient and it is the right tool for the job.
Now by no means do I advocate hanging around in the stone-age either. Not that long ago I worked with a distribution business that was running entirely on custom RPG II programs in emulation and never actually touched the AS/400 side except to do an IPL. The programmer never kept up to date and was actively cranking out RPG II programs instead of porting them over.
That was a huge disservice to the company and set them way behind. They couldn’t even benefit from using old tools like Query to write reports.
If you are a programmer or administrator using the IBM i it is way past time to get with the program and learn the web based frameworks, graphical programming tools and modern uses of the RPG language. Green screen is not the enemy, but it is not the cure all either.
Here, I think, you have just hit the nail on the head.
End users, business users have come to expect – and rely on – the visual cues that they get from a graphical environment. For these people, we should be putting together applications that meet our customers expectations.
For those of us working in IT, however, we should understand the command line and should be able to find our way around a 5250 screen. If you can’t, you’re not doing your job properly but if you can, the 5250 interface is often a lot quicker and more effective than the various client side tools.
However…
Really? Maybe I’m misunderstanding your comment here but your characterisation of development as being heads down data entry surprises me – a lot.
I would say that for most modern development, you need to first understand how your bit of code fits into the available framework. For program maintenance, you need to understand how the original program was structured. You may be able to achieve this understanding without using an IDE, but you will be a lot more productive if you use one.
The shorter version of all this is that, while I agree that we should be thinking more about which tool is the right one for the job, I suspect that there will some disagreement over which tools are right for which jobs.
It’s a conversation that needs to be had though.
@ExpatPaul
Thanks for the comment. In regards to heads down data entry I meant from the end-user finished application side of things, not exactly the actual development when it comes to writing the software.
I think you also re-inforce my point. I have culled resumes and interviewed a fair share of programmers for the IBM i and to find the person with more than just CL/DDS/RPG experience is a rare find, thus most programs are done the same old way simply because the developer has not bothered to keep up with change.
-John Andersen
Hi John,
I do agree with the core point of your article, that application modernisation is about identifying the right tool for the job rather than simply jumping on whichever bandwagon appears popular. Or avoiding every bandwagon you can.
I have also encountered programmers who can’t – or won’t – move beyond programming techniques or approaches that were looking dated 20 years ago. It may be easy to stick with what you know but I do think that the people doing this are shooting themselve in the foot – these are the programmers that are invariably the first to go when the next round of layoffs comes around.
As for heads down data entry, I’m not sure I would use that characterisation but this is just a semantic difference and, therefore, of no consequence. I certainly agree that, for people in IT, the most appropriate tool for the job may well be a green screen application.
Thanks for the clarification
-Paul
Where are your users doing a lot of heads down data entry? That space should be becoming smaller and smaller. Why? Because businesses that are modernizing aren’t paying staff to do order entry or customer service master file update and instead are allowing customers to make the changes themselves via the browser.
Note I am a HUGE fan of 5250 for admin tasks and a few other things, but much of new dev should be going to the browser. Not because the browser is better but because we get to live in the reality of perception. If we live in the reality of perception then IBM i stays relevant.
AaronBartell.com