Re: 'green screen' not sellable --> WE(?) are the problem -- MIDRANGE-L

Scott

Everything you write can also be done in screen scrapers like IceCap
(IceBreak) without RPGOA or changing a line of code in the basis 5250
program. How they (Niels/System & Method) do it I don’t know but he/they do
it!

To me RPGOA’s fixed interface represents a bottleneck exactly like the OPM
way of passing parameters into a javascript function (yes there is also an
OPM in javascript) with a predefined parameter list where we today just
parses a single JSON object that besides data parameters also may contain
executable javascript code.

The same goes for AJAX where a server may return executables to the request
telling what the result should do by injecting code in the javascript AJAX
object without predefinition. This is however probably far beyond what
“normal” programmers will do, but still it is done in advanced FDA’s.

On Mon, Jun 15, 2015 at 6:51 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Just to add one extra note to what Scott has said.

Once OA is in play many of the limitations of the 5250 model disappear.
Why? Because they were never imposed by RPG but by Workstation Data
Management (WDM) - and that is no longer being used.

For example when using OA you can write more record formats to the screen
than would actually be displayable on the real device because overlapping
is not a problem. In fact OA provides no row/column information.

Similarly should be possible for an OA enabled program to read from a
record format that has not been written the display. Again that limit was
imposed by WDM and so disappears.

It seems to me that many of the supposed drawbacks of OA are due to
people’s knowledge of the limitations of the 5250 stream and the ensuing
assumption that an OA program will have the same limits - but the minute
WDM is removed from the picture a lot of that disappears.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jun 15, 2015, at 12:00 PM, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Hello Henrik,

I think we've said all there is to say about the security side of

things, but I will address some of your other points.

On 6/14/2015 1:14 PM, Henrik Rützou wrote:

1) RPGOA. If customers just want a browser based GUI why not just screen
scrape their 5250 environment? There are very advanced screen scrapers
today that require no rewrite of 5250 code.

Because screen-scraping is limited to what can be put on 5250 screens,

and RPGOA is not.

Imagine you want your RPG program to calculate some tooltips visible

only on a mouse-over. Or perhaps your program wants to control the color
or font of data on the screen. How do you do that?

In a screen-scraper, the only way you can communicate between the RPG

code and the GUI is by placing data on the 5250 screen. So if you want a
tooltip, you have to write the tooltip as a string taking up space on the
screen. The GUI can then hide that data (maybe by applying a CSS class
with visibilty:hidden) and use JavaScript or whatever to load it into a
tooltip over the GUI element. This is clumsy.

With RPGOA, you can connect variables in your record format to anything

in the GUI. They are just variables being passed across, they do not need
to be printed on the screen. So you just tell the GUI to read the tooltip
from the field in the record and you're done. Same would be true for
colors, fonts, etc..

Those are just very simple (maybe too simple?) examples, of course.

Suppose you're loading data into a chart (such as FusionCharts) or need to
provide a picture of a product, where the image file referenced might be
different depending on calculations in the RPG program... same thing.
With RPGOA you can set a field in the record format to point to the image,
and connect that to the "img src" property in your web screen. With a
screen scraper, the only way to communicate is by printing data on the
screen itself, so you'd have to put the URL on the 5250 screen, hide it,
and load it into the image, taking up valuable real estate.

Another problem with 5250 screen-scraping is that you are generally

stuck with the limitations of 5250. Suppose you want to create a subfile
on the screen with 50 records per page? Can't do it, the 5250 screen will
only support 24 or so lines per page. Or maybe you want to have more than
132 columns? Same problem.

Yet another problem is identifying which screen to show. In RPGOA the

program executes a record format, and that's what's displayed. In
screen-scraping, however, the GUI has no clue whatsoever what your RPG
program is doing. It doesn't know which record format you're displaying,
so you have to tell the GUI to look for strings on the screen. "Look for
'APRZ001F' in position 61 of row 2, and that identifies this screen".
That's how screen-scrapers do it -- and that works fine if you always have
identifiers like that, and nobody ever duplicates them... but when
someone accidentally duplicates one, or when you have screens (including
the ones in the OS) where there are no identifiers, you can have problems.

Also, the GUI doesn't know the field names of your fields on the

screen. Imagine that you want the GUI to show a drop-down on the screen
instead of an input blank... all screen-scrapers support this, but do you
think you can go and say "I want to change the PRODCODE field to be a drop
down!" No, you can't do that, because the GUI has no idea that the field
is named PRODCODE. The 5250 controller told it "put a blank in row 5,
column 10" (or wherever it happens to be) and that's all... it doesn't know
the field name, so you can't use that field name in your GUI. Whereas in
RPGOA you do know the field names because you see the actual record format,
so you can use the same names in the GUI that are in the RPG program.

Screen scraping is a useful tool because it lets you incorporate screens

that you don't have the source code for, or are written in languages that
don't support OA (CL, Cobol, etc) or for things like the operating system
screens (WRKSPLF, WRKACTJOB, WRKUSRJOB etc are sometimes incorporated into
people's applications.) It also gets you up and running very quickly.

But it is limited and clumsy by comparison to RPGOA for the same screens.

2) RPGOA. Since the UI CGI programs and the REST(CRUD) services are
totally separated the REST(CRUD) service doesn’t know what information
(fields) that are passed to it. In the same time the UI CGI programs are
“design” driven based on the user settings. This means that the same UI

CGI

program may generate a form with 5 fields for one user while another may
have a form with 100 fields both using the same base REST(CRUD) services
for data handling.

This can be done from RPGOA as well. You can write a screen, display it

with EXFMT, and that screen can contain JavaScript that does AJAX calls.
We provide both REST and SOAP JavaScript APIs in our framework.

Or, instead of coding the web service calls in the screen itself, you

could do them from the RPG program that drives the screens using tools like
HTTPAPI or IBM's IWS, or the various commercial tools out there for calling
web services.

It's true, this does mean re-writing your screens instead of just

re-using the existing 5250 ones... but we have customers who have done
this with great success.

Using RPGOA/EXFMT will not tell the REST(CRUD) service which fields that
are passed to the handler. Using CGIDEV2 mydata = zhbGetVar(‘var1’);

will

neither. But powerEXT’s mydata = getExtVar(‘var1’:mydata); will search

the

input buffer for the variable and if not found return the default value

in

parameter 2 to the input field.

Typically customers would put text boxes on the screen with the default

values, and set visibility:hidden so the user can't see them... then they'd
get the default values back into their programs. That happens very often,
and it's easy to do. They can hide/unhide fields based on their RPG logic,
so can put out different numbers of fields for different users/situations.
This could be done by connecting the visibility to a field in the record
format, or it could be done with some JavaScript code on the display.

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

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