[Robelle-l] set limits tablesize command

[Neil Armstrong]

At 09:20 AM 6/18/2002 -0700, Tom Combs wrote:
Tom,


>Neil,
>
>1.  If you still have any CM Suprtool users with support contracts,
>then for completeness you need to say whether you are also changing
>the functionality of the CM Suprtool Set Limits Tablesize command.

I thought I had implied that by saying that this was the NM version
only, but yes this is not to be changed in the CM version.



>2.  I'm sure some of your customers use Suprtool to 'front-end'
>ad-hoc user report requests (Suprtool extracts the data that is
>then fed to Cognos or another report writer).  It's always possible
>for a user to accidentally create an ad-hoc request for an absurd
>amount of data, and Set Limits Tablesize is one way to detect that
>and terminate a job that is using a lot of resources to produce
>something the user doesn't really want anyway.  If you want to make
>Set Limits Tablesize nonfunctional (since you do have users being
>bitten by it), you may need to provide similar functionality under
>a different name (Set Limits Absurd?)

Ok.



>3.  I would suggest adding a NEW command whose sole purpose is to
>disable the Set Limits Tablesize command.  The new command would
>have two options: whether to disable Set Limits Tablesize silently,
>or with a warning.

I really dislike these types of commands but it looks like this
may be the way to go.


>The sites that are having problems with existing jobstreams that
>have Set Limits Tablesize 15 can set the NEW command in Suprmgr.pub.sys;
>they can choose the disabling's silent/warning option depending on
>whether they use $stdlist analyzers.  Robelle can choose whether to
>include this new command in Suprmgr.pub.sys by default in new
>installations of Suprtool.

We *never* supply a suprmgr.pub.sys file and I don't want
to start now, that is a whole new can of worms. :)



>Sites that really want to use Set Limits Tablesize would simply not
>use the new command.

I will give this some careful thought.

Neil



>Regards,
>
>Tom Combs (TCombs@vytek.com)
>
>
>-----Original Message-----
>From: robelle-l-admin@robelle.com [mailto:robelle-l-admin@robelle.com]On
>Behalf Of Neil Armstrong
>Sent: Tuesday, June 18, 2002 6:40 AM
>To: robelle-l@robelle.com
>Subject: [Robelle-l] set limits tablesize command
>
>
>Dear Suprtool users,
>
>In the NM version of Suprtool we increased the maximum size
>of the tables from 15 Mb for all tables to 2Gb's per table
>for up to ten tables. (Although I don't recommend doing this
>Suprtool is capable of it). Subsequently, because of the old
>limitations, some people have the command:
>
>set limits tablesize 15
>
>which sets the size of the table to be only 15 Mb's. This is
>in some customers Suprtool code mainly because previously
>the default for the CM version of Suprtool is 1Mb, so some
>customers have the set limits tablesize 15 sprinkled throughout
>some scripts.
>
>What then happens is the Suprtool stream aborts because the
>table they are loading grows beyond 15 Mb. This is counter
>productive, especially since there is really no overhead
>associated with having a "big" table.
>
>What I propose is that Suprtool ignores the value entered with
>the set limits tablesize command, and that the maximum number
>of megabytes be used instead of the value entered. This would
>only be in the NM version of Suprtool of course.
>
>Now I don't like doing something behind the customers back, so normally
>I would print a warning message, but sometimes the people with the
>$stdlist analyzers don't like it when we add new warning messages.
>
>So my questions are:
>
>1) Do we automatically ignore the value entered with set limits tablesize
>and just take the maximum.
>2) If yes, do we print a warning message.
>
>Let the design debate begin. :)
>
>Sincerely,
>
>
>Neil Armstrong
>Suprtool Architect
>Robelle
>
>
>_______________________________________________
>Robelle-l mailing list
>Robelle-l@robelle.com
>http://two.pairlist.net/mailman/listinfo/robelle-l