Traditional COBOL environment
in [Cobol]
|
From: WangVS on 28 Mar 2010 04:18 On Mar 27, 7:44 pm, docdw...(a)panix.com () wrote: > Nope, that one went to a lad of oleagenous affect who declared 'We can > make any machine do anything you want within 6 weeks for so small a > pittance you can readily pay it up front.' > > DD Ho ho! '...and for so small a pittance that you won't notice when we make off with your money and you never hear from us again!" TJ
From: Michael Wojcik on 28 Mar 2010 14:22 WangVS wrote: > > As I understand what little I have heard of it, the MAP stuff has to > do with screens that are completely external to the program. The screen *definitions* are external to the application program. Obviously the application needs access to the data that's being transferred to and from the terminal. > As I > understand what little I have heard about CICS, each workstation I/O > event causes the program to be run anew, not unlike CGI in a web > server. This is a fairly apt comparison (and one that a number of people, such as longtime IBM guru Lynn Wheeler, have made). CICS appications running in the basic pseudoconversational mode are quite similar, architecturally, to applications running under an HTTP server. Phrases like "causes the program to be run anew" might be misleading, simply because what it means to "run" a "program" depends on the execution environment, and running an application program under CICS is quite different from, say, exec'ing an executable as a CGI program under httpd on Unix (and even more so from the Windows CreateProcess mechanism). > Clever mechanisms are used to connect what was happening in > the previous screen to what is happening in the current screen, very > much like what goes on in web CGI. CGI, or any other server-side execution mechanism for HTTP servers (Apache modules like mod_php; IIS ASP, WPAS, and other execution engines; Tomcat's servlet container; ...). One important difference is that by default in CICS most of that application state is stored server-side, but HTTP applications use a variety of server-side and client-side mechanisms, and the trend (particularly with REST) is to push more and more to the client. Also, CICS does support various long-running, conversational-mode architectures as well. Pseudoconversational is the norm, but it's not the only option. > Later CICS has managed to hide much of the ugliness, What ugliness? In COBOL, it's simply a matter of addressing the appropriate area - one line of code. And in my experience this hasn't changed appreciably in decades for most CICS applications. The new ones I've seen mostly do the same sorts of things that IBM's mid-80s bank demo does, as far as using the COMMAREA, TIOA, queues, databases, and similar facilities to hold application state. > but the basic is that it is a mechanism that > allowed a batch environment to do interactive stuff. It might be more accurate to say "allowed a transaction-queuing environment to do interactive stuff". The key difference between an environment like CICS and a classic timesharing environment like Multics, TOPS-10, or Unix is that CICS has much coarser scheduling granularity. Interactive timesharing OSes typically employed an "illusion of a single user" model: each user should see a system that responds to each input as if there were no one else on the machine. (Note these systems used character-mode terminals, though there are interactive environments - eg CMS and the S/3x / AS/400 / iOS family - which use block-mode terminals.) Transaction-queuing environments like CICS (or IMS, etc), on the other hand, schedule units of work (as far as the user is concerned - they may employ finer-grained multiprocessing internally). The user submits a transaction, it's processed, and the results come back. Thus these environments use block-mode terminals. This is also the HTTP model, obviously, though AJAX applications try to provide a more-interactive user experience by performing more HTTP exchanges under the covers. A true batch environment generally schedules with an even larger grain: users submit batch jobs which may run much too long to be interactive, and output is spooled. Clearly these aren't hard-and-fast distinctions (as anyone who's used the web extensively knows), but there is a significant difference between the typical user interaction model for an interactive transaction-oriented environment and a character-oriented one. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Anonymous on 28 Mar 2010 22:43 In article <af8533cd-acfe-4b3e-bb50-92e72e3eba7b(a)35g2000yqm.googlegroups.com>, WangVS <tjunker(a)tjunker.com> wrote: >On Mar 27, 7:36?pm, docdw...(a)panix.com () wrote: >> In a prior life I worked on Wall Street for an International Bank that had >> rigid delineation of functions between groups... and I trod across the >> borders with joyful abandon. >> >> 'Hey... you can't do that, that's Ops' job!' > >This reminds me of another advantage of the Wang VS environment. I >never saw a Want site where there was rigid delineation of groups in >development or operations. You obviously didn't work at that International Bank to which I contracted. I found the VS to be a real Coder's Machine... give a progammer an idea about what you wanted done and it'd more-or-less happen after a few days of pizza-consumption, lack of showering and sleeping under conference tables. (I implemented 'pop-up windows' using DISPLAY AND READ MODIFIABLE that way.) DD
From: Anonymous on 28 Mar 2010 22:48 In article <ef64ca34-e4a8-4409-9930-6828e5efaada(a)q15g2000yqj.googlegroups.com>, WangVS <tjunker(a)tjunker.com> wrote: >On Mar 27, 7:44?pm, docdw...(a)panix.com () wrote: > >> Nope, that one went to a lad of oleagenous affect who declared 'We can >> make any machine do anything you want within 6 weeks for so small a >> pittance you can readily pay it up front.' >> >> DD > >Ho ho! '...and for so small a pittance that you won't notice when we >make off with your money and you never hear from us again!" Exactly... scarce was the ink dry when the request came of 'Say, might I borrow your watch in order to tell you what time it is?' A blight on my Good Profession's Name. DD
From: WangVS on 30 Mar 2010 06:51
On Mar 28, 12:22 pm, Michael Wojcik <mwoj...(a)newsguy.com> wrote: > WangVS wrote: > > > As I understand what little I have heard of it, the MAP stuff has to > > do with screens that are completely external to the program. > > The screen *definitions* are external to the application program. > Obviously the application needs access to the data that's being > transferred to and from the terminal. But in Wang COBOL the screen definitions are internal to the program, although they may be externalized by putting them in copybooks or subprograms. Either way, though, they are part of the program at compile or link time, so the compiler and linker have opportunities to flag reference errors. > > As I > > understand what little I have heard about CICS, each workstation I/O > > event causes the program to be run anew, not unlike CGI in a web > > server. > > This is a fairly apt comparison (and one that a number of people, such > as longtime IBM guru Lynn Wheeler, have made). CICS appications > running in the basic pseudoconversational mode are quite similar, > architecturally, to applications running under an HTTP server. But in Wang COBOL the screen I/O is subordinate to the program, and the stream of screen transactions occurs essentially inline in the program. So any and all state information is local to the program and no tricks need be employed to keep track of state. > > Clever mechanisms are used to connect what was happening in > > the previous screen to what is happening in the current screen, very > > much like what goes on in web CGI. > > CGI, or any other server-side execution mechanism for HTTP servers > (Apache modules like mod_php; IIS ASP, WPAS, and other execution > engines; Tomcat's servlet container; ...). One important difference is > that by default in CICS most of that application state is stored > server-side, but HTTP applications use a variety of server-side and > client-side mechanisms, and the trend (particularly with REST) is to > push more and more to the client. In Wang COBOL all state information is server-side and the series of screen transactions in a program run is one long-running stream completely controlled by the program. Throw up a screen and wait for a response; process the response and decide what to do next; throw up another screen, etc. It's essentially different from CICS in that the program drives the screens; the screens don't drive the program. > > Later CICS has managed to hide much of the ugliness, > > What ugliness? In COBOL, it's simply a matter of addressing the > appropriate area - one line of code. The ugliness of CGI-like state difficulties. No mechanisms are needed to keep track of state in a Wang COBOL program because the program utterly determines which screens to present and how to process what returns from them. Any state information is embodied in the program flow and in local variables. > A true batch environment generally schedules with an even larger > grain: users submit batch jobs which may run much too long to be > interactive, and output is spooled. In the Wang environment a batch job is not one that is much too long to be interactive; it is one that has no interactive requirements, such as a report, and that is scheduled for slack times instead of being run by an interactive user. > Clearly these aren't hard-and-fast distinctions (as anyone who's used > the web extensively knows), but there is a significant difference > between the typical user interaction model for an interactive > transaction-oriented environment and a character-oriented one. The Wang VS system uses block mode workstations, although there are several asynchronous character interfaces that emulate the block mode. Transactions are initiated by the program, not the user. I think that is the essential difference between the CICS model and the Wang model. TJ |