Top Secret

Expand all | Collapse all

TSS "priority" when reading the backup dataset

  • 1.  TSS "priority" when reading the backup dataset

    Posted 08-20-2018 03:26 PM

    I have a client with half a dozen LPARs.  Once a week I submit a job on each LPAR to get a full CFILE listing.  I used to submit all the jobs at once, but I was informed recently that because TSS gets a high priority, having six TSS listings running simultaneously is trashing response time for everyone else and I should run them one at a time.

     

    I started doing that, but someone put a bug in my ear:  Would it help if I generate the CFILE from the backup TSS file in each LPAR?  Or is TSS still going to take up too much of the CPU's attention regardless of the source data?

     

    (I'm assuming I can run the CFILE off the backup...)



  • 2.  Re: TSS "priority" when reading the backup dataset

    Broadcom Employee
    Posted 08-20-2018 03:39 PM

    Hi Bob,

     

    In CA Top Secret release 16, if you have fixes RO95454, RO96670, and RO97041 applied, you can run TSSCFILE against the backup file. TSSCFILE with TSS LIST(ACIDS) DATA(ALL) requires a lot of I/O to the security file and overhead in the TSS address space processing the command to list all acids. This enhancement allows you to run TSSCFILE against the TSS backup file in a private address space.  

     

    Best regards,

    Bob Boerum



  • 3.  Re: TSS "priority" when reading the backup dataset

    Posted 08-21-2018 01:50 PM

    Thanks, Bob.  I have an old colleague who saw this question and told me the same thing privately, citing some documentation for PGM=TSSCFBK.  Running off the backup would certainly be preferable.  But not being a systems programmer, I'm don't know whether "in a private address space" addresses my main concern:  Does that mean that six CFILE jobs, each reading a separate backup database, will relieve the high-priority pressure on the CPU?

     

    As it was told to me, TSS gets a high priority from the system so that running the six CFILE jobs together dramatically slows down response time for others.  I infer from this that although each job accesses a separate TSS database (one for each LPAR), all six LPARs use the same CPU(s)—and since TSS has a high priority, everyone suffers.  I fix this by running the six jobs sequentially.  Now, if I use TSSCFBK instead of TSSCFILE, would that cause the six jobs to run with a lower priority, thus enabling me to run them all at once without degrading response time?  Or does the fact that it's still six TSS LIST(ACIDS) mean that the priority assigned to the jobs is still high?  This is not the kind of information I would expect to find in the documentation.

     

    Or is this the kind of question that I must ask the client's sysprog?



  • 4.  Re: TSS "priority" when reading the backup dataset

    Broadcom Employee
    Posted 08-21-2018 03:09 PM

    Hi Bob,

     

    Running CFILE against the backup file eliminates contention for the security file and the security file lock. So other i/o requests for acid signons and command processing run with less contention. This does not reduce CPU usage for CFILE but CFILE may run faster (wall clock time) since it won't contend with i/o requests for the security file.

     

    Running the 6 jobs at the same time shouldn't impact response time for other processes, but they may contend with each other for i/o to the backup file. But they should run better than before because the 6 jobs and other i/o requests were processed on a single queue (prior to using TSSCFBK) and now they issue their requests without queue contention.

     

    Best regards,

    Bob



  • 5.  Re: TSS "priority" when reading the backup dataset

    Posted 08-23-2018 03:26 PM

    Bob, I may have misunderstood you but it sounds like you're still talking about contention for the TSS database, or for the backup.  Since each of the six LPARs has a separate TSS database, and therefore a separate backup as well, there can be no contention for the data no matter which program I run (TSSCFILE or TSSCFBK).  The problem in this case is contention, so to speak, for the attention of the CPU.

     

    I'm told that TSSCFILE has a high priority on the system (which is natural enough), and that when I run all six TSSCFILE jobs at once, one in each LPAR, that high priority leads to dramatically slower response time for other tasks.  So my question is whether the same thing will happen if I run TSSCFBK instead:  Does TSSCFBK get the same high priority, or is it treated just like any normal job? 

     

    But more and more I'm thinking this the sort of thing I must ask our systems programmer.



  • 6.  Re: TSS "priority" when reading the backup dataset

    Posted 08-23-2018 03:45 PM

    Bob, you mentioned the words "address space" in an earlier reply.  I didn't know what that meant, but I remembered them when I phoned my sysprog about this just now and he used the same words.  So I'm went back to your earlier reply, and now I'm thinking that answers my question:  The high priority assigned (for good reason) to TSS will not apply to TSSCFBK...probably.  I can at least try it and see.