Endevor

CAP has been running in Production in our shop for a number of years now.  We implemented almost as soon as CAP was introduced.  Use of the GLBLTYP sequencing saved us many problems.  With improvements in GLBLTYP processing included in Release 16, we plan to leverage the use of CAP even more.  The biggest drawback to using CAP has been the serialization of types within the GLBLTYP sequencing.  That issue appears to be addressed with the R16 enhancements, which we are exploring now.

roger.howard:

CAP has been running in Production in our shop for a number of years now.  We implemented almost as soon as CAP was introduced.  Use of the GLBLTYP sequencing saved us many problems.  With improvements in GLBLTYP processing included in Release 16, we plan to leverage the use of CAP even more.  The biggest drawback to using CAP has been the serialization of types within the GLBLTYP sequencing.  That issue appears to be addressed with the R16 enhancements, which we are exploring now.

Thanks Roger: What SPAWN CNT do you use ? Are you a big Endevor shop ? Do you use Packages ?
 

Grant, we have "8" specified as our default Spawn Count.  Our testing has shown that number works best within our environment.  (We are a very large Endevor shop :) and use packages heavily.)

Yes, we a fairly large Endevor shop.  We have 5 mapped environments, 1 emergency environment, and 1 environment we use for various activities such as Proof of Concept activities.  We currently use a SPAWN count of 10.  Nothing moves into any Stage 2 in any environment unless a package is involved.  We process packages with as few as 1 element and as many as 25000 elements, depending on the activity in the system involved.  We have 110+ systems defined with multiple subsystems under most of those.  We currently have apporximately 250 active processors in our environment.  We are also a heavily customized API shop, using API programs to do a multitude of tasks, including determining whether or not a production package fails of runs successfully.  The use of cap allowed us to remove an arbitrary element limit of 250 elements in a package, which we had enforces to allow fro prompt execution of packages.  Now, we don't worry about how many elements a package contains, other than to be aware when exceptionally large packages are executed.  We are looking forward to being able to exploit the new features for the GLBLTYP sequencing process.

Hi Roger:

Are you going to be taking taking advantage of the CATEGORY field in the Global Type Sequncing file for CAP processing for Endevor R16.0 ? If so, what is one of your typical scenarios ?

Cheers

Grant

We already have defined our categories and tested in R16.  Because of the nature of some of our vendor products, we have several type definitions for input  contorl cards.  Combining these into one category allows multiple types to move at once.  Anothe instance in our environment is that we receive load only modules from some vendors.  Along with load modules generated from our Assembler and COBOL programs, we have a number of types defined which are all basically just load modules.  Combining all of these types into one category has gained us some significant throughput.  If you take a wider view, in our environment, we only generate in Stage 1 of our entry environments.  In that type of scenario, we can move control card members, and copybooks at the same time, which we are now doing with the CATEGORY option.  We have separate PDSEs for Contol cards, and copybooks, so we haven't seen any contention issues that were significant.  We are also able to mix the movement of DBRM elements in with the copy member/contol card elements.  Almost anything that generates a load module can be put into our LOAD category.  Sequesncing within the GLBLTYP definitions (which we have been refining over the years) simplifies the process for us.  Every environment is different, but this seems to be working for us with no issues at this time.

Hi Grant,

your CAP tests show that you gain a factor 4 in throughput. 4 times 45 minutes equals to 3 hours, while with 8 concurrent STCs you would probably hope for a gain of a factor close to 8.

It might be an indication that your STCs are waiting on each other when in contention for data sets.

If you're not already running RLS or LSERV, you should try to get either implemented and probably see greater throughput. If you  already have RLS or LSERV implemented then you may want to run some tests with a LOWER number of concurrent STCs, like 4-6 as it serves no purpose to put on more requestors on a system that's too heavily loaded with work or trying to handle contentions.

Jan

BTW, As far as packages or non-packages are concerned:

CAP makes no difference in handling either of them. The only factor that matters is that there should be more than a handful of Endevor actions in a single jobstep for CAP to offer benefits. That will usually be within a package indeed, but I would not want to leave the impression that CAP is beneficial for packages only.