Re: Class Notes for a PL/I Course.

"Joe Monk [email protected] [H390-MVS]" <[email protected]> Sat, 5 Oct 2019 03:39:44 -0500
Newsgroups gmane.comp.emulators.hercules390.mvs
Message-ID <CAPcd4G8aPGu4GHoNO6E46OYtjiHtDxZGBOz3_EYPc2E76e29_Q@mail.gmail.com>
"I can't picture why and how IBM forget to implement
these primitive structured programming loop tokens in
the PL/I (F) compiler. The only way to implement them
is using GOTO, I can't figure out any other way."

The concepts didnt exist :) thats why theyre not implemented. The concept
came about with standardization of PL/I, which led to the
checkout/optimizing compilers.

Joe

On Sat, Oct 5, 2019 at 3:29 AM Giuseppe Vitillaro giuseppe-yuD/ahkh7LvrZ44/[email protected]
[H390-MVS] <[email protected]> wrote:

>
>
> On Sat, 5 Oct 2019, Bernd Oppolzer berndoppolzer-/[email protected] [H390-MVS]
> wrote:
>
> > Am 04.10.2019 um 18:53 schrieb Giuseppe Vitillaro giuseppe-yuD/[email protected]
> > [H390-MVS]:
> >>
> >>
> >> By the way. PL/I(F) doesn't have LEAVE/CYCLE
> >> to control a WHILE loop, isn't it? So a GOTO
> >> is a must for these case?
> >>
> > You're right; I didn't notice this until now.
> >
> > I have some PL/1 books (PL/1 360 compiler, from 1966 and 1968),
> > which must be close to PL/1 (F), and there is no LEAVE statement.
> > This is really strange.
> >
> > I learned PL/1 in 1991, when I had the first assignment at a customer
> > of mine to do PL/1 classes for developers there. I did only ASSEMBLER
> classes
> > until then, but they had a strong need for PL/1. My languages before PL/1
> > included Pascal, Fortran, COBOL, RPG, several ASSEMBLERs, of course,
> > and Microsoft BASIC etc.; some experience with ALGOL.
> >
> > This was OS/PL1 V2.3; this compiler was very successful and was IBM's
> > flagship
> > compiler until the late 1990s. Then came Visual Age PL/1 (which had a
> Windows
> > variant, too) and then today's Enterprise PL/1.
> >
> > I never could imagine a PL/1 compiler WITHOUT a LEAVE statement.
> > LEAVE without arguments leaves the innermost DO group; but if you
> > put a label behind LEAVE, you can LEAVE a surrounding (labeled) DO
> group,
> > too.
> >
> > Today's compilers have ITERATE, too.
>
> Yep, ITERATE, sorry, what 'continue' is for C
> and LEAVE, what 'break' is for C.
>
> I can't picture why and how IBM forget to implement
> these primitive structured programming loop tokens in
> the PL/I (F) compiler. The only way to implement them
> is using GOTO, I can't figure out any other way.
>
> >
> >
> >>
> >> >
> >> > ....
> >> >
> >> > DO WHILE (^ SW_EOF);
> >> > ?? READ FILE(INPF) INTO (BUF);
> >> > ?? ...
> >> >
> >> > END;
> >> >
> >> > /* processing continues here at EOF */
> >> >
> >>
> >> The problem I'm facing now, is to retrieve
> >> from PL/I (F) the LRECL/BLKSIZE of an IEBCOPY
> >> dataset at "runtime".
> >>
> >> Infact restoring an IEBCOPY dataset from
> >> a packed F[B](80) dataset requires to restore
> >> also the original LRECL/BLKSIZE, otherwise
> >> IEBCOPY would miserably fail at load time,
> >> beside the F[B](80) dataset being basically
> >> correct.
> >>
> >> For what I've seen there are not builtin
> >> functions for that, even in modern PL/I
> >> implementation.
> >>
> >
> > there are some functions, for example you can retrieve the jobname etc,
> > IIRC. What you can get is the name of the current PL/1 procedure, which
> > is very handy ... PROCNAME () in Enterprise PL/1. I use this for a macro
> > which does trace output (for example).
> >
> > But, yes, you are right, there are no functions to retrieve the
> attributes
> > of files.
> >
> >
> >>
> >> But I've the C code to access DDNAMES
> >> for an open dataset, using MVS control blocks.
> >>
> >> I guess the same logic, starting from PSA,
> >> at absolute address ZERO, and following down
> >> the chain of control blocks to JFCB can be
> >> also implemented in PL/I (F), as I've seen
> >> it implemented in modern PL/I implementations,
> >> under Z/OS.
> >>
> >
> > Yes, this can be done, and I have code somewhere to find the allocated
> > DDNames
> > in the TIOT, for example. Written in PL/1.
> >
> > But: there are some troubles with the JFCBs and the file attributes on
> > modern systems. To access the DSN attributes, you need a macro called
> > SWAREQ. This cannot be done using pure PL/1 (or C) logic. Even the
> > TIOT is replaced by something called XTIOT on modern systems.
> > So that will be sort of a nightmare.
>
> Yep, I've seen using SWAREQ for Z/OS, but it shouldn't be
> required under MVS3.8j, I hope?
>
> >
> > That's why I often use the functions of the C runtime from PL/1 programs,
> > when I need to do special things. Believe it or not: I have a C function
> > callable from PL/1, which allows me to do a C fopen, C fread, C fwrite
> > and C fclose from PL/1 programs. This way I can use all the nice features
> > that the C runtime provides, for example: specify DD-Names or DS-Names
> > at runtime, doing all sorts of dynamic allocations, that is, let them do
> by
> > the C runtime, specify LRECL, BLKSIZE and RECFM dynamically in the fopen
> > string
> > etc. etc.
> >
> > I am talking of IBMs C compiler, of course ...
>
> I would prefer to see a "pure" PL/I (F) implementation, if possible.
>
> >
> >
> >>
> >> Does it happen you have a PL/I implementation
> >> already available, Bernd?
> >>
> >
> > the code to find the TIOT etc. must be somewhere, but at the moment
> > I cannot find it ... maybe next week at my working site.
>
> Take your time, it is just for my fun, no hurry at all.
>
> In the meanwhile I'll try to write some code about it,
> just as a useful exercise.
>
> Thanks, Peppe.
> 
>