Changes to PL/I over the years 
Author Message
 Changes to PL/I over the years

I am now working on a PL/I program that was probably originally written for
PL/I (F), but later run on PL/I optimizer.  I am trying to get it to run on
(F) again.

This is my first program using preprocessor procedures, and they seemed to
cause lots of errors.  It seems that (F) requires that they be declared with
the preprocessor ENTRY attribute, but optimizer doesn't require it.

I will probably find other changes along the way, but I was somewhat
surprised to see that one.

-- glen



Mon, 14 Nov 2005 13:49:10 GMT  
 Changes to PL/I over the years

Quote:

> I am now working on a PL/I program that was probably originally written for
> PL/I (F), but later run on PL/I optimizer.  I am trying to get it to run on
> (F) again.

> This is my first program using preprocessor procedures, and they seemed to
> cause lots of errors.  It seems that (F) requires that they be declared with
> the preprocessor ENTRY attribute,

Are you sure?  Try % on the procedure statement, and % on
the end statement.
And don't forget %activate
Quote:
> but optimizer doesn't require it.
> I will probably find other changes along the way, but I was somewhat
> surprised to see that one.

> -- glen



Mon, 14 Nov 2005 16:08:02 GMT  
 Changes to PL/I over the years


Quote:

> > I am now working on a PL/I program that was probably originally written
for
> > PL/I (F), but later run on PL/I optimizer.  I am trying to get it to run
on
> > (F) again.

> > This is my first program using preprocessor procedures, and they seemed
to
> > cause lots of errors.  It seems that (F) requires that they be declared
with
> > the preprocessor ENTRY attribute,

> Are you sure?  Try % on the procedure statement, and % on
> the end statement.
> And don't forget %activate

> > but optimizer doesn't require it.

I tried a little test program, with and without the %DCL, and it seems to be
true.

Yes, it has the %activate there.  The way the manual explains it, it is the
%DCL that starts the processing, though the procedure can occur anywhere
else in the program.

Also, it is necessary to DCL any function procedures if they return other
than the default type, if they are used before they are defined.   There is
a nice warning about that, though.

-- glen



Mon, 14 Nov 2005 22:27:07 GMT  
 Changes to PL/I over the years


Quote:

> > I am now working on a PL/I program that was probably originally written
for
> > PL/I (F), but later run on PL/I optimizer.  I am trying to get it to run
on
> > (F) again.

Also, it uses the DATE() and TIME() built in functions to get the date and
time.

Last I knew, argumentless functions didn't have () after them, unlike in C.

The (F) compiler won't take them with ()'s.

-- glen



Tue, 15 Nov 2005 08:15:52 GMT  
 Changes to PL/I over the years

Quote:




> > > I am now working on a PL/I program that was probably originally written
> for
> > > PL/I (F), but later run on PL/I optimizer.  I am trying to get it to run
> on
> > > (F) again.

> Also, it uses the DATE() and TIME() built in functions to get the date and
> time.

> Last I knew, argumentless functions didn't have () after them, unlike in C.

> The (F) compiler won't take them with ()'s.

That's right.
But even in current IBM compilers, it isn't necessary to use ().

- Show quoted text -

Quote:
> -- glen



Tue, 15 Nov 2005 16:26:53 GMT  
 Changes to PL/I over the years


Quote:

> > Also, it uses the DATE() and TIME() built in functions to get the date
and
> > time.

> > Last I knew, argumentless functions didn't have () after them, unlike in
C.

> > The (F) compiler won't take them with ()'s.

> That's right.
> But even in current IBM compilers, it isn't necessary to use ().

But it does allow them?  To make C programmers happy?  I suppose it makes a
nice reminder that they really are functions, but it seem so un-PL/I to me.

-- glen



Wed, 16 Nov 2005 01:33:19 GMT  
 Changes to PL/I over the years


Quote:




> > > Also, it uses the DATE() and TIME() built in functions to get
the date
> and
> > > time.

> > > Last I knew, argumentless functions didn't have () after them,
unlike in
> C.

> > > The (F) compiler won't take them with ()'s.

> > That's right.
> > But even in current IBM compilers, it isn't necessary to use ().

> But it does allow them?  To make C programmers happy?  I suppose it
makes a
> nice reminder that they really are functions, but it seem so un-PL/I

to me.

  C{rap} wasn't even dreamt of back then - and the computing world was
  better for it, IMNSHO.

  The PL/I designers made heavy use of parentheses to resolve
ambiguous
  language situations.  These come about mainly because keywords are
not
  reserved.  Compare this to a simple offshoot of PL/I, namely XPL,
  (McKeeman, Wortman & Horning).  Whereas PL/I requires paren.s for
  the WHILE, in XPL they are unnecessary.

  The situation with builtin functions is similar.  The requirement
