Hello Alexandre,
Am 12.03.2021 um 15:05 schrieb Alexandre Bencz <alebencz@xxxxxxxxx>:
I was studying this manual: ftp://ftp.www.ibm.com/systems/power/docs/systemi/v5r3/en_US/dsm.pdf
Ah, I saw this also. But this describes just the APIs, but not the underlying concepts. I guess, a solid understanding of the 5250 data stream format also helps.
I also did find:
https://search400.techtarget.com/tip/Dynamic-Screen-Manager-lets-you-build-screens-and-windows-on-the-fly
https://www.mcpressonline.com/programming/rpg/techtalk-getting-started-with-the-ile-dynamic-screen-manager-apis
https://www.wachs.dk/tag/dynamic-screen-manager/
But I didn't look closely, though.
I am using DSM, because I thought it would be the best option for what I am developing, I am developing an IRC Client for ILE ...
Wow! I'm highly interested in being a tester. If it is about to run (or being able to compile) on V4, that is.
and the part of the screen where the messages received and sent will be displayed, I would like to update it with each new message received , without interfering in the message that the user is typing ... if that is possible in the 5250 environment, if it is not possible, I believe that making a refresh button would be the best alternative
Commonly, people say, it's not possible. With support given by IBM, you can fake something similar by using the display invite facility. I've not yet taken time to tinker with it.
Usually, the application program is blocked in the read call to the DSPF (state DSPW in wrkactjob). With display invite, the read call can time out. Your program continues and can refresh the display. In addition, interrupt keys (enter, PF, etc.) can be used independently of that timeout to continue processing.
Open questions for me are:
Is the keyboard locked for an invited display, so text can't even be entered into fields? I assume, it's not, because invite was meant as a way to have one program service many display stations. That description smells like 3270 world's CICS handles conversional transactions. It's hard for me to come up with a use case for that facility. From what I've read on multiple sources, invite has been used most often as "auto refresh" facility for single display stations.
If the keyboard is not locked and a timeout occurs, is the terminal in question involved in that timeout or not? If it is involved, text entered into fields *might* be passed to to the application and your plan is feasible. From what I've read, I deduct that the read call to the display station is just cancelled on the host side. So, text entered into fields will not automatically reach the host, because Enter has not been pressed. And if your program cycles to the next invited READ, it most likely refreshes the display with a WRITE, and all entered text is gone.
5250 and 3270 screens can be seen like plain old HTML forms, without JavaScript: If you tell the browser via META tag to refresh the page after x seconds, entered text is AFAIK also lost.
This is one of the occasions where the resource saving approach of block communications (instead of character wise screen updates as with vt100 on common platforms) possesses restrictions on interactivity.
But for the sake of an interactive program like IRC, you can work around these restrictions by using invite on the main display, where the actual scrolling text is showing. This updates every other second or so and you'll see new messages in a timely manner.
If you want to respond to a message, you can press a command key of choice. The program will see the appropriate indicator is being set and can handle this non-timeout even appropriately. It displays a window with an input line *without* invitation. The user can type his text and send it with enter. As he types, there is no refresh of the background "base screen", though. Not a big problem.
More thoughts…
In theory you can have one thread place incoming irc messages to a *DTAQ, and the second one handling the display and send-message logic.
You might think about abandoning DSM altogether, and use plain DDS DSPFs. I bet implementing scrolling logic with a "static" load-paged subfile, and an array might be easier than trying to master DSM. This depends on your goal: Learning DSM, or finish the actual application. :-)
Last but not least, it could be feasible to exploit the ILE facilities by doing all network- and all text handling in C functions, and use RPG for the more easy handling of DSPFs and Data Queues.
:wq! PoC
midrange.com
