Traditional COBOL environment
in [Cobol]
|
From: Alistair on 27 Mar 2010 07:23 On Mar 27, 2:06 am, docdw...(a)panix.com () wrote: > In article <fdda974d-c39e-458e-ae97-a0e3b2971...(a)v20g2000yqv.googlegroups..com>, > > Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > >On Mar 26, 4:17?pm, docdw...(a)panix.com () wrote: > >> In article <f28d7cf0-3f40-46bc-9315-e6b1cc6e0...(a)15g2000yqi.googlegroups.com>, > >> Alistair ?<alist...(a)ld50macca.demon.co.uk> wrote: > >> >On Mar 26, 3:51?pm, docdw...(a)panix.com () wrote: > > [snip] > > >> >> Granted that I have no idea what Mr Dashwood's intentions might be.... but > >> >> for The Usual Suspects (COBOL '85, command-level CICS and DB2) MVS might > >> >> work just fine. > > >> >And from elsewhere on the Hercules site it transpires that the free-to- > >> >use version of MVS is MVS 3.8. When I looked at doing this way back > >> >when, MVS 3.8 was already a Granddaddy. > > >> Was it incapable of running The Usual Suspects? > > >MVS 3.8 was neither VHS nor Beta. > > According tohttp://cbttape.org/~jmorrison/mvs38j/: > > --begin quoted text: > > MVS 3.8J is the final public domain version of IBM's OS/370 MVS operating > system, released in the late 1970s and early 1980s. It runs with 24-bit > addressability so it can only address 16MB of virtual storage. It only > supports 3 hexadecimal digit I/O addresses. Aside from those limitations, > it has quite a lot in common with today's OS/390 and z/OS systems and can > still perform useful work. > > --end quoted text > > I recall doing a fair amount of work on such machines that kept a goodly > amount of commerce moving. > > DD I thought that you were going to come up with a quote about getting old video machines to run on MVS 3.8.
From: Pete Dashwood on 27 Mar 2010 08:41 WangVS wrote: > Pete, I don't think I would seriously recommend our product for your > project unless... unless your product will be powerful enough to drive > the platform sale. That used to be the way things worked in the good > old days but is less true today. Thanks Tom, I appreciate your honesty. That is not going to work for me (I can't become a Wang salesman at my time of life :-)) and I definitely need OO COBOL for the platform, which I noticed you didn't respond to... :-) > To use our product you'd have to > have a product of your own that would command the platform with no > questions asked. If that were the case, then we could provide you > with a complete, solid business data processing environment. If > you're trying to mix in things like Web, there could be ways to do > that with outboard web servers but we wouldn't propose our product. > Its TCP/IP is not strong enough even though there is a web server for > the Wang VS. My target is .NET which runs under Windows but I have Migration Tools which I would like to run on the mainframe. The Toolset is currently in C# but it is component based and some of the components are in COBOL. Web is definitely part of it because my Toolset produces objects that can run on the desktop or the Web. I'd like to have some of the fundamental Toolset components that generate a relational DB and generate Data Access Layer Objects, able to be run on a mainframe and I need a platform for that development/conversion. > > I'm a little bit fuzzy on how to reach you by private email from > here. I'd still like to show you our product... it might get some > gears turning. From what you're saying I don't think it will be a fit so there is no point in wasting time. I do appreciate your honesty, though, and I wish you success with it. Pete -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 27 Mar 2010 09:10 WangVS wrote: > Pete, > > Our engineer who looked at Hercules reported that it was not solid > enough to use as a basis for our Wang VS emulation. In theory it > should have been useful, because the Wang VS was based on IBM 360/370 > and has an instruction set almost identical, if a bit of a superset. > The Wang VS assembler and linker are just about identical to the IBM > versions. The assembler macro language is identical and all the > functions in the linker are identical from what I am told by people > who know both. The COBOL 85 is standards compiant with some Wang > extensions. One extension is a working storage screen statement that > defines an interactive screen down to field attributes and source and > object variables for fields, and explicit and implicit field > placement. Another extension is DISPLAY AND READ, which throws a > screen up and gets back fields and function key. A single program can > have a multitude of screens and be a complete interactive > application. No MAP file nonsense like in CICS. Whooooaaaa! Easy fella...!!! That "nonsensical" BMS Map provides a very sensible separation layer between applications and the Presentation Layer. It means that presentation and data acquisition are NOT embedded in Business Logic, like file access so often is in COBOL. CICS is not my favourite TP monitor, but it is light years ahead of SCREEN SECTION... Driving screens through the COBOL SCREEN SECTION means the process stops while it is waiting for a response. Too many screens, everything grinds to a halt. CICS and similar systems that dequeue and task switch (allowing other threads to use the same code) while waiting for a response (quasi-conversational mode in CICS or conversational for IMS/DC or whatever it is called now...), then re-enter the process when the user presses enter, are way more efficient and better. The ACE system mentioned here in a separate thread does that, even though it employs generated screen driver modules that use COBOL accept. It might be that your WANG system also task switches under the covers when it is waiting for user response, but there is absolutely nothing to trumpet about with SCREEN SECTION. On a PC it is acceptable (because you have a single dedicated local processor); on a mainframe or on a network server it is just ridiculous... > A program can throw > up a screen, get back fields and function key, decide what to do, > throw up another screen, get back fields and function key, etc. So can CICS :-) But CICS can be doing it with ONE set of memory resident code at any number of terminals, simultaneously. (this is achieved through terminal dependent buffers like DFHCOMM area). The SCREEN SECTION is tied to the screen it is waiting on. > > The Wang VS was designed from the ground up to be an interactive > system. All interactive systems can do batch by default... run a non- > interactive program from a workstation and you're doing batch. Good try, but I'm not entirely persuaded... :-) > But > the VS also has Job Queue and Job Classes and Print Queue and Print > Classes to facilitate true batch operations. So the "workstation batch" above is NOT "true batch"? :-) > It has Background Task > Initiators to reduce the parameters that must be provided when > submitting a job to background. Print output is directed to a Print > Class, and printers pick up print jobs according to the classes > enabled for each printer. Multiples can be defined, so it would be > possible, say, to have three printers for invoices, all defined to > accept Class I print jobs. Good stuff. > > It's a robust system. It also has an integrated development > environment in which the EDITOR can compile and link programs, and run > them, and from which the Interactive Debugger can be invoked. Does it have anythng like Intellisense (a la Visual Studio) where it will check syntax, provide parameters for methods and subprograms, and complete datanames as you type, or offer you a dropdown of what fits? > The > Debugger has all the features one would expect of a debugger today, > even though it was designed in the early 1980s. It displays source > code, allows stepping into or over, provides for watching variables, > setting program breakpoints, data modification breakpoints, etc. > Those who have worked in IBM and Wang systems consistently report that > the Wang VS program development environment far and away beats IBM's. > So do Eclipse and Visual Studio, by large margins... I smile sometimes when I am using SPF/PC occasionally for COBOL and think of the years I used it on mainframes and thought it was great. Now it seems like a quaint old relic alongside Visual Studio. Pete -- "I used to write COBOL...now I can do anything."
From: WangVS on 27 Mar 2010 11:49 On Mar 27, 6:41 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > WangVS wrote: > > Pete, I don't think I would seriously recommend our product for your > > project unless... unless your product will be powerful enough to drive > > the platform sale. That used to be the way things worked in the good > > old days but is less true today. > > Thanks Tom, I appreciate your honesty. That is not going to work for me (I > can't become a Wang salesman at my time of life :-)) and I definitely need > OO COBOL for the platform, which I noticed you didn't respond to... :-) > > > To use our product you'd have to > > have a product of your own that would command the platform with no > > questions asked. If that were the case, then we could provide you > > with a complete, solid business data processing environment. If > > you're trying to mix in things like Web, there could be ways to do > > that with outboard web servers but we wouldn't propose our product. > > Its TCP/IP is not strong enough even though there is a web server for > > the Wang VS. > > My target is .NET which runs under Windows but I have Migration Tools which > I would like to run on the mainframe. The Toolset is currently in C# but it > is component based and some of the components are in COBOL. Web is > definitely part of it because my Toolset produces objects that can run on > the desktop or the Web. I'd like to have some of the fundamental Toolset > components that generate a relational DB and generate Data Access Layer > Objects, able to be run on a mainframe and I need a platform for that > development/conversion. > > > > > I'm a little bit fuzzy on how to reach you by private email from > > here. I'd still like to show you our product... it might get some > > gears turning. > > From what you're saying I don't think it will be a fit so there is no point > in wasting time. I do appreciate your honesty, though, and I wish you > success with it. > > Pete > -- > "I used to write COBOL...now I can do anything." Pete, I accept your position but I don't understand why what you want to do is so complicated. Of course I don't know, really what you want to do, but it seems to me that traditional business data processing is more than adequately served by a system such as the New VS. By the way, here is an in-depth description of what the New VS offers: http://wangvs.ning.com/group/newvsreference/forum/topics/why-use-a-vs-features-and TJ
From: Anonymous on 27 Mar 2010 12:19
In article <9f61be9e-f82f-42c2-b3df-b96fcac95804(a)z11g2000yqz.googlegroups.com>, WangVS <tjunker(a)tjunker.com> wrote: >On Mar 26, 5:49?am, docdw...(a)panix.com () wrote: >> In article <4438cbb8-e9aa-44eb-b9ed-089637b54...(a)35g2000yqm.googlegroups.com>, >> >> WangVS ?<tjun...(a)tjunker.com> wrote: >> >> [snip] >> >> >It's a complete >> >environment that turns a Dell PowerEdge server into a >> >Wang VS mainframe. ?COBOL 85 would be the language of >> >choice, although it also has a powerful 4GL database. >> >> Would that '4GL database' happen to be... PACE? > >Yes indeed! You are familiar with it? Naw, just a lucky guess... now, let me gaze into the Eternal Aether, for a pathway to wisdom... I see a blue haze... does it have a blue haze, too? No, wait, I see letters... shimmering, floating, forming strange words... USERAIDS... USERSUBS... what could this all mean? DD |