How to decode PL1 programming language into C++ language

[kumaresh...@gmail.com]

Hi everyone,
I work with OpenFOAM based on C++ platform.
One of my reference code found in 1977 journal was written with PL1 language. I have no knowledge with PL1.
In order to understand the PL1 program, is it possible to decode into C++ language?

Kindly someone share your ideas.
Thank you

[nobody in particular]

A quick websearch resulted in hits for several companies offering the
service. I guess if you spend a bit of time you may be able to find a
freeware utility. PL/I was available for many platforms so depending on
what your code was written to run on it may be easy or difficult to
convert it to C++

PL/I is infinitely more readable than C++ except for a few features like
the macro language. The other thing about PL/I is that although it is
statically typed, it converts implicity based on the target variable.
That is used very often and will not necessarily be easily converted to
C++ straight across without some creative classmaking.

If the program is not large you could post it here although if it is a
homework question you will be drawn and quartered, shot, hung, and taken
down and shot again.

[kumaresh...@gmail.com]

Thank you for your response. The program is quite large. If you don't mind, can I mail you personally ?

Thank you again

[robin....@gmail.com]

On Tuesday, July 21, 2020 at 3:13:16 AM UTC+10, kumares...@gmail.com wrote:
> Hi everyone,
> I work with OpenFOAM based on C++ platform.
> One of my reference code found in 1977 journal was written with PL1 language. I have no knowledge with PL1.
> In order to understand the PL1 program, is it possible to decode into C++ language?

PL/I is easy to read; probably one of the easiest languages to read.
There are many introductory PL/I books available on Amazon.

[robin....@gmail.com]

Suitable books include:

J. K. Hughes: PL/I Structured Programming

[robin....@gmail.com]

On Tuesday, July 21, 2020 at 11:49:36 AM UTC+10, robin...@gmail.com wrote:

> PL/I is easy to read; probably one of the easiest languages to read.
> There are many introductory PL/I books available on Amazon.

P. Abel: Structured Programming in PL/I and PL/C

Neuhold & Lawson: The PL/I Machine: An Introduction to Proramming

E. Sturm: The New PL/I

[kumaresh...@gmail.com]

Thank you so much for your suggestion. I'll look into the books to understand the PL/I Programming

[Richard L. Hamilton]

In article <a8cc71d9-1afc-43dd...@googlegroups.com>,

If memory serves, that book had a lot of errors, although that would have
been the original, and it's in 3rd edition now, so maybe it's gotten better.

[nobody in particular]

I learned on that book in the late 70s or early 80s. I don't recall
whether it was bug-ridden or not but I do remember liking it and that it
helped at the time. I think it's worth getting a copy.

[Richard L. Hamilton]

In article <rgg93s$25pt$2...@neodome.net>,

I recently got a used copy of 2nd edition cheap from Amazon (3rd party
seller), just to refresh my memory. That does no good for all the new
C compatibility functions, post-Y2K date functions, sort of
object-oriented features, etc, but it's better than nothing at the
price, I suppose.

[Peter Flass]

Both Robin Vowels and Eberhard Sturm have relatively recent books that
cover the new features. I’m not sure Robin’s is readily available, you
might have to order from him and pay in Australian Dinars or something. I
think Eberhard’s is available from Amazon: “The New Pl/I”.

--
Pete

[nobody in particular]

The IBM publications are downloadable for free. If you want the latest
and greatest info, see here:

https://www.ibm.com/support/pages/enterprise-pli-zos-documentation-library

I hope the link doesn't break as it just wrapped in news client.

The PL/I Language reference will tell you about the language itself; the
PL/I Programmer's Guide is how to use the compiler options and compile
and link programs, but it often contains helpful guidance and examples
about various topics.

[Robert Prins]

You could put it on your GMail Drive and share the URL... (or any other
file-sharing service)

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

[Robin Vowels]

On Monday, August 31, 2020 at 11:09:00 PM UTC+10, Peter Flass wrote:
> Richard L. Hamilton <r......@smart.net> wrote:
> > In article <r......@neodome.net>,

> > nobody in particular <n.....@devnull.org> writes:
> >> On 05/08/2020 15:48, Richard L. Hamilton wrote:

> >>> In article <a......@googlegroups.com>,
> >>> r.......@gmail.com writes:
> >>>> On Tuesday, July 21, 2020 at 11:49:36 AM UTC+10, r......@gmail.com wrote:

> >>>>> On Tuesday, July 21, 2020 at 3:13:16 AM UTC+10, k.......@gmail.com wrote:
> >>>>>> Hi everyone,
> >>>>>> I work with OpenFOAM based on C++ platform.
> >>>>>> One of my reference code found in 1977 journal was written with PL1
> >>>>>> language. I have no knowledge with PL1.
> >>>>>> In order to understand the PL1 program, is it possible to decode into C++ language?
> >>>>>
> >>>>> PL/I is easy to read; probably one of the easiest languages to read.
> >>>>> There are many introductory PL/I books available on Amazon.
> >>>>
> >>>> Suitable books include:
> >>>>
> >>>> J. K. Hughes: PL/I Structured Programming
> >>>
> >>>
> >>> If memory serves, that book had a lot of errors, although that would have
> >>> been the original, and it's in 3rd edition now, so maybe it's gotten better.
>
> >> I learned on that book in the late 70s or early 80s. I don't recall
> >> whether it was bug-ridden or not but I do remember liking it and that it
> >> helped at the time. I think it's worth getting a copy.
> >
> > I recently got a used copy of 2nd edition cheap from Amazon (3rd party
> > seller), just to refresh my memory. That does no good for all the new
> > C compatibility functions, post-Y2K date functions, sort of
> > object-oriented features, etc, but it's better than nothing at the
> > price, I suppose.
.
> Both Robin Vowels and Eberhard Sturm have relatively recent books that
> cover the new features. I’m not sure Robin’s is readily available,

.
Yes, my book is still available, by mail order. It's title is
"Introduction to PL/I, Algorithms, and Structured Programming",
with 669 pages.
Comes with floppy disc containing the programs from the book,
plus procedure for many of the new built-in functions.
.

> you
> might have to order from him and pay in Australian Dinars or something. I

> think Eberhard’s is available from Amazon: “The New PL/I”.

[Kumaresh Selvakumar]

Hello all,
In my previous post, I have asked for decoding the PL1 program into C++ language (in order to understand the PL1 program). I couldnt able to decode into C++ language.
So, I thought of compiling PL1 program directly by its own compiler. I found a PL/1 compiler for a Linux here : iron-spring.com/download.html
I have installed the PL1 compiler there and while running sample case files, I found that three sample makefiles for one program that can be used to compile.

I don't know how to fix and compile the program, which I m looking for...
I'll copy the program here. Kindly someone guide me to compile or convert into C++ (so that its easy to compile in C++)
//*******************************************************//
PL1 PROGRAM

ANTHLOG: PROC OPTIONS (MAIN);

/* INPUT DATA */;

REPEAT: ON ENDFILE (SYSIN) STOP;
DECLARE ISTRING CHAR(80),NAME CHAR(20);
DT=120;
NSEG#=5;
FINTIM=30;
TSOAK=3;
AHEAT=130;
KHEAT=100;
XRAD=.01;
GET EDIT(ISTRING)(A(80));
IF INDEX(ISTRING,'=')>0 THEN DO;
IF INDEX(ISTRING,';')=0 THEN
SUBSTR(ISTRING,80,1)=';';
GET STRING(ISTRING) DATA;
GET EDIT(NAME) (A(80));
END;
ELSE NAME=SUBSTR(ISTRING,1,20);
DECLARE (MASS,NIT,MOISTO,NPVOL,KHEAT) DECIMAL FLOAT;
GET LIST(PC,PH,PX,PN,PS);
PY=PC+PH+PX+PN+PS;
CAR=PC/PY;
HY=PH/PY;
OX=PX/PY;
NIT=PN/PY;
SUL=PS/PY;

GET LIST(PMOISTO,PASHDRY,RHODRY,TO);
MOISTO=PMOISTO/100;
ASH=PASHDRY* (1-MOISTO) /100;
DAFO=1-MOISTO-ASH;
RHOWET=RHOORY/(1-MOISTO) ;
RHOO=RHOWET/(0.875+.137E-3*RHODRY);

GET LIST (WIDTH,WALL,WCOND,WSPHT,WRHO);

HWIDTH=WIDTH/2;
NSEG=NSEG#*4+1 ;
DX=HWIDTH/NSEG;
DO=DX*DX/DT;
VO=DX/DT;
M=1.5+WALL/DX;
N=M+NSEG-1;
WDIFF=WCOND/(WRHO*WSPHT);
*********************************************

GET LIST(NF);
(NOUFL): BEGIN;
DECLARE(TIMES,TIMESHR,TEMPS)(NF);
GET LIST(TIMESHR);
TIMES=TIMESHR*3600;
GET LIST(TEMPS);

/* INITIAL CONDITIONS */;

DECLARE(TRN1,TRN2,TRN3,TRN4,TRN5,H2,CH4,CO)(N);
YINF=1.573-16*HY-0.14*OX-NIT-SUL;
CINF=YINF-0.02;
PVOL=16.3*HY-.21*OX+NIT+SUL-0.667;
CPVOL=(15*HY-1.01*OX-0.598)/PVOL;
HPVOL=(1.3*HY-0.051)/PVOL;
XPVOL=(0.8*OX-.002)/PVOL;
NPVOL=(NIT-.01)/PVOL;
SPVOL=(SUL-0.006)/PVOL;
TRN1=0.015;
TRN2=MIN(0.05,PVOL-0.015);
TRN3=MIN(0.05,MAX(0,PVOL-0.065));
TRN4=MIN(0.1,MAX(0,PVOL-0.115));
TRN5=MAX(0,PVOL-0.215);
QH2=0.034-0.3*HY;
QCH4=0.06;
QCO=0.35*OX;
H2=QH2;
CH4=QCH4;
CO=QCO;

DECLARE(MOIST,DAF,ATMASS)(N)DECIMAL FLOAT;
DAF=DAFO;
MOIST=MOISTO;
ATMASS=1/(CAR/12+HY+OX/16+NIT/14+SUL/32);

