Re: UI design and build -- MIDRANGE-L

What you described is what my team is doing in the IceCap project with a
7ms response time ( faster that ACS)

However we are combining the dds and the “live” 5250 stream to a JSON
structure

That means-
1) you can run all your code without any changes
2) you can “morph” that JSON to angular/ extjs/react to create a mvvm

Your issue here is not the ui. The issue is that traditional RPG display
file handling it turns the inside out of the logic compared to REST that is
your goal

We have made a runtime environment for that in Icecap. And I will share
with you, that- for all the reasons that REST is promising- it is 90
degrees on a 5250.

Having said that. The RPG logic is good and solid. But you have to turn it
inside out.

Yes - icecap is a commercial product, however I can and will help you- with
the open source tooling we have made in this space to accomplish your
ideas.

You can get far with the open source tooling.

If you need help- you can always contact me and

Btw .. Jon knows what I am talking about- he asked me to make it open
source…

ons. 28. maj 2025 kl. 16.59 skrev Daniel Gross <daniel@xxxxxxxx>:

Hi Jon,

I really hoped, that you would jump into that discussion.

Today in my lunch break I wrote a small OAR handler that just loops
through that funny namesValues structure/array and sends out the data as
name-value pairs to the job log.

It wasn't so hard right now - I'm still asking myself, how this open- and
io-feedback areas should be defined, to they can map back to RPG - but
that's another story.

My idea is plain simple - just ignore everything that is in the DSPF DDS
description, and only use the externally defined record formats and fields.
Map those fields and values to a template engine and and back from the
form-variables into the fields.

In the end you maybe have to change the program code anyway (at least the
handler keyword) - and I don't think it makes sense to have a general 5250
mapping, as this is a) complex and b) in most cases ugly. So one should
redesign the screen for the web anyway.

Maybe a one-way "generate-me-an-ugly-template-from-this-DDS-source" tool
might be nice - but it's icing on the cake, not the basis.

The rest would be up for someone who loves HTML/CSS/JavaScript and who can
help with some basic templates and maybe a rendering engine. That could
practically be PHP if one likes.

And of course we would need some infrastructure that implements a
web-server and handles the sessions.

Personally I wouldn't mind, to redesign the new web-screens with a lot of
<div> tags and classes - as long as that is somehow easy to use.

In the end it would be: WRITE out all the records you need and do EXFMT to
kick off the HTML to the user and wait for the response.

I'm trying to bring my thoughts to "paper" in the next 1/2 weeks, and
would love, if some of the RPG and web programmers would jump on board and
help.

Thanks again for your comments and the links.

Kind regards,
Daniel

Am 28.05.2025 um 13:22 schrieb Jon Paris <jon.paris@xxxxxxxxxxxxxx>:

"And we already have that - kinda - with OA-RPG a handler could do

that, but a handler is a complex beast, so you would write it one-time and
reuse it with every screen."

I wrote up an example of a simple OA handler for the web and wrote up my

conclusions in a series of articles on Open Access. You can find them here:
https://authory.com/JonParisAndSusanGantner?collection=Open-Access-c6442821ee733408f8374c62e3d0bfdad

In particular the article ""Webulating" Printer Output Revisited"

outlined my ideas for a very simple OA web handler. In summary, an OA
handler that can deal with any and every 5250 program ever written is VERY
hard to do. It would be way, way cheaper to buy one from a vendor. If
anyone is interested I can spell out the details of why this is, but we
should probably start a new thread on the web list.

BUT ... it is my view that an OA handler could be developed relatively

easily providing that there is no intent to use it for anything but new
programs. By using the name-association approach I outlined in that article
the logic of the handler can be pretty simple.

Any project that wanted to dig deeper could start by looking at the work

done by my friend Pascal Polverini who proposed the idea of a DDS
replacement under the banner Open Access Definition Standard (OAMOS). Sadly
it went nowhere and its website seems to have disappeared. You can read
about the idea here
https://authory.com/JonParisAndSusanGantner/Life-After-DDS-a954c0b3cb7514babad3740ca7b62c199
one of the Open Access articles in the series mentioned above.

Jon Paris
Jon.Paris@xxxxxxxxxxxxxx

On May 28, 2025, at 5:41 AM, Daniel Gross <daniel@xxxxxxxx> wrote:

Am 28.05.2025 um 02:41 schrieb Infodorado InfoDorado via MIDRANGE-L <

midrange-l@xxxxxxxxxxxxxxxxxx>:

Thanks Raul.
One program per screen. Absolutely better, IMHO. Modular programming.

One program per screen - nice idea, but with CGI you often need 2

programs per screen. One that creates is (at least if your screen is not
something trivial like a static HTML form) and another program to receive
and process the user input - and maybe send something back to the user.

Of course you can do that in one program - but those are completely

different and even completely non-related processes, and your program
terminates between both processes.

One program per screen with the EXFMT programming model would mean -

your program defined the output - EXFMT - and processes the input. Looks
like "KISS" to me - especially as it keeps logic together, that should be
together.

Am 28.05.2025 um 01:32 schrieb Raul Alberto Jager Weiler <

raul.jager@xxxxxxxxx>:

I did suggest to IBM to add new "DEVICE" :web, to use whith an html

mask

instead of dds. ( it got rejected)

And we already have that - kinda - with OA-RPG a handler could do that,

but a handler is a complex beast, so you would write it one-time and reuse
it with every screen.

What I suggest would be:

- using the DDS only for the external format descriptions - do NOT

process any DDS keywords, constants, messages or anything

- use a "web-template" - referencing those external formats from the

DDS - again only to have field descriptions (data type, length) -
everything else is defined new in the web-template

- use a handler to combine both

- use an rendering engine that creates real HTML/CSS/Javascript from

your web-templates that looks modern and nice - based on some JS framework
out there.

For the web-template I don't think of HTML directly - but more a

lightweight description language that defines "screens", "parts of screens"
(-> DDS record formats), "fields" (-> DDS fields), "indicators" (-> 01-99,
fields or via API), "constants" and "attributes" (like editing, checks,
etc).

Some markup language (maybe similar to Markdown, XML or JSON) would be

easy to learn - but using HTML directly should be an option, to be future
proof.

Last but not least we would need some API to manipulate things in the

web-template directly, that DDS doesn't have - like BLOBs or other things.
But that would be the cherry on top.

It would merge the "traditional" transaction oriented process model

with web-tech - and like Profound.UI could gain some traction - especially
if it's open source and free.

Regards,
Daniel

Am 28.05.2025 um 02:41 schrieb Infodorado InfoDorado via MIDRANGE-L <

midrange-l@xxxxxxxxxxxxxxxxxx>:

Thanks Raul.
One program per screen. Absolutely better, IMHO. Modular programming.

And for goodness sake, put oft-repeated code routines into a subfile or
better yet a subprocedure, or if it's code repeated across multiple
programs put it into a service program already.

I can understand the early monolithic type programs, because of the

performance considerations.

--Alan

On 05/27/2025 7:32 PM EDT Raul Alberto Jager Weiler <

raul.jager@xxxxxxxxx> wrote:

Making one program for each screen makes the development easier
and faster, it also simplifies maintenance.
It is aso important to adhere to the KISS principle.
My issue is they are not price competitive for small

shops and folks like me that would not be building significantly

large > > >> applications.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.