Traditional COBOL environment
in [Cobol]
|
From: WangVS on 8 Apr 2010 10:32 On Mar 28, 1:39 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Mar 28, 11:29 am, WangVS <tjun...(a)tjunker.com> wrote: > > Did I mention that the Wang VS is a stack machine? Yep... stacks, > > push and pop instructions, linked list manipulation instructions. > > Good stuff. > > While 'stack machines' may have been a novelty in the 60s and 70s it > is unusual to find something that is not one today. True, but the Wang VS was based closely on the IBM 360, which I believe was not a stack machine. From its early origins in the late 1970s the Wang VS was designed with hardware and software use of stacks clearly in mind, just as it was designed to be interactive. TJ
From: WangVS on 8 Apr 2010 10:39 On Mar 30, 6:46 am, docdw...(a)panix.com () wrote: > It never occurred to me to call a new screen a 'full screen popup', it > was... a new screen. > > DD When a subordinate screen is presented, say to offer a picklist of valid values for a field on a superior screen, it could be called a popup because it pops up and after a selection is made, returns to the original screen. I wouldn't distinguish much between such a popup that cleverly uses only part of the screen and one which uses the entire screen. They are functionally the same. TJ
From: Kerry Liles on 8 Apr 2010 10:42 "WangVS" <wangvs(a)gmail.com> wrote in message news:4a931ab3-f0e2-41f0-957b-24c6029cde30(a)x3g2000yqd.googlegroups.com... On Mar 28, 1:39 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Mar 28, 11:29 am, WangVS <tjun...(a)tjunker.com> wrote: > > Did I mention that the Wang VS is a stack machine? Yep... stacks, > > push and pop instructions, linked list manipulation instructions. > > Good stuff. > > While 'stack machines' may have been a novelty in the 60s and 70s it > is unusual to find something that is not one today. True, but the Wang VS was based closely on the IBM 360, which I believe was not a stack machine. From its early origins in the late 1970s the Wang VS was designed with hardware and software use of stacks clearly in mind, just as it was designed to be interactive. TJ Indeed, the /360 (and later machines like the /370 etc) were not stack machines per se. However, many of us implemented "stacks" in software at the first opportunity... I think 'push' and 'pop' macros were the first ones I wrote in /360 assembler... First the tools, then the applications.
From: WangVS on 8 Apr 2010 10:44 On Mar 30, 6:46 am, docdw...(a)panix.com () wrote: > It never occurred to me to call a new screen a 'full screen popup', it > was... a new screen. > > DD Further, in Wang PACE, the 4GL database and application development package, picklists are well supported but are always full screen. In a simple example a table of States and their 2-letter codes would be a parent of a Customer table. In the Customer data entry screenset I would create a PICK function key on all the screens that show the Customer address and the State field. Pressing the PICK key would navigate to a State pick list screen showing all the States and their codes. Placing the highlight on the desired State line and pressing Enter would return to the modifiable Customer data entry screen and plug in the State code, possible with full name of the State. That's a popup screen instead of a little popup window within the screen. The PACE designers chose to support this using full screens. TJ
From: WangVS on 8 Apr 2010 10:48
Richard fully understands the points I have been trying to make about the Wang VS OS environment being a fully multitasking environment that nicely manages resources for hundreds of concurrent tasks sharing access to the key business files. It's a full-fledged multiuser OS. Many such existed while MS took 10-15 years to rediscover OS technology and finally developed NT using a crew from DEC. TJ On Mar 30, 9:25 pm, Richard <rip...(a)Azonic.co.nz> wrote: > 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." > > |