Re: New "base document" available


"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:575qohF2b8qf8U1@xxxxxxxxxxxxxxxxxxxxx

"Rick Smith" <ricksmith@xxxxxxx> wrote in message
news:130qevi9f1ebsd8@xxxxxxxxxxxxxxxxxxxxx

"Roger While" <simrw@xxxxxxxxxxxx> wrote in message
news:euj78t$5g8$03$1@xxxxxxxxxxxxxxxxxxxx
Maybe I formulated this incorrectly.
How to go about retrieving command line parameters?

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

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)

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?

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

Still, a FUNCTION COMMAND-LINE would resolve these

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.

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



.

Relevant Pages

  • Re: Display problems in Vista
    ... Very small overhead. ... the command packet needs to be transfered. ... have to display a line that is x pixels wide at any zoom level. ...
    (comp.graphics.api.opengl)
  • Re: Read Only / Thanks Keith.
    ... >'attrib' without any parameters will display a directory ... >The full syntax of the command follows (pasted from Help ... Used without parameters, attrib displays ... xcopy command uses archive attributes. ...
    (microsoft.public.windowsxp.general)
  • Problem linking two list boxes
    ... mode, but Access does not allow this, so I have an unbound form with two ... I want to display data in the second list box which is filtered from the ... query using the common field. ... I have a command button on the form that launches a separate modal ...
    (microsoft.public.access.formscoding)
  • Re: Need WMI script
    ... Dim strDomainName, strNodeText, strXmlBuilder ... ' Retrieve values and display. ... However, if you use the cscript host, ... you can use a command similar to below at a command prompt: ...
    (microsoft.public.windows.server.scripting)
  • Re: Basics of attaching a PC
    ... Your best friend is the HELP command. ... manuals, meant to be read and reread.. ... >> SHOW DISPLAY will display the target display for DECwindows. ... >> the security is set up in the X Windows server. ...
    (comp.os.vms)