Re: UI design and build -- MIDRANGE-L

Daniel,

If you haven't already done so I strongly advise you to download and use my OA template program. All the fundamental logic including state preservation is there. Don't waste time re-inventing the wheel - improve the design of the tires or add magnesium trims or ...

Other comments in-line.

Jon Paris
Jon.Paris@xxxxxxxxxxxxxx

On May 28, 2025, at 3:55 PM, Daniel Gross <daniel@xxxxxxxx> wrote:

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.

Re feedback areas. Forget them. If you are thinking of using them then (in my opinion) your approach is wrong becuase you are trying to handle too much. People like Profound spent many mnay years and mullions of $s building "do everything" handlers. If you think you can do that yourself ot just means that you haven't realized all the potential problems you face.

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.

The first para is the right idea. But realize that even then if you do not restrict DDS usage you still have issues. Just to name a few.

1) You basically can't easily use indicators because the handler won't know about them.

2) Overlapping fields. Nope - the handler will see both and have no idea which to use

3) Edit codes. Nope - you won't see them so you have to find some way to handle that

4) Without using naming conventions you can't tell a subfile record from a subd=file control, from a ....

This is just a tiny fraction of the potential problems. Hopefully this makes it a little clearer as to why I said you need to design for NEW programs with no thought of simply adding a Handler keyword and repurposing existing ones.

By limiting it in tnis way I think you have an achievable project which onve proven could grow.

Pascal's tool suggested using XML as the carrier mechanism - these days I think JSON makes more sense. He is willing to share the code he developed and his documentation covers a lot of of the pitfalls that need to be dealt with.

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.

I just used Apache in my experiments and the OA handler already provides for session date.

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.

You're welcome. Keep it simple, KISS really is the way to go with this. Evolution not revolution.

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.