From: WangVS on
On Mar 28, 8:43 pm, docdw...(a)panix.com () wrote:
> In article <af8533cd-acfe-4b3e-bb50-92e72e3eb...(a)35g2000yqm.googlegroups.com>,
>
> WangVS  <tjun...(a)tjunker.com> wrote:

> >This reminds me of another advantage of the Wang VS environment.  I
> >never saw a Want site where there was rigid delineation of groups in
> >development or operations.
>
> You obviously didn't work at that International Bank to which I
> contracted.  I found the VS to be a real Coder's Machine... give a
> progammer an idea about what you wanted done and it'd more-or-less happen
> after a few days of pizza-consumption, lack of showering and sleeping
> under conference tables.

Sounds the opposite of a coder's machine and environment. Everyone
did everything instead of delineation between system and application
groups and between systems analysts and coders. Right, give a
programmer a general idea of what you wanted, and after a short time
you'd have it. In the delineated environment it might be six months
before the first committee meeting...

> (I implemented 'pop-up windows' using DISPLAY AND READ MODIFIABLE that
> way.)

Cool! Really good programming resulted in sized popups within the
current screen. Less good programming resulted in full screen
popups. Poor programming resulted in no such options, just fill in
the current screen or die.

TJ
From: Anonymous on
In article <37d36ae2-c85e-4801-8c9b-2bbf8dc0fb23(a)o30g2000yqb.googlegroups.com>,
WangVS <tjunker(a)tjunker.com> wrote:
>On Mar 28, 8:43?pm, docdw...(a)panix.com () wrote:
>> In article <af8533cd-acfe-4b3e-bb50-92e72e3eb...(a)35g2000yqm.googlegroups.com>,
>>
>> WangVS ?<tjun...(a)tjunker.com> wrote:
>
>> >This reminds me of another advantage of the Wang VS environment. ?I
>> >never saw a Want site where there was rigid delineation of groups in
>> >development or operations.
>>
>> You obviously didn't work at that International Bank to which I
>> contracted. ?I found the VS to be a real Coder's Machine... give a
>> progammer an idea about what you wanted done and it'd more-or-less happen
>> after a few days of pizza-consumption, lack of showering and sleeping
>> under conference tables.
>
>Sounds the opposite of a coder's machine and environment. Everyone
>did everything instead of delineation between system and application
>groups and between systems analysts and coders.

We appear to disagree on what constitutes a 'Coder's Machine'. At the
International Bank folks would dither about for endless amounts of time
figuring out what they actually wanted; it was not up to the programmer to
determine how multiparty trades were to be executed or how a Failure To
Deliver condition was to be indicated in the weekly reports, just... tell
us what you want and we'll make it so.

>Right, give a
>programmer a general idea of what you wanted, and after a short time
>you'd have it. In the delineated environment it might be six months
>before the first committee meeting...

The latter does not rule out the former as a machine which allows the
programmer to concentrate on the code, as opposed to invoking CEMT and
scrabbling through CEDF.

>
>> (I implemented 'pop-up windows' using DISPLAY AND READ MODIFIABLE that
>> way.)
>
>Cool! Really good programming resulted in sized popups within the
>current screen. Less good programming resulted in full screen
>popups. Poor programming resulted in no such options, just fill in
>the current screen or die.

It never occurred to me to call a new screen a 'full screen popup', it
was... a new screen.

DD

From: Pete Dashwood on
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. 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."


From: Richard on
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."

From: Michael Wojcik on
WangVS wrote:
> On Mar 28, 12:22 pm, Michael Wojcik <mwoj...(a)newsguy.com> wrote:
>> WangVS wrote:
>>
>>> 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.
>> The screen *definitions* are external to the application program.
>> Obviously the application needs access to the data that's being
>> transferred to and from the terminal.
>
> But in Wang COBOL the screen definitions are internal to the program,
> although they may be externalized by putting them in copybooks or
> subprograms. Either way, though, they are part of the program at
> compile or link time, so the compiler and linker have opportunities to
> flag reference errors.

As they are with CICS map definitions, if the build process is at all
sane; the map files are processed to generate load modules and
copybooks, and then the application is compiled with those copybooks.

Keeping the screen definitions internal to the application isn't the
only way to make the necessary information available to the build
toolchain.

>>> 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.
>> This is a fairly apt comparison (and one that a number of people, such
>> as longtime IBM guru Lynn Wheeler, have made). CICS appications
>> running in the basic pseudoconversational mode are quite similar,
>> architecturally, to applications running under an HTTP server.
>
> But in Wang COBOL the screen I/O is subordinate to the program, and
> the stream of screen transactions occurs essentially inline in the
> program. So any and all state information is local to the program and
> no tricks need be employed to keep track of state.

Neither of these approaches is necessarily advantageous over the
other. And "no tricks need be employed" to maintain state in CICS
applications either; there are first-class state mechanisms provided
by the environment, and they work just fine.

>>> 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.
>> CGI, or any other server-side execution mechanism for HTTP servers
>> (Apache modules like mod_php; IIS ASP, WPAS, and other execution
>> engines; Tomcat's servlet container; ...). One important difference is
>> that by default in CICS most of that application state is stored
>> server-side, but HTTP applications use a variety of server-side and
>> client-side mechanisms, and the trend (particularly with REST) is to
>> push more and more to the client.
>
> 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.

Yes, as with essentially any of the traditional terminal-based
environments.

HTTP RIA applications broke with this model specifically to improve
user-visible response time by reducing the number of relatively
high-latency synchronous exchanges with the server. It's a natural
evolution of the interactive timesharing model.

But that's beside the point when considering differences between the
Wang environment and CICS, which both keep state on the server
(excluding hybrid environments that front-end server-side applications
with smart clients).

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

That's not a particularly significant difference in practice. The two
architectures are likely isomorphic for pretty much all application
designs and it's not difficult to convert between them.

And, as I noted previously, the pseudoconversational model is not the
only one provided by CICS, so this isn't an "essential" difference
between the two environments.

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

What difficulties?

> No mechanisms are needed
> to keep track of state in a Wang COBOL program

Nonsense, unless the application is stateless and purely functional.
The mechanisms might look different in the two environments (though
typically those differences will be very slight indeed), but they're
present in both.

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

That would be a larger scheduling grain.

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

I don't believe that's a meaningful distinction. CICS transactions can
be initiated by programs, and often are.

I'm afraid you're making "the CICS model" (already a suspicious
portmanteau of many facilities and application affordances) out to be
quite a lot simpler and restrictive than it actually is. CICS
certainly has its quirks, but it's far more flexible than the
request/response model you are describing.

None of this is to say anything against the Wang environment; I
haven't used it myself, and it may well be a swell walk in the park.
But having programmed in quite a few environments over the years
(8-bit personal computers and embedded systems; MS/DOS, OS/2, and
Windows versions 2 through 2008; a dozen or so Unix flavors on
machines big and small; the AS/400; CICS, IMS, MVS batch; and a
handful of others) and more programming languages and development
systems than I can count, I'm rather dubious about any attempt to
declare any one simply better than another. (Sure, Unix beats MS/DOS
for general-purpose work, but if I had to pick between them for a
monitor for a little embedded system...) It generally indicates a very
reductive and inaccurate portrayal of at least one of the players.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
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