CODEWITHSUNDEEP
ibm-midrangerpgle
Péter Mátyás
Péter Mátyás

Reputation: 3

How does the given automated display file refresh work?

I took an example from http://www-01.ibm.com/support/docview.wss?uid=nas8N1010188

I realized that 'DFRWTR *NO' is not necessary. Why?

KNUM 1 was converted to MAXDEV(*FILE) in rpgle. How does it contribute to the functionality? (the program compiles, but it doesn't refresh without it)

Regarding 'READ TIMED', why can't we use the record format to read? (it's an externally described file, and it compiles, but doesn't refresh)

Thanks a lot
Peter

Upvotes: 0

Views: 1322

Answers (1)

Buck Calabro
Buck Calabro

Reputation: 7648

DFRWRT(*YES) (the default for CRTDSPF) means that IBM i will accept the display buffer from the HLL program and immediately return control to the HLL program. In a second process, it will actually send the buffer to the terminal. EDIT: There's no second process; the screen is sent at the next READ. See Charles' comment. END EDIT So with DFRWRT(*YES) it is possible for the program to continue on before the user has seen the display. For this example that's irrelevant because the very next operation is a READ, so the program will stop there and wait for input.

The design here is called 'Read from Invited Devices' and the automatic refresh is about the only surviving use of the technique. Originally, read from invited was intended for one program - one job - to control multiple terminals. The idea was to write a screen to multiple display devices and INVITE them all to respond when ready. The first one to respond would satisfy the READ and the program would continue. If none of the devices responded within the WAITRCD() interval, the INVITE would expire (as an I/O error) and the program would get control - presumably to re-send updated information to the various terminals.

That's the reason we tell RPG that there are multiple devices - MAXDEV(*FILE) and also why we READ from the file but WRITE to the record format. Imagine an arrangement where the multiple devices are arranged in a boss - worker relationship. Your program would send the boss device the BOSS record format and all the worker devices would get the WORKER record format. But you don't want to only wait for the boss to respond; you need to get input from everyone. So you READ the file.

More information can be found in the Application Display Programming manual. Knowledge Center > Programming > Device > Application Display Programming

Upvotes: 1

Related Questions