If the program is being run under the Enterprise Server / Enterprise Developer JES environment, then accessing the parameter string works exactly the same way as under mainframe batch execution, receiving the parameter contents into a CHAR VARYING field named on the PROC statement.

However, if the program is linked as a .exe, and is being run under native Windows, this may not work as expected.

The section of the documentation that describes how to retrieve parameters when executing under native Windows can be found on our documentation website in the topic titled Open PL/I User's Guide > Using Open PL/I > Running a Program > Accessing Command-Line Arguments in Open PL/I Programs.

In the attached zip file is an example of using this technique to access individual command line arguments, as well as the entire command line argument string, in GETPARM1.pli. Note that a string enclosed in double quotes will be recognised as a single argument, whatever its contents, while single quotes will be interpreted as data. Arguments not enclosed in double quotes will be processed as textual tokens, and any blank characters between tokens will be discarded. Also note that if the parameter string is enclosed in single quotes, the first and last arguments will contain these leading and trailing quotes as their first and last characters, respectively.

An alternative to this technique is to call a Windows function to access the command line contents, which will be returned exactly as it was entered, without any tokenisation having occurred. An example of this technique is attached as GETPARM2.pli.

However, if the program is invoked using CWGUI, the parameter string is processed by CWGUI in a similar way as in GETPARM1, in that the actual argument string is tokenized, then reconstituted, even if it is enclosed in double quotes. The parameter string returned to the program is then similar to that seen using GETPARM1 without enclosing double quotes, but with any multiple consecutive blank characters replaced by a single blank.

A way around this problem is to use PLITEST instead of CWGUI, and the attached example GETPARM3.pli demonstrates how that works. If the program detects CWGUI as the first 5 characters of the parameter string, it calls PLITEST, which dynamically invokes CWGUI, preventing it from modifying the command line arguments at program invocation.