Cobol - New "base document" available

Author

New "base document" available

William M. Klein

2007-03-29, 9:55 pm

For those of you (if any <G> ) who care about the progress of the COBOL Standard
revision work, a new "base document" (WD 1.7) is available (in zipped format)
online at:

http://www.cobolstandard.info/j4/files/std.zip

--
Bill Klein
wmklein <at> ix.netcom.com

Frank Swarbrick

2007-03-29, 9:55 pm

I care. Thanks!
Is there anything that shows the differences between this version and the
prior version?
Just wondering.

Frank

n 3/29/2007 at 3:55 PM, in message
<lBWOh.137091$dB6.130725@fe08.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> For those of you (if any <G> ) who care about the progress of the COBOL
> Standard
> revision work, a new "base document" (WD 1.7) is available (in zipped
> format)
> online at:
>
> http://www.cobolstandard.info/j4/files/std.zip

Frank Swarbrick

2007-03-29, 9:55 pm

>>> On 3/29/2007 at 3:55 PM, in message
<lBWOh.137091$dB6.130725@fe08.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> For those of you (if any <G> ) who care about the progress of the COBOL
> Standard
> revision work, a new "base document" (WD 1.7) is available (in zipped
> format)
> online at:
>
> http://www.cobolstandard.info/j4/files/std.zip

Hmm, interesting, the standards guys can now time travel into the future.
That documented is dated 2007-05-29.
:-)

Rick Smith

2007-03-29, 9:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:lBWOh.137091$dB6.130725@fe08.news.easynews.com...
> For those of you (if any <G> ) who care about the progress of the COBOL
Standard
> revision work, a new "base document" (WD 1.7) is available (in zipped
format)
> online at:
>
> http://www.cobolstandard.info/j4/files/std.zip

Thank You!

William M. Klein

2007-03-30, 3:55 am

I asked about the May date and was told that it was just a typo. However, it
wasn't felt "important enough" to reissue the document.

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:460BE3D8.6F0F.0085.0@efirstbank.com...
> <lBWOh.137091$dB6.130725@fe08.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:
>
> Hmm, interesting, the standards guys can now time travel into the future.
> That documented is dated 2007-05-29.
> :-)
>

William M. Klein

2007-03-30, 3:55 am

I am not certain how useful this will be, if you want to see what has changed
(and sort-of why) from WD 1.6, check out:

http://www.cobolstandard.info/j4/files/07-0055.doc

and

http://www.cobolstandard.info/j4/files/07-0056.doc

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:460BE31D.6F0F.0085.0@efirstbank.com...[color=darkred]
>I care. Thanks!
> Is there anything that shows the differences between this version and the
> prior version?
> Just wondering.
>
> Frank
>
> n 3/29/2007 at 3:55 PM, in message
> <lBWOh.137091$dB6.130725@fe08.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:

Roger While

2007-03-30, 6:55 pm

Might I also suggest once again to the J4 that some consideration
be done about retrieving command line parameters.
How a about a FUNCTION COMMAND-LINE?

Roger

"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:X_%Oh.138844$dB6.50049@fe08.news.easynews.com...
>I am not certain how useful this will be, if you want to see what has
>changed (and sort-of why) from WD 1.6, check out:
>
> http://www.cobolstandard.info/j4/files/07-0055.doc
>
> and
>
> http://www.cobolstandard.info/j4/files/07-0056.doc
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:460BE31D.6F0F.0085.0@efirstbank.com...
>
>

William M. Klein

2007-03-30, 6:55 pm

You can make such a suggestion, but NOT via this newsgroup <G>.

I would say that most implementations that CARE about this have already
implemented the X/Open solution (via ACCEPT).

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:euj1eo$p6o$03$1@news.t-online.com...
> Might I also suggest once again to the J4 that some consideration
> be done about retrieving command line parameters.
> How a about a FUNCTION COMMAND-LINE?
>
> Roger
>
> "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
> news:X_%Oh.138844$dB6.50049@fe08.news.easynews.com...
>
>

Roger While

2007-03-30, 6:55 pm

Maybe I formulated this incorrectly.
How to go about retrieving command line parameters?
This is something that has been around for a long time.
No one from the standards committee has seen fit to address
this (Yes, I know from previous posts what was said)
Still, a FUNCTION COMMAND-LINE would resolve these

Roger

"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:v_8Ph.181468$Wn6.47181@fe06.news.easynews.com...
> You can make such a suggestion, but NOT via this newsgroup <G>.
>
> I would say that most implementations that CARE about this have already
> implemented the X/Open solution (via ACCEPT).
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:euj1eo$p6o$03$1@news.t-online.com...
>
>

Pete Dashwood

2007-03-30, 9:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:130qevi9f1ebsd8@corp.supernews.com...
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:euj78t$5g8$03$1@news.t-online.com...
>
> Format 1 ACCEPT and DISPLAY statements using
> mneumonic-name. The implementor defines the
> mnuemonic-names and their behavior with the ACCEPT
> and DISPLAY statements. For X/Open, the names are:
>
> ARGUMENT-NUMBER
> ARGUMENT-VALUE
>
> The following works for me
> (using Micro Focus COBOL 3.2.24).
> -----
> identification division.
> program-id. cmd-line.
> data division.
> working-storage section.
> 01 argc pic 99 value 0.
> 01 this-program-name pic x(80).
> 01 filler.
> 02 argv occurs 0 to 99 times
> depending on argc pic x(80).
> 01 x binary pic 9(4) value 0.
> procedure division.
> begin.
> accept argc from argument-number
> display 0 upon argument-number
> accept this-program-name from argument-value
> display this-program-name
> perform varying x from 1 by 1
> until x > argc
> display x upon argument-number
> accept argv (x) from argument-value
> display argv (x)
> end-perform
> stop run.
> -----
>
>
> Not true! The "Candidate features for a future revision" list
> has the following entry:
>
> "22. 02-0160 - Command line & environment variables
> (scan of 93-1045) (Schepman/Woerner): J4 - 43,
> WG4 - investigate; see also 05-0029 - Environment
> variables (Klink)"
>
> The problem may be that there are not enough people
> on J4 to investigate the changes required and to write
> those changes for the standard.

I wonder why people aren't flocking to be on J4... and how many people does
it take to document a simple function that returns a collection?

If the current round of J4 endeavour is simply going to repeat the mistakes
of past J4 endeavours, what's the point? If the excellent people who ARE on
J4 (and I include you and Bill here) are simply going to run into the same
old management and protocol issues, wading through molasses to get a date
changed on a document when a typist could do it in 5 minutes, as if nothing
was learned in the past, then why bother?

Hardly surprising that many of the brightest and best aren't queuing up for
seats on the committee...
>
>
> Because other means are already in use, it seems more
> likely that using a function would confuse; not resolve.
>

Not that I really care, but I STRONGLY disagree with that position. Roger is
right; a simple function would make the whole thing a lot simpler across all
platforms. The "other means" are clumsy, ugly and need a lot more time and
thought. The function could return the arguments and the number of them in a
single collection. (In fact, the collection automatically holds the number
of them as one of its attributes.) How hard is it to devise the syntax for a
simple function that returns a collection? Why should it be such an onerous
thing to do? It could be easily implemented on any platform, mainframe or
Client/Server, so there is unlikely to be resistance from vendors.

It's like when SEARCH was added to the language... there were "other means"
already in place and it took quite some time for people to start using
SEARCH (or STRING, EVALUATE etc.) - some people still never use these "new
fangled" constructs, but they are a minority... Anyone who came to COBOL in
the 1990s takes these things as read, and the Language is richer for them.

