Re: New "base document" available
- From: "Richard" <riplin@xxxxxxxxxxxx>
- Date: 2 Apr 2007 17:27:51 -0700
On Apr 1, 4:53 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Recall that intrinsic functions
return a temporary value to the point of activation,
whereas these two functions would return object
references that must be saved for further processing.
Yes, that's a fair comment. But, in my view at least, it is outweighed by
the advantage of having a simple means to get run time parameters.
What about....
FUNCTION GET-RUNTIME-PARAMETERS (<pointer to an array of pointers for
command-line>, <pointer to an array of pointers for EVs>)
It seems that you are tring to get something halfway between a
statement that is part of the language and a called program that is
not. By mis-using 'function' you have it built into Cobol while being
called.
Why not have
ACCEPT environment-table FROM parsed-environment
ACCEPT parameter-table FROM parsed-command-line
1. Parameters must be separated by commas and any number of spaces. Omitted
parameters are indicated by comma with no text.
That is not normally how command lines are constructed. You want a
'standard' that breaks other standards.
2. Keyword and positional parameters can be mixed in the same command line.
3. The function loads pointers for both keywords and values, even if no
keywords are present and all command line parameters are positional.
You do realise that Unix shells will generally expand wildcard
parameters while DOS will not don't you ?
form example: myrog *.cbl
will produce completely different results to myprog depending on where
it is executed.
4. Parameters are scanned left to right and if no keyword is found, a
default positional keyword is entered into the keyword name by the function.
This will be P1, P2, ...Pn. If a keyword is found, it is entered into the
corresponding keyword name for the ordinal position in the command line
where it is encountered. Keywords must be followed by = and there can be
spaces between the = sign and the keyword or the value. If the keyword name
has more than one word, it must be in quotes and likewise for the value.
What happens with myprog A,P1=B
Also your use of commas and quotes will break some systems.
For example ls a,"b c" is quite different to ls a, "b c"
For Environment Variable parameters:
1. The function loads both EV name and EV value for each EV in the context.
Example...
CONTEXT:
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.)
WORKING-STORAGE SECTION.
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.
PROCEDURE DIVISION.
...
*> Load the pointer sets...
FUNCTION GET-RUNTIME-PARAMETERS (Command-line-parms,
Environment-Variables)
...
What happens next depends on the requirements of the programmer...
So you say that the programmer has to sort out the mess that is all
these pointer tables, what's the point of that ? Why not get
something useful done. Command lines have been processed for decades,
you should at least see what thousands of programmers over dozens of
years have come with as solutions rather than setting out to reinvent
based on what seems to be a rather limited viewpoint.
For example getopt() and getopt_long() already specify how command
lines are processed and may simply be called from a Cobol program
(depending on vendor). These have the advantage of indicating what
options are allowed and what names are valid and picking up errors.
What would your code do with:
Command Line... myProg A, , C, PARAMX=D, E
At this[..]
point, given the parameters in the example above, the two sets contain the
following:
clp-name (1) points to a string containing "P1"
clp-value (1) points to a string containing "A"
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 "D".
And what if you had decided that a command-line parameter has a
keyword MAILCHECK=xyz but this hadn't been specified on the command
line, on MS-DOS this would correctly be blank. On Unix this may use
some weird value because this _is_ in my environment.
(this is why nested shells are necessary - in fact why they are called
shells).
Similarly, searches can be done on either table using the names, to locate
parameters the progam may be interested in.
So what is wrong with doing a 'call getparameter using somename
placeforvalue' ?
The "dummy" keyword names for the command line don't HAVE to be the ones I
used (they are intended as an example); maybe a COBOL reserved word with a
position concatenated to it would be better, and guarantee no possible
confusion if an application had a keyword parameter named "P1"...
It will not guarantee that, no. It is still possible for a user to do:
myprog A,PARAM1=B
where PARAM1 is the name you have for the first parameter.
I honestly believe the above would be a useful function (or whatever, if you
REALLY don't like it being a function...)
It _isn't_ a FUNCTION by any definition, you have merely stuck that
keyword on the front and claimed it is a function in order to force it
to being part of the standard without it having to be a statement.
Your 'function' does not act like a function and also has side
effects. The form it has is illegal in current Cobol and simply could
not work where function parameters are passed by value.
In other words it is technically unfeasible and incompetent.
It is also unimplementable as defined as your working-storage needs to
be dynamic and I don't know of any that are. A command line of * may
produce 1 parameter in DOS but several thousand in Unix.
.
- Follow-Ups:
- Re: New "base document" available
- From: Pete Dashwood
- Re: New "base document" available
- Prev by Date: Re: New "base document" available
- Next by Date: Re: Is there a mainframe skills shortage?
- Previous by thread: Re: New "base document" available
- Next by thread: Re: New "base document" available
- Index(es):
Relevant Pages
|
