No, it's just bending the rules of the block-mode UI concept that drove
business throughout the 70s, 80s and even the 90s, and still survives
today. Block mode is very efficient - it allowed remote processing on
1200-baud modem lines; there aren't many web application architectures
that could do that today. 5250 isn't particularly good for
high-bandwidth glitz but it works just fine for presenting textual data
to end users and getting their responses.
Ha! Thanks, Joe. Pretty slick. I hadn't thought to do this with multiple
Still feels like using a hammer to drive screws into the wall, though.
Reality is for those who can't face Science Fiction.
Dennis, here's the IBM book on the issue. Not terribly helpful but it
gives you the basic idea.
The idea is that if the entry on the data queue is *DSPF, then READ the
display file, otherwise do whatever the entry says (which in this
business case would be to upadte the data and WRITE the display file).
Great to hear it's possible, Jack. Care to elaborate on _how_ one
would post updates to the 5250 screen (barring status messages, which
are too limited to satisfy the need) without flicker, flash, or
disruption to user input? That is a challenge for which I have never
seen a solution with the
(naturally-blocking) 5250 display.
"Never lend books, for no one ever returns them. The only books I
have in my library are those that other folks have lent me."
-- Anatole France
Not only possible with RPG and 5250- it's been possible since IBM
enabled display files to post status changes to data queues. FWIW, I
believe that feature was introduced on the System 38 from the
research I did supporting an such an application 12 years ago. Said
app was at least 10 years old at that time.
Was an undocumented maintenance nightmare until I used object
auditing to trace through the event chains, but I came to appreciate
it as one of the most elegant designs I've seen implemented on the