From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 101deb,6be11e765df1680d
X-Google-Attributes: gid101deb,public
X-Google-Thread: 103376,6be11e765df1680d
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-02-25 17:19:46 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!vixen.cso.uiuc.edu!uwm.edu!rpi!not-for-mail
From: multics@neroon.user.acm.cs.rpi.edu (Richard Shetron)
Newsgroups: comp.lang.pl1,comp.lang.ada
Subject: Re: PL/I is a viable language
Date: 26 Feb 2003 01:19:38 GMT
Organization: Rensselaer Polytechnic Institute, Troy NY, USA
Sender: multics@nospam.acm.rpi.edu
Message-ID: <b3h4na$nro$1@newsfeeds.rpi.edu>
References: <OqV5a.53545$jM5.135177@newsfeeds.bigpond.com>
 <BkW5a.222858$vm2.168685@rwcrnsc54> <v5i2u5dt5cp9c0@corp.supernews.com>
 <q0g6a.538999$HG.95100948@news4.srv.hcvlny.cv.net>
NNTP-Posting-Host: neroon.user.acm.cs.rpi.edu
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Originator: multics@neroon.user.acm.cs.rpi.edu (Richard Shetron)
Xref: archiver1.google.com comp.lang.pl1:4458 comp.lang.ada:34587
Date: 2003-02-26T01:19:38+00:00
List-Id: <comp.lang.ada>

In article <q0g6a.538999$HG.95100948@news4.srv.hcvlny.cv.net>,
John W. Kennedy <jwkenne@attglobal.net> wrote:
>GerardS wrote:
>> | Glen Herrmannsfeldt wrote:
>> || robin wrote:
>> | (snip regarding the ability to find errors in programs)
>> |> PL/I tells you where the needle actually is.
>> 
>> | On the 360/91 it told you where the error was near.
>> 
>> PL/I had an option (for the 360/91) to identify the
>> correct PL/I statement.  One method was to put an extra
>> semicolon at the end of each statement (or those
>> statements that were likely to cause an error).
>
>At the cost of slowing the 91 down to a 75.  It meant issuing the
>          BCR   15,0
>(flush pipeline) instruction.
>
>By the way, all this also applied to the 360/95, 360/195, and 370/195.

This was not a PL/1 problem, but a problem with the underlaying
hardware.  These were early pipelined machines where an error in
the pipeline wasn't readily tracked back to actually offending
instruction.  If the hardware can't report the correct program
counter for errors, the software can't do more then guess.