Re: Class Notes for a PL/I Course.
"Bernd Oppolzer berndoppolzer-/[email protected] [H390-MVS]" <[email protected]> Thu, 3 Oct 2019 11:38:43 +0200
| Newsgroups | gmane.comp.emulators.hercules390.mvs |
|---|---|
| Message-ID | <[email protected]> |
Hi Peppe, in traditional PL/1, there is NOTHING outside the outermost procedure, so the only way to have global variables is to define them in the outermost procedure; then they are known to all inner procedures, as long as there are no duplicate names (normal block scope rules). Remember: while in C a module consists of several functions, which are all at the top level (no function nesting allowed), a PL/1 module consists of only one procedure (the top level procedure), and all others are inner procedures to this top procedure. They may be nested over and over again. Same with Pascal (http://bernd-oppolzer.de/job9.htm) the static nesting level may be limited (nine levels in case of my Pascal compiler, which is not much). Of course, you can have external definitions, but that means static linkage of seperately compiled modules. Does not work, if you have some sort of dynamic linking (like with DLLs). This is possible in PL/1, too, using the EXTERNAL attribute. But I guess, this is not what you were referring too. Static definitions, like in C, which are outside every function and are known to every function (global definitions, but know only to the current source) are in fact not possible in PL/1. They must be defined in the outermost function. Then they are known to every function, too (and: they may be static or automatic, regarding storage class - see the STATIC or AUTO attribute; AUTO should be the default, but this can easily be changed on a per module base, using the DEFAULT RANGE(*) ... statement). HTH, feel free to ask more questions Kind regards Bernd Am 03.10.2019 um 11:21 schrieb Giuseppe Vitillaro giuseppe-yuD/ahkh7LvrZ44/[email protected] [H390-MVS]: > > Thank you so much for this long comment, Bernd, really appreciated. > > PL/I is a really interesting language and I'm trying to grasp > its surface, but IBM manuals are not the best way to get > deeper into the topic, at least for my level. > > There are a lot of PL/I source of references around, but, > unfortunately, the version we have on board is really > far from the modern level. > > For a newby like me, this is a little bit confusing and > this course seems a good bridge. > > Thank again, Peppe. > > P.S. A dummy question, I'm still unable to answer myself. > > Damn, how a "global variable", one with a scope > visible from ANY procedure, nested or external, > may be declared in PL/I F? > > On Thu, 3 Oct 2019, Bernd Oppolzer berndoppolzer-/[email protected] [H390-MVS] > wrote: > > > Hi Peppe, > > > > thanks a lot for posting this link, great fun :-) > > > > somewhere in the Paper I found the Checkout compiler mentioned; > > in fact, the Optimizing and the Checkout Compiler were two Compilers > that, > > AFAIK, followed PL/1 (F) and were very successful products. > > > > Some years ago I did some tests with PL/1 (F), simply to find out > how much it > > differs > > from today's standards. > > > > What annoyed me most: it cannot compile definitions like > > > > DCL VARX DEC FIXED (15) BASED (ADDR(VARY)); > > > > that is, a variable BASED on the ADDR of another variable. This > coding is > > omnipresent in > > our sources; I had to replace this by > > > > DCL PVARY PTR; > > PVARY = ADDR (VARY); > > DCL VARX DEC FIXED (15) BASED (PVARY); > > > > BASED in PL/1 (F) supports only pointers, no ADDR expressions. > > > > I also checked the format of descriptors of parameters, when passing > strings > > etc.; > > I tried to call ASSEMBLER and FORTRAN subroutines from PL/1 (F) and to > > evaluate > > the PL/1 descriptors in the called functions. I was successful in > the end, > > although the > > format of the descriptors is different from today's format. > > > > To summarize: I believe most of the topics mentioned in the paper > are present > > in > > PL/1 (F) with minor restrictions; the definition of the language > from, say, > > 1964, > > contained all the features mentioned in this 1975 paper, but, maybe, > PL/1 (F) > > failed to implement some of those features properly. The Optimizer > and the > > Checker did much better. From time to time, I run some examples programs > > on PL/1 (F) to see if a certain feature was already present there. > > > > Some interesting example, not known to many of today's PL/1 people: > > > > it is possible to omit the name of a component of a structure, if it > is not > > used, and use a star instead ... no need to invent FILLER names > (many use F1, > > F2, F3 etc.) > > (What is FILLER in COBOL is simply a star in PL/1). Although I did PL/1 > > teaching for > > many years, I didn't know this for a long time. Then I saw this > coding in a > > very old > > paper, and of course, even today's compilers support this: > > > > Example: > > > > DCL 1 STRUCTA, > > ????? 5 NAME? ? ? ? CHAR (25), > > ????? 5 ADDRESS ? ? CHAR (25), > > ????? 5 *?? ? ? ? ? CHAR (10),??? /* Offsets 50 to 59 not used */ > > ????? 5 POSTBOX ? ? CHAR (10); > > > > This was already possible with PL/1 (F). > > > > Kind regards > > > > Bernd > > > > > > Am 03.10.2019 um 09:55 schrieb Giuseppe Vitillaro > giuseppe-yuD/ahkh7LvrZ44/[email protected] > > [H390-MVS]: > >> > >> Wondering how much this Argonne National Lab > >> PL/I Course, by Kenneth W. Dritz (Nov 1975) > >> > >> https://www.osti.gov/servlets/purl/7150488/ > >> > >> is far from the PL/I F we have on board > >> under MVS3.8j (TK4- or Moseley SYSCPK volume). > >> > >> From a first look, compared with IBM manuals, > >> it doesn't seem really far. > >> > >> Probably is a slightly lower version? For OS/VS1? > >> > >> Peppe. > >> > >> > > > > -- > Giuseppe Vitillaro | E-Mail : giuseppe-yuD/ahkh7LvrZ44/[email protected] > CNR - ISTM | 06123 Perugia Phone:+39.075.585-5518 > ---------------------------------------------------------- > >