== Why is this an issue?

Specifying the parameters to a procedure with a ``++PLIST++`` makes that procedure unusable from free-format code. Instead, prototypes should be used - both when defining a procedure and when calling it. They have the additional benefit of allowing you to use keywords such as ``++Const++`` to better-specify how parameters are passed to a procedure. Further, the use of a prototype instead of a ``++PLIST++`` is cleaner and  more consistent with the code required for subprocedures. 


=== Noncompliant code example

[source,rpg]
----
      * Noncompliant; PLIST specified
     C     *ENTRY        PLIST
     C                   PARM                    ZipCode           5 0
     C                   PARM                    City             20
...
      * Noncompliant; PLIST used in call
     C                   CALL      'OTHERPROG'
     C                   PARM                    ZipCode
     C                   PARM                    City
----


=== Compliant solution

[source,rpg]
----
     D MYPROG          PR                 
     D  ZipCode                       5I   Const
     D  City                         20A   Const
     D MYPROG          PI                 
     D  ZipCode                       5I   Const
     D  City                         20A   Const     
...
     D OTHERPROG       PR                  ExtPgm('OtherProgram')
     D  ZipCode                       5I   Const
     D  City                         20A   Const
      /free
        OTHERPROG(ZipCode:City);
      /end-free
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Convert this "PLIST" to a prototype


'''
== Comments And Links
(visible only on this page)

=== is duplicated by: S1897

=== relates to: S1897

=== on 29 Oct 2014, 13:21:17 Ann Campbell wrote:
Assigned to you for validating

=== on 30 Oct 2014, 17:27:00 Pierre-Yves Nicolas wrote:
I think that this rule should also be applied to the following code where the PLIST is implicit:

----
     C                   CALL      'MYPROG'
     C                   PARM                    ZipCode
     C                   PARM                    City
----

In such case, the compliant code would be:

----
     D MYPROG          PR                  ExtPgm('MyProgram')
     D  ZipCode                       5I   Const
     D  City                         20A   Const
     ...
      /free
        MYPROG(ZipCode:City);
      /end-free
----


=== on 3 Nov 2014, 13:02:49 Ann Campbell wrote:
\[~pierre-yves.nicolas] this looks to me like the calling code, rather than the declaration. Once a sub-proc has been specified with a prototype, do you then have the choice of invoking it with a PLIST?

=== on 3 Nov 2014, 13:28:23 Pierre-Yves Nicolas wrote:
My previous comment was about code calling another program. It seems possible to call a program with a PLIST even if the main procedure of that program is defined with a prototype. I was able to compile and execute something like that.

=== on 4 Nov 2014, 13:44:02 Ann Campbell wrote:
\[~pierre-yves.nicolas], your code samples incorporated (I hope) correctly & minor wording change made in description. See what you think now.


BTW, I 'edited' your comment to be able to copy the code samples, but no actual changes made.

=== on 4 Nov 2014, 14:21:19 Pierre-Yves Nicolas wrote:
In the second case example code which I provided, the compliant solution has to be understood as a whole: the call to MYPROG in free form uses the prototype which is defined in the D specs. However, in the new version of the rule compliant solution, the comment line "* or in free-format:" seems to indicate that the lines just above and the lines just after are alternatives.


Moreover, in that new version of the compliant solution, the prototype (D specs containing "PR") for "MYPROG" is defined twice.

=== on 4 Nov 2014, 15:50:21 Ann Campbell wrote:
\[~pierre-yves.nicolas], clearly I'm confused. Would you correct the code samples, please?

=== on 4 Nov 2014, 16:10:53 Pierre-Yves Nicolas wrote:
I think the examples make more sense now.

endif::env-github,rspecator-view[]
