Spool

 View Only
  • 1.  How can I determine what process in CA-Spool is using CPU?

    Posted Jun 17, 2014 09:51 PM

    We have noted that CA-Spool is a relatively high user of CPU. How can we determine what process within CA-Spool is using CPU, with a view towards tuning CA-Spool to reduce CPU usage?



  • 2.  Re: How can I determine what process in CA-Spool is using CPU?

    Posted Jun 18, 2014 06:00 PM

    Hello David,

     

    There is not a single CA Spool display command that can provide you with the detail you are looking for in regards to CPU usage by process/subtasks running under the main region David.

    If you open a case I an ask you for some documentation to address your concerns on CPU usage and how you can implement changes in the featurres you are currently using to impreve overall CPU utilization.

    Let us know if you agree with this plan and once the issue is open please update this Community posting so I can take ownership of it.

     

    Let me know David if this sounds like a plan for you today.

    Regards, Cesar



  • 3.  Re: How can I determine what process in CA-Spool is using CPU?

    Posted Jun 19, 2014 09:37 PM

    Thanks for your response, Cesar.

     

    My question was really just for general information, rather than for specific advice.

     

    The system where we noticed the CPU usage is making use of XFERSAPI to get output from the JES2 spool and we know that we have a lot of requests per interval. We are in the process of reducing the number of requests by deleting unused printer node definitions and making use of the XFERNODE=DEST/ALIAS/BOTH/NONE parameter where appropriate, then once we’ve reduced the number of requests as far as possible we’ll be changing to XFERSAPI=THREADS.

     

    So, my question about CPU usage by CA-Spool was just to find out what other processes could be using CPU, e.g. AFP transformation, EBCDIC to ASCII translation etc.

     

    Cheers



  • 4.  Re: How can I determine what process in CA-Spool is using CPU?

    Posted Jun 24, 2014 04:04 PM

    Hello David,

    Glad to hear you are making changes in your NODE definitions to reduce the SAPI requests we send to JES to ask for SYSOUTs that are part of your criteria.

    We go into a single thread in alphabetical ascending order by the NODE/ALIAS names asking for SYSOUTs to JES every time the timer set in XFERTIME= expires.

    There are multi-threading input interfaces like NJE that could allow you transfer 8 SYSOUTs at the same time if you have that amount of SYSOUT Transmitters setup for your NJE definition.

    Also you could use the pre JES spool SYSOUT Allocation Intercept to bring the file into CA Spool prior it is spooled to JES and leave XFER as a backup contingency for the output created on JES shared systems where CA Spool is not running.

    However, this is only one aspect of CPU usage you can address since other tasks will require other changes documented in the Bet Practice guide for a better overall CPU usage.

    As I said before there are no single commands to tell how much CPU a subtask is using other than reviewing a dump or dumps of the task taken at CPU spikes for analysis.

    If you want to go that route David then please open a ticket so we can provide you with more info on what we need to give you a better review of your Mainframe CA Spool task CPU usage.

    Regards, Cesar



  • 5.  Re: How can I determine what process in CA-Spool is using CPU?
    Best Answer

    Broadcom Employee
    Posted Jul 22, 2014 04:56 PM

    Hi David,

         Everything we do has some kind of CPU cost.  The steps you are taking with SAPI should make a definite and measurable difference.  You mentioned AFP transformation.  We make some tuning suggestions for that in our Best Practices Guide.  If you take advantage of resource caching, use the B transformer option and BUFSIZE=27998, you should also see improvements.  There are other topics in the Configuration chapter of our Best Practices Guide that may apply to your site, as well.  That is the best place to go for tuning information and over time we will add more information whenever we identify new things that can help.

     

    Regards,

    Len