The moribundity and lollygagging that characterised previous J4 committees
seems to be alive and well...

OK, I don't want to restart the flame wars that happened last time (or throw
the baby out with the bath water; there are some dedicated people wasting
their time on J4), so that will be my final statement on this, and I'll keep
my opinions to myself in future. (Unless, of course, I'm asked, or the
nonsense gets to a level that is more than flesh and blood can stand...:-))

Pete.

Rick Smith

2007-03-31, 7:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:575qohF2b8qf8U1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:130qevi9f1ebsd8@corp.supernews.com...
>
> I wonder why people aren't flocking to be on J4... and how many people
does
> it take to document a simple function that returns a collection?

The annual cost to be a member of J4 is in the
thousands. Attendance at meetings includes a
per meeting fee plus the cost of accommodations,
food, and transportation for each meeting. It all
adds up! It would seem to require a commitment
by a business or other organiztion with a vested
interest in furthering the COBOL standard to
absorb these costs.

There are, currently, six types of intrinsic functions:
alphanumeric, boolean, national, numeric, integer,
and index. Each returns a temporary value to the
point of activation. I don't know what you intend
by "function"; but it would seem not to be related
to intrinsic functions as in the standard.

> If the current round of J4 endeavour is simply going to repeat the
mistakes
> of past J4 endeavours, what's the point? If the excellent people who ARE
on
> J4 (and I include you and Bill here) are simply going to run into the same
> old management and protocol issues, wading through molasses to get a date
> changed on a document when a typist could do it in 5 minutes, as if
nothing
> was learned in the past, then why bother?

I am not now and have never been a member of J4!
To support the COBOL standard, I have followed
the activities of J4, commented on the standard, and
worked with members of J4 on specific issues of
my choosing.

> Hardly surprising that many of the brightest and best aren't queuing up
for
> seats on the committee...
>
> Not that I really care, but I STRONGLY disagree with that position. Roger
is
> right; a simple function would make the whole thing a lot simpler across
all
> platforms. The "other means" are clumsy, ugly and need a lot more time and
> thought. The function could return the arguments and the number of them in
a
> single collection. (In fact, the collection automatically holds the number
> of them as one of its attributes.) How hard is it to devise the syntax for
a
> simple function that returns a collection? Why should it be such an
onerous
> thing to do? It could be easily implemented on any platform, mainframe or
> Client/Server, so there is unlikely to be resistance from vendors.

I notice that Mr While did not provide any detail
for how FUNCTION COMMAND-LINE would
work.

Forgive me; but "a simple function would make ..."
seems to be a lot like "all you got to do is ...". <g>
Let me skip that for the moment an look at the "end"
rather than the "means".

It seems to me that the application programmer has
no direct interest in the content of the command line;
but is interested in how that content affects the
behavior of the program. Thus, it would seem that
the "end" is a record or object that may be queried
to control the application. This suggests that each
application would have a program or class to process
the command line arguments (and environment variables)
to create that record or object. (Here, I assume that
command line arguments may override environment
variables which override program default values and
establishes a possible relationship between command
line arguments and environment variables.)

Returning now to the "means", there is the possibility
that both command line arguments and environment
variables need to be accessed and it would seem that
accessing these in a similar manner would be beneficial.
Given the request to add "FUNCTION
COMMAND-LINE" to access all command line
arguments, it then becomes reasonable to include
"FUNCTION ENVIRONMENT-VARIABLES" as
a complement to access all environment variables.
(Though it would not be able to alter those variables.)
The latter function would accept a list of environment
variable names and return a collection of the
corresponding values. So, instead of one "simple"
function, there are now two "simple" functions; both
of which are used in a manner not consistent with
other intrinsic functions. 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.
Perhaps,
set command-line-arguments to command-line
and
set environment-values
to environment-variables (environment-names)
for example. Thus, these are not functions at all; but
replace the factory method "new" to instantiate
objects into otherwise non-OO programs. <g>
That being the case, why not just add them to the
COBOL collection classes?

Since Micro Focus is on record as opposing the
COBOL collection classes and has implemented
the X/Open "means", your comment "so there is
unlikely to be resistance from vendors" seems
rather optimistic.

In any case, the X/Open standard is a sufficient
"means" to accomplish the suggested "end".

Pete Dashwood

2007-03-31, 6:55 pm

This s a very good response, Rick. Thank you for taking my comments
seriously and responding in a thoughtful and reasoned way.

I have added some comments below...

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:130s9oip482tf38@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:575qohF2b8qf8U1@mid.individual.net...
> does
>
> The annual cost to be a member of J4 is in the
> thousands. Attendance at meetings includes a
> per meeting fee plus the cost of accommodations,
> food, and transportation for each meeting. It all
> adds up! It would seem to require a commitment
> by a business or other organiztion with a vested
> interest in furthering the COBOL standard to
> absorb these costs.

And I guess they are getting thin on the ground as time goes by...OK, that's
fair comment.
>
> There are, currently, six types of intrinsic functions:
> alphanumeric, boolean, national, numeric, integer,
> and index. Each returns a temporary value to the
> point of activation. I don't know what you intend
> by "function"; but it would seem not to be related
> to intrinsic functions as in the standard.
>
> mistakes
> on
> nothing
>
> I am not now and have never been a member of J4!
> To support the COBOL standard, I have followed
> the activities of J4, commented on the standard, and
> worked with members of J4 on specific issues of
> my choosing.

I stand corrected. I misunderstood your role. I have great respect for your
ability and it would be good for J4 if people like you WERE on it.

>
> for
> is
> all
> a
> a
> onerous
>
> I notice that Mr While did not provide any detail
> for how FUNCTION COMMAND-LINE would
> work.
>
> Forgive me; but "a simple function would make ..."
> seems to be a lot like "all you got to do is ...". <g>

Sometimes, "all you got to do is..." IS actually all you have to do. There
is a subtle difference between over-simplifying ("All ya gotta do is..") and
actually cutting to the real essentials (it worked for William of Ockham and
many people since have derived benefit from following his example...:-)

> Let me skip that for the moment an look at the "end"
> rather than the "means".
>

Good. You have my full attention :-)

> It seems to me that the application programmer has
> no direct interest in the content of the command line;
> but is interested in how that content affects the
> behavior of the program.

Certainly, but that is another problem. What Roger is suggesting is an
approach that allows the programmer to obtain these things he is interested
in, in an easily asssimilable and manipulable form. I favour a collection,
but that may not have been Roger's intention. It is also important to
realise that no-one is seriously suggesting dropping support for the XOpen
approach, as currently implemented by some vendors. The FUNCTION
COMMAND-LINE would be a language standard approach, giving people a choice,
and not affecting the operation of existing programs.

Thus, it would seem that
> the "end" is a record or object that may be queried
> to control the application. This suggests that each
> application would have a program or class to process
> the command line arguments (and environment variables)
> to create that record or object. (Here, I assume that
> command line arguments may override environment
> variables which override program default values and
> establishes a possible relationship between command
> line arguments and environment variables.)

As usual, you have perspicaciously identified some of the less obvious
implications of any approach to command line parameters. :-)

