In <bitnet.adsm-l%9511140437.AA0051@ESS_OSS_AMR.cml.com>, raibeck AT connix DOT 
com (Andy Raibeck) writes:
>Bill Colwell writes:
>
>[ snip ]
>
>> I know that I have complained more than once via PMR's and suggestions
>> about this problem (returning too many nodes, etc.), but I never suggested
>> an arbitrary limit.  What I always suggested was to pop up the include
>> window before the server was queried and the initial list was displayed.
>> Every admin could then limit the display or see the whole list - first
>> time, every time.
>
>I agree with Bill. It would also be helpful to have the include window up
>front on many of the other functions as well - nodes, storage pool volumes,
>activity log, filespaces, etc. This would help reduce the wait time involved
>to initially build the list, when all you want is to see a few items.
>
>I don't know what can be done to improve the overall response time on
>building the output, but if I could limit it from the outset via the
>include filter, that would go a long way toward achieving some kind of
>compromise on the issue.
>
>Andy Raibeck
>Connecticut Mutual
>203-987-3521

 I have a suggestion for IBM as to how to provide quick relief for this
problem.  You, the developers, know the format of DSMADM.INI, where the
include specs are stored, and of course we, the users, don't.  Could you
write a Rexx exec which would present a display of the ini and
provide preview/editting of the include specs, and then after exiting the
display, invoke DSMADM.EXE?  You could use the 'Visual Rexx' freeware,
available at software.watson.ibm.com/os2/ews to make the display.
Putting this tool out as 'unsupported' would be quite acceptable.


Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550