Re: New "base document" available

"Richard" <riplin@xxxxxxxxxxxx> wrote in message
On Apr 2, 10:29 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Compare, for MS-DOS, the pairs:
dir /p *.
dir *. /p
copy a.txt b.txt
copy /b a.txt b.txt

The arguments to the "dir" command are not position
sensitive. The arguments to the "copy" command are
relative position sensitive for the input and output files;
but are not absolute position sensitive.

These are implicit/shorthand keyword parameters. The / indicates a
"keyword" is about to follow. If it is boolean (as in the examples you
posted (and they are good examples)) nothing further is required,
the keyword is followed by an = or a colon and a value... (explicit

Note that the '/' is a CP/M convention and conflicits with the prior
use of this in Unix as a path separator. Because MS-DOS adopted the CP/
M '/' it had to use '\' as its path separator when it adopted Unix
hierarchical directories.

Unix uses '-' as a parameter leadin. The convetion is that it may have
short code parameters or long name parameters:

xxx -f name
or xxx --filename=name

and shortnames may be concatenated so that these are the same:

ls -a -l
ls -al

You may be expressing a convention that you have seen, and you may
have seen no other, but command lines have been used for decades in
ways that seem to have never occured to you.

And you are doing exactly that also.

This discussion is NOT about Unix command lines; it is about application
programs written in COBOL and activated from a command line interface.

I never claimed expertise with Unix command lines; I do know something about
running COBOL applications in both mainframe and PC environments.

You could think of /p as implying "/page=yes".

The file description parameter is easily identifiable as such and so does
not need to be position sensitive, as you observed. This is equivalent to

XCOPY /A /D:04-03-2007 /EXCLUDE:".obj" /E c:\MyStuff\*.*

Note that /D and /EXCLUDE are non-Boolean and therefore reqire a keyword
parameter format.

The above expands as:

Copy all files with the archive bit set (/A...implicit ATTRIB=A) that
in the directory c:\MyStuff and any of its subdirectories, that were
on or after the 3rd April 2007 (/D...explicitly stated), to the directory
d:\MyOldStuff, excluding (/EXCLUDE...explicitly stated) any files with
extension of ".obj".

This is all very well for OS commands, which need to be brief and
consistent, and can be documented in a manual, but for applications the
is a little different. Especially in the mainframe environment,
parameters are normally positional so that no keyword needs to be

They are only relatively positional, not absolutely. In your example
the first two parameters could be moved to the end of the command, or
even spread through it.

That's because they were OS commands and used only to make the point that
even these are really implicit name/value pairs.

The APPLICATION example of positional parameters given below is NOT
relational; it is absolute.

Missing parameters must be identified by a separator.

However in some cases the positioning of short parameters may be
significant. For eample with compiling a list of source files an 'add
debug' parameter may be repeatedly used to turn on or off this feature
for each file.

hypothical -o outputname -g off a.src b.src -g on c.src -g off d.src

While this is interesting, it has no bearing on what I am suggesting here.
My comments apply to application command lines intended for COBOL programs.

The use of separators indicates the position and only the runtime
value needs to be specified.

MyProg 123,Y,,,xyz

Even so, some sites prefer the use of Keyword parameters which obviously
don't need to be positional so there is no misunderstanding...

MyProg OUTFILE=Something.member INFILE=Something.else.member

(The order is immaterial, and separators are not required.)

My point is that one can not necessarily assume that
a user will place a particular type of argument at a fixed
position and, in my experience with a number of utilities,
there is little dependence on absolute positioning of

I see your case and what you based it on, but there is a difference
OS parameters and system utilities which can be considered an extension
the OS. Our COBOL requirement is purely for applicatiions.(It will be
issued from COBOL application programs...)

If you are arguing that the tables need ot be mainupaleted after they are
loaded, I would not disagree. However, my point is that they can be
manipulated with the COBOL SEARCH verb and that was one of the design
in the proposal. I would rather see a SEARCH than a bunch of ACCEPTS and

You will actually see a _bunch_ of SEARCHes.

Not at all. You should never need more than two of them (one for each of the
pointer sets). Depends how smart your SEARCH is...

Coming back to the original posted example...


1. Environment Variables... EV1=X, EV2=Y, PARMX=Z

2. Command Line... myProg A, , C, PARMX=D, E

(The command line must cater for positional and keyword parameters and a
mixture of both, see below.)


01 Command-line-parms.
12 clparms occurs max-clparms-for-program
indexed by cl-x1.
15 clp-name usage pointer.
15 clp-value usage pointer.

01 Environment-Variables.
12 EVparms occurs max-EVparms-for-context
indexed by EV-x1.
15 EV-name usage pointer.
15 EV-value usage pointer.

*> Load the pointer sets...

What happens next depends on the requirements of the programmer... At this
point, given the parameters in the example above, the two sets contain the

clp-name (1) points to a string containing "P1"
clp-value (1) points to a string containing "A"
clp-name (2) points to a string containing "P2"
clp-value (2) points to a string containing "0x00" (null)
clp-name (3) points to a string containing "P3"
clp-value (3) points to a string containing "C"
clp-name (4) points to a string containing "PARMX"
clp-value (4) points to a string containing "D"
clp-name (5) points to a string containing "P5"
clp-value (5) points to a string containing "E"

EV-name (1) points to a string containing "EV1"

EV-value (1) points to a string containing "X"
EV-name (2 points to a string containing "EV1"

EV-value (2) points to a string containing "Y"
EV-name (3) points to a string containing "PARMX"

EV-value (3) points to a string containing "Z"

... all other entries are null pointers.

It is pretty trivial to check both tables and find that the original EV
value of PARMX ("Z") has been overridden on the command line to now be

It is also "pretty trivial" to do a smart search and get what you're
interested in.

Say the program is interested in the values of EV1 and EV3, and the command
line values of the second and fourth parameters. We also know that the
fourth value in the command line parameters is the value of PARMX and it may
be specified in Keyword format or positionally, with just the value. A
command line setting is to override an EV setting...


01 Program-parms.
12 EV1-value pic x(01).
12 EV3-value pic x(4).
12 PARMX-value pic x(3).
12 CLP2-value pic x(12).


(Note pointer sets have been loaded by code above...with a single FUNTION
*> get what we need...
AT END continue
WHEN EV-name (EV-X1) = "EV1"
move EV-value (EV-X1) to EV1-value
WHEN EV-name (EV-X1) = "EV3"
move EV-value (EV-X1) to EV3-value
WHEN EV-name (EV-X1) = "PARMX"
move EV-value (EV-X1) to PARMX-value
move CL-value (1) to CLP1-value
move CL-value (4) to PARMX-value
*> finished getting parms...

The above is just one way... I have omitted some code that could be required
in the BASED-STORAGE section on some environments and I haven't used pointer
qualification where it might, in fact, be necessary...

It should also check for null pointers before moving values and, in this
specific instance, there is no need to get the PARMX EV value because it is
being overridden form the command line.

It is intended to demonstrate a concept; having the two sets available as
name/value pairs simplifies everything. However, it is not possible to get
by with doing no work whatsoever... :-)

In any case I generally use a table driven approach. I have a table
of parameter names that I am interested in and a simple loop through
this will recover all the values needed by the program whether this be
from a _single_ accept statement or a call (or a search).

Chacun a son gout (Alistair, please note :-))

You are just making up strawman arguments.

I have no idea what prompted that...:-)

First off, it is not a rhetorical device I use, secondly I have done nothing
to push anyone else's argument or re-interpret their argument to suit
myself, thirdly, I'm not actually ARGUING anything. I'm suggesting an

I guess I've said everything I want to about this :-) and as it is not
anywhere anyway, I might as well get back to work :-)