get/set runtime environment information

Taken over from the thread "Is the (draft) 2008 standard available".

Chuck, can you comment on Bill's post ?

Roger


> "Bill Klein" wrote ..
>Roger,
>  Chuck doesn't come from an X/Open -type COBOL environment, so he didn't
> understand your question. Your real question was "how do you get and set
> run-time environment variables".  (The X/Open syntax has always been
> "conforming" - but only portable to SOME implementations and
> environments).

> I know that there have been discussions about this at both J4 and WG4
> (i.e.
> adding a "standard syntax" for doing this) - along with a function (or
> something) to get the number of arguments passed to a program/function.
> I
> agree that I don't see this in the draft '08 Standard.  Once he
> understands the
> question, Chuck might be able to tell us whether this is still on the
> "candidates" list - or has been rejected (and if so why).
> --
> Bill Klein
>  wmklein <at> ix.netcom.com

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e4vf9v$2kvc$1@si05.rsvl.unisys.com...
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e4uekq$jnf$01$1@news.t-online.com...
> \
<snip> 
>
> The draft says "The execution of a device format ACCEPT statement causes
> information from a device to be transferred to the specific data item,
> where
> the device is a hardware or software device in the operating
> environment.".
> Given the deliberate vagueness in this wording -- that whatever you ACCEPT
> from is something that the implementor has defined in the operating
> environment that is capable of providing information -- I'm at rather a
> loss
> to understand what it is that you expect of it.
>
<snip>
>    -Chuck Stevens

Chuck,
to be more specific ...

What was done with the paper
"05-0029- Environment variables"

Available online at:
http://www.cobolstandard.info/j4/files/05-0029.doc

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:e513g8$mm0$00$1@news.t-online.com...
> Taken over from the thread "Is the (draft) 2008 standard available".
>
> Chuck, can you comment on Bill's post ?
>
> Roger
>
> 
> 
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:e4vf9v$2kvc$1@si05.rsvl.unisys.com... 
> <snip> 
> <snip> 
>
>

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:D36dg.33729$aA3.31843@fe06.news.easynews.com...
> Chuck,
>   to be more specific ...
>
> What was done with the paper
>    "05-0029- Environment variables"
>
> Available online at:
>    http://www.cobolstandard.info/j4/files/05-0029.doc
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com

The Environment Variables and Command Line Variables features were in the
"include if feasible in the time frame" category from WG4.

05-0029, Environment Variables, was presented and discussed at Meeting #250
(7-11 February 2005; see the final minutes for that meeting, J4/05-0073).
At that meeting J4 suggested some refinements.

The related document, Command Line variables (assigned J4 document number
05-0030), has not yet been completed or received by J4 for review.

The revisions to 05-0029 were not made available for Meeting #251 (as far as
I know they're still not available), and 05-0030 hasn't been made available
for review at all (it may not even exist yet).

The features were dropped from consideration for the 2008 draft precisely
because it was not feasible to include them in the time frame required for
that revision given the state of their specifications.

Both features are considered desirable, and both features are included in
the list of candidate features for a future revision.  But the details
simply weren't ready in time for this one.

-Chuck Stevens

Roger (et al),
*If* this IS a feature that you think is "so important" that it should still
be added to the 2008 Standard, you should

A) contact your "national standards body" to make certain this is conveyed f
rom
them to WG4 (and to J4).  To find out information on "your" national standar
ds
body, see:
http://www.iso.ch/iso/en/aboutiso/i...CODE=1
0

B) Contact the Micro Focus representative to J4 (as listed in the latest mai
ling
list) who was ALSO the original author of the proposal (still waiting a
revision).  His email address is listed at:
huib.klink <at> microfocus.com
For long time viewers of comp.lang.cobol, this name may well be familiar.

NOTE:
As Richard (I think) indicated, this "features" does tend to assume an
operating system WITH such things as "environment variables".  Certainly, th
ese
are always (I think) available in POSIX-conforming environments, but it woul
dn't
surprise me that IF such a feature were added to a future Standard that it w
ould
be in the "processor depenendent" category (but I don't know that would be
true).

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e54edh$2hqo$1@si05.rsvl.unisys.com...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:D36dg.33729$aA3.31843@fe06.news.easynews.com... 
>
> The Environment Variables and Command Line Variables features were in the
> "include if feasible in the time frame" category from WG4.
>
> 05-0029, Environment Variables, was presented and discussed at Meeting #25
0
> (7-11 February 2005; see the final minutes for that meeting, J4/05-0073). 
At
> that meeting J4 suggested some refinements.
>
> The related document, Command Line variables (assigned J4 document number
> 05-0030), has not yet been completed or received by J4 for review.
>
> The revisions to 05-0029 were not made available for Meeting #251 (as far 
as I
> know they're still not available), and 05-0030 hasn't been made available 
for
> review at all (it may not even exist yet).
>
> The features were dropped from consideration for the 2008 draft precisely
> because it was not feasible to include them in the time frame required for
> that revision given the state of their specifications.
>
> Both features are considered desirable, and both features are included in 
the
> list of candidate features for a future revision.  But the details simply
> weren't ready in time for this one.
>
>    -Chuck Stevens
>