But this is now muddying the water because there is already an established
precedence for the items you mention. That should remain intact and we
should confine ourselves to obtaining parameters from a command line and
having them in a form that easily usable. No other considerations are
important in the context of that. If there is a conflict with exisiting EVs
or default values, that is something that must be handled exactly as it is
now, but AFTER using FUNCTION COMMAND-LINE to determine exactly what the
command line parameters are...
>
> Returning now to the "means", there is the possibility
> that both command line arguments and environment
> variables need to be accessed and it would seem that
> accessing these in a similar manner would be beneficial.
> Given the request to add "FUNCTION
> COMMAND-LINE" to access all command line
> arguments, it then becomes reasonable to include
> "FUNCTION ENVIRONMENT-VARIABLES" as
> a complement to access all environment variables.

That is certainly a possibility, but for J4 one simple idea at a time might
be best...:-)

We could also kill two birds with one stone and have FUNCTION
GET-RUNTIME-PARAMETERS which would return two collections; one for command
line and one for EVs.

> (Though it would not be able to alter those variables.)
> The latter function would accept a list of environment
> variable names and return a collection of the
> corresponding values.

As presenting a list of EVs to it complicates it, why not just let it return
all EVs in the context?

>So, instead of one "simple"
> function, there are now two "simple" functions; both
> of which are used in a manner not consistent with
> other intrinsic functions.

And the second one is not really "simple" at all....:-)

I wouldn't be too worried about the incompatibility with other intrinsic
functions; this one (or two, if you insist) would be a different function
type, that's all.

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.

> Perhaps,
> set command-line-arguments to command-line
> and
> set environment-values
> to environment-variables (environment-names)
> for example. Thus, these are not functions at all; but
> replace the factory method "new" to instantiate
> objects into otherwise non-OO programs. <g>

:-)

> That being the case, why not just add them to the
> COBOL collection classes?
>
> Since Micro Focus is on record as opposing the
> COBOL collection classes and has implemented
> the X/Open "means", your comment "so there is
> unlikely to be resistance from vendors" seems
> rather optimistic.

OK, I was unaware of that, although, now you mention it, I do recall Bill
stating they were against Collections, in his capacity representing them. As
we are not looking for trouble here and don't want to have to "sell" a
solution to resistant vendors...

Your case above is a reasoned and persuasive one.

What about....

FUNCTION GET-RUNTIME-PARAMETERS (<pointer to an array of pointers for
command-line>, <pointer to an array of pointers for EVs> )

Function Type: System interfacing.

Description:

This function returns two sets of pointers to Key/Value pairs representing
the parameters passed on the command line and the Environemt Variables set
in the program's context. It will initialize the pointer arrays each time it
is called so, if you call it twice it will overwrite what was previously
there. This may be important in checking if certain parameters have changed
on certain events.

For command line parameters:

1. Parameters must be separated by commas and any number of spaces. Omitted
parameters are indicated by comma with no text.

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.

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.

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... 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"
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 "D".

Similarly, searches can be done on either table using the names, to locate
parameters the progam may be interested in.

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"...

I realise I just wasted 40 minutes doing this, but it made a welcome relief
from some papers I was reading, and I wanted to reassure myself that the
process of documenting a new feature in COBOL CAN be done in less than 17
years...:-)

I honestly believe the above would be a useful function (or whatever, if you
REALLY don't like it being a function...) and I don't think it would be
difficult to implement (the strings would be on the heap anyway). If I was
still developing COBOL I'd go ahead and write it as a component...:-)

>
> In any case, the X/Open standard is a sufficient
> "means" to accomplish the suggested "end".
>

Well, that is a matter of opinion...:-) I would agree it serves the purpose,
but it is inelegant and inflexible.

Pete.

Rick Smith

2007-03-31, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:577i0vF2btvnlU1@mid.individual.net...
> This s a very good response, Rick. Thank you for taking my comments
> seriously and responding in a thoughtful and reasoned way.
>
> I have added some comments below...
>
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:130s9oip482tf38@corp.supernews.com...
>
> And I guess they are getting thin on the ground as time goes by...OK,
that's
> fair comment.
ARE[color=darkred]
date[color=darkred]
>
> I stand corrected. I misunderstood your role. I have great respect for
your
> ability and it would be good for J4 if people like you WERE on it.
>
Roger[color=darkred]
across[color=darkred]
>
> Sometimes, "all you got to do is..." IS actually all you have to do.
There
> is a subtle difference between over-simplifying ("All ya gotta do is..")
and
> actually cutting to the real essentials (it worked for William of Ockham
and
> many people since have derived benefit from following his example...:-)
>
>
> Good. You have my full attention :-)
>
>
> Certainly, but that is another problem. What Roger is suggesting is an
> approach that allows the programmer to obtain these things he is
interested
> in, in an easily asssimilable and manipulable form. I favour a collection,
> but that may not have been Roger's intention. It is also important to
> realise that no-one is seriously suggesting dropping support for the XOpen
> approach, as currently implemented by some vendors. The FUNCTION
> COMMAND-LINE would be a language standard approach, giving people a
choice,
> and not affecting the operation of existing programs.
>
> Thus, it would seem that
>
> As usual, you have perspicaciously identified some of the less obvious
> implications of any approach to command line parameters. :-)
>
> But this is now muddying the water because there is already an established
> precedence for the items you mention. That should remain intact and we
> should confine ourselves to obtaining parameters from a command line and
> having them in a form that easily usable. No other considerations are
> important in the context of that. If there is a conflict with exisiting
EVs
> or default values, that is something that must be handled exactly as it is
> now, but AFTER using FUNCTION COMMAND-LINE to determine exactly what the
> command line parameters are...

It bears repeating, the current means ("handled
exactly as it is now") for environment variables is
X/Open COBOL DISPLAY and ACCEPT
statements.

>
> That is certainly a possibility, but for J4 one simple idea at a time
might
> be best...:-)
>
> We could also kill two birds with one stone and have FUNCTION
> GET-RUNTIME-PARAMETERS which would return two collections; one for command
> line and one for EVs.

Well, a function can return only one value, but I
suppose that value could be an object reference
to an object holding to two object references,
one for each collection.

>
> As presenting a list of EVs to it complicates it, why not just let it
return
> all EVs in the context?

While an environment pointer (**environ) is defined
for Unix, it may not be defined for all variants. In fact,
the C standard (ISO 9899:1990) no longer accepts
the environment pointer as a parameter to "main".
What you suggest would make environment variables
processor dependent. Accessing each by name is
universal for all conforming, hosted C implementations
(using the function "getenv") and conforming COBOL
(with environment variables) could run on those same
processors, all else being equal.

>
> And the second one is not really "simple" at all....:-)
>
> I wouldn't be too worried about the incompatibility with other intrinsic
> functions; this one (or two, if you insist) would be a different function
> type, that's all.
>
> Recall that intrinsic functions
>
> 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.
>
>
> :-)
>
>
> OK, I was unaware of that, although, now you mention it, I do recall Bill
> stating they were against Collections, in his capacity representing them.
As
> we are not looking for trouble here and don't want to have to "sell" a
> solution to resistant vendors...
>
> Your case above is a reasoned and persuasive one.
>
> What about....
>
> FUNCTION GET-RUNTIME-PARAMETERS (<pointer to an array of pointers for
> command-line>, <pointer to an array of pointers for EVs> )

Ah! I see you are not using "function" as an "intrinsic
function"; but rather more as a called program.
Functions in COBOL have value that is returned to
the point of activation, called programs do not. <g>

