| ->It looks like /gen isn't being handled in the way that might reasonably
->be expected...
This is the expected behavior in CMS. When you fetch one element from a CMS
library, CMS will fetch any particular generation you specified. However,
fetching multiple elements with different generation, CMS will try to fetch
all the element with the generation of the last element in your command line.
->cms fetch gem_se.bli/gen=10,gem_sr.bli/gen=35,gem_lu.bli/gen=55,gem_df.bli/gen
If you want to fetch these elements, you can insert these elements into a
class then fetch them from the class or fetch them one by one.
-James
|
| I agree with Kent. I've been bitten by this too.
It is very reasonable to EXPECT /GEN to be a local qualifier; DCL has
this concept. In fact, based on DCL rules, one would expect:
fetch /gen=75 foo.bar, zork.bar, alph.bar/gen=55
to get foo and zork gen 75, and alph gen 55. AND
fetch foo.bar/gen, zork.bar, alph.bar/gen=55
to get foo gen 75, zork gen 1+, and alph gen 55.
That his perfectly reasonable construct (and mine) produce something
other than what WE EXPECT is a human interface defficiency. I expect
that the DCL rules for global, local, and sticky (defaulted) qualifiers
will be obeyed by products. When a product doesn't play by the rules,
saying that "the product's behavior is expected" (and the user wrong)
seems like inverted logic to me.
At this late date, one might argue that correcting this bug may have more
side effects than it cures. I'm not sure where I'd come down on that.
But, the argument that "this is the expected behavior in CMS", because
"that's the way it works" is specious.
Yes, the alternate cumbersome methods work.
T
|
| Hi Kent and Tim,
I agree; CMS does behave differently from, say, DCL. We'll raise this
as a wish.
In James' defense, what he was responding to was the fact that at some
point in the history of CMS, a design decision was made to implement
the qualifier with its present behavior for technical reasons; only one
/generation qualifier is expected by CMS on a command line. I'm not
sure why it was designed that way, but it may have been before
positional qualifiers became commonplace.
In any event, we'll look at changing it to behave more normally for a
future version. Thanks for raising this.
-- Daryl
|