Skip to Main Content
IBM Data and AI Ideas Portal for Customers

This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at

Status Future consideration
Workspace Spectrum LSF
Components License Management
Created by Guest
Created on Jun 23, 2023

In the 'License Scheduler' product, monitor only necessary features instead of all


sometimes, we encounter slowness (freezes) on LSF jobs scheduling due to big slowness in licenses monitoring (lmstat) from License Scheduler because license features used for some resources under LS management are part of license services managing thousands of features for 10 thousands end-users.

When license service works fine, it takes ~30s to get data for all features and less than 5s for the concerned features.

When there's issue to monitor license service, it takes more than 10mns to monitor all features but only ~30s for the desired features.

Can you please improve the license monitoring by doing lmstat per feature instead of all ?

If the behavior (global vs per feature) could be selectable using a switch, it would be a plus.

As a side effect, it will also reduce the load on the license server (KBs of data instead of  MBs for several thousands of token).




Needed By Week
  • Admin
    Bill McMillan
    Nov 20, 2023

    Thanks for the feedback. We'll considere this in our future planning.

  • Guest
    Nov 8, 2023

    Hi Bill,

    as discussed with MingLiang ZU from your company this morning, our usage of LS is limited to few feature of hundreds per license services. By doing a lmstat -a per license services, we create a load x1000 vs lmstat -f <feature> per features.

    we already put in place a wrapper for a license service that, sometime, take more than 10mns for a lmstat -a (not acceptable for LS usage ) vs 15s when doing a lmstat per requested feature (2 of 414 features in use, for 3k vs 11k tokens in use).

    maybe a switch parameter, per SD, to select the way of work could be a solution ?

    otherwise, triggering a lmstat -f if the features are listed in the SD could be another solution.

    In term of robustness, the wrapper solution is so dangerous: we must take care of any change in the lmstat output, any change in the feature used in LS, any change in license servers list, etc ...

    we would appreciate a robust solution.



  • Admin
    Bill McMillan
    Aug 8, 2023

    Hi Olivier, a very long time ago we used to query by feature, which did put a higher load on lmgrd and could cause instability in the license quorum - so we moved to the query all approach. While it can be slower, it seemed to have less impact on lmgrd itself.

    What you have suggested could be achieved with a wrapper around blcollect/lmstat/lmutil:

    blcollect. -------------> wrapper ---------------->license server

    1. configure wrapper script in lsf.licensescheduler file

    2. blcollect calls the wrapper instead of calling lmstat/lmutl directly.

    3. Input of wrapper script is port@server, features list, timeout, and location of lmstat/lmutil,

    4. Output is the combined features information which is similar with lmstat -a

    5. Wrapper script call license server per specified feature, and combines all the output before returning.

    It's not something the development team have bandwidth for at present, but it could be implemented via Expert Labs.