> Function Type: System interfacing.
>
> Description:
>
> This function returns two sets of pointers to Key/Value pairs representing
> the parameters passed on the command line and the Environemt Variables set
> in the program's context. It will initialize the pointer arrays each time
it
> is called so, if you call it twice it will overwrite what was previously
> there. This may be important in checking if certain parameters have
changed
> on certain events.
>
> For command line parameters:
>
> 1. Parameters must be separated by commas and any number of spaces.
Omitted
> parameters are indicated by comma with no text.
>
> 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.
>
> 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.
>
> 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... 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"
> 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
"D".
>
> Similarly, searches can be done on either table using the names, to locate
> parameters the progam may be interested in.
>
> 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"...
>
> I realise I just wasted 40 minutes doing this, but it made a welcome
relief
> from some papers I was reading, and I wanted to reassure myself that the
> process of documenting a new feature in COBOL CAN be done in less than 17
> years...:-)
>
> I honestly believe the above would be a useful function (or whatever, if
you
> REALLY don't like it being a function...) and I don't think it would be
> difficult to implement (the strings would be on the heap anyway). If I was
> still developing COBOL I'd go ahead and write it as a component...:-)

How would you access the enviroment variables
for those Unix variants that have no environment
pointer?

>
> Well, that is a matter of opinion...:-) I would agree it serves the
purpose,
> but it is inelegant and inflexible.

Fortunately, it can be used in more cases than
the alternatives being discussed. <g>

Rick Smith

2007-03-31, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:130tcmqj4754a70@corp.supernews.com...
[snip]
> It bears repeating, the current means ("handled
> exactly as it is now") for environment variables is
> X/Open COBOL DISPLAY and ACCEPT
> statements.

For IBM the current means appears to be the
LE callable service: CEEENV.

[snip]
> While an environment pointer (**environ) is defined
> for Unix, it may not be defined for all variants. In fact,
> the C standard (ISO 9899:1990) no longer accepts
> the environment pointer as a parameter to "main".

I referred to the previous C standard; but the comment
also applies to the current C standard (ISO 9899:1999).

William M. Klein

2007-03-31, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:130tfeq9fu5jb14@corp.supernews.com...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:130tcmqj4754a70@corp.supernews.com...
> [snip]
>
> For IBM the current means appears to be the
> LE callable service: CEEENV.
>
<Much snippage>

And CEE3PRM and CEE3PR2 are th3e ways to get things SIMILAR TO "command-line
parameters" when on z/OS (but the "3" means they are NOT portable across IBM
platforms).

--
Bill Klein
wmklein <at> ix.netcom.com

William M. Klein

2007-03-31, 6:55 pm

<all snipped>

Roger or Pete, (or others)
Other than the fact that it is NOT in an ANSI/ISO Standard (which was Roger's
original problem) can anyone who doesn't "like" the X/Open solution for both
environment variables and command-line parameters help me understand what you
don't like about this approach? It may take one or two "tries" to get used to
it, but I haven't ever seen application programmers (in environments that
support them) have problems with them.

This might NOT have been how I would have "designed" things if I was starting
from scratch, but I just don't see this as a seriously flawed approach -
certainly not flawed enough to create a new an incompatible solution (where this
is in common usage across multiple vendors today).

P.S. As Acucorp *is* now represented on J4, you might want to contact them and
see what there opinion is on this - as far as a "standard" solution.

--
Bill Klein
wmklein <at> ix.netcom.com

Pete Dashwood

2007-04-01, 6:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:p7CPh.12823$Ts6.1572@fe12.news.easynews.com...
> <all snipped>
>
> Roger or Pete, (or others)
> Other than the fact that it is NOT in an ANSI/ISO Standard (which was
> Roger's original problem) can anyone who doesn't "like" the X/Open
> solution for both environment variables and command-line parameters help
> me understand what you don't like about this approach?

1. You have to make repeated calls to get command line parameters.

2. You have to make more calls to get EVs, and know what you are looking
for.

3. It isn't Keyword/Value pair friendly which is what the Web uses, and what
most Web programmers have come to know and love.

4. You still have to sort out keyword parameters and values from the command
line, in your own code, after you've accessed them.

The solution I suggested overcomes all of these objections.

> It may take one or two "tries" to get used to it, but I haven't ever seen
> application programmers (in environments that support them) have problems
> with them.
>

Sure, I've used it successfully on mainframe and PC. It isn't that I don't
understand it, I just think it is cumbersome and ugly. It should be possible
to load all of this stuff with a single call and it should be available at
my fingertips after that.

> This might NOT have been how I would have "designed" things if I was
> starting from scratch, but I just don't see this as a seriously flawed
> approach - certainly not flawed enough to create a new an incompatible
> solution (where this is in common usage across multiple vendors today).

It is not incompatible, it is alternative. Just as you can still write a
PERFORM loop to search a table if you want to, rather than use SEARCH.

>
> P.S. As Acucorp *is* now represented on J4, you might want to contact
> them and see what there opinion is on this - as far as a "standard"
> solution.

As I said, I saw it as some light relief from REAL work... I have no
illusuions about how far my (or anyone else's) suggested solutions will get
with J4... :-)

>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>

Pete Dashwood

2007-04-01, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:130tcmqj4754a70@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:577i0vF2btvnlU1@mid.individual.net...
<snip>

> EVs
>
> It bears repeating, the current means ("handled
> exactly as it is now") for environment variables is
> X/Open COBOL DISPLAY and ACCEPT
> statements.
>

Tsk tsk :-) my "as it is now" was referring to the conflict of interest
between EVs and command line parameters, NOT the mechanism for obtaining
them. I suspect you knew that... :-)

> might
>
> Well, a function can return only one value, but I
> suppose that value could be an object reference
> to an object holding to two object references,
> one for each collection.

You are absolutely right (and I did understand this and knew you would
object on these grounds) but the difference between us is that you see it
violating the rules for functions and therefore undesirable, wheras I see it
as providing needed functionality and really don't care whether it is a
function, a module, a nested subprogram included at compile time by the
compiler or a COBOL generated ActiveX/COM component :-), as long as the
compiler takes the job off my hands and gives me everything I want with one
call :-)

If one is going to work in the area of defining a standard then one should
be prepared to extend the existing rules where it makes sense to do so. If a
better idea doesn't present itself, then, a new type of function or
extension to the concept of a function...

And no, I don't consider not doing it, a better idea... :-)

>
> return
>
> While an environment pointer (**environ) is defined
> for Unix, it may not be defined for all variants. In fact,
> the C standard (ISO 9899:1990) no longer accepts
> the environment pointer as a parameter to "main".
> What you suggest would make environment variables
> processor dependent. Accessing each by name is
> universal for all conforming, hosted C implementations
> (using the function "getenv") and conforming COBOL
> (with environment variables) could run on those same
> processors, all else being equal.

Hmmm... I think what you are saying is that it is not possible to access ALL
EVs on aUNIX system? I recall a DOS command (SET with no operands, I
think...) that could do this under DOS on a PC. Has UNIX no equivalent? Is
there no UNIX command to list all EVs on the console? Anyway, I'm sure a
bright UNIX COBOL compiler writer could find a way... :-)

(Run a command like SET and pipe it's output to a temp file
read the temp file and store each keyword/value pair on the heap
return the heap pointers into the EV table of keyword and value pointers
release the EV entries on the heap
go and have a coffee...)

The point is that implementation is only a passing consideration. (Unless
there is no doubt that it really is impossible to implement, and, with all
due respect, I don't think the fact that getenv works a certain way
establishes that...)

>
> As
>
> Ah! I see you are not using "function" as an "intrinsic
> function"; but rather more as a called program.
> Functions in COBOL have value that is returned to
> the point of activation, called programs do not. <g>

