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

We started by rewriting/refacing/whatever the applications that were used
most by employees that tend to be new. So the applications that are done
in offices out in the warehouse were modified. We started 15 years ago so
we chose Visual Lansa. I love using LANSA so I would still choose it
today. The apps are still running strong.

This worked great for us with high turnover employees and training.

The "Back office" apps where employees tend to stay longer remained the
same because green screen works. We upgraded most output to offer CSV or
PDF output via email. The users sometimes like to move their reports
around with excel. It's a freight/warehouse company, so we need tracing.
Those applications used externally by the customers were written using
LANSA at the time. They are browser based. They all run on the IBM i.

When my customer bought a new imaging system, we used the IBM i to use the
imaging web service to grab the images from the microsoft server and put
them on the i so we can show them with the lansa tracing. We show BOL's,
signatures, drivers licenses on the customer web app. Most internal users
use it as well, but the green screen tracing is still available.

We use Java running on the i to convert our TLAshford label formats to
JPEG's so we can combine them into one document. The i makes all the calls
and we use imagemagick on the i to manipulate the images.

Today are using the latest version of LANSA to rewrite some "gun" scanning
programs to run on android or iOS devices so we can take pictures of the
returns for claims. It's going to take a month or two. LANSA handles
showing the app on browser or mobile. The rewrite isn't completely new
code, we modify the green screen programs a little to let them run
headless, we pass fields back and forth. This helps later if we choose to
use another product, the back side code is still usable.

The point is that things are modern. Our new employees generally use a
windows GUI. To print manifests, our back office users scan a barcode to
the green screen and the manifest prints beautifully on a color laser, it
includes the signatures we have on file for the users.

We send customers data any way they want, EDI, CSV, Excel, XML. We send
via FTP, VAN, FTPS, AS2, anything. We process inbound transactions from
customers anyway they want also. Our customers use our website to to get
POD's often before the look to see if it's on their system.

Wow that was a TL:DR maybe.

Art




On Wed, Dec 13, 2017 at 12:53 PM, mlazarus <mlazarus@xxxxxxxxxxxx> 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

On 12/13/2017 7:56 AM, Nathan Andelin wrote:

Mark,

In fairness to Tim and other folks at IBM, it has been my experience that
when organizations migrate to Windows or Linux and Intel, it has little to
do with the fact that IBM hasn't provided a GUI, or bundled it with the
operating system. The real problem was that the organization ran into
constraints within (in order of priority):

1. A legacy database (e.g. dates stored as 5-digit numeric; the list goes
on and on).
2. An application architecture that was resistant to change.
3. An IT organization who failed to respond to new requirements in a
timely
manner.

In regard to the IT people, the nail in the coffin that sealed their fate
was their proposal, or adoption of a screen scraper, and an attempt to
cover up the more relevant issues delineated above.

It had nothing to do with the cost of the screen scraper. It always costs
a
lot more to migrate to Windows or Linux. In addition to the migration
cost,
the ongoing operational costs are higher.



On Tue, Dec 12, 2017 at 8:39 PM, mlazarus<mlazarus@xxxxxxxxxxxx> wrote:

Tim,

I was discussing this subject recently with a very respected member of
this group. We were both confused how turning over a crucial, and I do
mean crucial to the longevity of the system, piece of creating a modern
UI
is turned over to third party vendors instead of being fully integrated
and
included in the OS.

Some vendors have done an admirable job creating a product, but IMHO,
it's ridiculous to have to pay a large bundle extra to get what should be
included and easily integrated into the system. It is also more
expensive
to develop using (at least) some of these tools. My estimate is at least
25% longer to develop and test.

I have three clients that are jumping ship to a PC based platform,
another that has already gone in that direction (they used to have the
largest AS/400 config in the US northeast (which included 14 AS/400's)
and
another is in the midst of moving part of their operation to a PC based
cloud system. I haven't heard of a new member to the midrange fold in a
long time. I would imagine that they exist, but I think that 20+ years
after the GUI became popular, for IBM not to include this required
functionality, plus the GUI development tools as part of the base OS, is
just plain foolish.

No offense to the tool vendors, but I believe that this functionality
is
best integrated at a low level in the OS, not as a generic API in order
to
get the best integration, debugging and performance.

-mark

On 12/12/2017 10:44 AM, Tim Rowe wrote:

Yes!! Moving from Green Screen to a Mobile or Web based interface
is
being requested by many. Not just your either. In todays world its
really
becoming a necessity. That is one of the reasons that the IBM i
team
has
been investing in Open Technologies that are being created to
interface
with our existing back end programs. Its why we have REST Api
engines
that
are delivered with the operating system. To allow our IBM i
customer
to
move in to this 'normal' world. Not only do we have many options
that
allow you to do the work, we have a wealth of great ISVs that
provide
tooling to help you make this transition in a fraction of the time
while
in many cases leaving your existing code virtually untouched. If
you
are
interested in getting a view of some of these ISV, please send me a
note
and I can get you a list.

Or if you need more info on the options in the Open world for IBM
i,
please let us know.
Tim

Tim Rowe, timmr@xxxxxxxxxx
Business Architect Application Development& Systems Management
for
IBM i

IBM i Development Lab, Rochester, MN
(507) 253-6191 (Tie) 553-6191

http://www-03.ibm.com/systems/power/software/i/are/index.html



message: 2
date: Tue, 12 Dec 2017 12:19:29 -0300
from: Raul Jager<raul@xxxxxxxxxx>
subject: Re: Moving from Green screen app to GUI because of push
back
from younger employees?

Go ahead with the change.? Go to web.

We began the change 20 years ago. Some user where against the new
interface, and we had to restrict the green screen, but when we
put
it
back on, the users stayed with the web.

Once we learned to use the web, none of the programmers wanted to
do any
more green screen programs.? The web gives a lot of resources ,
and
frees from the limit in the size. You can replace one program at
a
time,
and run "hybrid". Usually, by replacing just a few programs you
will
take most of the work to the web.

We use CGIDEV2.? It replaces the "screen" with a "mask" in html
and
the
RPG logic remains very similar.? (assuming you have small - one
task
each - programs)
A good web designer can do the "presentation" without knowing
RPG,
and
you can use it with minimal web knowledge.? Basic html is simple,
but
not spectacular. Even so, it is better than green screen.

On 12/12/2017 11:04 AM, Ken Meade wrote:
> I had a request to update our interface from a green screen
application to
> a 'more modern GUI' because of an inability to keep new
employees
because
> of the look/feel of the green screen apps and the ability to
more
easily
> train them if the look/feel was something they were more
familiar
with.
>
>
>
> I'm just curious if others have run into this as a reason to
'modernize'
> their applications.
>
>
>
> Thanks,
>
> Ken Meade
>
> Director of Information Technology |
kmeade@xxxxxxxxxxxxxxxxx |
> 603.444.3570 |
>
> 1309 Mt. Eustis Road, Littleton, NH 03561
>
> microsoft windows sharepoint services logo
>

**********************************

--
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