× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I think it's more likely Rochester's changing because of the influx of
younger folks with heavy exposure to PC architecture and little, if any,
exposure to mainframes.

Back in the 70's, I coded CCP (CICS on the System/3) and rejoiced when the
System/38 was announced (fortunately I avoided the False Prophet of the
System/34).  While CICS and CCP are efficient for simple transactions,
developing a program for a complex transaction is much more difficult in
that environment.  And those techniques were developed at a time when
hardware and communications resources were extremely slow and extremely
expensive.  Yes, they're efficient from a hardware standpoint because they
had to be...back then, CFINT was really hardware: core memory and small,
slow disks.  Today CFINT is software.

The issues today are application flexibility and programmer
skills/resources.  Notwithstanding a variety of tools available today, I
don't see application development, particularly when using PRUF-type coding,
getting any easier and I don't see a lot of iSeries programmers boosting
their professional skills to meet the challenge.  Maybe I need more
education and it's likely I need to find the right development tools.  But,
if application redesign is required, the big question is if the iSeries, or
OS/400, is the right target platform.

There's no question in my mind that the Karmic wheel is turning on the
iSeries.  Somebody in IBM has a Post-It with a notation: "Kill the iSeries".
Those of us, er, those of /you/, with modern application designs (UI
separated from business logic, etc.) will survive.  For everybody else, Y2K
will seem like a picnic.

-----Original Message-----
From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On
Behalf Of Paul Raulerson
Sent: Saturday, November 10, 2001 8:37 PM
To: midrange-l@midrange.com
Subject: Re: CFINT: I understand it now...

I don't agree with this chain of thought. In fact, server applications when
well designed,
are very efficient. Interactive programs can be very efficient, but in an
AS/400 environment,
they are nowhere near as efficient as say, CICS applications. (Even given
that AS/400
interactive applications are probably more efficient that anything else out
there except for
old Wang VS programs.... ;)

I was talking to someone yesterday who mentioned this debate going on, and
after reading the
past 400 or so messages on the subject, I think we are all missing some
crucial point of logic.
I *think* it may be that the people in Rochester are slowing being replaced
by people from
mainframe backgrounds, who just have a really different train of thought
than pure midrange
people. Batch processing is a different animal entirely on a mainframe than
an interactive
application. In fact, programs like TSO and CICS  on a mainframe are a
single 'batch'
application that just happens to provide interactive services.

The CFINT thing, well, it sort of makes sense from a mainframe point of
view - and there is
no doubt at all that IBM is in a STRONG push to unify their product line.


-Paul

----- Original Message -----
From: "Leif Svalgaard" <leif@leif.org>
To: <midrange-l@midrange.com>
Sent: Saturday, November 10, 2001 12:13 PM
Subject: Re: CFINT: I understand it now...


> From: Joe Pluta <joepluta@PlutaBrothers.com>
> > From: Reeve Fritchman
> > It's simple: compared to 5250 applications, server applications
> > are grossly inefficient.
>
> In what way?  In fact, a well written server program is far MORE efficient
> than a traditional monolithic green screen application.
>
> ===> I think you are overstating the point here. They are about the
> same when talking processing efficiency. The server approach is
> far MORE efficient when it comes to maintenance, but that is not
> the issue here.
>
> Let us assume for a moment that everybody went where 'IBM
> wants them to go' and converted everything to run client/server.
> That would remove the CFINT revenue and if as some (e.g.
> Jon Pais) have claimed that revenue is essential to the viability
> of the platform, then the platform will die when everybody is
> doing client/server. The only saving grace is that doing client/
> server may require a lot more processing power forcing people
> to buy bigger boxes thus enhancing IBM's revenue to offset the
> CFINT tax,
>
> If as you say, server programs are far MORE efficient, people
> can get by with smaller boxes further eroding IBM's revenue
> and thus the viability of the platform. I think I may be missing
> something here, but I can't see what.
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.