Yes, I know that, but I'm not as concerned by it as you are :-) That's just
stamp collecting...as another Kiwi (Lord Ernest Rutherford) once remarked...
(They told him splitting the atom couldn't be done, too...And Edmund Hilary
was told he could break a leg if he kept on with his perverse notions about
climbing mountains... There is something in the culture here that seems to
be triggered when something is perceived as difficult, dangerous, or
impossible... (of course, a number of Kiwis die each year attempting things
that can be considered heroic or foolhardy, depending on your point of
view.... :-)) It is no coincidence that both bunjee jumping and zorbing
were invented here.

(To save looking it up... zorbing involves being ensconced in a sphere of
plastic bubble wrap, then rolled down a mountain...I understand it is a
unique experience, although I haven't tried it yet...:-))

>
> it
> changed
> Omitted
> line.
> function.
> name
> context.
> the
> "D".
> relief
> you
>
> How would you access the enviroment variables
> for those Unix variants that have no environment
> pointer?

If a given platform cannot return EVs then it cannot. Isn't much point in
having them if you can't access them though, is there? :-)
>
> purpose,
>
> Fortunately, it can be used in more cases than
> the alternatives being discussed. <g>
>
No, I don't hink so.

The suggested solution would work on any platform where EVs and command line
parameters are allowed. It is simply down ot implementation.

Pete.

Rick Smith

2007-04-01, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:57a406F2be8hsU1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:130tcmqj4754a70@corp.supernews.com...
> <snip>
[snip]
>
> Hmmm... I think what you are saying is that it is not possible to access
ALL
> EVs on aUNIX system? I recall a DOS command (SET with no operands, I
> think...) that could do this under DOS on a PC. Has UNIX no equivalent? Is
> there no UNIX command to list all EVs on the console? Anyway, I'm sure a
> bright UNIX COBOL compiler writer could find a way... :-)

Neither Unix nor MS-DOS (nor Windows, I believe) is a problem.
The header <stdlib.h> provides "extern char **environ".

This program displays a list of all environment variables and
was done with Visual C++ 5.0 as a Win32 console program.
-----
#include <stdlib.h>
#include <stdio.h>

void main (void) {
int i;
for (i=0; environ[i] != NULL; i++)
printf ("%s\n", environ[i]);
return;
}
-----

C is implemented on platforms other than those
mentioned and, according to my sources, the environment
list is not always implemented as an array of pointers
to strings. It is in these cases that "getenv()" will work;
whereas, the above program will not.

Rick Smith

2007-04-01, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:130vrcb244odo05@corp.supernews.com...
[snip]
> Neither Unix nor MS-DOS (nor Windows, I believe) is a problem.
> The header <stdlib.h> provides "extern char **environ".

To clarify that which is not obvious, the header <stdlib.h>
for standard C does not provide "extern char **environ".

The header <stdlib.h> for POSIX, Unix, MS-DOS, etc,
does provide "extern char **environ".

Both provide the function "getenv()".

William M. Klein

2007-04-01, 9:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:57a0ugF2bdavuU1@mid.individual.net...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:p7CPh.12823$Ts6.1572@fe12.news.easynews.com...
>
> 1. You have to make repeated calls to get command line parameters.
>

That is true if you use theARGUMETNT-VALUE approach, but not if you use the
COMAND-LINE approach - that gets the entire "command-line buffer" in one ACCEPT.

--
Bill Klein
wmklein <at> ix.netcom.com

Pete Dashwood

2007-04-01, 9:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:130vu3feb4bepfe@corp.supernews.com...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:130vrcb244odo05@corp.supernews.com...
> [snip]
>
> To clarify that which is not obvious, the header <stdlib.h>
> for standard C does not provide "extern char **environ".
>
> The header <stdlib.h> for POSIX, Unix, MS-DOS, etc,
> does provide "extern char **environ".
>
> Both provide the function "getenv()".
>
>
>

I understand what you are saying and thanks for the example.

It seems to me you are second guessing what the implementor will do. While
most Unix compiler writers will probably use C, there is no guarantee that
that is so, and neither should we assume that because a C header file
doesn't provide support for pointers to the environment, it is therefore
impossible to implement. All that proves is that it cannot be done DIRECTLY
in C, on that platform. There are many ways to skin a cat and compiler
writers are notoriously imaginative. Although I don't claim expertise in
Unix, I did some quick searching and found the following:

"The PRINTENV command is used to display environment variable definitions.
If it is given with no arguments then all environmental variables wil be
displayed. You can also give the command with a single argument, which is
the name of an environmental variable without a dollar sign. Then the
definition of that variable is displayed. "

As far as I can establish, PRINTENV is available across ALL UNIX platforms

As OS commands can certainly be accessed from C, the approach I posted
previously would seem to be viable.

The compiler could generate code to run this command and redirect the output
to a temp file, which would then be read and the EV Key/Value pairs
obtained. We are only interested in the actual values of the variables (and
their names); we don't HAVE to access the EVs directly.

The bottom line is that if EVs can be accessed in ANY way, then the solution
I suggested can be implemented by a compiler provider.

However, it is not the job of J4 to decide HOW COBOL facilities are
implemented. Reviews of proposals by vendors will establish if something
CANNOT be done, and that just means it can't be done in a certain
environment.

Very often, in the course of my career I have heard IT people say: "You
can't do that, it's not possible." (There was even one famous case in Spain
where IBM said that what we wanted to do was impossible and could not be
done because the 3270 devices could not be refreshed in conversational mode.
They quoted paragraphs in the manual and everyone seemed to think that was
the end of that. Two months later, I demoed a roomful of 3270s, all in
conversational mode, being refreshed and updating their screens when a
certain event occurred. After the secret was revealed to IBM, their lead
programmer said: "Well, of course you can do it, if you do it like THAT..."
He couldn't understand my amusement at his comment :-)) We all have 20/20
vision in hindsight :-)

The point is that we are constrained by what we know and accept. And our
view of solutions is limited by our tech knowledge. So, when IT people say:
"You can't do that, it's not possible." what they are really saying is "I
don't know how to do that". Obviously, there are technical specifics that
are limitations and prevent you achieving your goal. That's the time to
think sideways and find another approach.

1. We need to generate code (or a solution) to provide access to EVs at run
time.
2. There is no direct support in certain implementations of C on certain
platforms, to do this.

Solution: Don't use C directly. Generate a module that interfaces to the
OS, and gets the EVs with an OS command. Not elegant, but a solution. I have
no doubt there are other solutions that people in the business of providing
compilers and with much more experience in C and Unix than I have, can come
up with.

Often, finding a solution will depend on how earnestly you want to do
something :-)

(Note deliberate avoidance of "badly" in previous sentence... :-))

Pete.

Rick Smith

2007-04-01, 9:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:FJYPh.26820$Ts6.13784@fe12.news.easynews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:57a0ugF2bdavuU1@mid.individual.net...
solution[color=darkred]
understand[color=darkred]
>
> That is true if you use theARGUMETNT-VALUE approach, but not if you use
the
> COMAND-LINE approach - that gets the entire "command-line buffer" in one
ACCEPT.

X/Open does not have an approach "that gets the
entire 'command-line buffer' in one ACCEPT".
Micro Focus and maybe others used that approach
for MS-DOS.

Because command line arguments are not normally
position sensitive, the choice is to process them
one-at-a-time from the command line or
one-at-a-time from a table! The latter choice may
be more familiar.

Pete Dashwood

