× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I remember SRT (or a variation) being called PRUF (Program Request Under
Format). Talk about a balancing act. RPGII, Overlays, RRN's, 32K,
etc.....

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Peter Dow (ML)
Sent: Thursday, November 01, 2007 8:18 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Multiple Displays vs One Display


Hi Scott,

Way back when I first started working on the Sys3 Mod15D they had CCP (I

think it was Communications Control Program), and there were two
recommendations - SRT and MRT programs. The idea SRT (Single Requesting

Terminal?) was for the program to quickly display a screen that
contained the name of the next program that would process that screen
embedded as a hidden field. When the user pressed Enter, the system
would use that hidden name to call the program and let it process the
screen. This meant that while the user was filling in the screen
fields, there was no program taking up any of the 32KB or whatever
memory the machine had. It also meant that programs were small, so that

when they were in memory, there was room for other programs.

An MRT (Multiple Requesting Terminals?) program was designed to handle
several users at once. It had to keep track of the data for each
requester and respond appropriately when it received a request from that

user's terminal.

I think of the SRT model a lot when looking at browser-based programs...

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /

Scott Klement wrote:
This is an interesting thread. I've never hard of this "one screen /
one module" recommendation before. I'm having a hard time
understanding
why you'd do this...

All of the recommendations I've seen involve separating the display
logic from the business logic -- usually using an MVC pattern. I've
never heard of separating the display logic from other display logic.
I
don't understand the advantages of separating each screen from the
other
ones.

Can you please provide links to where you saw these recommendations?
Preferably, a link to an article that really explains the premise of
this technique?

Thanks


Wilt, Charles wrote:

Now-a-days, I think most the experts recommend one screen per
module/program. While not an expert, that's what I'd recommend also
:)

Tends to lead to more modular programming. Maintenance is easier as
you don't have to worry about accidentally changing another screens
behavior.

Also makes it easy to call a particular screen from someplace else.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.