Re: DSM

On 23 Apr 2012 00:11, A Sheth wrote:

Thanks guys. Yes, I was too on the same minds of using two subfiles.
However, the length of the fields are dynamic. As in RUNQRY when F20
key is pressed, it moves right, thereby displaying the next set of
fields/data. So I thought to build a dynamic subfile.

I am not sure but still believe that RUNQRY uses DSM logic. Because
it creates a subfile dynamically based on different files and their
fields.

I am planning to build a similar functionality that is been used in
RUNQRY (F19, F20, F21, F22). F22 becomes visible only when the
session is using 27x132 mode. I using an API was able to figure out
the mode of session.

I am thereby trying to understand the RUNQRY functionality.

The Query/400 run-time report writer, output to display, uses the DDS defined Externally Described Display File QDQUWSRUN to present the data, primarily RcdFmt F29RPT for WRKQRY\RUNQRY "Display Report" and RcdFmt F29RPTLIVE for STRSQL "Display Data", not Dynamic Screen Management APIs. This is visible information, obtained from WRKJOB OPTION(*OPNF) during processing those reports.

The display data is generated into memory and then output to the display file. The report display serves as an effective window over a page layout of already formatted data, where the first 1 to 3 lines are populated with the already formatted column headings. When the report is split, there are effective two side-by-side windows over the data where one becomes immovable left\right while the other is allowed to move according to the same rules as just one window.

Regards, Chuck