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

Wow.  I am impressed.  Very unusual, or is this a more common story
than I realized?


On 12/13/2017 1:32 PM, Art Tostaine, Jr. wrote:

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