2007-04-02, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:FJYPh.26820$Ts6.13784@fe12.news.easynews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:57a0ugF2bdavuU1@mid.individual.net...
>
> That is true if you use theARGUMETNT-VALUE approach, but not if you use
> the COMAND-LINE approach - that gets the entire "command-line buffer" in
> one ACCEPT.
>
But you still have to "parse" it if it has keyword parameters, and sort out
what the values are. And you still have to make further ACCEPTs to get the
EVs...

My solution does that for you, with ONE invocation, AND it handles mixed
positional and keyword parms on the command line.

My point is that programmers shouldn't have to do all this bullshit. A
single "facility" can do it for them and put everything away in a form that
is easily accessible.

I posted some COBOL here to do the parsing of keyword parameters a few
w

s back...

http://tinyurl.com/26hw83

How much nicer if there was a COBOL construct that just did it for us.

Roger got rubbished for suggesting a "simple function". I agree with him and
that's why I posted. (That... and because my head was spinning from REAL
work... :-)).

Pete.

Pete Dashwood

2007-04-02, 3:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:1310s0kq88331d4@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:FJYPh.26820$Ts6.13784@fe12.news.easynews.com...
> solution
> understand
> the
> ACCEPT.
>
> X/Open does not have an approach "that gets the
> entire 'command-line buffer' in one ACCEPT".
> Micro Focus and maybe others used that approach
> for MS-DOS.
>
> Because command line arguments are not normally
> position sensitive, the choice is to process them
> one-at-a-time from the command line or
> one-at-a-time from a table!

That conflicts with my experience. Command line parameters are ALWAYS
position sensitive (P1, P2, ...), UNLESS they are presented as a
Keyword/Value pair (P3=Value3 P1=Value1 P4=Value4...) the latter are
sometimes loosley referred to as 'free-format" parameters, but the former
are always positional. How else can you know which value represents what?

The latter choice may
> be more familiar.
>
From a table? Yes, if it is on disk. Then this is very similar to using an
..ini file or some other environment mechanism (like the Registry...). I
have never seen a table passed from the Command Line.

Pete.

Rick Smith

2007-04-02, 3:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:57bapsF2cbj24U1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:1310s0kq88331d4@corp.supernews.com...
was[color=darkred]
one[color=darkred]
>
> That conflicts with my experience. Command line parameters are ALWAYS
> position sensitive (P1, P2, ...), UNLESS they are presented as a
> Keyword/Value pair (P3=Value3 P1=Value1 P4=Value4...) the latter are
> sometimes loosley referred to as 'free-format" parameters, but the former
> are always positional. How else can you know which value represents what?

Compare, for MS-DOS, the pairs:
dir /p *.
dir *. /p
and
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.

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
arguments.

>
>
> The latter choice may
> From a table? Yes, if it is on disk. Then this is very similar to using
an
> .ini file or some other environment mechanism (like the Registry...). I
> have never seen a table passed from the Command Line.

You have been proposing a collection for command
line arguments; which, to me, is equivalent to a table.
Whether the table is one of object references to values
or of the values themselves is not particularly important.
The comparison was between processing arguments
from the command line or arguments from such a table.

Roger While

2007-04-02, 3:55 am

"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:131139b8gi0ik5a@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:57bapsF2cbj24U1@mid.individual.net...
> was
> one
>
> Compare, for MS-DOS, the pairs:
> dir /p *.
> dir *. /p
> and
> 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.
>

That is just not true.
The "dir" command above gives different outputs.
So it IS position sensitive.
Another example :
copy a.txt + b.txt dest.txt
is VERY different to :
copy b.txt + a.txt dest.txt
Equivalent in shell -
cat a.txt b.txt >dest.txt
versus
cat b.txt a.txt >dest.txt

> 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
> arguments.
>
> an
>
> You have been proposing a collection for command
> line arguments; which, to me, is equivalent to a table.
> Whether the table is one of object references to values
> or of the values themselves is not particularly important.
> The comparison was between processing arguments
> from the command line or arguments from such a table.
>
>
>

Pete Dashwood

2007-04-02, 7:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:131139b8gi0ik5a@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:57bapsF2cbj24U1@mid.individual.net...
> was
> one
>
> Compare, for MS-DOS, the pairs:
> dir /p *.
> dir *. /p
> and
> 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, otherwise
the keyword is followed by an = or a colon and a value... (explicit keyword
parameter)

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
"file=a.txt".

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

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 are
in the directory c:\MyStuff and any of its subdirectories, that were changed
on or after the 3rd April 2007 (/D...explicitly stated), to the directory
d:\MyOldStuff, excluding (/EXCLUDE...explicitly stated) any files with an
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 case
is a little different. Especially in the mainframe environment, non-keyword
parameters are normally positional so that no keyword needs to be entered.
The use of separators indicates the position and only the runtime parameter
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
> arguments.
>

I see your case and what you based it on, but there is a difference between
OS parameters and system utilities which can be considered an extension of
the OS. Our COBOL requirement is purely for applicatiions.(It will be
issued from COBOL application programs...)
[color=darkred]
> an
>
> You have been proposing a collection for command
> line arguments; which, to me, is equivalent to a table.
> Whether the table is one of object references to values
> or of the values themselves is not particularly important.
> The comparison was between processing arguments
> from the command line or arguments from such a table.

OK, I acceot you are talking about a conceptual table. The tables I proposed
are real ones in the memory of a COBOL application. They are TARGETs not
SOURCEs... The arguments do not come from such a table, pointers to their
values are placed in it.

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 EASILY
manipulated with the COBOL SEARCH verb and that was one of the design goals
in the proposal. I would rather see a SEARCH than a bunch of ACCEPTS and
compares.

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

Thanks for taking the time to look at and discuss it fairly.

Pete.

Pete Dashwood

2007-04-02, 7:55 am

"Roger While" <simrw@sim-basis.de> wrote in message
news:euq7q0$gc5$03$1@news.t-online.com...
>
> "Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
> news:131139b8gi0ik5a@corp.supernews.com...
>
> That is just not true.
> The "dir" command above gives different outputs.
> So it IS position sensitive.

Really? I don't think so, Roger. Am I missing something here?... I would
expect exactly the same paged output from both of Rick's dir commands. Mind
you, it is quite some time since I used DOS so I may be overlooking
something... :-)

I decided to take my own advice (given here on numerous occasions) and try
it... :-)

I got exactly the same result, as I expected. Maybe it's different on UNIX?

Anyway, what did you think of the proposed solution overall? Is it in line
with what you were suggesting?

I wholeheartedly support your suggestion for a better and simpler way to get
runtime parameters; I think we are failing to make the case for it, because
there is a perception that what is there already is fine (it isn't...), and
because it is so difficult to get ANYTHING through J4.

This exercise has taught me that I wouldn't last 5 minutes on J4...:-) (Not
that they'd have me anyway...)

I hope you get your "simple function"... let me know if you do, and we can
go skating with Satan...:-)

Pete.

Rick Smith

2007-04-02, 7:55 am

"Roger While" <simrw@sim-basis.de> wrote in message
news:euq7q0$gc5$03$1@news.t-online.com...
>
> "Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
> news:131139b8gi0ik5a@corp.supernews.com...
[snip]
>
> That is just not true.
> The "dir" command above gives different outputs.
> So it IS position sensitive.

If you got different results, then I suggest you entered
different values for the two commands. Please
document your claim. Something like the following
would be sufficient.

I created the file a.txt and this batch file.
-----x.bat
dir /b ?.txt > xdir.txt
dir ?.txt /b >> xdir.txt
-----
I ran the batch file and got this result.
-----xdir.txt
a.txt
a.txt
-----
The two "dir" commands povided the same results,
which show here as a repetition of the file name "a.txt",
and did so without regard to the absolute positions
of the arguments.

