Re: 20 years ago -- RPG400-L

I'll comment from my perspective on a couple of Reeve's points. As an IBMer during some of the time period covered I have a slightly different perspective.

On Aug 17, 2022, at 5:03 PM, Reeve <rfritchman@xxxxxxxxx> wrote:

Chris, I understand why: a non-text interface is hugely more flexible and
the constraints of the 60's and 70's (kilobit data lines, limited RAM,
limited developer tools) are gone. The development work that led to the
System/38 wouldn't have been possible or made sense if some in IBM hadn't
recognized that data speed, memory, and CPU performances were going to
increase at a staggering rate. I used 3270's for CCP and did crazy stuff
to get good response time on 4800 BPS dial-up lines. Advancements in the
hardware domain is the big reason the efficiency of a text-based display is
no longer a factor.

Second reason: IBM wanted to sell Websphere. The 5250 market was hammered
by 3rd party hardware; Websphere is soft and licensed--you can't go wrong
if you're the licensor. Don't forget follow-on hardware!

Third reason: by charging for interactive seats, IBM somehow made 5250 look
better than before.

Au contraire. They wanted to make 5250 more expensive to encourage a move to browser-based and/or otherwise connected apps. There was almost a desperation among some executives to do anything to help shed the old-fashioned and legacy labels being throw at us by the competition who at the time were offering mostly networked Windows "solutions". I sometimes suspected that (not in Rochester) there was also a feeling of "we might as well make more money from those who can't/won't update".

The conspiracy theorist in me thinks factions in IBM blocked additional
development in Open Access for RPG to prevent native handling of HTML *without
requiring 3rd party applications*.

I think you have two separate points here - and this first one I think is just plain wrong. OA was developed as far as it was ever intended to go. I don't recall ever hearing of any pressures to restrict its development. It was always intended as an enabler for ISVs and for large shops who would build their own handlers. Those ISVs had already expended millions of $s enhancing "screen scrapers" and one of the objectives of OA was to allow them to go beyond the 5250 model.

I realize 10,000 vendors are now typing
emails of protest--but my 5250 support came bundled with the compiler and
OS; why shouldn't full HTML as well, with comparable tools, utilities, and
compiler features?

Your system came complete with Apache and full browser support too. IBM made a number of attempts over the years to produce tooling that would facilitate the development of web and/or network based solutions (VARPG, etc.) but the IBM corporate types were so firmly stuck on the notion of Java/Websphere as the salvation of the world that everything had to be slanted that way in order to get funding. And that broke the simplicity mold at the heart of conventional 5250 apps.

In my opinion had IBM done what you suggest it would have been a miserable failure. It would have been over engineered and overly complex and simply been ignored by most shops. In addition, which Javascript library should they have blessed? By the time they had done anything all of the ISVs who had browser based products had already made their choices. Guess what - they all chose different ones or in the case of Profound built their own. That, by the way, is what IBM would have done because there was a strong "not invented here" bias still in those days. Then of course they would have been roundly criticized for not going with industry standards. They were on a hiding to nothing and in my opinion did the best they could by facilitating a wide range of ISV solutions.

Customer satisfaction with the platform would be
higher, there'd be new blood in the developer community, and IBM would have
a fiercely loyal customer base willing to pay premium rates. IBM invented
the midrange market *and they killed it*. I guess it was...too old (a dig
at IBM's age discrimination troubles).

Open Source has bought new blood - and it is about the only thing that could have done so.

As a vendor, I'm seeing little consensus WRT modernization (specifically,
the UI) technology approaches. Some are enamored with Python, others like
a Windows-centric approach, and a few think the world of 4GL and 5GL
products. There are even those who want to convert RPG to Java, and I wish
them a long and happy life (their professional life is going to be long and
it will not be happy). I've made my choice, and it's to focus on the
application functionality and build interfaces that support alternate
UI's. It's my choice as of today!

I agree with your choice and frankly, given the pace of "progress", it is the only thing that really makes sense. If I was to critique IBM it would be that they did not develop tools to abstract and "proceduralize" the business logic in RPG apps to facilitate this kind of development. IWS came too late and only offers a deployment option - not a logic extraction option. There was an opportunity many years ago to develop a tool that would have done this but the IBM owners of the base tooling were not interested in anything midrange and it died on the drawing board.

Having standards put in place by IBM--like 5250 and 96-column cards--makes
budgeting easier (the price may be high but you'll be confident you have
them right). It reduces the breathtaking variations we see in satisfaction
with modernization projects (granted: a weak base system will not modernize
well and coupling application reengineering with a new UI is high risk).
"Blue handcuffs"--we complained but they worked.

I think you are missing the point here that dissatisfaction with modernization projects is not an IBM i thing. It applies to Unix, mainframe and Windows based apps too. The pace of progress and the insistence by some people that just because we can do something is a good enough reason to do it has outstripped all of us. This weeks new and sexy will be blasé in 2 years - such is the pace of IT life these days.

For me, having IBM provide a native HTML interface would remove the
technology selection challenge (and the cost and the time) and would allow
me to do what I do best: deliver high-function, low-cost business
applications. A UI with a full color palette, variable fonts, and
unlimited screen size, all thanks to HTML, would make it fun to code for 60
hours a week.

See my earlier comment - nobody would ever agree on what the native interface should be and we can already do all of this. The companies who haven't already made moves in this direction probably never will and their green screens will live on because they are "good enough"

The best path looks like starting with the HTML up front, building
interactive applications, and using the AS/400 family as database and batch
servers--they're the bots for HTML's Jedi warriors. This approach protects
much of your investment from IBM's business plans, which the prudent
business person will do.

And there you are calling it and "AS/400" while you wonder about the future ... sorry couldn't resist!

Just saying.

On Tue, Aug 16, 2022 at 3:02 PM Hiebert, Chris <chris.hiebert@xxxxxxxxxxxxxx>
wrote:

I've always found it strange the IBM has resisted any updates to the
Display File spec, or even the 5250 data stream in general.

Although we can use DSPATR(&FIELD), then load the field is all the
attributes you want, and get rid of indicators all together.

A DSPATR(&DSPATR02A)
A DSPATR02A 1A P

RPG Procedure parses the input color and attribute and sets the DSPATR
value accordingly.

Dspatr02A = Rtndspatr('TRQ':'RI');
Dspatr02A = Rtndspatr('WHT':'UL');

--
Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author
and do not necessarily represent those of the company.

From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Gad
Miron
Sent: Tuesday, August 16, 2022 11:33 AM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: 20 years ago

Speaking of DSPFs

Some 20 years ago (st. Peppers) I had the notion to ask IBM to let us use

Field attributes indicators in DSPFs in a more straight forward (and self

explanatory) way.

This by adding all 7 attributes of each field ( HI RI CS BL ND UL PC) to

the INDRADA area

Then we could write in the RPG program like this:

FIELD1.PC = *ON (Set on Position cursor for FIELD1)

FIELD2.RI = *ON (light up Reverse Image for FIELD2)

you get the point...

This method will also help with the limited number of indicators.

But, as I have been coding less and less during that time I kind of

dropped it.

BTH, I know that one can map names to each indicators and use named

indicators

But if IBM were to add a built-in support for this feature it would have

standardize all

reference to these field attribute and not leave it to the (lazy , like me)

programmer.

Just a flash-back

Gad
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com