HP3000-L Archives

July 2015, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Chuck Trites <[log in to unmask]>
Reply To:
Chuck Trites <[log in to unmask]>
Date:
Wed, 15 Jul 2015 22:13:51 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (141 lines)
Lets not forget about using a QUICK screen cluster and trying to delete a line item.  What a nightmare.  I know a few shops that tried to develop applications using 4GL's including TRANSACT.    COBOL and FORTRAN and even BASIC (GrowthPower) were the languages that built the HP3000 applications for business. Any 3rd generation programmer ever liked Data Express? 
Chuck [log in to unmask] Consulting, Inc.59 Doe Ave.Laconia, NH 03246Phone: (603) 219-1500
 


     On Wednesday, July 15, 2015 5:46 PM, Cortlandt Wilson <[log in to unmask]> wrote:
   

 Michel,

Nice to hear from someone from Powerhouse tech support.

I eventually started telling clients and folks at user group meetings on
full support to call you guys more often.  I told them not to feel bad
about it because in a rational world if the vendor wanted the customers to
figure things out on their own they would have invested more in quality
documentation.  The state of the documentation must have been a cleverly
designed full employment plan for the tech support team.

As for bringing a system to it's knees I recall even a efficiently
designed QUIZ report consumed significantly more resources than an
equivalent report written in FORTRAN or COBOL.

There were a couple of known efficiency improvements exploited by SUPRTOOL
that never made it or took a long time to make it into QUIZ.

To go off on a tangent.  I found out much later that the another
organization might have re-written QUIZ from the ground up because the
code base was very delicate.  Another classic case of "just throw
something together for now-- it won't get used much and we can re do it
later".  Except "later" never came and the code was heavily used for
years.
  I've got customers with degrees in science and engineering but with
little knowledge of software engineering or IT who never got the memo
and daily suffer the economic consequences.  It feels to me like the
lack of attention to quality in one important aspect of the business
mystically creeps into other areas of the business.  Excuse me if I
grumble overly much.  Thus endeth the lesson.

- Cortlandt

> Very true. Just like a house, you have to have a solid foundation, and the
> combination of hardware, Image and solid 3GLs is what allowed the platform
> to thrive, and allowed 4GLs to blossom on it later.
>
> As the old saying goes, 'to err is human, but to really foul things up
> requires a computer'.[1]
>
> If you don't know what you are doing, it will take longer to do so in a
> 3GL
> situation, and the lesser level of forgiveness of Cobol and Fortran might
> help a programmer by forcing him/her to think things through a bit more.
> That 'safety net' isn't has 'developped' in Powerhouse (I can't speak
> about
> Speedware, other contributors to this list can).
>
> The product makes so many assumptions in trying to help the programmer,
> that you can code very inefficiently and still produce the intended
> results
> at the development phase, without realizing that it won't scale when you
> put it in production. That's when it brings a 3000 to its knees. I saw
> those situations regularly when doing PowerHouse tech support at Cognos,
> in
> the early 80s.
>
> Clients would call in in search of a solution, and in many instances the
> process of replicating and understanding their issues would highlight
> various 'sub-optimal' approaches that they had been pursuing. Often time,
> they programmers at the other end would come to this realization on their
> own when they were trying to explain the problem to us in Tech Support.
> The
> light would come on.
>
> We were getting commendation from management if we could resolve the issue
> on the initial conversation, since the call was on the customer's dime.
> Even with 'InWats' the telcos were soaking us big time. A call from
> outside
> North America was at the top of the list of those to be resolved on first
> contact.
>
> What became apparent early on in my work with Powerhouse was the
> importance
> of the original design for the database and other file structures.
> Typically, 3GLs will allow a programmer to code himself out of a corner
> much more readily than when using a 4GL, to programmatically overcome
> sub-optimal data structures. You might need to do a head stand with a 4GL
> to do the same. But given a properly designed database/KSAM/flat file
> environment, a 4GL should allow a much faster design and implementation of
> application.
>
> That is not to say there was no mistake in the products being offered.
> Cognos at one time bought a third party application, originally named
> $Flow. They rebranded it 'PowerPlan'. It was a spreadsheet-on-a-3000
> product.
>
> It would bring a 3000 to its knees. Mercifully, it died an early death
> when
> PCs started proliferating.
>
> Internally, we called it 'PowerPig'.
>
> Jean-Michel Adam
>
> [1] http://quoteinvestigator.com/2010/12/07/foul-computer/
>
> On 14 July 2015 at 06:08, Chuck Trites <
> [log in to unmask]> wrote:
>
>> To say that COBOL and FORTRAN programmers were less productive than
>> users
>> using a 4th GL on an HP3000 is outrageous.  The applications written and
>> used by businesses all over the world for decades were NOT 4th GL's.  In
>> the early days of 4th GL's, these amateur users brought the HP3000 to
>> it's
>> knees.  I have used almost all of the 3rd party products developed for
>> the
>> 3000 over the last 30 or so years.  Without COBOL and FORTRAN this
>> platform
>> would not have existed for MB Foster or any other 3rd party 4th GL to
>> have
>> been born.
>> Chuck [log in to unmask] Consulting, Inc.59 Doe
>> Ave.Laconia, NH 03246Phone: (603) 219-1500
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *



* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
  

ATOM RSS1 RSS2