DECLARE(Q,H,K,CVOL,ESHR)(N) DECIMAL FLOAT;
DECLARE(KPART,KCOKE,KMOIST,KGAS,KO,KRAD,KL,KU,LBOIL,TIME)
DECIMAL FLOAT;
H=0;
EO=1-RHOO*(0.000668*DAFO+ASH/3000);
DO I=1 TO M-1;
Q(I)=0;
K(I)=WCOND;
CVOL(I)=WRHO*WSPHT;
END;
*********************************************

DECLARE(T,L,G,U,Z)(N)DECIMAL FLOAT;
DO I=1 TO M-1;
T(I)=TEMPS(1);
END;
DO I=M TO N;
T(I)=TO;
END;
IF=1;
XB=0;
CSTEAM=2000;
LBOIL=2.257E6;
QINPUT=0;

DECLARE INDX(5),OUT(26,5);
CTIME=20;
INDX=TO/50+1;
DO I=1 TO 26;
IF TO>50*I THEN OUT(I,*)=0;
ELSE OUT(I,*)=100;
END;

CTIME=OUT(18,5);
TIME=0;

TLOOP: DO TIME=0 BY DT WHILE(TIME<MIN(FINTIM,CTIME+TSOAK)*3600);
XLOOP: DO I=M TO N;
TK=T(I)+273;

/* VOLATILE EVOLUTION MODEL */

IF T(I)>350 THEN DO;
TRN1(I)=TRN1(I)*EXP(-.13E14*EXP(-29486/TK)*DT);
TRN2(I)=TRN2(I)*EXP(-.13E14*EXP(-28042/TK)*DT);
TRN3(I)=TRN3(I)*EXP(-.13E14*EXP(-26838/TK)*DT);
TRN4(I)=TRN4(I)*EXP(-.13E14*EXP(-26116/TK)*DT);
TRN5(I)=TRN5(I)*EXP(-.13E14*EXP(-25755/TK)*DT);
PVOL=TRN1(I)+TRN2(I)+TRN3(I)+TRN4(I)+TRN5(I);

H2(I)=MIN(H2(I),QH2*EXP(-((T(I)-350)/455)**2.5));
CH4(I)=MIN(CH4(I),QCH4*EXP(-((T(I)-350)/324)**2.38));
CO(I)=MIN(CO(I),QCO*EXP(-((T(I)-350)/420)**2.63));

Y=PVOL+H2(I)+CH4(I)+CO(I)+YINF;
CAR=(CPVOL*PVOL+.75*CH4(I)+.4286*CO(I)+CINF)/Y;
HY=(HPVOL*PVOL+.25*CH4(I)+H2(I)+.002)/Y;
OX=(XPVOL*PVOL+.5714*CO(I)+.002)/Y.;
NIT=(NPVOL*PVOL+.01)/Y;
SUL=(SPVOL*PVOL+.006)/Y;
DAF(I)=Y*DAFO;
ATMASS(I)=1/(CAR/12+HY+OX/16+NIT/14+SUL/32);
END;

****************

/* PHYSICAL PROPERTIES /MODEL */;

MASS=DAF(I)+ASH+MOIST(I);
RHO=RHOO*MASS;

DENSDAF=1/(0.001388-7.69E-5*ATMASS(I));
DENS=MASS/(DAF(I)/DENSDAF+ASH/3000+MOIST(I)/1000);

E=1-RHO/DENS;
ESHR(I)=MAX(0,1-(1-E)/(1-EO));

F1=EXP(380/TK);
E1=F1*(380/TK/(F1-1))**2;
F2=EXP(1800/TK);
E2=F2*(1800/TK/(F2-1))**2;
CDAF=8314.4*(E1+2*E2)/ATMASS(I);
CASH=754+.586*T(I);
C=(DAF(I)*CDAF+ASH*CASH+4186.8*MOIST(I))/MASS;
CVOL(I)=C*RHO;

HOCH4=6234000*(QCH4-CH4(I));
HOCO=-4243000*(QCO-CO(I));
HOH2=966000*(QH2-H2(I));
HO=HOCH4+HOCO+HOH2;
QDAF=KHEAT*EXP(-AHEAT*1E6/(8314.4*TK))*(HO-H(I));

Q(I)=QDAF*DAFO*RHOO;
H(I)=H(I)+QDAF*DT;
IF TK<700 THEN KGAS=7.83E-5*TK;
ELSE IF TK<1100 THEN KGAS=1.095E-3*TK-0.712;
ELSE KGAS=4.48E-4*TK;
KO=(0.016*ATMASS(I)-0.105)*SQRT(TK);
IF E<EO THEN DO;
EPART=1-(1-E)**0.333333;
KPART=1/(EPART/KGAS+(1-EPART)/KO);
EMOIST=RHOO*MOIST(I)*0.001;
KMOIST=(0.6-KPART)*EMOIST;
K(I)=KPART+KMOIST;
END;
ELSE DO;
ECOKE=E/(1-E**.6666667+E);
KCOKE=ECOKE*KGAS+(1-ECOKE)*KO;
ERAD=1-(1-ESHR(I))**.666667;
KRAD=1.822E-7*ERAD*XRAD*TK**3;
K(I)=KCOKE+KRAD;
END;

END XLOOP;

****************************

/* TEMPERATURE HISTORY MODEL */;

IF TIME<TIMES(1) THEN
TF=TEMPS(1);
ELSE IF TIME<TIMES(NF) THEN DO;
IF TIME>TIMES(IF+1) THEN
IF=IF+1;
TF=(TEMPS(IF)*(TIMES(IF+1)-TIME)+TEMPS(IF+1)*(TIME-TIMES(IF)))
/(TIMES(IF+1)-TIMES(IF));
END;ELSE
TF=TEMPS(NF);

G(1)=1;
U(1)=0;
Z(1)=TF;
DO I=2 TO N-1;
KL=2/(1/K(I)+1/K(I-1));
KU=2/(1/K(I+1)+1/K(I));
DIFFL=KL/CVOL(I);
DIFFU=KU/CVOL(I);
@DIFFL=DIFFL/DO;
@DIFFU=DIFFU/DO;
REACT=Q(I)/CVOL(I);
@REACT=REACT*DT;
L(I)=-@DIFFL;
G(I)=1+@DIFFL+@DIFFU;
U(I)=-@DIFFU;
Z(I)=T(I)+@REACT;
END;
L(N)=-@DIFFU;
G(N)=1+@DIFFU;
U(N)=0;
Z(N)=T(N)+Q(N)*DT/CVOL(N);
IB,IC=N+1;
DO I=N BY -1 TO M;
IF T(I)=100 & MOIST(I)>0 THEN IB=I;
END;
DO I=N BY -1 TO IB+1;
IF T(I)<100 THEN IC=I;
END;
DO I=IB TO IC-1;
L(I)=0;
G(I)=1;
U(I)=0;
Z(I)=100;
END;

************************************

DO I=2 TO N;
FACTOR=L(I)/G(I-1);
G(I)=G(I)-FACTOR*U(I-1);
Z(I)=Z(I)-FACTOR*Z(I-1);
END;
DO I=N-1 BY -1 TO 1;
Z(I)=Z(I)-Z(I+1)*U(I)/G(I+1);
END;
DO I=1 TO N;
T(I)=Z(I)/G(I);
END;

DO I=M TO N;
IF T(I)>100 & MOIST(I)>0 THEN T(I)=100;
END;
IF IB<N+1 THEN DO;
QB=K(IB-1)*(T(IB-1)-100)/DX;
QBMAX=LBOIL*(DX-XB)*RHOO*MOIST(IB)/DT;
IF QB>QBMAX THEN DO;
QB=QBMAX;
XB=0;
MOIST(IB)=0;
END;
ELSE XB=XB+QB*DT/(RHOO*MOIST(IB)*LBOIL);
IF IC<N+1 THEN DO;
QC=K(IC)*(100-T(IC))/DX;
QERR=QB-QC;
DO I=IC TO N HHILE(QERR>O);
QSENS=CVOL(I)*(100-T(I))*VO;
IF QSENS>QERR THEN DO;
T(I)=T(I)+QERR/(CVOL(I)*VO);
MOIST(I)=MOIST(I)+QERR/(LBOIL*RHOO*VO);
QERR=0;
END;
ELSE DO;
T(I)=100;
MOIST(I)=MOIST(I)+QSENS/(LBOIL*RHOO*VO);
QERR=QERR-QSENS;
END;END;END;
ELSE DO;
V=CSTEAM*QB/LBOIL;
DO I=IB-1 BY -1 TO M WHILE(ESHR(I)=0);
VEL=V/CVOL(I);
@VEL=VEL/VO;
T(I)=T(I)-@VEL*(T(I-1)-T(I+1))/2;
END;END;END;
IF M>2 THEN
QINPUT=QINPUT+MAX(O, WCOND*(T(1)-T(M-1))/((M-2)*VO));

***********************

/* OUTPUT */;

