Re: what was the single mgmt decision made in mid-1990s. period

I can't see the advantage of rewriting MOVE and indicator usage in existing programs. New programs should use the new techniques and old programs should >> be changed as needed when they are maintained. But where's the justification for rewriting the existing programs. At a practical level a MOVE does the same >> thing as an assignment ans SETON does the same thing as a BIF. You're not making the program run any differently, you're only making the source look
different

I think to me the issue is maintainability. Trying to understand what
a MOVE is doing can be a royal pain. Just because you are doing a MOVE
does not mean you are just moving to another field. The fields well
may be different sizes so you are moving to the right. No way to know
except research it.

%Subst(Field:2:4) = Field4;

makes a whole lot more sense than

Move Field4 Field

Or

Move Field1 Field2

vs

Field2 = %Dec(Field1:4:0);

But is old question. Many people have a philosophy of if it ain't
broke, don't fix it. I try to go in the middle. I recently had an
example where programmers had gone in and put in the same date logic
in 10 differents place in the program and everyplace used moves in and
out of different fields. Up to twenty lines of code for every date.
Technically you don't change but trying to figure out what 20 lines of
code for every date was doing was a nightmare. I just wrote one
procedure and tore out the old logic.

Actually, a GUI is a DRAIN on performance

My point exactly. Building an OS to run GUI means doing things
different. For example, when NT was first designed, Cutler designed it
as a server operating system to replace VMS (V > W, M > N, S > T) WNT,
(get it) and he know nothing about GUI. He designed it with subsystems
and all to be message driven but the second they tried to start adding
GUI they ran into problems. The wonderful subsystem and message driven
system was too slow and all that got scrapped to get everything to
perform faster. Same thing with having the GUI run in the kernel. Pure
insanity for a server but necessary to get enough performance of the
GUI.

On Tue, Feb 17, 2009 at 4:40 PM, James Lampert <jamesl@xxxxxxxxxxxxxxxxx> wrote:

Alan Campin wrote:

A GUI is about performance, a server about
stability and security.

Actually, a GUI is a DRAIN on performance. Think about it: the original
Macintosh, and the Tandy 6000 were both based on the 68000. The 6000
could run up to 6 concurrent users (5 of them on VT-100-compatible
terminals). The Mac 128 barely supported one, and indeed, the first
truly viable Mac was the Mac Plus.

Running DOS apps, an 8MHz 8086 was a speeding bullet. Running GEM apps,
it was barely adequate. Running even the earliest versions of WinDoze
was completely impractical, and running anything beyond WinDoze 2 (maybe
3.0) was outright impossible.

Any hypothetical native GUI for the 400 would have to be based on the
graphic extensions to the 5250 data stream, with each terminal handling
all its own rendering.

--
James H. H. Lampert
Touchtone Corporation

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.