Just a reminder:  An overriding concern of WG4 in the production of the next
COBOL standard is the AVOIDANCE OF ANY DELAY.    Both committees recognize
the dangers of Feature Creep, and from the beginning "command line and
environment variables" have been in the category "If you can get it in
without delaying the mandatory features, fine; if you can't, don't."

Feature Creep was one of the big problems delaying the production of the
2002 standard, and it's a problem WG4 has insisted will not recur.

The Environment Variables feature was classified "Look into this" at the WG4
meeting in '03, and escalated to "Include if feasible in the time frame" in
October '04.  The first proposal on the subject was presented to J4 in
February '05, and by April '05 J4 had determined that the clock for this
feature had ticked past the "if feasible in the time frame" boundary.

Can't have it both ways, folks -- either the Feature Content of the draft
stays the way it's been established for a couple of years now, or the
adoption of the standard will be delayed while it gets redrafted to include
the new feature and re-reviewed at the US and international levels.

I don't think WG4 is likely to agree to delay publication to add this
feature, particularly given that they've been saying since '03 that it's NOT
a mandatory feature to begin with.

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:mUodg.53373$Gj2.31342@fe05.news.easynews.com...
> Roger (et al),
>   *If* this IS a feature that you think is "so important" that it should
> still be added to the 2008 Standard, you should
>
> A) contact your "national standards body" to make certain this is conveyed
> from them to WG4 (and to J4).  To find out information on "your" national
> standards body, see:
>
> http://www.iso.ch/iso/en/aboutiso/i...CODE
=10
>
> B) Contact the Micro Focus representative to J4 (as listed in the latest
> mailing list) who was ALSO the original author of the proposal (still
> waiting a revision).  His email address is listed at:
>   huib.klink <at> microfocus.com
> For long time viewers of comp.lang.cobol, this name may well be familiar.
>
> NOTE:
>   As Richard (I think) indicated, this "features" does tend to assume an
> operating system WITH such things as "environment variables".  Certainly,
> these are always (I think) available in POSIX-conforming environments, but
> it wouldn't surprise me that IF such a feature were added to a future
> Standard that it would be in the "processor depenendent" category (but I
> don't know that would be true).
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:e54edh$2hqo$1@si05.rsvl.unisys.com... 
>
>

As a follow-up on this, you might want to look at the current "draft revisio
n
schedule" at:
http://www.cobolstandard.info/j4/files/04-0182.doc

According to that document:

" 3  First CD submitted for registration and approval      2006-08 - sooner 
if
few changes"

Given the fact that neither the Collection Class nor the XML TR has yet reac
hed
"International final approval" (and that therefore, IMHO adding them to the
first CD by August 2006 seems HIGHLY quesitonaable),  (As has been mentioned
here, there was a new "WD" (working draft) made available at the most recent
 J4
meeting.

Once COULD ask whether either of these involves "feature creep" (and/or as m
uch,
more, or less than environment variables - where the X/Open specification is
already in "common usage").

WG4 documents are not (normally) "public".  However, looking at the J4 docum
ent
at:
http://www.cobolstandard.info/j4/files/05-0196.doc

These items are categorized as:
"TR - do immediately in a TR

what isn't clear from that document (and I don't know if WG4 has or has not
expressed an opinion on) is whether or not such items are sufficiently impor
tant
that not only a TR but a delay in the 2008 Standard is appropriate - or whet
her
JUST having a TR is sufficient (and NOT delaying the 2008 revision) would be
best - even without them.

OBVIOUSLY (I think) it is the hope/expectation of both J4 and WG4 that the 3
TR's will be completed and included in the next refvision AND that this will
 be
completed by 2008.  What I don't know is what the WG4 opinion is - when it c
omes
to choosing between those two goals.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:e55944$31f5$1@si05.rsvl.unisys.com...
> Just a reminder:  An overriding concern of WG4 in the production of the ne
xt
> COBOL standard is the AVOIDANCE OF ANY DELAY.    Both committees recognize
 the
> dangers of Feature Creep, and from the beginning "command line and environ
ment
> variables" have been in the category "If you can get it in without delayin
g
> the mandatory features, fine; if you can't, don't."
>
> Feature Creep was one of the big problems delaying the production of the 2
002
> standard, and it's a problem WG4 has insisted will not recur.
>
> The Environment Variables feature was classified "Look into this" at the W
G4
> meeting in '03, and escalated to "Include if feasible in the time frame" i
n
> October '04.  The first proposal on the subject was presented to J4 in
> February '05, and by April '05 J4 had determined that the clock for this
> feature had ticked past the "if feasible in the time frame" boundary.
>
> Can't have it both ways, folks -- either the Feature Content of the draft
> stays the way it's been established for a couple of years now, or the adop
tion
> of the standard will be delayed while it gets redrafted to include the new
> feature and re-reviewed at the US and international levels.
>
> I don't think WG4 is likely to agree to delay publication to add this feat
ure,
> particularly given that they've been saying since '03 that it's NOT a
> mandatory feature to begin with.
>
>    -Chuck Stevens
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:mUodg.53373$Gj2.31342@fe05.news.easynews.com... 
>
>

Actually, I am glad that 05-0029 did NOT make it.
In this form it is obviously a "MicroFocusism".
Totally confusing and overengineered.
Much better would be simple keyword context -
ACCEPT identifier FROM ENVIRONMENT identifier-or-literal
and
SET ENVIRONMENT id-or-lit TO id-or-lit.
Concise, readable, does not add extra reserved words
and doesn't need SPECIAL-NAMES changes.

Roger

"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:mUodg.53373$Gj2.31342@fe05.news.easynews.com...
> Roger (et al),
>   *If* this IS a feature that you think is "so important" that it should
> still be added to the 2008 Standard, you should
>
> A) contact your "national standards body" to make certain this is conveyed
> from them to WG4 (and to J4).  To find out information on "your" national
> standards body, see:
>
> http://www.iso.ch/iso/en/aboutiso/i...CODE
=10
>
> B) Contact the Micro Focus representative to J4 (as listed in the latest
> mailing list) who was ALSO the original author of the proposal (still
> waiting a revision).  His email address is listed at:
>   huib.klink <at> microfocus.com
> For long time viewers of comp.lang.cobol, this name may well be familiar.
>
> NOTE:
>   As Richard (I think) indicated, this "features" does tend to assume an
> operating system WITH such things as "environment variables".  Certainly,
> these are always (I think) available in POSIX-conforming environments, but
> it wouldn't surprise me that IF such a feature were added to a future
> Standard that it would be in the "processor depenendent" category (but I
> don't know that would be true).
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:e54edh$2hqo$1@si05.rsvl.unisys.com... 
>
>

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:P9qdg.60064$p_1.15774@fe03.news.easynews.com...

> These items are categorized as:
>   "TR - do immediately in a TR
>
> what isn't clear from that document (and I don't know if WG4 has or has
> not expressed an opinion on) is whether or not such items are sufficiently
> important that not only a TR but a delay in the 2008 Standard is
> appropriate - or whether JUST having a TR is sufficient (and NOT delaying
> the 2008 revision) would be best - even without them.