DO I=1 TO 5;
IF INDX(I)<27 THEN
IF T(NSEG#*(I-1)+M)>=50*INDX(I) THEN DO;
OUT(INDX(I),I)=TIME/3600;
INDX(I)=INDX(I)+1;
END;END;
CTIME=OUT(18,5);

END TLOOP;


PUT EDIT(NAME)(PAGE,X(35),A(20));
PUI EDIT('INPUT DATA')(SKIP(2),X(5),A);
IF INDEX(ISTRING, '=')>0 THEN DO;
PUT EDIT('PROGRAMME CONTROL DATA')(SKIP(2),X(5),A);
PUT EDIT(ISTRING)(SKIP,X(5),A);
END;
PUT EDIT('COAL SPECIFICATION')(SKIP(2),X(5),A);
PUI EDIT('C','H','O','N','S')
(SKIP,X(7),(5) A(6));
PUT EDIT(PC,PH,PX,PN,PS)
(SKIP,X(4),(5) F(6,2));
PUT EDIT('% (DAFB)')(X(2),A(8));
PUT EDIT('CHARGE PREPARATION') (SKIP(2),X(5),A);
PUT EDIT('MOISTURE','ASH','BULK DENSITY','TEMPERATURE')
(SKIP,X(5),A(15),A(12),A(17),A);
PUT EDIT(PMOISTO,PASHDRY,RHODRY,TO)
(SKIP,F(10,1),F(13,1),F(17),F(15));
PUT EDIT('%','% (DRY BASIS)','KG/M3 (DRY BASIS)',' DEG C')
(SKIP,X(8),A(7),A(15),A(21),A);
PUT EDIT ('OVEN SPECIFICATION' )(SKIP(2) ,X(5)) ,A);
PUT EDIT ('WIDTH','WALL:THICKNESS CONDUCTIVITY SPECIFIC '
II'HEAT DENSITY')(SKIP,X(5),A(10),A);
PUT EDIT (WIDTH,WALL,WCOND,WSPHT,WRHO)
(SKIP,F(10,3),F(17,3),F(13,1),F(13),F(10));
PUT EDIT ('M','M','W/M K','J/KG K','KG/M3')
(SKIP,X(7),A(17),A(12),A(12),A(10),A);
PUT EDIT('FLUE TEMPERATURE READINGS')(SKIP(2),X(5),A);
PUT EDIT('NUMBER',NF,'TIMES',TlMESHR,' H','TEMPS',
TEMPS,' DEG C')(SKIP,X(5),A,F(5),SKIP,X(5),A,(NF) F(6,1),A,
SKIP,X(5),A,(NF) F(6),A);
PUT EDIT('PREDICTED TEMPERATURE HISTORY')(SKIP (2) ,X(5) ,A);
PUT EDIT('TEMPERATURE','TIME (H)')(SKIP(2),X(5),A(31),A);
PUT EDIT('(DEG C)','WALL','1/8','1/4','3/8','CENTRE',' ')
(SKIP(2),X(5) ,(4) A(10),A(9),A,SKIP,A);
PUT EDIT((50*I,(OUT(I,J) DO J=1 TO 5) DO I=1 TO 26))
(SKIP,F(9),(5) (X(6),F(4,1)));
PUT EDIT ('COKING TIME',CTIME+3,'H')
(SKIP(2),X(5),A(11),F(8,2),X(3),A);
PUT EDIT('HEAT REQUIREMENTS',QINPUT*1E-6/(RHOO*HWIDTH),
'MJ/KG (DAF INITIAL COAL BASIS)')
(SKIP,X(5),A(17),F(6,3),X(3),A);
END;
GO TO REPEAT;
END ANTHLOG;

//*******************************************************//

Thank you

[Robin Vowels]

On Saturday, October 24, 2020 at 5:11:14 PM UTC+11, Kumaresh Selvakumar wrote:
> Hello all,
> In my previous post, I have asked for decoding the PL1 program into C++ language (in order to understand the PL1 program). I couldnt able to decode into C++ language.
> So, I thought of compiling PL1 program directly by its own compiler. I found a PL/1 compiler for a Linux here : iron-spring.com/download.html
> I have installed the PL1 compiler there and while running sample case files, I found that three sample makefiles for one program that can be used to compile.
>
> I don't know how to fix and compile the program,

.
Since you are able to compile three of the sample programs,
you should have no difficulty in compiling the program you have
posted.
.
For help with that, you should post any error messages here.
.

[Peter J. Seymour]

On 24/10/2020 07:11, Kumaresh Selvakumar wrote:
> Hello all,
> In my previous post, I have asked for decoding the PL1 program into C++ language (in order to understand the PL1 program). I couldnt able to decode into C++ language.
> So, I thought of compiling PL1 program directly by its own compiler. I found a PL/1 compiler for a Linux here : iron-spring.com/download.html
> I have installed the PL1 compiler there and while running sample case files, I found that three sample makefiles for one program that can be used to compile.
>
> I don't know how to fix and compile the program, which I m looking for...
> I'll copy the program here. Kindly someone guide me to compile or convert into C++ (so that its easy to compile in C++)

.....
Out of interest, I tried compiling the supplied source code. I am left
with the impression that it is an unfinished program. It contains
uncorrected syntax errors and there may be portions of code missing. Do
you have other versions of the source?

[carlos feldman]

Hi Kumaresh Selvakumar;

I was taking a look to your program.
Seems to be an old fortan program translated into PL/I, you can easily translate into C,C++,Fortran or even Basic.
It has only one module, called anthlog, no subroutines or external procedures.
Unlike C or C++, PL/I do has Input output routines (also have them Fortran and Basic )
You may want to compile PLI your program with the options SOURCE,NEST,ATTR,XREF . This will give you the nesting of modules and do loops, also the position and type of each variable used.
The program uses Get Edit, and put edit equivalents to printf and scanf.
Also take into account that DO .... END is equivalent to Do {}, that beguin... end is like { }.
There are some complilation errors ( sorry the listing is about 900 lines long, I can't attach it to this message. If you want me, I can email it to you ), mostly format errors, I used IBM's PLI(f) from the middle 60's, so it may be some sintax differences.
With the nested listing you may easily translate PL/I to C, since the 90% of the progam is arithmetic expressions, and the rest is printout. You'll need to convert the put to printf, and the dos, if/then, beguin to the C format.

regards

Carlos
Argentina

[Peter Flass]

Kumaresh Selvakumar <kumaresh...@gmail.com> wrote:
> Hello all,
> In my previous post, I have asked for decoding the PL1 program into C++
> language (in order to understand the PL1 program). I couldnt able to
> decode into C++ language.
> So, I thought of compiling PL1 program directly by its own compiler. I
> found a PL/1 compiler for a Linux here : iron-spring.com/download.html
> I have installed the PL1 compiler there and while running sample case
> files, I found that three sample makefiles for one program that can be used to compile.
>
> I don't know how to fix and compile the program, which I m looking for...
> I'll copy the program here. Kindly someone guide me to compile or convert

> into C++ (so that its easy to compile in C++.

I’m always happy to have code to test with, particularly bad code ;-)

The problems are a mix of errors in the code and a couple of Iron Spring
problems. Simplest are the lines of “***” which should be either converted
to comments or deleted.
1. Line 142: “Y.” at the end of the statement should be just “Y”?
2. Line 316, 322: “PUI” instead of “PUT”.
3. Line 334: extra “)” in format.
4. Line 336: “II” (letter I) instead of “||” (concatenation)
Obviously, as someone said, this program has never compiled.

