Traditional COBOL environment
in [Cobol]
|
From: Anonymous on 27 Mar 2010 12:23 In article <816eemF3ooU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >WangVS wrote: [snip] >> 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"? :-) Long ago 'Quid est veritas?' was reported as being asked, Mr Dashwood... but if you want to see folks get a 2:am call then code a DISPLAY into a WANG VS batch program that doesn't have a SYSOUT equivalent defined *just so*. DD
From: Anonymous on 27 Mar 2010 12:26 In article <aa32012e-c65d-4737-bdda-747f969a024c(a)b33g2000yqc.googlegroups.com>, Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >On Mar 27, 2:06?am, docdw...(a)panix.com () wrote: [snip] >> I recall doing a fair amount of work on such machines that kept a goodly >> amount of commerce moving. > >I thought that you were going to come up with a quote about getting >old video machines to run on MVS 3.8. I once wrote a Formal Proposal that contained the statement 'Contrary to what some might say a mainframe *cannot* do everything a PC can; this is one of the reasons that 3278 terminals rarely display a Flying Toaster screen-saver.' DD
From: Anonymous on 27 Mar 2010 12:29 In article <2aa10a30-f889-4d56-98fa-ebc93b3825af(a)g10g2000yqh.googlegroups.com>, WangVS <tjunker(a)tjunker.com> wrote: [snip] >We looked at Hercules before writing our virtualization of the Wang >VS, as the VS was originally based on IBM 360/370. Is that the reason the System Reference was a purple booklet instead of a yellow one? DD
From: Clark F Morris on 27 Mar 2010 14:51 On Sat, 27 Mar 2010 12:44:41 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >Alistair 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: >>>>> In article >>>> <686a67d1-8659-4d75-a3c4-7558fd3f3...(a)k17g2000yqb.googlegroups.com>, >>>>> Alistair ?<alist...(a)ld50macca.demon.co.uk> wrote: >>>>>> On Mar 26, 2:39?pm, docdw...(a)panix.com () wrote: >>> >>> [snip] >>> >> >> MVS 3.8 was neither VHS nor Beta. > >Ah, those were the days... I have retained my faithful VCR and play >Blackadder, Fawlty Towers, and Harry Enfield tapes occasionally when in >need of some witty light relief :-). Compared to flat screen HD which is >what I'm normally viewing the quality is appalling, but it just goes to show >that content usually trumps form, even though form is important. > >Anyway, getting back to Hercules (wasn't that Steptoe's horse?)... > >I appreciate the contributions from both of you. I understand your >reservations, Alistair, and I also see Doc's point about usual suspects. I >have been out of the mainframe arena for so long now, I'm not sure how >relevant the usual supects still are, but I suspect many people are still >using them under modern versions of the OS. > >At this stage, I'm not sure on what I would be offering or where my focus >should be so it is hard to tell whether Hercules would be OK or not. But at >least I am now aware of the option (and some possible pitfalls with it) so I >am much better informed. > >Again, thanks to both of you. As a developer, IBM may have an appropriate "do we have a deal for you" on a time sharing service or other facility such as zPDT. Since you probably don't want to get into the techno grunge of system software installation and maintenance, I recommend first deciding what areas you want to develop code for (IBM web servers, CICS, TSO/ISPF, batch etc.) and then see what IBM or maybe even a university might offer. The advantage of z/OS or any of the complex server environments is that they provide good security and reliability in part by centralizing things for a large number of users. This allows specialization and concentration on areas of expertise (security, backup, load balancing, etc.) but the setup and administration can be daunting for just one person. Probably the best way that would want your tools and see if you can negotiate time on their system in return for a reduced cost on the license. Several packages have been developed that way. Subscribe to the IBM mainframe listserv (e-mail listserv(a)bama.ua.edu for instructions and then read it as newsgroup bit.listserv.ibm-main if you want to pursue this. I might add that you will find quite a few people on that group who are interesting in and use OO where it is available in the IBM z series world. > >Pete.
From: WangVS on 27 Mar 2010 17:16
On Mar 27, 7:10 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > 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 compliant 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... 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. 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. 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. Later CICS has managed to hide much of the ugliness, but the basic is that it is a mechanism that allowed a batch environment to do interactive stuff. What is essentially a batch program is run each time a screen comes back from the user. The languages of the Wang VS are all interactive to begin with. Procedure, COBOL, BASIC, C, PL/I, FORTRAN and Glossary are all languages with interactive features built in. A single program run in the VS can run through hundreds of screens, all directly controlled by the one program, each screen transaction being an I/O in the context of the program, just like disk file I/O. When the user exits from the program, the program run finally ends. During its run it may have done many thousands of I/Os, from workstation to disk file to telecommunications. It sounds like the VS OS is more like Unix and NT-like PC OSs than it is like IBM OSs. Not too surprising, as IBM carried its batch baggage forward into the interactive age with the odd result that the way IBM does interactive came to be viewed by the people working with it as the natural way to do interactive. I don't know what SCREEN SECTION is, but from the way you describe it it sounds nothing like what goes on in Wang COBOL. > 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. Nothing like that happens in the Wang VS. Yes, the instance of the program waiting for a screen to come back stops, but all other instances continue concurrently. The system never stops. > 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. That's sounds more like the way the Wang VS works, although the terminology and the mechanisms are not the same. The Wang VS is a full multitasking system with common code elements residing only once in memory and mapped into each task requiring them. Each task has its own modifiable data sections in memory, of course. If I have 100 users running the online order entry program, all the code exists only once in memory. Each user has separate modifiable sections. There is a robust paging system. Nonmodifiable code is never paged out since it can't change. If its space is needed in memory it is simply given up and later paged back in from the program file. The program file serves as the paging file for code sections. Modifiable sections can be paged out to a page pool, then brought back in later. The OS manages all of that seamlessly and "under the covers." When a task is waiting for a workstation function key nothing grinds to a halt. The task is put into a wait state and the processor is freed up to serve other tasks that have completed their I/O and are awaiting the processor. This is pretty standard stuff for fully multitasking operating systems. There is a Run Queue for tasks ready to run, and various other queues for I/O processing. Unless and until the VS hits 100% CPU utilization there are never more than a few tasks in the Run Queue, while there might be hundreds of tasks awaiting I/O completions such as workstation I/O or disk I/O within the file system code. > The ACE system mentioned here in a separate thread does that, even > though it employs generated screen driver modules that use COBOL accept. COBOL ACCEPT? In the VS world ACCEPT is very primitive and is only occasionally used for receiving simple parameters such as file, library and volume where a data file is located, from a Procedure (JCL) program that is running the program, and is considered a crude shortcut. User workstation I/O never uses ACCEPT. The user interface uses robust screen I/O that is generally invoked inline in the program. The screen definitions may or may not be included in the main program. They might be in subprograms or in copybooks. The copybook feature allows single instances of screen definitions to be used in multiple programs. > It > might be that your WANG system also task switches under the covers when it > is waiting for user response, I wouldn't necessarily call it under the covers -- it's basic to the multitasking operating system. All tasks can wait for I/O while the OS gives the CPU to other tasks that have completed their I/O and are ready to run again. In the VS, workstation I/O is no different than disk I/O. > but there is absolutely nothing to trumpet > about with SCREEN SECTION. Apparently SCREEN SECTION is something very specific that is also foreign and unknown to me. It doesn't sound like it has anything to do with what I was trying to describe about how the VS works. > 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... Oh, good grief! Nothing grinds to a halt in a VS. The VS is nothing like a PC, except that PCs have been given operating systems in recent years that are more and more event driven and multitasking. How do you think the VS can serve 500 users at desktop PCs without it having a robust multitasking OS? Each user might be running one of hundreds of programs in an application, and the program might have anywhere from a few to 50 files open, with most files being shared between users, with record locking that works perfectly. Thousands of things would be going on per second, from indexed file reads to reads with lock for update, to updates freeing record locks, to records being deleted, etc. Programs go to sleep in queues while awaiting I/O, and are awakened on I/O completion and moved to the Run Queue. Watching through the system monitor while hundreds of users are banging away at the system might show the Run Queue with 2-10 tasks in it, while the hundreds of other tasks are waiting for file or workstation I/O in a mix that is constantly shifting and changing. > > > 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. Concurrently. So does the VS. > (this is achieved through > terminal dependent buffers like DFHCOMM area). The SCREEN SECTION is tied to > the screen it is waiting on. Like I said, I don't know what a SCREEN SECTION is and it doesn't sound like anything in the Wang VS. The VS has a robust parameter passing mechanism. A simple example would be the DISPLAY utility, which can display the contents of all kinds of VS files. The DISPLAY utility requires parameters before it can display a file. The basic ones are the File, Library and Volume where the file to be displayed is located. Some lesser ones might be whether to display as a print file or whether to display as a record file. The DISPLAY utility constructs several parameter receiving blocks and passes them to the OS. Each one is idenfitied by a parameter referenc name. One is INPUT, another is EOJ. The OS looks to see whether a higher level progam has passed in any parameter sending blocks that match the parameter reference names. If so, the OS moves parameter values from the sending block to the receiving block. If all the requirements of the receiving block are satisfied, DISPLAY continues and has the parms it needs. If any are missing, the OS throws up a screen to request them. The receiving block also contains screen formatting information so that the resulting screen is properly formatted. In this example, perhaps a higher level program provided the Library and Volume but omitted the File name. The resulting screen solicits all the fields, but the Library and Volume fields will already be filled in from the values received from the higher level program. The interactive user would normally fill in the missing parm and press Enter, but has the option to change any of the parms. In a properly proceduralized set of programs, the higher level programs will pass all the needed parms into the lower level programs by this mechanism, and no screens will appear. Thus I might have a Procedure that runs the EDITOR and primes it with the Library and Volume location of the source program to be edited, and passes in compile and link parms. I run the Procedure, which runs teh EDITOR, which throws up a screen because it needs the File name. I provide that and press Enter, after which no further screens appear because the Procedure program has provided all the other parameter blocks needed by the compiler, the editor, and perhaps even the executable being edited and compiled. I suspect something like this may exist in the IBM world, too, because Wang did not invent all of its technology from scratch. Where things existed and looked good, Wang used them, including the VS instruction set taken from 360/370, and I suspect the VTOC structure for volumes, and the frequency of update of file header information to have a reasonable tradeoff between too-frequent updates and data loss if the system stops unexpectedly. > > 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... :-) I think IBM has skewed the understanding of multitasking for a lot of people by the way they shoehorned interactivity into their batch operating systems. A batch OS can't easily do interactivity but an interactive OS can easily do batch, and can easily be equipped with a few simple features that facilitate batch, such as the Wang VS's Job Queue and Job Classes. IBM, though, has left a lot of people with some strange ideas about how multitasking should work. At least it seems to me to be the case. > > > 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"? :-) No, of course not. It's an academic example. Walk up to any interactive system and run a program that requires no user interactivity, such as a report, and you're doing batch, although it ties up the terminal or PC. To facilitate batch in an interactive OS one might add a way to submit the program to background to free up the terminal. One might further support batch in the scripting or JCL language and might have a feature that creates preformed tasks supported by Job Classes to reduce the parameters that need to be provided to run a program. etc. > > > 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. Yes. I can create, say, two Background Task Initiators in Class A, with a certain Modifiable Data Area size and a few other runtime parameters, then in the scripting language submit certain overnight jobs to Class A. Since there are two initiators, as many as two of that type of job can run concurrently. Any more than two wait in the Job Queue for an initiator of their Class to become available. It's a form of throttling, or load control. The Print Queue and Print Classes are analagous to the Job Queue and Job Classes. A print job tries to go to an available printer of the Class to which the print job was directed. If one is available, the print output goes there, with Print Queue control over restarts, disposition, # of copies, etc. If no printer is available of the required Class, the spooler queues the print output in the Print Queue for a printer of the required class to become available. I believe IBM mainframe OSs use a similar mechanism for Print and Job Queues, although the class might be a 3-digit number while in the Wang VS it is a single letter. That's part of the difference in scale. A large IBM mainframe can run many thousands of users, while a Wang VS can run only 500-1000. So all the facilities of the Wang VS OS are scaled accordingly. > > 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? Sorry, I'm unfamiliar with Intellisense and Visual Studio (although I may have dabbled with the latter a time or three). Direct comparison is difficult because the features and structure are not the same. When I throw a program into Debug, Debug comes up showing me the source line that was executing, from the compiler listing. So it shows comments and everything else shown in the compiler listing. What was executing is usually nothing, as the program was probably waiting for I/O completion. So I might have to press the function key for Step to get the focus into the source code. Once there I can resume execution or Step Over or Step Into, or set a program breakpoint or a data modification breakpoint. I can display and "watch" variables in any of the program's sections. I can modify variables. There's a ton of stuff I can do in Debug to get a handle on what may be a bug in the program. It doesn't do things like autocompletion but it does everything I've found necessary to debug programs, and more. TJ |