> Another example :
> copy a.txt + b.txt dest.txt
> is VERY different to :
> copy b.txt + a.txt dest.txt

I wrote "The arguments to the "copy" command are
relative position sensitive for the input and output files;
but are not absolute position sensitive." So, if one
changes the "relative position" of input files, the result
will be different!

Roger While

2007-04-02, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:1311pe6bl2sbefb@corp.supernews.com...
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:euq7q0$gc5$03$1@news.t-online.com...
> [snip]
>
> If you got different results, then I suggest you entered
> different values for the two commands. Please
> document your claim. Something like the following
> would be sufficient.
>
> I created the file a.txt and this batch file.
> -----x.bat
> dir /b ?.txt > xdir.txt
> dir ?.txt /b >> xdir.txt
> -----
> I ran the batch file and got this result.
> -----xdir.txt
> a.txt
> a.txt
> -----
> The two "dir" commands povided the same results,
> which show here as a repetition of the file name "a.txt",
> and did so without regard to the absolute positions
> of the arguments.
>
>

Yea, Got mixed up wtih all these different command processors
like Cygwin and MSYS/MingW (both of which are on my Win boxen) :-)
However :
dir a.txt b.txt
is not
dir b.txt a.txt

>
> I wrote "The arguments to the "copy" command are
> relative position sensitive for the input and output files;
> but are not absolute position sensitive." So, if one
> changes the "relative position" of input files, the result
> will be different!
>
Not sure what you mean here.
Input files come first and are interpreted left to right and
then comes the output.
I do not see any relative/absolute confusion here.

Rick Smith

2007-04-02, 6:55 pm

X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Complaints-To: abuse@supernews.com
Lines: 113
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:163872

"Roger While" <simrw@sim-basis.de> wrote in message
news:eurdle$mlb$01$1@news.t-online.com...
>
> "Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
> news:1311pe6bl2sbefb@corp.supernews.com...
>
> Yea, Got mixed up wtih all these different command processors
> like Cygwin and MSYS/MingW (both of which are on my Win boxen) :-)
> However :
> dir a.txt b.txt
> is not
> dir b.txt a.txt
-----
C:\cbl-chal>dir a.txt b.txt
Too many parameters - b.txt

C:\cbl-chal>dir b.txt a.txt
Too many parameters - a.txt
-----<g>

>
>
>
> Not sure what you mean here.
> Input files come first and are interpreted left to right and
> then comes the output.
> I do not see any relative/absolute confusion here.

Given:
copy a.txt + b.txt dest.txt
and
copy b.txt + a.txt dest.txt
the positions relative to "a.txt" are,
in the first case:
0 - a.txt
1 - +
2 - b.txt
3 - dest.txt
in the second case:
-2 - b.txt
-1 - +
0 - a.txt
1 - dest.txt
The relative positions have changed, therefore
the results are different.

Given:
copy a.txt + b.txt dest.txt /b
and
copy /b a.txt + b.txt dest.txt
the positions of the files relative to "a.txt" are the same;
but the absolute positions of the files are different.
The results are the same.

Richard

2007-04-02, 6:55 pm

On Apr 2, 4:12 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

> I recall a DOS command (SET with no operands, I
> think...) that could do this under DOS on a PC. Has UNIX no equivalent? Is
> there no UNIX command to list all EVs on the console?

Yes there is a Unix command for this, it is 'set' and was lifted from
Unix/Xenix and added into MS-DOS 2.x along with many other Unix/Xenix
features.

But surely EV are deprecated by MS - replaced by the hooror of 'The
Regitry'.

Did you want your 'FUNCTION somethingorother' to regurgitate the whole
registry into your program so that you can pick through it like
chicken entrails ?

Richard

2007-04-02, 6:55 pm

On Apr 2, 1:51 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

> I understand what you are saying and thanks for the example.
>
> It seems to me you are second guessing what the implementor will do. While
> most Unix compiler writers will probably use C, there is no guarantee that
> that is so, and neither should we assume that because a C header file
> doesn't provide support for pointers to the environment, it is therefore
> impossible to implement. All that proves is that it cannot be done DIRECTLY
> in C, on that platform. There are many ways to skin a cat and compiler
> writers are notoriously imaginative. Although I don't claim expertise in
> Unix, I did some quick searching and found the following:
>
> "The PRINTENV command is used to display environment variable definitions.
> If it is given with no arguments then all environmental variables wil be
> displayed. You can also give the command with a single argument, which is
> the name of an environmental variable without a dollar sign. Then the
> definition of that variable is displayed. "
>
> As far as I can establish, PRINTENV is available across ALL UNIX platforms

Environment variables are a feature of the shell, not of the OS. The
behaviour of these and the means of setting and reading them may vary
between different shells (ge sh, bash, csh, zsh).

It happens that 'printenv' (note lower case) is an external program
that will list the environment variables and 'set' is built into bash.

These do not produce exactly the same results, in particular bash's
set will produce more information about the environment.

> We are only interested in the actual values of the variables (and
> their names); we don't HAVE to access the EVs directly.

We are actually only interested in what the user is attempting to get
the program to do. This may be by having the user fill in a dialog,
or it may be from having something set in an EV or from a command
line.

The point is that my programs needs to know what the user wants for
some particular setting. I want to use some name to call that setting
by but I neither know nor care whther it is in the environment, the
registry, on the command line or has to gotten via a dialog or from a
configuration file.

I want my application to 'call getparam using thisname uservalue'.
The getparam program should do whatever is necessary on the particular
OS following some (configurable?) priority.

For examply it could look at the command line for 'thisname=value'
then a configuration file, and then the environment or the registry.
I don't want a list of various values to sift through, that may be the
job of the 'black box' getparam.

Certainly some mechanism is required but it need not be part of the
standard because I can write a different 'getparam' for each OS, and
one for CGI and one for web services.

In each case the priority and method of determining the values may be
quite different.

> The bottom line is that if EVs can be accessed in ANY way, then the solution
> I suggested can be implemented by a compiler provider.
>
> However, it is not the job of J4 to decide HOW COBOL facilities are
> implemented. Reviews of proposals by vendors will establish if something
> CANNOT be done, and that just means it can't be done in a certain
> environment.

I don't want J4 to be involved at all in this particular issue.

> 1. We need to generate code (or a solution) to provide access to EVs at run
> time.

But it isn't the EV's that are required, it is the value of the
parameter that the user wants to specify. This may be in EVs on one
system, a registry in another, or a configuration file in others.

Richard

2007-04-02, 6:55 pm

On Apr 2, 3:20 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

> 1. You have to make repeated calls to get command line parameters.

You have to process each command line parameter separately regardless
of whether you have them as a list or as separate 'reads'.

> 2. You have to make more calls to get EVs, and know what you are looking
> for.

That is just silly. You need to know what you are looking for
regardless of whther you have everything in a list of get things one
by one. Many (maybe all) of the things in the EV are irrelevant and/or
meaningless to an application.

> 3. It isn't Keyword/Value pair friendly which is what the Web uses, and what
> most Web programmers have come to know and love.

What about EVs isn't 'keyword/value' pairs ?

Whether a command line is or isn't 'keyword/value' pairs is dependent
entirely on how the command line has been contructed.

> 4. You still have to sort out keyword parameters and values from the command
> line, in your own code, after you've accessed them.

Which is why I do that once in one program that I call whenever I need
some sort of 'sorting out'. It doesn't need J4 to tell me how to do
this.

Richard