Now to the bad stuff :-(
5. Line 18: Iron Spring PL/I currently doesn’t support GET DATA without a
data list. This syntax allows you to input any data element “known” at this
point in the program. The format of ISTRING read above with A(80) would be
“name1=value1, name2=value2, ... ;
6. Line 349: unknown, may be a bug handling type-3 DO data lists or may be
syntax error
7. Line 54: Array expressions currently not supported. May be in next
release
8. Line 114, 115: Array cross-sections such as “OUT(I,*)” not currently
supported
9. Various: There is a known lexing bug. A statement that breaks at the and
of a line with no trailing blank and continues in the start column of the
next line with no leading blank may be scanned incorrectly. See line
204-205. This is a simple global change to add a blank following a THEN
that ends a line. I really should fix this, but in <mumble> years no one
has ever encountered it before.

There are simple work-arounds for all the above. For (5) you’d have to
limit the data to be input by saying, e.g. GET DATA(var1,var2...) However,
without having data to be input, and knowing that the program has never
compiled, it might not be worth it.
--
Pete

[Iron Spring Software]

On 10/23/20 11:11 PM, Kumaresh Selvakumar wrote:
> Hello all,
> In my previous post, I have asked for decoding the PL1 program into C++ language (in order to understand the PL1 program). I couldnt able to decode into C++ language.
> So, I thought of compiling PL1 program directly by its own compiler. I found a PL/1 compiler for a Linux here : iron-spring.com/download.html
> I have installed the PL1 compiler there and while running sample case files, I found that three sample makefiles for one program that can be used to compile.
>
> I don't know how to fix and compile the program, which I m looking for...
> I'll copy the program here. Kindly someone guide me to compile or convert into C++ (so that its easy to compile in C++)
> //*******************************************************//
> PL1 PROGRAM
>

...

I don't know what happened. I thought I'd posted a reply, but haven't
seen it yet. I looked thru your program and found a mix of bugs in your
code and a few problems or unimplemented features in Iron Spring PL/I.

My conclusion was that most things are simple to fix, but since this
program has obviously never compiled, and you presumably don't have any
data to be input, it's probably not worth spending time on it. If my
original reply doesn't show up and you still want to pursue it I could
probably recreate it.

If this is for a profit-making operation I could clean up the source for
a small fee. If it's just for fun and entertainment I can help with
fixing it.

[Iron Spring Software]

Oh, I see my previous reply now...

[Kumaresh Selvakumar]

Thank you all for the replies...

Mr. Robin >> A little misunderstanding here. I have said that, to compile a single program three sample makefiles seems necessary (with extensions .lst, .map, .pli) and so, I don't know how to fix with this and compile.

Mr. Peter >> Currently, I'm working on my Ph.D. thesis, and I found a thesis written in PL1 language. I'm hereby attaching the thesis by drive below, where APPENDIX - 3 is the source code which I'm looking forward to. Kindly check it please.

Thesis --> Attached here by google drive, I couldn't able to find attach file option here.
https://drive.google.com/file/d/11LzHppFSCbJyOQU8W5AhSe-A-nwwlds0/view?usp=sharing

Mr. Carlf >> Thank you. I'm not sure whether the code is Fortran based, but ANTHLOG (in thesis found in above link) what you meant is the computer model used to examine the temperature history in the coke oven charge. The programme written in PL1 was operated on an IBM 370/145 computer under the CMS-VM/370 system (REF: thesis).
Thank you for sharing your programming knowledge. Kindly mail me (kumaresh...@gmail.com) the details when you are free please. The reason why I looked for the conversion of PL1 into C language is because, I thought that the compilation process in PL1 is complex and PL1 is new to me. Can I opt PL1 lang or C lang (by conversion) for compilation ? kindly suggest me here please.

Mr. Bearly >> Thank you for your detailed explanation with error messages. I haven't compiled my code yet. It's not my own set of code (Source code is found in the thesis - APPENDIX -3). Being a Ph.D. student, in order to understand the flow physics, I'm looking forward to interpret the sample code based on PL1 language. Thank you again for your kind statements. Its all about my work, not a business related profit making operations. Kindly help me out here to fix it, and I would like to learn and compile by suitable compiler and run on my own.

Once again, thank you all whole heatedly for the responses.
Although my working platform is OpenFOAM, understanding this PL1 code might help to grasp some ideas about my problem. And, it would be a great help if someone guide me to install the appropriate PL1 compiler, where I can work with it. Kindly guide me.
Thank you again

[Peter J. Seymour]

I had a look at the PL/I source code in the thesis PDF. It seems that
some of the errors I previously identified are down to inaccurate OCR of
the source code. When I attempted to OCR the source in the PDF for
myself, I ended up with even more errors. Also, it is now apparent that
the extraneous lines of '*' are not missing code, but are page boundaries.
The OCR errors are easily fixed by comparing the extracted code flagged
as in error with the original in the pdf. The extraneous asterisks can
simply be removed. In his post, Peter Flass has identified the errors
and also identified some current Iron Spring compiler limitations and
work arounds.
Now the program has got me interested, I will look further into making
it run.

[Peter J. Seymour]

On 25/10/2020 04:51, Kumaresh Selvakumar wrote:

I have nibbled away at another error, the PUT EDIT with an iterative
specification.
According to a late language reference manual, an iterative EDIT
specification must be in parentheses. The source code statement needs to
be changed to strictly implement this:

/**PUT EDIT((50*I,(OUT(I,J) DO J=1 TO 5) DO I=1 TO 26))***/
PUT EDIT(50*I,((OUT(I,J) DO J=1 TO 5) DO I=1 TO 26))

That involved moving an opening bracket and the Iron Spring compiler now
accepts the statement. Presumably, early compilers were more lax in
their accepted syntax.

[Robin Vowels]

This PUT statement appears to be syntactically correct to me.
The inner spec is
(OUT(I,J) DO J=1 TO 5)
.
while the outer spec is:

(50*I,(OUT(I,J) DO J=1 TO 5) DO I=1 TO 26)

.
That leaves an outer pair of parentheses for the EDIT list.
.

> PUT EDIT(50*I,((OUT(I,J) DO J=1 TO 5) DO I=1 TO 26))
>
> That involved moving an opening bracket and the Iron Spring compiler now
> accepts the statement. Presumably, early compilers were more lax in
> their accepted syntax.

.
Not observed. Both specs are OK.

[Peter J. Seymour]

OK, my theory doesnt seem to fit, it merely has the merit of compiling.
I wonder what the resultant program would actually do.

[Peter J. Seymour]

Some more progress:

Near the front of the program are the statements:

GET STRING(ISTRING) DATA;
GET EDIT(NAME) (A(80));

They do not seem to make any sense.
If I merge them as
GET STRING(ISTRING) EDIT(NAME) (A(80));
the program seems to make more sense and it compiles, links and runs.
I cannot go further without understanding the input data.
There is one further point though. When I say it runs, I mean
it will start executing and then just hang, even if supplied with some
arbitrary data, and I have to reboot to recover. So it is possible a
further change is required to get the program to end cleanly. (This is
Iron Spring compiler and OS/2)

[Kumaresh Selvakumar]

Thank you for the valuable comments.

Here are the input data:
>>GET LIST(PC,PH,PX,PN,PS);
PC=0.894, PH=0.049, PX=0.037, PN=0.012, PS=0.008

>>GET LIST(PMOISTO,PASHDRY,RHODRY,T0) // Here its T0(initial temperature) not TO --> inaccurate OCR error
PMOISTO=10, PASHDRY=5, RHODRY=750, T0=20

>>GET LIST(WIDTH,WALL,WCOND,WSPHT,WRHO)
WIDTH=0.45, WALL=0.05, WCOND=2.3, WSPHT=1200, WRHO=2800

>>GET LIST(NF)
NF= 1

>>GET LIST(TIMESHR)
TIMESHR= 0-20 (varies hope so)

>>GET LIST(TEMPS)
TEMPS= 1050

In page no:364 of the thesis, from the top at line 8, the line is declared as "IF=1". I think, it shouldn't be "IF" (may be "LF"). Because, the word "IF" might mismatch with the usage of "IF" - conditional statement everywhere in the program. I'm not sure here, kindly correct me if I'm wrong.

Thank you again

[Peter J. Seymour]

On 25/10/2020 12:22, Robin Vowels wrote:

I'm still thinking about this. Maybe I moved the wrong bracket. How about:
PUT EDIT(((50*I,OUT(I,J) DO J=1 TO 5) DO I=1 TO 26))
which also compiles.
What I find confusing is that loop variable I is referenced in two places.

[Peter J. Seymour]

A variable 'IF' will not worry PL/I, it is capable of dealing with such
situations. It could be bad OCR as there is also a variable 'TF' but I
cannot say what is correct for the program.

[Kumaresh Selvakumar]

Thank you. May be 'IF' will not worry PL/I.
Similarly, the variable 'TF' is unique too.

[Peter J. Seymour]

On 25/10/2020 15:24, Kumaresh Selvakumar wrote:
> Thank you. May be 'IF' will not worry PL/I.
> Similarly, the variable 'TF' is unique too.

> It was an interesting problem to look at but I feel I should stop there.
You will need to be sure there are no further OCR errors in the
extracted source code whichever onwards direction you go.

All the best
Peter

[Peter Flass]

That’s what I thought. The syntax is a bit...infelicitous.


--
Pete

[Peter Flass]

Peter J. Seymour <n...@pjsdemon.uk> wrote:

That’s the question. With all these obvious errors, what else is lurking in
the OCRed code? The program doesn’t declare most (all?) variables, and I
think there are over one hundred. It’s going to take a while to comb out
all the errors.

--
Pete

[Peter Flass]

Peter J. Seymour <n...@pjsdemon.uk> wrote:

I don’t have the program in front of me. Doesn’t it loop reading multiple
sets of data until ENDFILE? Use ^z for endfile. Input for GET DATA has to
be terminated by a semicolon, and character input needs to be in quotes.

--
Pete

[Peter Flass]

Peter J. Seymour <n...@pjsdemon.uk> wrote:

Unless they wanted the “50*I” to be repeated, which I do have a problem
with. I looked at the list of 93 undeclared variables, and offhand I didn’t
notice any that seemed to be typos for any others.

--
Pete

[Peter Flass]

Kumaresh Selvakumar <kumaresh...@gmail.com> wrote:
> Thank you for the valuable comments.
>
> Here are the input data:
>>> GET LIST(PC,PH,PX,PN,PS);
> PC=0.894, PH=0.049, PX=0.037, PN=0.012, PS=0.008
>
>>> GET LIST(PMOISTO,PASHDRY,RHODRY,T0) // Here its T0(initial temperature)
>>> not TO --> inaccurate OCR error

> PMOISTO , PASHDRY=5, RHODRYu0, T0
>
>>> GET LIST(WIDTH,WALL,WCOND,WSPHT,WRHO)
> WIDTH=0.45, WALL=0.05, WCOND=2.3, WSPHT 00, WRHO(00

>
>>> GET LIST(NF)
> NF= 1
>
>>> GET LIST(TIMESHR)
> TIMESHR= 0-20 (varies hope so)
>
>>> GET LIST(TEMPS)
> TEMPS= 1050
>
> In page no:364 of the thesis, from the top at line 8, the line is
> declared as "IF=1". I think, it shouldn't be "IF" (may be "LF"). Because,
> the word "IF" might mismatch with the usage of "IF" - conditional
> statement everywhere in the program. I'm not sure here, kindly correct me if I'm wrong.
>
> Thank you again
>

PL/I has no reserved words. I did notice the use of “IF” as a variable
name.

--
Pete

[Robin Vowels]

.
The loop variable can be referenced in as many places as you want.
It's just like an ordinary DO loop, but in a single statement --
the ends of which are indicated by parentheses.

[John W Kennedy]

I have a distant memory of this being the substance of an APAR long,
long ago.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

[Peter J. Seymour]

I find the syntax with multiple DO groups a bit alarming. The problem in
this case is the multiple DO groups. If you remove the 1 TO 26 group so
reducing things to a single group, and recode it as a loop around the
PUT statement, the results seem correct.

[Robin Vowels]

On Tuesday, October 27, 2020 at 8:26:38 PM UTC+11, Peter J. Seymour wrote:

> I find the syntax with multiple DO groups a bit alarming. The problem in
> this case is the multiple DO groups. If you remove the 1 TO 26 group so
> reducing things to a single group, and recode it as a loop around the
> PUT statement, the results seem correct.

.
There's nothing intimidating or alarming about that PUT statement.
The EDIT list occupies less than half a line, and is quite clear.

[Eric Jackson]

On 10/24/2020 8:16 PM, Peter Flass wrote:
> However,
> without having data to be input, and knowing that the program has never
> compiled, it might not be worth it.

The thesis document contains the input for an example run of ANTHLOG at
page 274, with the output on the following pages.

I took a stab at running the program; there are a lot of OCR errors and
a few small PL/I-F incompatibilities with (in my case) PL/I for Windows.
I got it as far as reading the sample input data:

S25
89.4, 4.9, 3.7, 1.2, 0.8
10 5 750 20
0.450 0.050 2.3 1200 2800
1
0
1050

But it fails with INVALIDOP trying to divide by zero on this statement:

ESHR(I)=MAX(0,1-(1-E)/(1-EO));

At which point I ran out of energy. I'm sure there are more OCR errors
I didn't uncover causing this problem. OP (or other interested parties)
could msg me for my updated code if interested.

[Peter Flass]

Maybe host it on sourceforge, github, or somewhere, on the off-chance that
more than one person wants to work on it. (I can’t right now, I have my
hands full)

--
Pete

[Robin Vowels]

You could try getting an attribute and cross-reference listing.
With OCR, zeros and capital OH can be mis-interpreted.
For example, is that E0 or EO?

As well as that, good idea to enable SUBSCRIPTRANGE, SIZE.

[carlos feldman]

Hi Everyone,

I was working on this program yesterday, and I've got a clean compilation, and the same numeric results as the thesis.
I used PL/I (F) under Music/SP system, what's saying working in the same envirnoment as the original program, written for IBM370 CMS.
There were a couple of typos, from scanning, and a a format error in the original program ( trying to read A(80) into a string (20).
I think modern versions of PL/I may have different behaviour. So the best thing to do is to rewrite it in C++, using the working program as a base.
Of course I sent the corrected program to mr. Kumaresh

I also had the zerodivide condition, and after tracking the guilty sentencem i was a thypo, sompething like t0 instead of to, I checked the cross referencte and the variable was used once. The same happened in other sentence. That's the price for undeclared variables in PLI, worst, where variables with the name of a pli keyword....
The results are as follow:

1 PAGE 1
VERSION 5.5 OS/360 PL/I COMPILER (F) DATE 20.301
-PL/I F COMPILER OPTIONS SPECIFIED ARE AS FOLLOWS--
0 SM=(2,72,1),D,NS,NA,NX,NOL,FE,NOSOURCE,NOXREF,NOATR,NOMAP
0IEM3904I THE FOLLOWING STRING NOT IDENTIFIED AS A KEYWORD- NOMAP
1 ANTHLOG: PROC OPTIONS (MAIN); PAGE 2
- COMPILER DIAGNOSTICS.
-
0 ERRORS.
- IEM0097I 82 INVALID CHARACTER HAS BEEN REPLACED BY BLANK IN OR FOLLOWING STATEMENT NUMBER 82 . THE
- CONTAINING OUTPUT RECORD IS MARKED BY AN ASTERISK.
-
- WARNINGS SUPPRESSED.
-AUXILIARY STORAGE WILL NOT BE USED FOR DICTIONARY WHEN SIZE = 120K
-COMPILE TIME .24 MINS
0ELAPSED TIME .02 MINS
1
1 S25
0 INPUT DATA
0 COAL SPECIFICATION
C H O N S
89.40 4.90 3.70 1.20 0.80 % (DAFB)
0 CHARGE PREPARATION
MOISTURE ASH BULK DENSITY TEMPERATURE
10.0 5.0 750 20
% % (DRY BASIS) KG/M3 (DRY BASIS) DEG C
0 OVEN SPECIFICATION
WIDTH WALL:THICKNESS CONDUCTIVITY SPECIFIC HEAT DENSITY

0.450 0.050 2.3 1200 2800

M M W/M K J/KG K KG/M3
0 FLUE TEMPERATURE READINGS
NUMBER 1TIMES
0.0 H
TEMPS 1050 DEG C
0 PREDICTED TEMPERATURE HISTORY
0 TEMPERATURE TIME (H)
0 (DEG C) WALL 1/8 1/4 3/8 CENTRE

50 0.0 0.2 0.7 1.3 2.0
100 0.0 0.3 0.7 1.4 2.2
150 0.1 1.5 4.2 8.0 12.6
200 0.1 1.6 4.5 8.7 12.9
250 0.1 1.7 4.9 9.0 13.2
300 0.2 1.9 5.1 9.5 13.5
350 0.2 2.0 5.3 9.9 13.8
400 0.2 2.1 5.6 10.3 14.1
450 0.3 2.2 5.9 10.8 14.4
500 0.3 2.4 6.2 11.4 14.7
550 0.3 2.6 6.6 12.3 15.0
600 0.4 2.8 7.4 13.5 15.3
650 0.4 3.4 8.4 14.6 15.7
700 0.4 4.0 9.9 15.5 16.2
750 0.5 5.0 12.0 16.2 16.7
800 1.0 6.6 14.9 16.9 17.2
850 1.8 9.5 16.6 17.5 17.7
900 3.3 15.1 17.6 18.0 18.1
950 7.5 17.8 18.4 18.6 18.6
1000 17.9 19.2 19.3 19.2 19.1
1050 00.0 00.0 00.0 00.0 00.0
1100 00.0 00.0 00.0 00.0 00.0
1150 00.0 00.0 00.0 00.0 00.0
1200 00.0 00.0 00.0 00.0 00.0
1250 00.0 00.0 00.0 00.0 00.0
1300 00.0 00.0 00.0 00.0 00.0
0 COKING TIME 21.13 H
HEAT REQUIREMENTS 1.645 MJ/KG (DAF INITIAL COAL BASIS)
*** END OF PROGRAM ***

The warning is a tab introduced by my windows editor, into the CMS file

[Eric Jackson]

On 10/27/2020 9:40 AM, Eric Jackson wrote:
> The thesis document contains the input for an example run of ANTHLOG at
> page 274, with the output on the following pages.
>
> I took a stab at running the program; there are a lot of OCR errors and
> a few small PL/I-F incompatibilities with (in my case) PL/I for Windows.
>  I got it as far as reading the sample input data:
>
> S25
> 89.4, 4.9, 3.7, 1.2, 0.8
> 10 5 750 20
> 0.450 0.050 2.3 1200 2800
> 1
> 0
> 1050
>
> But it fails with INVALIDOP trying to divide by zero on this statement:
>
> ESHR(I)=MAX(0,1-(1-E)/(1-EO));
>
> At which point I ran out of energy.  I'm sure there are more OCR errors
> I didn't uncover causing this problem.  OP (or other interested parties)
> could msg me for my updated code if interested.

There were just a couple of more OCR errors to resolve before it ran
with the same results as the PDF. You can see the results here:

https://drive.google.com/drive/folders/1HWh8OfxHDgbwaN0rIaeo3kmr3mj96JWW

[Robin Vowels]

On Thursday, October 29, 2020 at 3:19:41 AM UTC+11, c......@gmail.com wrote:
> Hi Everyone,
>
> I was working on this program yesterday, and I've got a clean compilation, and the same numeric results as the thesis.
> I used PL/I (F) under Music/SP system, what's saying working in the same envirnoment as the original program, written for IBM370 CMS.
> There were a couple of typos, from scanning, and a a format error in the original program ( trying to read A(80) into a string (20).

.
That isn't a format error. It's perfectly OK in PL/I(F).
The string is truncated on the right; only the frst 20 characters are stored.

.
> I think modern versions of PL/I may have different behaviour.

.
Later versions of PL/I introduced the STRINGSIZE condition
that detected this and could issue an error message (by raising the
STRINGRANGE condition).

.
> So the best thing to do is to rewrite it in C++,

.
Why? If it works, don't fix it.
.

> using the working program as a base.
> Of course I sent the corrected program to mr. Kumaresh
>
> I also had the zerodivide condition, and after tracking the guilty sentencem i was a thypo,
> sompething like t0 instead of to, I checked the cross referencte and the variable
> was used once. The same happened in other sentence. That's the price for
>undeclared variables in PLI, worst, where variables with the name of a pli keyword....

.
These days, undeclared variables can be flagged as a compilation error.
.
In PL/I there are no reserved words, and any keyword may be
used as a variable.
One doesn't go round deliberately using every keyword as a variable name,
but if a programmer uses a keyword inadvertently as a variable,
it doesn't cause an error.
The advantage of not having reserved words, is that if the language is extended,
new keywords do not invalidate ex

[carlos feldman]

Hi Robin!,

In the compiler version I used I've got a conversion error during runtime, that's why I changed the format. Actually there are some differences in PL/I Subset D, (f) and optimizing, reflecting the development of the software and computer capacity along years.
PLI(f) was able to run, in computers so tiny, we would consider them a joke.

I agree PL/I is very permisive in the use of identifiers, and not declaring them, but this is also a nice way, to get hard to find bugs ( for instance the overflows, were caused by endings in 0 and O. or L and I or 1.

As for myself I would have declared all the variables, commenting out them, a way I use since my first PLI in the 1970's. This, along the options, nest, xref and nest and (check:) are wonderful debugging tools, from a time where you had to debug based in assembly code, and memory dumps.

I would have modularizated the program, with internal modules, and also would have simplified all the formats.
Seems like the then candidate to doctorate, was influenced by FORTRAN IV style, very much used in universities, during 1960's and 70's

And why translate to C++ ? Because mr Kumaresh is doctorate candidate, doing original work, using as a tool flow model systems based in C++. Having this programs up and running, can help him to veryfy his results. This original thesis from the 1970's was test using PL/I under CMS. Now half a century later, there are other tools.

Regard,
Carlos

[Robin Vowels]

On Friday, October 30, 2020 at 2:41:12 AM UTC+11, c......@gmail.com wrote:
> El miércoles, 28 de octubre de 2020 a la(s) 22:20:21 UTC-3, Robin Vowels escribió:
> > On Thursday, October 29, 2020 at 3:19:41 AM UTC+11, c......@gmail.com wrote:
> > > Hi Everyone,
>

> Hi Robin!,
>
> In the compiler version I used I've got a conversion error during runtime, that's why I changed the format. Actually there are some differences in PL/I Subset D, (f) and optimizing, reflecting the development of the software and computer capacity along years.
> PLI(f) was able to run, in computers so tiny, we would consider them a joke.
>
> I agree PL/I is very permisive in the use of identifiers, and not declaring them, but this is also a nice way, to get hard to find bugs ( for instance the overflows, were caused by endings in 0 and O. or L and I or 1.
>
> As for myself I would have declared all the variables, commenting out them, a way I use since my first PLI in the 1970's. This, along the options, nest, xref and nest and (check:) are wonderful debugging tools, from a time where you had to debug based in assembly code, and memory dumps.
>
> I would have modularizated the program, with internal modules, and also would have simplified all the formats.
> Seems like the then candidate to doctorate, was influenced by FORTRAN IV style, very much used in universities, during 1960's and 70's
>
> And why translate to C++ ? Because mr Kumaresh is doctorate candidate, doing original work, using as a tool flow model systems based in C++. Having this programs up and running, can help him to veryfy his results. This original thesis from the 1970's was test using PL/I under CMS. Now half a century later, there are other tools.
>
> Regard,
> Carlos

.
Back in 1966, PL/I took the default rule for names
from FORTRAN, along with the facility to avoid
explicit declarations for names.
That was helpful, because most people had limted typing skills.
For years now, it has been possible to force all variables
to be declared explicitly.
.
As for IBM PL/I subset D, that was intended for small
machines having limited core memory.
.
IBM's PL/I-F compler was intended for modest to large
machines, from 64K core memory and above. It implemented
pretty well all the language.
.
IBM's PL/I Optimising and Checkout compilers introduced a few
extra features relevant to structured programming,
including DO FOREVER; LEAVE and ITERATE.
.
Major enhancements occurred with IBM's PL/I for OS/2 in 1994.
They included many character-handling built-in functions,
and many numeric built-in functions including a random number
generator.
.
There's no need to translate that PL/I program to C++.
You say, "half a century later, there are other tools".
But just because the name of the language has not changed
does not mean that no improvements have been made to the
language. In effect, PL/I has become PL/I++.
It is just as modern and useful as it ever was.

p.s., Thanks for getting the PL/I program to work.

[carlos feldman]

Well, this thesis on combustion models, was done with the more advanced equpment of it's time, IBM/370, CMS, PLI.But at the time computers were really slow, and with very few memory ( a fortran finite differential equations, took me 15 minutes of CPU time ) only batch processing, and the only "plotter" available was 1403 chain printer.

Now you have wonderful tools, even direct connection to your experiment sensor network. This gentleman, has to write a model, in a modern sytem called Open Foam, which accepts C++ modules.

Sorry about, the "modern" language, I'm out of the mainframe world, since I used for the last time an IBM/370 in 1980.
I would have loved to use PL/I in my daily work with realtime systems, but there's no PL/I available for microcontrollers. Last version was INTEL's and Gary Tildall PL/M, almost 40! years ago.

I'm not very impressed with object oriented programming, Most of their concepts, were implemented in PL/I(f) , we had multiple entries for procedures. Internal procedures, are pretty much like classes, we had static and dynamic data storage, even structures and arrays could be dynamically allocated.

That was a real advance from a time when computers, where card and tape feed, to crunch numbers, or manage HUGE, finantial data.

At the time of PL/I developement, IBM was very jealous of their OS, so you need to be a super user, with OS privileges, to access, I/O Channels, or memmory, so you have to write assembly or use the forbidden tool PL/C if you want to write hardware drivers. IBM at the time stated: USERS ONLY RUN BATCH ( even CMS is a sort of specialized batch machine ).
Today we can program FOR FREE, in a 32 bit microcomputer, using a realtime preemptive multitasking OS, device drivers, user interfases , Fast Fourier Transform, Networking, Input and output, several datacommunication protocols, etc.
Of course I prefer UNIX or Linux, over Windows. But in my area, Microsoft just made tabula rasa, and there's no OS/2 systems ( last one I used was 1994 ) and very few Unixes ( Some Qnxs and may be some linuxes, for non critical applications ).

best regards
Carlos

[Cornell Sternbergh]

>
> I'm not very impressed with object oriented programming, Most of their concepts, were implemented in PL/I(f) , we had multiple entries for procedures. Internal procedures, are pretty much like classes, we had static and dynamic data storage, even structures and arrays could be dynamically allocated.
>

...
>
> best regards
> Carlos

Carlos, you forgot that PL/I could be compiled to pseudo code, similar to a machine code. One could write an interpreter on any machine to read the pseudo code and execute the local machine's machine code. Just as is done with the JVM (Java Virtual Machine). Which is to say that PL/I was write once, run anywhere. It was way ahead of Java. Unfortunately, IBM considered themselves a hardware company and didn't push their software.

Cornel

[Eric Jackson]

On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

That's not what pseudo code is at all. You should look it up the
definition of pseudo code.

And the only major PL/I compiler that had an interpreted target machine
was The PL/I Checkout Compiler, and it didn't target anything but the
then-current IBM 360 OS. PL/I was never write once, run anywhere.

And it was PL/S, not PL/C. PL/C was a student debugging compiler.

Anyone who thinks PL/I was more advanced than Java doesn't know anything
about PL/I or Java.

[Cornell Sternbergh]

On Sunday, November 1, 2020 at 3:51:40 AM UTC-5, Eric Jackson wrote:
> On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:
>
> That's not what pseudo code is at all. You should look it up the
> definition of pseudo code.
>
> And the only major PL/I compiler that had an interpreted target machine
> was The PL/I Checkout Compiler, and it didn't target anything but the
> then-current IBM 360 OS. PL/I was never write once, run anywhere.
>
> And it was PL/S, not PL/C. PL/C was a student debugging compiler.

I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware that anyone did.

[John W Kennedy]

I believe you are thinking of Pseudo-Assembler Code, a printed hex
representation of the object code produced by the compiler, annotated
with an approximation of assembler language that might produce it.
Something of the sort has been standard in IBM compilers for many
decades, though more modern systms generally rely on the ability of
symbolic debuggers to display code as it runs.

[Robin Vowels]

On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:
> On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

.

> That's not what pseudo code is at all. You should look it up the
> definition of pseudo code.
>
> And the only major PL/I compiler that had an interpreted target machine
> was The PL/I Checkout Compiler, and it didn't target anything but the
> then-current IBM 360 OS. PL/I was never write once, run anywhere.

.
PL/I has pretty well been "write once, run anywhere".
Additions to the language have not affected the running of existing programs.

.
> And it was PL/S, not PL/C. PL/C was a student debugging compiler.

.
PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
it was also intended for general use, because it was so much faster at compilation
than PL/I-F. The weakness of the IBM offering was the link editor that added
about 45 seconds to the compile-link-go sequence.
.
Compilation and execution of a PL/I program via PL/C could be over in less time
than the compile-link-go of the IBM sofware.
.
Execution time of a PL/C program was slower than that of PL/I-F,
but that didn't matter for short running programs.
.
One special advantage of PL/C was its ability to take a program to
execution, because it was a correcting compiler -- far more than
PL/I-F was.
.
PL/C was to PL/I like WATFOR was to FORTRAN -- a fast compiler
that could get the jobs through in a short time.

.
> Anyone who thinks PL/I was more advanced than Java doesn't know anything
> about PL/I or Java.

.
PL/I came out a long time before Java.

[John W Kennedy]

On 11/1/20 10:55 PM, Robin Vowels wrote:
> On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:
>> On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:

> ..

>> That's not what pseudo code is at all. You should look it up the
>> definition of pseudo code.
>>
>> And the only major PL/I compiler that had an interpreted target machine
>> was The PL/I Checkout Compiler, and it didn't target anything but the
>> then-current IBM 360 OS. PL/I was never write once, run anywhere.

> ..

> PL/I has pretty well been "write once, run anywhere".

Write once, compile anywhere, as opposed to Java’s compile once, run
anywhere.

> Additions to the language have not affected the running of existing programs.

> ..

>> And it was PL/S, not PL/C. PL/C was a student debugging compiler.

> ..

> PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
> it was also intended for general use, because it was so much faster at compilation
> than PL/I-F. The weakness of the IBM offering was the link editor that added
> about 45 seconds to the compile-link-go sequence.

Which is why the load-and-go program was developed as an alternative.

> ..

> Compilation and execution of a PL/I program via PL/C could be over in less time
> than the compile-link-go of the IBM sofware.

> ..

> Execution time of a PL/C program was slower than that of PL/I-F,
> but that didn't matter for short running programs.

> ..

> One special advantage of PL/C was its ability to take a program to
> execution, because it was a correcting compiler -- far more than
> PL/I-F was.

> ..

> PL/C was to PL/I like WATFOR was to FORTRAN -- a fast compiler
> that could get the jobs through in a short time.

> ..

>> Anyone who thinks PL/I was more advanced than Java doesn't know anything
>> about PL/I or Java.

> ..

> PL/I came out a long time before Java.
>

[Iron Spring Software]

On 11/1/20 4:46 PM, John W Kennedy wrote:
> On 11/1/20 1:52 PM, Cornell Sternbergh wrote:
>> On Sunday, November 1, 2020 at 3:51:40 AM UTC-5, Eric Jackson wrote:
>>> On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:
>>>
>>> That's not what pseudo code is at all. You should look it up the
>>> definition of pseudo code.
>>>
>>> And the only major PL/I compiler that had an interpreted target machine
>>> was The PL/I Checkout Compiler, and it didn't target anything but the
>>> then-current IBM 360 OS. PL/I was never write once, run anywhere.
>>>
>>> And it was PL/S, not PL/C. PL/C was a student debugging compiler.
>>
>> I know what pseudo code means now.  And I know that back in the 70's,
>> one of the optional outputs from a PL/I compiler was called pseudo
>> code.  And I know that is was like a machine code and one could write
>> an interpreter for it, though I'm not aware that anyone did.
>>
> I believe you are thinking of Pseudo-Assembler Code, a printed hex
> representation of the object code produced by the compiler, annotated
> with an approximation of assembler language that might produce it.
> Something of the sort has been standard in IBM compilers for many
> decades, though more modern systms generally rely on the ability of
> symbolic debuggers to display code as it runs.
>

Iron Spring PL/I does this. That was how the compiler was originally
ported from zOS to OS/2 and Linux. In addition to the listing, one of
the options is to generate the assembler file in a format the assembler
accepts. I'm not sure this is actually able to be assembled any more,
since it's been years since I had to use it.

The assembly code listing is quite useful for debugging.

[Cornell Sternbergh]

On Sunday, November 1, 2020 at 6:46:36 PM UTC-5, John W. Kennedy wrote:

> > I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware that anyone did.
> >
> I believe you are thinking of Pseudo-Assembler Code, a printed hex
> representation of the object code produced by the compiler, annotated
> with an approximation of assembler language that might produce it.
> Something of the sort has been standard in IBM compilers for many
> decades, though more modern systms generally rely on the ability of
> symbolic debuggers to display code as it runs.
> --

Nope... the assembler/machine code output (it was kind of like machine code, but with some names and stuff to make it easier to read, not quite assembler like) from PL/I was the same kind of output one could get from CoBOL or ForTran, it was needed for dump-reading, the primary debugging method back then. This pseudo code wasn't 360 assembler or machine code, or machine code for any existing hardware. But it was easily (sort of) read by an interpreter which would then execute the local machine's machine code. But again, I'm not aware anyone ever wrote a virtual machine, i.e. interpreter, for it. IBM figured they were a hardware company and didn't push their software.

[Iron Spring Software]

PLUM for the UNIVAC 1108 was the same. I _think_ I do have the source
for PLUM, if anyone has any use for an 1108 assembler program.

[John W Kennedy]

Pre-360 IBM compilers generally produced assembler source code instead
of machine code, but the 360 compilers went directly to object code, and
it was quickly noticed that 360 compilers were actually faster than 360
assemblers were for equivalent programs (probably because of the huge
system macros needed to write normal 360 programs), which led to the
360’s huge jump in use of compilers (apart from FORTRAN, which had
always been popular). Most of them could print assembler-like listings,
but some just did hex dumps of the code, and none of the 360 compilers
produced source-code assembler that could actually be assembled.

[Eric Jackson]

On 11/2/2020 1:07 PM, Cornell Sternbergh wrote:
> Nope... the assembler/machine code output (it was kind of like machine code, but with some names and stuff to make it easier to read, not quite assembler like) from PL/I was the same kind of output one could get from CoBOL or ForTran, it was needed for dump-reading, the primary debugging method back then. This pseudo code wasn't 360 assembler or machine code, or machine code for any existing hardware. But it was easily (sort of) read by an interpreter which would then execute the local machine's machine code. But again, I'm not aware anyone ever wrote a virtual machine, i.e. interpreter, for it. IBM figured they were a hardware company and didn't push their software.
>

You remain very confused. Pseudo code and the pseudo-assembly listing
are two completely different things. The PL/I-F and PL/I Optimizing
compilers compiled into object code with no intermediate human-readable
output; there was an intermediate encoding, called "triples" in the PLM,
but it wasn't the pseudo-assembly listing produced by the "list" option.
The object code generation phase produced object code directly from
the triples without any intermediate assembly being produced.

The pseudo-assembly listing wasn't machine independent at all; it was a
representation of the generated 360 object code and was only a listing
created for the programmer to aid debugging. There was no interpreter
to run it and it didn't wasn't used for anything by the during
compilation, linking or at run time.

[John W Kennedy]

The listings were not in a format that could be read by any assembler
program, but they represent, opcode-for-opcode, the actual 360 or 370
binary.

[Eric Jackson]

On 11/1/2020 7:55 PM, Robin Vowels wrote:
> PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
> it was also intended for general use, because it was so much faster at compilation
> than PL/I-F. The weakness of the IBM offering was the link editor that added
> about 45 seconds to the compile-link-go sequence.

Most often serious programs were compiled a few times and then run many
times. Student programs are compiled until the student hopes the errors
are gone and never run again.

Nobody used PL/C for serious commercial or scientific work. It never
had extended floating point, the macro facility nor the fixed decimal
data type.

[Robin Vowels]

IBM didn't invent load-and-go, nor PL/C, nor Watfor.
.
Load and go was developed in 1957 by Charles Hamblin -- for GEORGE.
.
Perhaps it was invented even earlier than that.

[Robin Vowels]

On Tuesday, November 3, 2020 at 8:07:55 AM UTC+11, Cornell Sternbergh wrote:
> On Sunday, November 1, 2020 at 6:46:36 PM UTC-5, John W. Kennedy wrote:
>
> > > I know what pseudo code means now. And I know that back in the 70's, one of the optional outputs from a PL/I compiler was called pseudo code. And I know that is was like a machine code and one could write an interpreter for it, though I'm not aware that anyone did.
> > >
> > I believe you are thinking of Pseudo-Assembler Code, a printed hex
> > representation of the object code produced by the compiler, annotated
> > with an approximation of assembler language that might produce it.
> > Something of the sort has been standard in IBM compilers for many
> > decades, though more modern systms generally rely on the ability of
> > symbolic debuggers to display code as it runs.
> > --
> Nope... the assembler/machine code output (it was kind of like machine code, but with some names and stuff to make it easier to read, not quite assembler like) from PL/I was the same kind of output one could get from CoBOL or ForTran, it was needed for dump-reading, the primary debugging method back then.

The assembler code might have been needed for COBOL and FORTRAN,
but it was not needed for PL/I --- PL/I came with its own debugging tools,
including CHECK, STMT compiler option(s), and ON conditions for dealing
with computational conditions such as division by zero, SUBSCRIPTRANGE,
STRINGRANGE, OVERFLOW, etc etc.

[Robin Vowels]

On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote:
> On 11/1/2020 7:55 PM, Robin Vowels wrote:
> > PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
> > it was also intended for general use, because it was so much faster at compilation
> > than PL/I-F. The weakness of the IBM offering was the link editor that added
> > about 45 seconds to the compile-link-go sequence.
.
> Most often serious programs were compiled a few times

.
Probably many times, especially for large projects.
.

> and then run many
> times. Student programs are compiled until the student hopes the errors
> are gone and never run again.
.
> Nobody used PL/C for serious commercial or scientific work.

.
Really!?! Tucker did, and probably many others.

.
> It never had extended floating point,

.
Nor did the machine.
.
> the macro facility
.
Not everyone needs it.
.

> nor the fixed decimal data type.

.
FIXED DECIMAL was available, but compiled to use floating-point instructions.

[carlos feldman]

Hi To everyone !!!

I just ended dodaqy, to debug the four PL/I programs, having the same results as the original thesis.
It was fun to debug using the GET COPY, ( CHECK (VARLIST)): and PRINTDATA.
First program took me a mornig, last one just 1 hour.
Most of the problems were OCR, (for instance T0 and TO, or 14 value versus I4) Specially when variables weren't declared.
Funny thing is the programmed included a nice data map, with all the declarations in his thesis .
I know, in the 1970's we don't wanted to punch cards, so we do strange, untidy things.
Things mus be now clearer for Kumaresh, since migration into C++, for Open Foam, should be straightforward.
Other issue was, speed. Compilation and Linkedition, and Runtime were considerably faster in an emulator on an I5 class machine, that they were in a real CMS under VM370.
Of course all this programs were sent to Kumares, so it only needs to work in his real thesis.

Carlos

Argentina

[Peter Flass]

Eric Jackson <jh...@ca.rr.com> wrote:
> On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:
>
> That's not what pseudo code is at all. You should look it up the
> definition of pseudo code.
>
> And the only major PL/I compiler that had an interpreted target machine
> was The PL/I Checkout Compiler, and it didn't target anything but the
> then-current IBM 360 OS. PL/I was never write once, run anywhere.

Not major, but I think there was a machine whose microcoded instruction set
was intended to be a direct analog of PL/I.

>
> And it was PL/S, not PL/C. PL/C was a student debugging compiler.
>
> Anyone who thinks PL/I was more advanced than Java doesn't know anything
> about PL/I or Java.
>
>> Carlos, you forgot that PL/I could be compiled to pseudo code, similar
>> to a machine code. One could write an interpreter on any machine to
>> read the pseudo code and execute the local machine's machine code. Just
>> as is done with the JVM (Java Virtual Machine). Which is to say that
>> PL/I was write once, run anywhere. It was way ahead of Java.
>> Unfortunately, IBM considered themselves a hardware company and didn't
>> push their software.
>>
>> Cornel
>>
>
>

--
Pete

[Peter Flass]

Congratulations! You’re now an official PL/I programmer!

--
Pete

[Peter Flass]

I’m having fun now working on the preprocessor. I compiler preprocessor
statements to intermediate code, and then interpret that to do the actual
preprocessing.

--
Pete

[wat fiv]

My PL/C memories...

- At the university I attended it was heavily used, from the 101 classes on up as it was free, offered the ability to do structured programming at a time before decent and inexpensive Pascal compilers became available and used a lot less CPU time for compilation and fewer surprises with arithmetic than IBM’s compilers.

- It was said the main deficiently of PL/C was that it didn’t support BASED variables. The IBM checkout compiler did but it was expensive. Pascal did, so for this reason and many others Pascal replaced PL/C at my institution.

- I never looked closely at the code generated by PL/C, but I had it on good authority all the code did was to build parameter lists and call internal library routines, no matter how simple the operation was. So in a way the code resembled pcode.

- PL/C was a one pass compiler. It had a lot of trouble (would crash) with large programs with a lot of forward procedure references, especially if the parameters to the procedures required type conversion, or if a function returned something other than fixed binary or float. Apparently if the formal parameter type or function return type were unknown (forward) it would make a guess and later back patch as necessary when the procedure source was encountered. Usually you had to rearrange your source code to eliminate the forward references. For forward function references you could add a "hint declaration" for example “DCL FUNC(X,Y,Z) INTERNAL RETURNS (CHAR(1))” and this often gave enough info to the compiler to stop the crashes.

[John W Kennedy]

On 11/3/20 7:04 AM, Robin Vowels wrote:
> On Tuesday, November 3, 2020 at 4:07:14 AM UTC+11, John W. Kennedy wrote:
>> On 11/1/20 10:55 PM, Robin Vowels wrote:
>>> On Sunday, November 1, 2020 at 7:51:40 PM UTC+11, Eric Jackson wrote:
>>>> On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:
>>> ..
>>>> That's not what pseudo code is at all. You should look it up the
>>>> definition of pseudo code.
>>>>
>>>> And the only major PL/I compiler that had an interpreted target machine
>>>> was The PL/I Checkout Compiler, and it didn't target anything but the
>>>> then-current IBM 360 OS. PL/I was never write once, run anywhere.
>>> ..
>>> PL/I has pretty well been "write once, run anywhere".
>> Write once, compile anywhere, as opposed to Java’s compile once, run
>> anywhere.
>>> Additions to the language have not affected the running of existing programs.
>>> ..
>>>> And it was PL/S, not PL/C. PL/C was a student debugging compiler.
>>> ..
>>> PL/C was a serious PL/I compiler. Yes, though it was intended for student use,
>>> it was also intended for general use, because it was so much faster at compilation
>>> than PL/I-F. The weakness of the IBM offering was the link editor that added
>>> about 45 seconds to the compile-link-go sequence.

> ..

>> Which is why the load-and-go program was developed as an alternative.

> ..

> IBM didn't invent load-and-go, nor PL/C, nor Watfor.

> ..

> Load and go was developed in 1957 by Charles Hamblin -- for GEORGE.

> ..

> Perhaps it was invented even earlier than that.
>

I said “developed”, not “invented”.

[John W Kennedy]

On 11/3/20 12:49 PM, Peter Flass wrote:
> Eric Jackson <jh...@ca.rr.com> wrote:
>> On 10/31/2020 9:51 AM, Cornell Sternbergh wrote:
>>
>> That's not what pseudo code is at all. You should look it up the
>> definition of pseudo code.
>>
>> And the only major PL/I compiler that had an interpreted target machine
>> was The PL/I Checkout Compiler, and it didn't target anything but the
>> then-current IBM 360 OS. PL/I was never write once, run anywhere.
>
> Not major, but I think there was a machine whose microcoded instruction set
> was intended to be a direct analog of PL/I.

The Allen-Babcock RUSH time=sharing system used a 360/50 with funky
PL/I-oriented ROM.

>>
>> And it was PL/S, not PL/C. PL/C was a student debugging compiler.
>>
>> Anyone who thinks PL/I was more advanced than Java doesn't know anything
>> about PL/I or Java.
>>
>>> Carlos, you forgot that PL/I could be compiled to pseudo code, similar
>>> to a machine code. One could write an interpreter on any machine to
>>> read the pseudo code and execute the local machine's machine code. Just
>>> as is done with the JVM (Java Virtual Machine). Which is to say that
>>> PL/I was write once, run anywhere. It was way ahead of Java.
>>> Unfortunately, IBM considered themselves a hardware company and didn't
>>> push their software.
>>>
>>> Cornel
>>>
>>
>>
>
>
>


--

[Eric Jackson]

On 11/3/2020 9:49 AM, Peter Flass wrote:
> Not major, but I think there was a machine whose microcoded instruction set
> was intended to be a direct analog of PL/I.

Which would be pretty much the opposite of "write once, run everywhere".

[Cornell Sternbergh]

A bit off-topic, but... fond memories... The preprocessor can be lots of fun. It basically used PL/I syntax on strings in the code, and generated strings which would then be consumed as PL/I statements by the compiler. One of the few things I miss about CoBOL is the DATE-COMPILED special register. One could set a variable to that value and then print the variable and show the compile date/time, and hence the version, of the program. I created a PL/I preprocessor function that would return the current date/time as a string, i.e. simulated the DATE-COMPILED special register.

[carlos feldman]

Never used this compiler version, I only used the ones, that generate IBM360/370 Assembly or Load Modules

[carlos feldman]

El martes, 3 de noviembre de 2020 a la(s) 14:49:50 UTC-3, bearlyabus...@gmail.com escribió:

Pete, Thanks, for calling me a newbie !!!
I wrote my first PL/I in 1979, I was some time at IBM, and I wrote my engineering thesis, a microrocessor, assembler, using PL/I. Even had used CMS in a selectric printing terminal !!!!
This Covid-19, gave lots of free time, to relearn this.
Regards.
Carlos

[John W Kennedy]

Not at all. “Write once, run everywhere” demands only that the source
code be compatible. You’re confusing “write once” with “compile once”.
The latter is relatively uncommon—Java, UCSD Pascal, and some gaming
engines like ZIL and Inform. The LLVM engine was conceived in that way,
as I understand it, but whenever I have encountered it in the wild, it
has been used as an intermediate stage in a conventional machine-code
compiler, such as CLANG.

[Eric Jackson]

On 11/4/2020 4:41 PM, John W Kennedy wrote:
> Not at all. “Write once, run everywhere” demands only that the source
> code be compatible.

So it was write once, run anywhere as long "anywhere" is this one
particular machine.

The compiler for the machine in question wasn't source compatible with
anything else. All the PL/I compilers had language differences, even
among the various IBM compilers. PL/I wasn't even compatible with its
original language definition.

You could write portable PL/I if you were careful about staying within
certain limitations, but that wasn't any different from FORTRAN or COBOL.

I loved PL/I, but this is claiming something for PL/I that was never there.

[Robin Vowels]

On Thursday, November 5, 2020 at 12:13:17 PM UTC+11, Eric Jackson wrote:
> On 11/4/2020 4:41 PM, John W Kennedy wrote:
> > Not at all. “Write once, run everywhere” demands only that the source
> > code be compatible.
> So it was write once, run anywhere as long "anywhere" is this one
> particular machine.

.
Don't be ridiculous.

.
> The compiler for the machine in question wasn't source compatible with
> anything else.

.
Not true. The language implemented on various other manufacturers'
machines adhered to the standard.

.
> All the PL/I compilers had language differences, even
> among the various IBM compilers.

.
Rubbish. Over time, IBM enhanced their main PL/I compiler (originally PL/I-F).
With the OPTIMISING and CHECKOUT compilers in c.1970, some structured
programming features were added, including DO FOREVER; LEAVE; and ITERATE;
(for exiting loops before normal termination of the loop). Similar features
were not added to FORTRAN until decades later.
.
The PL/I for OS/2 compiler was introduced in c. 1994,
and it contained a great number of new features.
That compiler became the principal compiler for IBM
machines when it was ported to the mainframe.
In about 1999, new language facilities and built-ins
were added to the language to deal with Y2K.
.
Despite all these changes, old programs were upwards compatible.
.
IBM produced a subset PL/I compiler (D) for the smaller S/360 machines.

.
> PL/I wasn't even compatible with its
> original language definition.

.
Really?

[John W Kennedy]

PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, blocking machine-dependent
mappings (such as character string over binary integer) and the like. Of
course, this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and Unicode have largely
eaten the world. Compare that to the madness in IBM’s eight pre-360
product families alone.

[Robin Vowels]

.
For the record, A. B. Tucker compared several compilers, including PL/C,
performing matrix inversion on a 20 x 20 matrix, in each case. [1]
The matrix is declared as FLOAT DECIMAL (16).

Times were (Table 9-4, page 279):
compile time execution time
Burroughs B6700 PL/I 7.25 secs 6.10 secs
IBM 370/145 PL/I(F) 14.49 secs 6.31 secs
IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs
IBM 370/145 PL/C 1.37 secs 16.07 secs

Link times for the two IBM compilers are not included. For that
you'd need to add some 30 seconds.

PL/C compiled ten times faster than the two IBM compilers.
The total time (compile + execution) for PL/C was half the compile
time for IBM PL/I Optimising compiler, and just over the compile time
for PL/I(F).
When you add in the link time for the IBM compilers, PL/C
is about four times faster for this task.

[1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.

[Peter Flass]

The other interesting stat is that the extra compile time the Optimizing
Compiler used, probably doing optimization, only resulted in a small
improvement in execution time.

--
Pete

[Robin Vowels]

On Saturday, November 7, 2020 at 12:54:35 AM UTC+11, b.......@gmail.com wrote:

.
Agreed. The improvement in run time was only 0.54 seconds in 6 seconds,
or about 10%.
.
Tucker does not appear to have specified the REORDER option
for the Optimising compiler, nor did I notice anywhere whether
a compiler option to optimise was specified.
.
Some years ago, a similar comparison was made between Pascal
and PL/I Optimising compiler. The program was performing operations
on COMPLEX data.
The author made two blunders. The first was that he failed to specify
the REORDER option for the PL/I program, so it could not carry out
a complete optimisation. I ran the program as it was,
and also with the REORDER option. The improvement
was about 10%.
The second blunder related to the COMPLEX arithmetic operations.
Pascal does not have COMPLEX data type. The author translated the
Pascal program to PL/I and ran that. The PL/I version mimicked
the Pascal. It did not use COMPLEX. When I modified the PL/I program
to use COMPLEX data, it ran another 10% faster.
.
The moral about COMPLEX? The more information that the compiler has,
the better can it do the optimisation.

[John W Kennedy]

Without knowing the OPT setting or whether the code is marked REORDER,
that’s essentially meaningless.

[Robin Vowels]

On Saturday, November 7, 2020 at 7:59:07 AM UTC+11, John W. Kennedy wrote:
> On 11/6/20 8:54 AM, Peter Flass wrote:

I said that REORDER wasn't used.
And the info is not meaningless.
The fact is that the optimiser took twice as long as PL/I-F and produced only
a marginal improvement in execution speed.
What can be said is that even if the OPT option was set for low optimisation,
full optimisation would have been intolerably longer.

[Richard L. Hamilton]

In article <9dad9b74-9b49-4f9c...@googlegroups.com>,

Robin Vowels <robin....@gmail.com> writes:
> On Saturday, November 7, 2020 at 7:59:07 AM UTC+11, John W. Kennedy wrote:

>> On 11/6/20 8:54 AM, Peter Flass wrote:=20
>> > Robin Vowels <r........@gmail.com> wrote:=20
>> >> On Tuesday, November 3, 2020 at 12:49:43 PM UTC+11, Eric Jackson wrote=
>:=20
>> >>> On 11/1/2020 7:55 PM, Robin Vowels wrote:=20
>> >>>> PL/C was a serious PL/I compiler. Yes, though it was intended for st=
> udent use,=20
>> >>>> it was also intended for general use, because it was so much faster =
> at compilation=20
>> >>>> than PL/I-F. The weakness of the IBM offering was the link editor th=
> at added=20
>> >>>> about 45 seconds to the compile-link-go sequence.=20
>> >> .=20
>> >>> Most often serious programs were compiled a few times and then run ma=
> ny=20
>> >>> times. Student programs are compiled until the student hopes the erro=
> rs=20
>> >>> are gone and never run again.=20
>> >>>=20
>> >>> Nobody used PL/C for serious commercial or scientific work. It never=
> =20
>> >>> had extended floating point, the macro facility nor the fixed decimal=
> =20
>> >>> data type.=20
>> >> .=20
>> >> For the record, A. B. Tucker compared several compilers, including PL/=
> C,=20
>> >> performing matrix inversion on a 20 x 20 matrix, in each case. [1]=20
>> >> The matrix is declared as FLOAT DECIMAL (16).=20
>> >>=20
>> >> Times were (Table 9-4, page 279):=20
>> >> compile time execution time=20
>> >> Burroughs B6700 PL/I 7.25 secs 6.10 secs=20
>> >> IBM 370/145 PL/I(F) 14.49 secs 6.31 secs=20
>> >> IBM 370/145 PL/I (Optimiser) 25.92 secs 5.77 secs=20
>> >> IBM 370/145 PL/C 1.37 secs 16.07 secs=20
>> >>=20
>> >> Link times for the two IBM compilers are not included. For that=20
>> >> you'd need to add some 30 seconds.=20
>> >>=20
>> >> PL/C compiled ten times faster than the two IBM compilers.=20
>> >> The total time (compile + execution) for PL/C was half the compile=20
>> >> time for IBM PL/I Optimising compiler, and just over the compile time=
> =20
>> >> for PL/I(F).=20
>> >> When you add in the link time for the IBM compilers, PL/C=20
>> >> is about four times faster for this task.=20
>> >>=20
>> >> [1] A. B. Tucker, Programming languages, McGraw-Hill, 1977.=20
>> >=20
>> > The other interesting stat is that the extra compile time the Optimizin=
> g=20
>> > Compiler used, probably doing optimization, only resulted in a small=20
>> > improvement in execution time.=20
>> >
>> Without knowing the OPT setting or whether the code is marked REORDER,=20
>> that=E2=80=99s essentially meaningless.

>
> I said that REORDER wasn't used.
> And the info is not meaningless.

> The fact is that the optimiser took twice as long as PL/I-F and produced on=

> ly
> a marginal improvement in execution speed.

> What can be said is that even if the OPT option was set for low optimisatio=

> n,
> full optimisation would have been intolerably longer.

In situations where source is automatically generated, compiled, and
only used once (doable given the power of the PL/I preprocessor),
unless it runs against a LOT of data, you probably don't want to waste
the time on optimization. But if it does run against a lot of data, or
is compiled once and run a lot more than once, who cares if it takes a
few more minutes to compile? During development, don't turn on the
optimization until you're close enough to done that you want to do
some serious testing, of both correctness and performance.

But all that was back-in-the-day, when the compiler was many passes and
had to be quite small. Doubtless it can have a larger region now.