Patrik,
In CICS "pseudo-conversational" programming, where the program ends after each screen is presented, and when the user fills in the blanks and presses Enter, the next small program (via its own transaction ID) runs to handle that screen, and so on. That was how you did large applications in CICS back on OS/360 and early OS/VS or DOS/VS, when you had fairly limited region sizes and limited resources (like main storage).
S/34 and S/36 had a technique called "SRT" (single requester terminal) and "MRT" (multiple requester terminal) that worked in a similar way. With MRT, one program could handle multiple physical screens (5250s) and handle multiple users, while using far fewer resources, since only one (reentrant) program was loaded into memory. Remember, S/3, S/32, S/34 and S/36 had only a 64K address space to work with, per job or program (in this case).
The analogy with the "web" is the way CGI programs work -- you get some input, usually via a URL encoding, then look up some stuff, and then format and display a "results" page, and then the program "ends" ... freeing any resources etc., as you described.
Then, if the HTML page that was displayed happened to be an HTML form, e.g. a fill-in-the-blanks screen, the user can type stuff in, and when they press Enter or a "Send" button etc., the CGI program runs all over again, as new.
So, there is no "memory" from one screen to the next, very similar to CICS pseudo-conversational programming. (In CICS, programmers would be "clever" and pass some information in 3270 "non-display" fields, to allow passing data to the next transaction in the sequence. Or CICS had "temp storage" also useful for this kind of thing.)
HTH,
Mark
On Friday, August 11, 2023 at 02:40:46 PM EDT, Patrik Schindler <poc@xxxxxxxxxx> wrote:
Hello Jon,
Am 11.08.2023 um 20:19 schrieb Jon Paris <jon.paris@xxxxxxxxxxxxxx>:
For anyone who has ever done S/36 MRT programming CICS is pretty simple.
For those who grew up on the S/38 / AS/400 with the "why should I have to worry about state information?) mentality it is much harder. In some ways it is the same reason that programmers with that background have difficulty getting their heads around web programming. S/36 MRT programmers find the web a breeze!
I know the underlying concept about "conversional transaction" from web server applications (Apache). The client connects, places a request, Apache serves that, feeds back the data and the connection is closed. No state is retained within the web server.
If there is another — related — request to be served, the client is supposed to supply some kind of information so the software being in use "behind" Apache can assign the correct pseudo state (aka: user is already logged in, etc.) Most often, this is handled by web cookies. The client always sends back the cookie and the server has an id or other "state" saved locally to recognize the new request being related to a "session", a series of many requests.
Apache has a set of "workers" (threads or forked processes) where a main dispatcher thread or forked process listening on the TCP port(s) in question for incoming requests and passes those on to already running workers. No need to expensively start and end workers for each request.
While it's indeed easy for me to understand how this works for http, I have not yet enough insight into CICS or 3270 to understand how this works inside CICS and which role 3270 peculiarities play.
But it's fascinating that again IBM has been first with that, before Tim Berners-Lee pushed "start" on the "change the world" button.
:wq! PoC
midrange.com
