>Richard,
>
>Back in V1 of the product, the limitation of 20 operands on the command
>line was thought to be a good idea. Many (if not all) UNIX shells expand
>un-quoted wildcard characters with a list of files that match in the
>current directory. The limit of 20 operands was put in place to
>short-circuit a user who issued a command like: dsmc sel /home/* and
>accidentally got the wildcard expanded by the shell. In fact, the message
>you receive says something to that affect:
>
>ANS1102E Excessive number of command line arguments passed to the program!
>ANS1133W An expression might contain a wildcard not enclosed in quotes.
>
>You are correct in pointing out that in today's environment 20 operands is
>not very flexible. To that end, here is what I can tell you about the
>current product and welcome any suggestions.
>
>In TSM 4.2.2 and 5.1.5.2, we introduced the testflag NOOPERANDLIMIT. Coded
>on the command line as:
>dsmc sel <fs> -testflag=nooperandlimit
>This gives UNIX systems the ability pass in up to 450 operands (in 4.2.2);
>in 5.1.5.2 it is for all operating systems and the limit is 512.
Jim -
Thanks for pointing out that new option. It's not yet in the current clients
manual (which still quotes a hard limit of 20) so I wasn't aware of it.
Thoughts on it below.
>Having said this, you may encounter another one of the TSM backup-archive
>client's command-line parsing limits: only 2048 total bytes are allowed.
>If this is exceeded, you will see message:
>
>ANS1209E The input argument list exceeds the maximum length of 2048
>characters.
>
>The customers for whom the NOOPERANDLIMIT (all of whom were running UNIX)
>was introduced have been satisfied with the new operand limit and there
>have not yet been any complaints about only accepting 2048 bytes.
>
>Questions to you:
>
>1. Do you think TSM is being too cautious in trying to protect the
> wild-card expansion, i.e., would you rather see us just drop the testflag
> and let the client accept 512 (or more) operands. Is this worth the
> trade-off of stopping unwanted wild-card expansions?
>2. Any thoughts about how many operands and bytes one really needs the
> command-line client to accept (if 512 operands / 2048 bytes is not
> sufficient).
>
>Thanks,
>Jim Smith
My honest opinion: When I first saw that 20 limit, my reaction was, "You've got
to be kidding me." This is like a Playskool limit, as though we were running
BASIC on an 8080 machine. TSM is classified as an Enterprise level product.
If I were the product manager, I would be getting paid a lot more than I am now.
Er, If I were the product manager, I would stipulate that this major product is
supposed to run on an evolving variety of platforms, and therein the largest
consideration is that THE PRODUCT SHOULD SCALE. That is, there should never be
artificially imposed restrictions (which also hurt competitiveness). I would
also say that adding options statements to the product to counteract
restrictions which should not be there in the first place is costing us needless
money in programming, documentation, and support, and should be eliminated.
I would also say that IBM product people should consider that their products
should mesh well, as for example the high limits programmed into the AIX product
should be accommodated by the TSM product.
Putting my customer hat back on, and adopting a much lower pay scale:
I think trying to "protect" against this is silly. I mean, one of the earliest
things we learn in a new opsys environment is its limits. As novice users of
shell commands we quickly run afoul of the "too many command line arguments" and
so realize the limits in place in that environment. (From my AIX QuickFacts:
Command line, max len of args Command line arguments data cannot be
more than the ARG_MAX limit value in
<sys/limits.h>.
The sysconf(_SC_ARG_MAX) system call
returns this value.
Contemporary AIX value: 24576)
I wouldn't bother trying to protect people against it, in that you are actually
trying to protect them against what they don't want without knowing what they do
want. For example, with the current limit of 20, would not 19 be a runaway
condition if the user actually intended four?
In summary: Don't limit it. That's artificial and is constraining the product.
The prevailing operating system environment limit should be the natural limit,
and will afford the user the maximum opportunity to utilize the product while
relieving you of concern about limits.
In addendum: Perspective should prevail: The command line client is TERRIBLY
primitive compared to what it could and should be. By now it should have
evolved far beyond its current limited capabilities. Look at GNU command line
utilities such as their tar command to see how advanced and flexible they are in
comparison to the held-back dsmc. That's where real attention should be going!
thanks for listening, Richard Sims, BU
|
