Re: Class Notes for a PL/I Course.

Am 04.10.2019 um 18:53 schrieb Giuseppe Vitillaro giuseppe-yuD/ahkh7LvrZ44/[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.


>
> >
> > ....
> >
> > 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.

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 ...


>
> 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.

Kind regards

Bernd


>
> Thanks again for your nice words and your time,
>
> Peppe.
>
> .
>
>