From: Anonymous on
In article <816eemF3ooU1(a)>,
Pete Dashwood <dashwood(a)> wrote:
>WangVS wrote:


>> 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

From: Anonymous on
In article <aa32012e-c65d-4737-bdda-747f969a024c(a)>,
Alistair <alistair(a)> wrote:
>On Mar 27, 2:06?am, docdw...(a) () wrote:


>> 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


From: Anonymous on
In article <2aa10a30-f889-4d56-98fa-ebc93b3825af(a)>,
WangVS <tjunker(a)> wrote:


>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?

From: Clark F Morris on
On Sat, 27 Mar 2010 12:44:41 +1300, "Pete Dashwood"
<dashwood(a)> wrote:

>Alistair wrote:
>> On Mar 26, 4:17 pm, docdw...(a) () wrote:
>>> In article
>>> <f28d7cf0-3f40-46bc-9315-e6b1cc6e0...(a)>,
>>> Alistair <alist...(a)> wrote:
>>>> On Mar 26, 3:51?pm, docdw...(a) () wrote:
>>>>> In article
>>>> <686a67d1-8659-4d75-a3c4-7558fd3f3...(a)>,
>>>>> Alistair ?<alist...(a)> wrote:
>>>>>> On Mar 26, 2:39?pm, docdw...(a) () 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) for instructions and then read it as newsgroup 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.
From: WangVS on
On Mar 27, 7:10 am, "Pete Dashwood"
<dashw...(a)> 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

> 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

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

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.


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.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Prev: Oracle free to use release question
Next: Function Reverse