for paren.s
  to identify them as functions and not simple variables may be
avoided by

    DECLARE  ( DATE, TIME, NULL, EMPTY ... ) BUILTIN;

  Now, without consulting the LRM, (and it's been years since the
situation
  arose), can one use the same names in the same scope when buried
  in a structure?  E.g.:

   DECLARE  /* a sin I'd never commit */

     1  TRANSACTION,
        2 ( DATE, TIME ) CHARACTER ( 10 ),
        2 NAME  ...



Wed, 16 Nov 2005 23:56:45 GMT  
 Changes to PL/I over the years


Quote:

>   Now, without consulting the LRM,
>  (and it's been years since the situation arose),
> can one use the same names in the same scope when
>  buried  in a structure?  E.g.:

>    DECLARE  /* a sin I'd never commit */

>      1  TRANSACTION,
>         2 ( DATE, TIME ) CHARACTER ( 10 ),
>         2 NAME  ...

I would guess that if it is fully qualified you could.  If I remember, and
this is where I would check the LRM, you can reference structures with an
unambiguous subset of the name.

So you could say NAME=(blah), (assuming no other NAME in scope), but DATE or
TIME would be ambiguous unqualified.

-- glen



Thu, 17 Nov 2005 09:43:20 GMT  
 Changes to PL/I over the years

Quote:






>>>>Also, it uses the DATE() and TIME() built in functions to get

> the date

>>and

>>>>time.

>>>>Last I knew, argumentless functions didn't have () after them,

> unlike in

>>C.

>>>>The (F) compiler won't take them with ()'s.

>>>That's right.
>>>But even in current IBM compilers, it isn't necessary to use ().

>>But it does allow them?  To make C programmers happy?  I suppose it

> makes a

>>nice reminder that they really are functions, but it seem so un-PL/I

> to me.

>   C{rap} wasn't even dreamt of back then - and the computing world was
>   better for it, IMNSHO.

>   The PL/I designers made heavy use of parentheses to resolve
> ambiguous
>   language situations.  These come about mainly because keywords are
> not
>   reserved.  Compare this to a simple offshoot of PL/I, namely XPL,
>   (McKeeman, Wortman & Horning).  Whereas PL/I requires paren.s for
>   the WHILE, in XPL they are unnecessary.

>   The situation with builtin functions is similar.  The requirement
> for paren.s
>   to identify them as functions and not simple variables may be
> avoided by

>     DECLARE  ( DATE, TIME, NULL, EMPTY ... ) BUILTIN;

>   Now, without consulting the LRM, (and it's been years since the
> situation
>   arose), can one use the same names in the same scope when buried
>   in a structure?  E.g.:

>    DECLARE  /* a sin I'd never commit */

>      1  TRANSACTION,
>         2 ( DATE, TIME ) CHARACTER ( 10 ),
>         2 NAME  ...

Any unqualified reference to DATE or TIME within the scope of both
DECLARE statements is to the corresponding built in function.
Parentheses may be used but are not needed.  To refer to the structure
member explicit qualification must be used.

Within the scope of the sceond DECLARE but outside the scope of the
first, an unqualified reference to DATE or TIME is a reference to the
corresponding structure member and parentheses after the name are in
error since the item is neither an array nor an entry.

Outside the scope of either declare statement as well as any others
declaring the same names, a reference to (say) TIME results in an
implicit declaration of TIME as a DECIMAL FLOAT variable, whereas a
reference to TIME() results in a contextual declaration of TIME as a
built in function.  In either case, the scope of the implicit or
contextual declaration is the outer most block minus any inner scopes in
which the name is explicitly declared.

I am not certain, but there may have been a time when it was impossilbe
to use a parameterless built in function without explicitly declaring
it; but using an empty set of parentheses to cause a contextual
declaration has worked for a long time.



Thu, 17 Nov 2005 14:02:14 GMT  
 Changes to PL/I over the years
Actually, it's clearly explained in the LRM:

"Some built-ins do not require arguments. You must either explicitly declare
these with the BUILTIN attribute or contextually declare them by including a
null argument list in the reference - for example, ONCHAR(). Otherwise, the
name is not recognized as a built-in."

This is also pretty logical, given that PL/I allows implicit declarations.


Quote:




> > > Also, it uses the DATE() and TIME() built in functions to get the date
> and
> > > time.

> > > Last I knew, argumentless functions didn't have () after them, unlike
in
> C.

> > > The (F) compiler won't take them with ()'s.

> > That's right.
> > But even in current IBM compilers, it isn't necessary to use ().

> But it does allow them?  To make C programmers happy?  I suppose it makes
a
> nice reminder that they really are functions, but it seem so un-PL/I to
me.

> -- glen



Thu, 17 Nov 2005 16:35:07 GMT  
 Changes to PL/I over the years

Quote:






> >>>>Also, it uses the DATE() and TIME() built in functions to get

> > the date

> >>and

> >>>>time.

> >>>>Last I knew, argumentless functions didn't have () after them,

> > unlike in

> >>C.

> >>>>The (F) compiler won't take them with ()'s.

> >>>That's right.
> >>>But even in current IBM compilers, it isn't necessary to use ().

> >>But it does allow them?  To make C programmers happy?  I suppose it

> > makes a

> >>nice reminder that they really are functions, but it seem so un-PL/I

> > to me.

> >   C{rap} wasn't even dreamt of back then - and the computing world was
> >   better for it, IMNSHO.

> >   The PL/I designers made heavy use of parentheses to resolve
> > ambiguous
> >   language situations.  These come about mainly because keywords are
> > not
> >   reserved.  Compare this to a simple offshoot of PL/I, namely XPL,
> >   (McKeeman, Wortman & Horning).  Whereas PL/I requires paren.s for
> >   the WHILE, in XPL they are unnecessary.

> >   The situation with builtin functions is similar.  The requirement
> > for paren.s
> >   to identify them as functions and not simple variables may be
> > avoided by

> >     DECLARE  ( DATE, TIME, NULL, EMPTY ... ) BUILTIN;

> >   Now, without consulting the LRM, (and it's been years since the
> > situation
> >   arose), can one use the same names in the same scope when buried
> >   in a structure?  E.g.:

> >    DECLARE  /* a sin I'd never commit */

> >      1  TRANSACTION,
> >         2 ( DATE, TIME ) CHARACTER ( 10 ),
> >         2 NAME  ...

> Any unqualified reference to DATE or TIME within the scope of both
> DECLARE statements is to the corresponding built in function.
> Parentheses may be used but are not needed.  To refer to the structure
> member explicit qualification must be used.

> Within the scope of the sceond DECLARE but outside the scope of the
> first, an unqualified reference to DATE or TIME is a reference to the
> corresponding structure member and parentheses after the name are in
> error since the item is neither an array nor an entry.

> Outside the scope of either declare statement as well as any others
> declaring the same names, a reference to (say) TIME results in an
> implicit declaration of TIME as a DECIMAL FLOAT variable, whereas a
> reference to TIME() results in a contextual declaration of TIME as a
> built in function.  In either case, the scope of the implicit or
> contextual declaration is the outer most block minus any inner scopes in
> which the name is explicitly declared.

> I am not certain, but there may have been a time when it was impossilbe
> to use a parameterless built in function without explicitly declaring
> it; but using an empty set of parentheses to cause a contextual
> declaration has worked for a long time.

All of which is, in my opinion, an excellent argument for using
    RULES(NOLAXBIF NOLAXDCL NOLAXQUAL).

----
Jeff



Fri, 18 Nov 2005 00:51:01 GMT  
 Changes to PL/I over the years


Quote:
> All of which is, in my opinion, an excellent argument for using
>     RULES(NOLAXBIF NOLAXDCL NOLAXQUAL).

  Hey, no fair - your manual is newer than mine.


Fri, 18 Nov 2005 01:39:39 GMT  
 Changes to PL/I over the years


Quote:



> >   Now, without consulting the LRM,
> >  (and it's been years since the situation arose),
> > can one use the same names in the same scope when
> >  buried  in a structure?  E.g.:

> >    DECLARE  /* a sin I'd never commit */

> >      1  TRANSACTION,
> >         2 ( DATE, TIME ) CHARACTER ( 10 ),
> >         2 NAME  ...

> I would guess that if it is fully qualified you could.  If I
remember, and
> this is where I would check the LRM, you can reference structures
with an
> unambiguous subset of the name.

> So you could say NAME=(blah), (assuming no other NAME in scope), but
DATE or
> TIME would be ambiguous unqualified.

  Due to urgent business, I neglected to add the particular case I
  had in mind:

  TRANSACTION = '';



Fri, 18 Nov 2005 01:41:50 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. PL/I 34 years old this year.

2. PL/1 and testing mainframes past year 2000

3. Year 2000 PL/I Compiler

4. Wanted - Year 2000 Project Needs PL/1 Programmers

5. Year 2000 Conversion tool for PL/I

6. US/TX PL/1 Programmer/Analysts Year 2000 Conversion Project

7. Database Consultant - 5 years DBA, Oracle 6 - 7.2 - 7.3, PL/SQL, UNIX, backup/recovery - NE

8. ML - much changed in 10 years?

9. Re-programming for the year 2000 date change.

10. Literary Agency Looking for Books on Year 2000 Date Change

11. Re-programming for the year 2000 date change.

12. Changes to PL/I for OS/2 + Windows 95/NT

 

 
Powered by phpBB® Forum Software