FUNCTION COMMAND-LINE/ENVIRONMENT-VALUE (was something else)
- From: "Roger While" <simrw@xxxxxxxxxxxx>
- Date: Tue, 3 Apr 2007 18:31:27 +0200
Top-post-
Per subject and original post.
Gives all that is required.
C-L can be unstringed and ev is obviuous.
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:57f2rnF2cp3f4U1@xxxxxxxxxxxxxxxxxxxxx
"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:1175594478.983188.322290@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Apr 3, 7:40 pm, "Pete Dashwood"You might be right. I always said it was arguable :-)
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Obviously, whether or not this is better than the current situation in
COBOL, is a matter of opinion. (My own opinion on it is divided, and
Rick
made some good points that made me think again. So did you, but I could
have
done without the anger and personal disparagement, and at least an
attempt
on your part to view what was being suggested, in terms of a
cross-platform
COBOL environment, rather than a C/Unix one.)
There was no anger. I have before been accused of having a particular
'tone' in my writing, but I can't even control the font or colour of
what you see let alone how you hear the voices when you read the
words.
A tirade on the details of how this violates decades of what people have
been doing is just plain unnecessary.
Mainframe programmers in IBM environments who have no knowledge of argc
or
get_opt() have been using keyword and positional parameter sets for
decades
and it is you who have not known about that. But that isn't the point.
Of course they have but cross-platform does not mean 'do it my way',
it means everyone can do it their own way and it still works.
No-one (least of all me) has suggested that the current COBOL way of
doing
things should be abandoned.
No-one is explicitly or implicity criticizing how you personally do
things.
No-one is saying that getting parameter counts and processing
accordingly is
wrong or bad practise. Of course it isn't. What we are looking for is
something that is more COBOL like, and simpler for COBOL programmers who
HAVEN'T been exposed to argc etc., that's all.
I would suggest that dynamic tables of pointers is not 'more COBOL
like' nor 'simpler for COBOL programmers'.
Certainly whether it is useful to have all the EVs loaded is debatable
and I
take your points on that. Rick didn't like it either and the main reason
I
proposed it was for consistency and to avoid having to request what was
wanted. Certainly that is a deviation from how we usually do things and,
it
might not even be a good idea, but the luxury of a pointless exercise,
such
as this, is that bad suggestions can be explored and no harm is done.
Now, if you're calm and sitting comfortably, let's go through your
points
below... :-)
You do realise that Unix shells will generally expand wildcard
parameters while DOS will not don't you ?
No, I didn't know that. Not sure what effect that would have... I guess
it
depends on what you mean by "expand".
If you specify *.cbl in a command line then unless it is in quotes it
will be expanded to be all the file names that match. If a directory
x has files a.cbl b.cbl a.lst and makefile then a command 'myprog x/
*.cbl' tthe program will get an argc of 3 and argv[1] of x/a.cbl and
argv[2] of x/b.cbl. That is it will never see the '*' unless it is
quoted.
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 ?
For "all these", read "2" :-)
It was 'all those' after adding configuration files, registry, and
other sources that an application may require.
As the facility is a general one and cannot know what keyword values are
valid for a given application, it could not detect that PARAMX is not
PARMX.
Well it should be able to if it is to be useful.
I never pretended that nothing needs checking or manipulating, the point
was
that having the items in two easily accessible sets facilitates that.
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.
If it isn't speciified, it won't be loaded into the command line set.
Well, no it won't be in the command line set, but the EV might be
found and that has a value that is wrong because it had been set into
the EV for a _different_ application that happened to use the same EV
name.
There's nothing "wrong" with it; it is another possibility. It seems to
me
that having the two sets makes things immediately available, easily.
I am not sure that a SEARCH, or more likely a pair of SEARCHes and
associated logic is more 'immediate' than a CALL, or even an ACCEPT.
It is also unimplementable as defined as your working-storage needs to
be dynamic and I don't know of any that are.
No it doesn't. The pointers would be to heap values.
It isn't the pointers that make it dynamic, it is that the tables
themselves must expand to take all of the environment. W-S sets aside
the storage areas at compile time (on every system I have used). Your
tables of pointers have no way of knowing how large this is so you
need to have these tables in BASED storage or LINKAGE SECTION or
somesuch as these need to be a pointer to a table of pointer pairs.
Besides the arrays in
WS could be allocated dynamically by using a GETMAIN or MALLOC ...
(That's a
joke...:-))
Well actually it probably would beed to be done that way.
A command line of * may
produce 1 parameter in DOS but several thousand in Unix.
I agree that could be a problem. Perhaps the person designing the
application might need to place the thousand names into a file and pass
the
file name as a parameter on the command line... or just use the Unix
facilities they have now.
Are you saying that they would need to know ahead of time whether the
user will put one filename in the command line or a wildcard ?
Certainly you have demonstrated that this is not a Unix friendly
solution...
:-)
Cross platform has to be for all platforms.
I still seriously think the COBOL facilities for getting CL and EV parms
could be simpler, but it is academic.
Maybe, but I don't think that you made it simpler at all.
Thanks for the gentler response.
Pete.
.
- References:
- Re: New "base document" available
- From: Richard
- Re: New "base document" available
- From: Pete Dashwood
- Re: New "base document" available
- From: Richard
- Re: New "base document" available
- From: Pete Dashwood
- Re: New "base document" available
- Prev by Date: Re: mfcobols
- Next by Date: Parametr passing and ACU
- Previous by thread: Re: New "base document" available
- Next by thread: Re: New "base document" available
- Index(es):
Relevant Pages
|