In the general case, WG4 has an overriding opinion -- Thou Shalt Not Add
Features That Threaten To Delay The Draft.

The TR's were listed as Mandatory in the initial list, have not strayed from
it, and remain there.

My recollection is that J4 expects to incorporate the TR's into the draft
once J4 is satisfied that they're ready for their formal international
ballot, and doesn't expect a significant problem (they've both been through
an international review period).

The XML TR is ready for an informal straw poll among the WG4 HoD's to see if
they think it's ready for international ballot; the only reason that hasn't
happened is that I'm still working through the diplomacies and procedures
involved.

The Collection Class TR has probably one more cycle of J4 work to go through
before it's in that same state.

The Finalizer TR is already approved and published by ISO/IEC.

I don't think either committee anticipates significant problems with the
incorporation of any of the three TR's into the 2008 draft.

> OBVIOUSLY (I think) it is the hope/expectation of both J4 and WG4 that the
> 3 TR's will be completed and included in the next refvision AND that this
> will be completed by 2008.  What I don't know is what the WG4 opinion is -
> when it comes to choosing between those two goals.

My opinion is that WG4 wants these features in.  They don't want *anybody*
to add requests for *additional* features to this draft at this stage, but
ensuring that a feature that was a "must-have" in the first list, and has
remained there since, is actually there does not represent "feature creep".

We are doing what we can to get the draft ready for international ballot in
the timeframe WG4 has requested.     I do not believe WG4 wants us to start
ripping features out of either the requested feature content list or the
draft standard itself at this point.

-Chuck Stevens