Traditional COBOL environment
in [Cobol]
|
From: WangVS on 27 Mar 2010 17:40 On Mar 27, 10:19 am, docdw...(a)panix.com () wrote: > In article <9f61be9e-f82f-42c2-b3df-b96fcac95...(a)z11g2000yqz.googlegroups..com>, > > > > WangVS <tjun...(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 Ah! It seems that in some prior life you inhabited my world. TJ
From: WangVS on 27 Mar 2010 17:43 On Mar 27, 10:29 am, docdw...(a)panix.com () wrote: > In article <2aa10a30-f889-4d56-98fa-ebc93b382...(a)g10g2000yqh.googlegroups..com>, > > WangVS <tjun...(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 No idea. It sounds, though, like you are speaking of the small handbooks, not the primary full-size documentation, which was all 8-1/2 x 11 three ring punched until sometime in the 1990s when a smaller format was adopted for COBOL 85 and COBOL ReSource manuals and VS TCP/IP. TJ
From: Pete Dashwood on 27 Mar 2010 19:38 docdwarf(a)panix.com wrote: > 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... Ah, but the difference between me and Pontius is that I DO wait for an answer... :-) (In fact I usually won't leave until I get one. This has been found to be a real incentive for people to supply an answer...) 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*. My favourite Kipling... So we can add "The land of WANG displays" to "How the elephant got his trunk" and "The Cat that walked by Himself"? :-) Pete -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 27 Mar 2010 20:27 WangVS wrote: > 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 I read all of this very carefully. Thanks for posting it. You are right that SCREEN SECTION is irrelevant and was a conclusion I had jumped to. Your argument that exposure to a certain way of doing things can persuade people that that is the "right" way is also valid. I have encountered this many times in fields from computer programming to Philosophical logic. While it is true that I have been employed by IBM, I made a point very early on in my career to get as broad an experience as was possible at the time. This resulted in me either working for, or on equipment supplied by, the BUNCH (Burroughs, Univac, NCR, CDC, and Honeywell) When PCs arrived, I moved to that environment but primarily with DOS and Windows (because that was the marketplace. Computers have been my career, they are not just a hobby...) By the 90s I was moving into project management and consultancy and nowadays I manage my own company providing software, support, and consultancy to mainly Windows based users. The point about all of this is that I DON'T have a preconceived idea of how things should work.(I DO have a broad enough experience base to be able to understand variations on the fundamental principles.) These days I am not involved with COBOL and all my development is in C# for ..NET, but I still need to deal with clients' legacy COBOL from time to time, and, after making a living from it for a couple of decades, I have a degree of affinity for it. As always, I wish you success with your venture. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 27 Mar 2010 20:34
Clark F Morris wrote: > 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. Thanks Clark. This is the conclusion I am also coming to. I'm not quite ready to move yet until I complete some ongoing cycles with existing clients, but I think I'll be posting on IBM Listserv once my decks are clear. If I get no response, at least I'll know there is no market there for me and I can channel my energies into other areas :-) >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. Bill Klein made me aware of it a little while back. Thanks for the advice. It is likely I will go this way when the time is right. Pete. -- "I used to write COBOL...now I can do anything." |