Command-Line / Environment variable acess (new thread)

In the original thread, Pete answered my question with (in part)

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

I guess my follow-up question is

IF (and I assume this is true - but don't know for a fact that it is) OTHER
"languages" already provide the facility that you are looking for (and/or th
e
"operating system" does), what (if anything) stops you from using THOSE
facilities from within COBOL?

I am a GREAT believer in "fixing" any problems with COBOL using facilities
"already available" in the environment.  Therefore, if there is something th
at
makes "accessing" existing facilities for getting command-line parameters or
environment variables using existing approaches more difficult or impossible
,
then I would certainly agree with "solving" this.

If, on the other hand, what you want does NOT already exist for other
languages/systems, then I don't see that there is probably enough demand to 
add
it to COBOL.

OF COURSE, this does not "solve" Roger's portability problem, but if the
"solution" to this problem isn't portable in other languages, then I don't
expect it to be in COBOL.  If it is portable in other languages, then I woul
d
expect COBOL to have a "portable" way of using the facilities in those other
portable languages.



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

On Sun, 01 Apr 2007 16:37:19 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>In the original thread, Pete answered my question with (in part)
>
>"3. It isn't Keyword/Value pair friendly which is what the Web uses, and wh
at
>most Web programmers have come to know and love."
>
>I guess my follow-up question is
>
>IF (and I assume this is true - but don't know for a fact that it is) OTHER
>"languages" already provide the facility that you are looking for (and/or t
he
>"operating system" does), what (if anything) stops you from using THOSE
>facilities from within COBOL?
>
>I am a GREAT believer in "fixing" any problems with COBOL using facilities
>"already available" in the environment.  Therefore, if there is something t
hat
>makes "accessing" existing facilities for getting command-line parameters o
r
>environment variables using existing approaches more difficult or impossibl
e,
>then I would certainly agree with "solving" this.
>
>If, on the other hand, what you want does NOT already exist for other
>languages/systems, then I don't see that there is probably enough demand to
 add
>it to COBOL.
>
>OF COURSE, this does not "solve" Roger's portability problem, but if the
>"solution" to this problem isn't portable in other languages, then I don't
>expect it to be in COBOL.  If it is portable in other languages, then I wou
ld
>expect COBOL to have a "portable" way of using the facilities in those othe
r
>portable languages.

Since command lines in MS DOS, MVS JCL , and Unix are obscurely
idiosyncratic in different ways, I suspect that designing a facility
in COBOL that could cope would be an exercise in futility.  If there
is such a beast that produces a common form across environments, I
would just use a CALL or INVOKE for it.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:3dRPh.168477$Wg6.71106@fe07.news.easynews.com...
> In the original thread, Pete answered my question with (in part)
>
> "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."
>
> I guess my follow-up question is
>
> IF (and I assume this is true - but don't know for a fact that it is)
OTHER
> "languages" already provide the facility that you are looking for (and/or
the
> "operating system" does), what (if anything) stops you from using THOSE
> facilities from within COBOL?

With respect to command line arguments, there
appears to be no way to access those arguments
without extending COBOL; that is, one can not,
for example, call a C function from COBOL to
get the arguments.

With respect to environment variables, one might
call the C function "getenv()".

> I am a GREAT believer in "fixing" any problems with COBOL using facilities
> "already available" in the environment.  Therefore, if there is something
that
> makes "accessing" existing facilities for getting command-line parameters
or
> environment variables using existing approaches more difficult or
impossible,
> then I would certainly agree with "solving" this.
>
> If, on the other hand, what you want does NOT already exist for other
> languages/systems, then I don't see that there is probably enough demand
to add
> it to COBOL.
>
> OF COURSE, this does not "solve" Roger's portability problem, but if the
> "solution" to this problem isn't portable in other languages, then I don't
> expect it to be in COBOL.  If it is portable in other languages, then I
would
> expect COBOL to have a "portable" way of using the facilities in those
other
> portable languages.

Using the hosted implementation defined in
standard C as a basis, the command line and
environment variable features that are portable
across all standard C implementations may be
defined as intrinsic functions in COBOL.

FUNCTION ARGUMENT-COUNT
returns the number of arguments in the command
line. The type of this function is integer.

FUNCTION ARGUMENT-VALUE (integer-1)
returns, from the command line, the value of the
argument at the position given by integer-1. The
type of this function is alphanumeric.

FUNCTION ENVIRONMENT-VALUE
(literal-1 | identifier-1)
returns the value of a name/value pair where
literal-1 or identifier-1 is the name. The type of
this function is alphanumeric.

For each of these functions, if the host environment
is not able to supply command line arguments nor
environment values, the implementation returns
0 for ARGUMENT-COUNT and spaces for
ARGUMENT-VALUE and ENVIRONMENT-VALUE.

Prior attempts to incorporate these features into
COBOL included the ability to change or add
environment names and values; however, standard
C does not include that ability. (Where available,
it is a function "putenv()" of the host environment.
This function may be called from COBOL by
linking the appropriate library.)

There is a conflict between the names used for
the functions, described above, and their use with
X/Open COBOL; but only to the extent that
implementors of X/Open COBOL extended that
specification to permit the direct use of the names
in ACCEPT and DISPLAY statements. X/Open
defined their use as implementor-names for the
SPECIAL-NAMES paragraph. [The X/Open
specification made their use in ACCEPT and
DISPLAY statements ambiguous by using these
names rather than their corresponding
mnemonic-names in the General rules.]

On Apr 1, 12:37 pm, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> In the original thread, Pete answered my question with (in part)
>
> "3. It isn't Keyword/Value pair friendly which is what the Web uses, and w
hat
> most Web programmers have come to know and love."
>
> I guess my follow-up question is
>
> IF (and I assume this is true - but don't know for a fact that it is) OTHE
R
> "languages" already provide the facility that you are looking for (and/or 
the
> "operating system" does), what (if anything) stops you from using THOSE
> facilities from within COBOL?
>
> I am a GREAT believer in "fixing" any problems with COBOL using facilities
> "already available" in the environment.  Therefore, if there is something 
that
> makes "accessing" existing facilities for getting command-line parameters 
or
> environment variables using existing approaches more difficult or impossib
le,
> then I would certainly agree with "solving" this.
>
> If, on the other hand, what you want does NOT already exist for other
> languages/systems, then I don't see that there is probably enough demand t
o add
> it to COBOL.
>

The latest Fortran standard, 2003, does contain these types of
features. I know of at least one current Fortran95+ compiler that
includes them:

"G95 implements several features of Fortran 2003. For a discussion of
all the new features of Fortran 2003,
see: http://www.kcl.ac.uk/kis/support/ci...d_new_2003.pdf.

The following intrinsic procedures are available:
COMMAND_ARGUMENT_COUNT(), GET_COMMAND_ARGUMENT(),
GET_COMMAND() and GET_ENVIRONMENT_VARIABLE()"

ref: http://ftp.g95.org/G95Manual.pdf

This is in addition to a number of vendor specific extensions which do
the same types of things. It's also worth noting that F2003 includes
provisions for interoperability with "C".

Perhaps a future COBOL standard will incorporate them? So we can wait
around for compilers to catch up to the standards in *both*
languages :-)!

"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:1316vsobd9d549@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:3dRPh.168477$Wg6.71106@fe07.news.easynews.com... 
> what 
> OTHER 
> the 
>
> With respect to command line arguments, there
> appears to be no way to access those arguments
> without extending COBOL; that is, one can not,
> for example, call a C function from COBOL to
> get the arguments.
>
> With respect to environment variables, one might
> call the C function "getenv()".
> 
> that 
> or 
> impossible, 
> to add 
> would 
> other 
>
> Using the hosted implementation defined in
> standard C as a basis, the command line and
> environment variable features that are portable
> across all standard C implementations may be
> defined as intrinsic functions in COBOL.
>
> FUNCTION ARGUMENT-COUNT
> returns the number of arguments in the command
> line. The type of this function is integer.
>
> FUNCTION ARGUMENT-VALUE (integer-1)
> returns, from the command line, the value of the
> argument at the position given by integer-1. The
> type of this function is alphanumeric.
>
> FUNCTION ENVIRONMENT-VALUE
>    (literal-1 | identifier-1)
> returns the value of a name/value pair where
> literal-1 or identifier-1 is the name. The type of
> this function is alphanumeric.
>
> For each of these functions, if the host environment
> is not able to supply command line arguments nor
> environment values, the implementation returns
> 0 for ARGUMENT-COUNT and spaces for
> ARGUMENT-VALUE and ENVIRONMENT-VALUE.
>
> Prior attempts to incorporate these features into
> COBOL included the ability to change or add
> environment names and values; however, standard
> C does not include that ability. (Where available,
> it is a function "putenv()" of the host environment.
> This function may be called from COBOL by
> linking the appropriate library.)
>
> There is a conflict between the names used for
> the functions, described above, and their use with
> X/Open COBOL; but only to the extent that
> implementors of X/Open COBOL extended that
> specification to permit the direct use of the names
> in ACCEPT and DISPLAY statements. X/Open
> defined their use as implementor-names for the
> SPECIAL-NAMES paragraph. [The X/Open
> specification made their use in ACCEPT and
> DISPLAY statements ambiguous by using these
> names rather than their corresponding
> mnemonic-names in the General rules.]
>

Yes, that is what should be available.
I would also plaud for a
FUNCTION COMMAND-LINE
as well, to get the complete unadorned command line.