Traditional COBOL environment
in [Cobol]
|
From: WangVS on 30 Mar 2010 06:56 On Mar 28, 8:43 pm, docdw...(a)panix.com () wrote: > In article <af8533cd-acfe-4b3e-bb50-92e72e3eb...(a)35g2000yqm.googlegroups.com>, > > WangVS <tjun...(a)tjunker.com> wrote: > >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. Sounds the opposite of a coder's machine and environment. Everyone did everything instead of delineation between system and application groups and between systems analysts and coders. Right, give a programmer a general idea of what you wanted, and after a short time you'd have it. In the delineated environment it might be six months before the first committee meeting... > (I implemented 'pop-up windows' using DISPLAY AND READ MODIFIABLE that > way.) Cool! Really good programming resulted in sized popups within the current screen. Less good programming resulted in full screen popups. Poor programming resulted in no such options, just fill in the current screen or die. TJ
From: Anonymous on 30 Mar 2010 07:46 In article <37d36ae2-c85e-4801-8c9b-2bbf8dc0fb23(a)o30g2000yqb.googlegroups.com>, WangVS <tjunker(a)tjunker.com> wrote: >On Mar 28, 8:43?pm, docdw...(a)panix.com () wrote: >> In article <af8533cd-acfe-4b3e-bb50-92e72e3eb...(a)35g2000yqm.googlegroups.com>, >> >> WangVS ?<tjun...(a)tjunker.com> wrote: > >> >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. > >Sounds the opposite of a coder's machine and environment. Everyone >did everything instead of delineation between system and application >groups and between systems analysts and coders. We appear to disagree on what constitutes a 'Coder's Machine'. At the International Bank folks would dither about for endless amounts of time figuring out what they actually wanted; it was not up to the programmer to determine how multiparty trades were to be executed or how a Failure To Deliver condition was to be indicated in the weekly reports, just... tell us what you want and we'll make it so. >Right, give a >programmer a general idea of what you wanted, and after a short time >you'd have it. In the delineated environment it might be six months >before the first committee meeting... The latter does not rule out the former as a machine which allows the programmer to concentrate on the code, as opposed to invoking CEMT and scrabbling through CEDF. > >> (I implemented 'pop-up windows' using DISPLAY AND READ MODIFIABLE that >> way.) > >Cool! Really good programming resulted in sized popups within the >current screen. Less good programming resulted in full screen >popups. Poor programming resulted in no such options, just fill in >the current screen or die. It never occurred to me to call a new screen a 'full screen popup', it was... a new screen. DD
From: Pete Dashwood on 30 Mar 2010 20:03 WangVS wrote: > On Mar 28, 12:22 pm, Michael Wojcik <mwoj...(a)newsguy.com> wrote: >> WangVS wrote: >> <snipped good discussion > > 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. > I've been following this with some interest. Most COBOL programmers like processes that are controlled by the program. It is intuitive for Procedural programming. And you are making a case for it, Tom. However (and it isn't fair to only consider CICS here) there are some very good arguments for why interrupt driven processing has 'caught on'. Probably the most important one is that interrupt driven code is asynchronous and therefore very easily distributed to different processors or multithreaded on a single one. It is inherent in the processing model and seamless. Interrupt processing code is normally encapsulated and so it is hardly surprising that Object Oriented Programming is ideally suited for this type of process. Personally, I prefer to have a bunch of threads all instantiating objects they need and working to immediately handle events as they occur, rather than a single monolithic process that churns through the steps in a process serially. But that's just me. >>> 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. But it ISN'T difficult to keep track of state (whether in CGI or CICS). Like everything else it is simply an acquired skill. When you are familiar and comfortable with doing it, you don't consider it difficult. I can't see any difference between storing the state of a Web based process in session variables (or server side in a C# code-behind) and storing similar information in local variables in a COBOL program. > >> 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. > Michael is right on the button here. (Funny, he often is... :-)) > 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. And which is better is very arguable. As we can see :-) I don't think it really matters which is "better" as long as you get the results you are seeking. I've been working for years now with Objects in event driven environments. I LIKE not having control as I would in a procedural environment. There is a challenge in responding to events as they happen (even or especially, when lots of them happen at once) and there is satisfaction in coping with complex interactions using simple objects that can create themselves when they are needed, and destroy themselves when they are not. It's fun :-). Obviously, these are two different paradigms. I don't think the argument has to be about which is "better" (and the World has voted with its feet anyway; it would be very hard to sell anything that doesn't accommodate Objects, in today's world), as long as they each achieve the results that whoever owns them is paying for. Nevertheless, I still believe the future is in Objects and Layers. Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 30 Mar 2010 22:25 On Mar 31, 1:03 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > WangVS wrote: > > On Mar 28, 12:22 pm, Michael Wojcik <mwoj...(a)newsguy.com> wrote: > >> WangVS wrote: > > <snipped good discussion >> 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. > > I've been following this with some interest. > > Most COBOL programmers like processes that are controlled by the program. It > is intuitive for Procedural programming. > > And you are making a case for it, Tom. > > However (and it isn't fair to only consider CICS here) there are some very > good arguments for why interrupt driven processing has 'caught on'. > > Probably the most important one is that interrupt driven code is > asynchronous and therefore very easily distributed to different processors > or multithreaded on a single one. That is irrelevant to a multi-user environment. There will be dozens of processes running at any one time and the operating system can easily distributes these to many CPUs and/or cores. I suspect that you didn't mean 'interrupt driven' but 'event driven'. Wang has pre-emptive multi-tasking which is what 'interrupt driven' means. > It is inherent in the processing model and > seamless. Interrupt processing code is normally encapsulated and so it is > hardly surprising that Object Oriented Programming is ideally suited for > this type of process. > > Personally, I prefer to have a bunch of threads all instantiating objects > they need and working to immediately handle events as they occur, rather > than a single monolithic process that churns through the steps in a process > serially. But that's just me. > >>> 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. > > But it ISN'T difficult to keep track of state (whether in CGI or CICS). Like > everything else it is simply an acquired skill. When you are familiar and > comfortable with doing it, you don't consider it difficult. I can't see any > difference between storing the state of a Web based process in session > variables (or server side in a C# code-behind) and storing similar > information in local variables in a COBOL program. > > >> 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. > > Michael is right on the button here. (Funny, he often is... :-)) > > > 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. > > And which is better is very arguable. As we can see :-) > > I don't think it really matters which is "better" as long as you get the > results you are seeking. > > I've been working for years now with Objects in event driven environments.. I > LIKE not having control as I would in a procedural environment. There is a > challenge in responding to events as they happen (even or especially, when > lots of them happen at once) and there is satisfaction in coping with > complex interactions using simple objects that can create themselves when > they are needed, and destroy themselves when they are not. It's fun :-). > > Obviously, these are two different paradigms. I don't think the argument has > to be about which is "better" (and the World has voted with its feet anyway; > it would be very hard to sell anything that doesn't accommodate Objects, in > today's world), as long as they each achieve the results that whoever owns > them is paying for. > > Nevertheless, I still believe the future is in Objects and Layers. > > Pete. > > -- > "I used to write COBOL...now I can do anything."
From: Michael Wojcik on 30 Mar 2010 13:56
WangVS wrote: > 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 they are with CICS map definitions, if the build process is at all sane; the map files are processed to generate load modules and copybooks, and then the application is compiled with those copybooks. Keeping the screen definitions internal to the application isn't the only way to make the necessary information available to the build toolchain. >>> 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. Neither of these approaches is necessarily advantageous over the other. And "no tricks need be employed" to maintain state in CICS applications either; there are first-class state mechanisms provided by the environment, and they work just fine. >>> 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. Yes, as with essentially any of the traditional terminal-based environments. HTTP RIA applications broke with this model specifically to improve user-visible response time by reducing the number of relatively high-latency synchronous exchanges with the server. It's a natural evolution of the interactive timesharing model. But that's beside the point when considering differences between the Wang environment and CICS, which both keep state on the server (excluding hybrid environments that front-end server-side applications with smart clients). > 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. That's not a particularly significant difference in practice. The two architectures are likely isomorphic for pretty much all application designs and it's not difficult to convert between them. And, as I noted previously, the pseudoconversational model is not the only one provided by CICS, so this isn't an "essential" difference between the two environments. >>> 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. What difficulties? > No mechanisms are needed > to keep track of state in a Wang COBOL program Nonsense, unless the application is stateless and purely functional. The mechanisms might look different in the two environments (though typically those differences will be very slight indeed), but they're present in both. >> 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. That would be a larger scheduling grain. > 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. I don't believe that's a meaningful distinction. CICS transactions can be initiated by programs, and often are. I'm afraid you're making "the CICS model" (already a suspicious portmanteau of many facilities and application affordances) out to be quite a lot simpler and restrictive than it actually is. CICS certainly has its quirks, but it's far more flexible than the request/response model you are describing. None of this is to say anything against the Wang environment; I haven't used it myself, and it may well be a swell walk in the park. But having programmed in quite a few environments over the years (8-bit personal computers and embedded systems; MS/DOS, OS/2, and Windows versions 2 through 2008; a dozen or so Unix flavors on machines big and small; the AS/400; CICS, IMS, MVS batch; and a handful of others) and more programming languages and development systems than I can count, I'm rather dubious about any attempt to declare any one simply better than another. (Sure, Unix beats MS/DOS for general-purpose work, but if I had to pick between them for a monitor for a little embedded system...) It generally indicates a very reductive and inaccurate portrayal of at least one of the players. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University |