Re: Class Notes for a PL/I Course.

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

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.