2007-04-02, 6:55 pm

On Apr 2, 10:29 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

>
>
> 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, otherwise
> the keyword is followed by an = or a colon and a value... (explicit keyword
> parameter)

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.

> 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
> "file=a.txt".
>
> XCOPY /A /D:04-03-2007 /EXCLUDE:".obj" /E c:\MyStuff\*.* d:\MyOldStuff\
>
> 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 are
> in the directory c:\MyStuff and any of its subdirectories, that were changed
> on or after the 3rd April 2007 (/D...explicitly stated), to the directory
> d:\MyOldStuff, excluding (/EXCLUDE...explicitly stated) any files with an
> 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 case
> is a little different. Especially in the mainframe environment, non-keyword
> parameters are normally positional so that no keyword needs to be entered.

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.

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

> The use of separators indicates the position and only the runtime parameter
> 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.)
>
>
> I see your case and what you based it on, but there is a difference between
> OS parameters and system utilities which can be considered an extension of
> 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 EASILY
> manipulated with the COBOL SEARCH verb and that was one of the design goals
> in the proposal. I would rather see a SEARCH than a bunch of ACCEPTS and
> compares.

You will actually see a _bunch_ of SEARCHes.

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).

You are just making up strawman arguments.

> I guess I've said everything I want to about this :-) and as it is not going
> anywhere anyway, I might as well get back to work :-)
>
> Thanks for taking the time to look at and discuss it fairly.
>
> Pete.

Richard

2007-04-02, 6:55 pm

On Apr 3, 5:14 am, "Roger While" <s...@sim-basis.de> wrote:
> "Rick Smith" <ricksm...@mfi.net> schrieb im Newsbeitragnews:1311pe6bl2sbefb@corp.supernews.com...

> Not sure what you mean here.
> Input files come first and are interpreted left to right and
> then comes the output.
> I do not see any relative/absolute confusion here.

There isn't, but PD appered to be arguing that they were in absolute
positions and thus could be processed without having to step through
each parameter in turn.

He was arguing against the idea of:

accept argc from argument-count
perform varing argn from 1 by 1 until argn > argc
display argn upon argument-number
accept parameter from argument-value

process here
end-perform

on the basis (apparently) that some magic was going to always make
everything be in the correct place.

Richard

2007-04-02, 6:55 pm

On Apr 3, 6:12 am, "Rick Smith" <ricksm...@mfi.net> wrote:

> -----
> C:\cbl-chal>dir a.txt b.txt
> Too many parameters - b.txt
>
> C:\cbl-chal>dir b.txt a.txt
> Too many parameters - a.txt
> -----<g>

The results that you get will be entirely dependent on what version of
dir that you use, and possibly on other factors. I have a 'dir' that
will completely ignore the 2nd parameter, other versions could
possibly do a 2nd listing or could list all wildcards mixed together.

Richard

2007-04-02, 9:55 pm

On Apr 1, 4:53 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

> Recall that intrinsic functions
>
[color=darkred]
> 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.

Clark F Morris

2007-04-02, 9:55 pm

On Mon, 2 Apr 2007 15:04:47 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>
>"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>news:FJYPh.26820$Ts6.13784@fe12.news.easynews.com...
>But you still have to "parse" it if it has keyword parameters, and sort out
>what the values are. And you still have to make further ACCEPTs to get the
>EVs...
>
>My solution does that for you, with ONE invocation, AND it handles mixed
>positional and keyword parms on the command line.
>
>My point is that programmers shouldn't have to do all this bullshit. A
>single "facility" can do it for them and put everything away in a form that
>is easily accessible.
>
>I posted some COBOL here to do the parsing of keyword parameters a few
>w

s back...
>
>http://tinyurl.com/26hw83
>
>How much nicer if there was a COBOL construct that just did it for us.
>
>Roger got rubbished for suggesting a "simple function". I agree with him and
>that's why I posted. (That... and because my head was spinning from REAL
>work... :-)).

I come back to the point that the whole thing is dependent on
operating system, method of invocation and flavor of the month. I'm
using Agent which stuffs things somehow into some file in its primary
directory path so I can run it on a USB key and take it from computer
to computer. If they had a Linux version they might be able to do the
same thing. On the other hand, a program that stuffs and gets things
from the registry will work differently from one that gets its
equivalent information from Unix/Linux environmental values and the et
of values available in a z/OS environment will again be different and
presented in a different way which can depend on how the program is
invoked.
>
>Pete.
>

Pete Dashwood

2007-04-02, 9:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1175551275.527091.185090@q75g2000hsh.googlegroups.com...
> On Apr 2, 1:51 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
>
> Environment variables are a feature of the shell, not of the OS. The
> behaviour of these and the means of setting and reading them may vary
> between different shells (ge sh, bash, csh, zsh).
>
> It happens that 'printenv' (note lower case) is an external program
> that will list the environment variables and 'set' is built into bash.
>
> These do not produce exactly the same results, in particular bash's
> set will produce more information about the environment.
>

Thanks for that, Richard.

>
> We are actually only interested in what the user is attempting to get
> the program to do. This may be by having the user fill in a dialog,
> or it may be from having something set in an EV or from a command
> line.

That was Rick's original position, I think.

I believe the action of GETTING parameters (from wherever, as you suggest)
should be separate from the action of USING parameters.
>
> The point is that my programs needs to know what the user wants for
> some particular setting. I want to use some name to call that setting
> by but I neither know nor care whther it is in the environment, the
> registry, on the command line or has to gotten via a dialog or from a
> configuration file.
>
> I want my application to 'call getparam using thisname uservalue'.
> The getparam program should do whatever is necessary on the particular
> OS following some (configurable?) priority.
>
> For examply it could look at the command line for 'thisname=value'
> then a configuration file, and then the environment or the registry.
> I don't want a list of various values to sift through, that may be the
> job of the 'black box' getparam.
>

Yes, I see your point.

> Certainly some mechanism is required but it need not be part of the
> standard because I can write a different 'getparam' for each OS, and
> one for CGI and one for web services.
>

I think the idea is to avoid having to do that. If there is a COBOL
facility, it could be invoked from COBOL running anywhere... Web Service,
CGI, or desktop.

> In each case the priority and method of determining the values may be
> quite different.

Hmmm... it could, but that is probably undesirable... :-)

>
>
>
> I don't want J4 to be involved at all in this particular issue.

Amen... I don't want them involved in ANY issue :-)

Unfortunately, it is impossible to get a facility added to COBOL unless they
are... :-)

>
>
> But it isn't the EV's that are required, it is the value of the
> parameter that the user wants to specify. This may be in EVs on one
> system, a registry in another, or a configuration file in others.
>

I agree that is a valid consideration. It would be MUCH harder for
implementors, who would have to know what the .ini file name is, which
Registry values are affected, and all of this complicates what has to be
passed to the facility. (unless they are separately configurable, and that
means more work... it might be possible to have some defaults, like
progname.ini... )

I see your point about requesting what you want, but this becomes tedious
when there are a number of things you want, in different "locations" around
the environment. It means multiple calls and is very much what we currently
have...

That's why I suggested two sets that hold everything as name/value pairs. I
admit, this doesn't cover .ini and registry entries; maybe it should, for
systems that have those facilities, but then we are getting into something
that is not so simple for implementors.

Pete.
>

Pete Dashwood

2007-04-02, 9:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1175549219.871504.320880@y80g2000hsf.googlegroups.com...
> On Apr 2, 4:12 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
>
> Yes there is a Unix command for this, it is 'set' and was lifted from
> Un