Photo courtesy of Kevin Trotman

During CA May Mainframe Madness last month, CA Technologies announced that the next major release of CA Endevor (CA Endevor v15.0) will include a brand new web services feature for no additional cost. Out of the box, CA Endevor web services by itself will not do anything for you. It is not an application. And it’s not an interface for another system.  But none the less, CA Endevor web services will ultimately take CA Endevor and mainframe software change management to the next level.

If CA Endevor web services is not really an application and you can’t see it do anything then how can it take CA Endevor and mainframe software change management to the next level?  The answer is not because of what it isn’t (an application), but because of what it is.  CA Endevor web services is a foundation to allow other applications to communicate to CA Endevor through web-based HTTPS.

THIS IS HUGE. So I will repeat it once more to make sure that you caught it. CA Endevor web services is a foundation to allow other applications to communicate to CA Endevor through web-based HTTPS.

The ability to communicate to CA Endevor via HTTPS creates an opportunity for CA Technologies to build cross-product and cross-platform integration between CA Endevor and other CA Technologies products such as CA Service Desk, CA Clarity, and various CA Application Quality and Testing Tools.  Imagine your problem ticketing system, project management system, and application development testing tools being able to communicate with CA Endevor, both to query or update information and to perform CA Endevor actions. The possibilities seem endless, limited only by our imaginations.

The first product to take advantage of the new CA Endevor web services is the CA Endevor Eclipse plug-in which will also be available with CA Endevor v15 for no additional cost.  The Endevor Eclipse plug-in allows application developers to interact with CA Endevor from the Eclipse software development platform. CA Endevor web services removes the CA Change Manager Enterprise Workbench (CMEW) prerequisite. However, CA Endevor web services does not replace CMEW or the functionality provided by CMEW. So you will still need CMEW if you use CMEW features such as Enterprise Packages.

And you can bet that CA Technologies will be working very diligently to build strong product integrations between CA Endevor and many of their other products.  However, the CA Endevor web services feature is not limited to just CA Technologies. Other software vendors will also be able to build product integrations to CA Endevor for their products if they choose. And if the other software vendors do not choose to build such product integrations, then you will be able to build your own product integrations.

In addition to product integrations, with CA Endevor web services, all software developers (including CA Endevor customers) will be able to build their own custom web-based applications. For example, imagine allowing your business application owners to check test results and approve software changes from a friendly, easy-to-use, visually rich web-based application. Or imagine an iPhone or Android application that would allow your manager to view and approve an Endevor package from their smart phone at a restaurant or ball game. Or maybe you can imagine a web-based “point and click” release management application.

If you haven’t already started dreaming about all the possibilities, then start now. The new CA Endevor web services feature in the upcoming release of CA Endevor v15.0 is a game changer. It will open a world of new opportunities that will take CA Endevor and mainframe software change management to the next level.

Kevin Grimes, Sr. Endevor Consultant

Computer Technology Solutions, Inc.

http://www.kevingrimes.me

Related articles

• The Cloud and the Mainframe: Bringing the Best of Both Worlds Together (java.sys-con.com)

Previously:

• Taming the Jungle of Endevor Processor Groups – Part 1
• Taming the Jungle of Endevor Processor Groups – Part 2
• Taming the Jungle of Endevor Processor Groups – Part 3
• Taming the Jungle of Endevor Processor Groups – Part 4
• Taming the Jungle of Endevor Processor Groups – Part 5
• Taming the Jungle of Endevor Processor Groups – Part 6

CONPARMX Additional Considerations

Photo courtesy of Tim Waters

You may have to add a STEPLIB DD statement to point to the load library where the parm1 program is to be called from.  There is also a PTF available to correct a problem with the STEPLIB concatenation. So if you need to use a STEPLIB for your parm1 program then save yourself some frustration and apply the PTF before you start working on CONPARMX.

A PARMSDEF DD statement is required. This DD is a concatenation of one or more Fixed Block Logical Record Length=80 (FB-80) type PDS or PDS/E datasets from which the CONPARMX utility reads the options members coded in the CONPARMX parameter string. The options members can be located in any of the concatenated datasets but they do not have to exist at all. I highly recommended that you define a new Endevor type for the options member with a source output library that you would include in the PARMSDEF concatenation. And I would also highly recommend that you have Endevor ACM monitor these libraries on the PARMSDEF concatenation using MONITOR=COMPONENTS so that Endevor will automatically relate the options member to the program source member when the program is generated in Endevor.

The PARMS DD statement is only needed if parm8 is set to Y. If used, the PARMS output file should be defined as an FB-80 sequential dataset.

The PARMSMSGS DD statement is not required. However, if coded, the CONPARMX utility program will write the resulting output options string value to this dataset for diagnostic purposes only. The PARMSMSGS dataset is also an FB-80 sequential dataset with a blocksize of 32720. Even though it’s an FB-80 dataset, CONPARMX will write the resulting output options string to the PARMSMSGS dataset at 72 bytes per line until the options string is exhausted. The maxiumun size of the resulting output options string is 512 bytes, so a maximum of 512 bytes of data will be written to the PARMSMSGS dataset.

If you let parm8 default to a value of “N” or if you specify parm8 to have a value of “N”, then you will need to add any additional DD statements required for the program name specified in parm1. For example, if you are calling the IGYCRCTL COBOL compiler then you will need to add the additional DD statements required by the IGYCRCTL program.

The Endevor MAXRC value should be set in your processor according to the parm1 program being called. If the parm1 program is not being called by CONPARMX (ie, parm8 = “Y”), then the MAXRC should be set to 0. And a return code of 0 from CONPARMX indicates successful processing. A CONPARMX return code of 16 indicates an error condition as described in a WTO message. All other CONPARMX return codes are issued by the parm1 program when called. So for example, a CONPARMX return code 4 from the COBOL compiler would indicate a compiler warning.

Now let’s take a look at an example to see how you might setup CONPARMX in your Endevor processors.  (My apologies for the poor formatting in WordPress, but you can also download the following example at: http://www.endevorexperts.net/Endevor/Downloads_files/CONPARMX_example.txt)

//*******************************************************************

//**    COMPILE THE ELEMENT                                        **

//*******************************************************************

//COMPILE  EXEC PGM=CONPARMX,COND=(0,LT),MAXRC=4,

// PARM=(IGYCRCTL,’(&PARMCOBA)’,$$$$DFLT,&C1PRGRP,&C1ELEMENT,

// ‘(&PARMCOBZ)’,'N’,'N’)

//PARMSDEF DD DSN=&PARMLIB,DISP=SHR,MONITOR=COMPONENTS,ALLOC=LMAP

//PARMSMSG DD SYSOUT=*

//SYSIN    DD DSN=&&EXPOUT,DISP=(OLD,PASS)

//SYSLIN   DD DSN=&&SYSLIN,DISP=(,PASS,DELETE),

//            UNIT=&WRKUNIT,SPACE=(TRK,(100,100),RLSE),

//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),

//            FOOTPRNT=CREATE

//SYSUT1   DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))

//SYSUT2   DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))

//SYSUT3   DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))

//SYSUT4   DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))

//SYSUT5   DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))

//SYSUT6   DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))

//SYSUT7   DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))

//SYSPRINT DD DSN=&&COBLIST,DISP=(OLD,PASS)

//*

Here’s an example of a COBOL Generate processor that is setup to use the CONPARMX utility. Let’s start with the DD statements and then I will review the parm statement.

In this example, the PARMSDEF DD points to a parmlib dataset concatenation as indicated by the DSN=&PARMLIB and the processor keyword ALLOC=LMAP.   The parmlib is the source output libraries for the PARM element type that I define to Endevor. Whenever an options member is added to Endevor, it is written to the parmlib source output library where the processors can now access the options members directly from the source output library. Also notice that I have coded a MONITOR=COMPONENTS on the PARMSDEF DD so that Endevor will automatically create the component relationship to the options member.

Next there is a PARMSMSGS DD with the output going to the default output class. This is a good idea when you are setting up and testing the CONPARMX utility in your Endevor processors, but it’s not required.

Then I have all the remaining DD statements required by the COBOL compiler including the SYSIN that points to the output of a previous CONWRITE step, a SYSLIN DD for the output object module, a number of SYSUT DD statements for temporary work datasets, and a SYSPRINT DD for the compile listing.

All of that is pretty easy. Now let’s go back and look at the EXEC statement. You see here that I now execute the CONPARMX utility instead of the actual COBOL compiler. Since a return code 4 from the COBOL compiler is a warning message, I set the MAXRC=4 to indicate that a Return Code 4 Warning from the COBOL compiler is the highest acceptable Return Code for this processor step.

Then I have the PARM statement with 8 positional parm values. Since the parm values are positional, they must be coded in this exact order. If you do not want to supply a parm value for an optional positional parm value then you can just leave that value null and include the comma to separate the null value from the next parm value.

The value of the first parm value or parm1 is IGYCRCTL. That’s the name of the COBOL compiler program name. This is the program name that CONPARMX will call since I set parm8 to a value of “N” (to direct CONPARMX to call the parm1 program and not to build the PARMS output dd).  Also, since parm8 is set to “N”, you notice that I do not need to include the output PARMS DD statement.

The value of parm7 is also “N”. This indicates to CONPARMX to NOT concatenate the options from parms 3, 4, and 5. Working backwards from right to left, CONPARMX will use the element options member specified in parm5 as &C1ELEMENT.  So at processor execution time the CONPARMX utility will attempt to find the element options member with the same member name as the COBOL source element in the PARMSDEF concatenation. If a matching element options member is not found in the parmlib concatenation, then the CONPARMX utility will look for a processor group options member with the same name as the COBOL source element processor group name from the PARMSDEF concatenation. And if no matching processor group options member is found in the parmlib concatenation, then the CONPARMX utility will look for a default options member named $$$$DFLT from the PARMSDEF concatenation.

Endevor will substitute the &PARMCOBA and &PARMCOBZ variables, remove the surrounding parentheses, and then insert the value of the &PARMCOBA variable ahead of any output options string and append the value of the &PARMCOBZ variable to the end of the output options string.

So you can set the &PARMCOBA variable to include any COBOL options that you always want to include in the options string. Since these options appear first in the options string, the application programmer can override one of these options by coding the option in the element options member since the COBOL compiler will ignore the conflicting option specified in the &PARMCOBA variable and use the overriding option from the element options member.  And you can set the &PARMCOBZ variable to include any COBOL options that you always want to enforce in the options string. For example, if you always want to include the LIB compiler option regardless of what the developer may have provided in the element options member then you could set the &PARMCOBZ to include the LIB compiler option and it will override any conflicting NOLIB option that the developer may have set in the element options member.

This is just one example of how you can start using the CONPARMX utility to simplify your Endevor processors and reduce the number of Endevor processor groups in your shop.  I hope that you have enjoyed this series on Endevor processor groups.

If you have any questions about the CONPARMX utility or if you would like some help in setting this up for your Endevor environment, then please visit my website at http://www.endevorexperts.net for more information about engaging Endevor consulting services from my company. I would be happy to help you tame your jungle of Endevor processor groups.

Kevin Grimes, Sr. Endevor Consultant

Computer Technology Solutions, Inc.

http://www.kevingrimes.me

Related articles

• Taming the Jungle of Endevor Processor Groups – Part 1 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 2 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 3 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 4 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 5 (kevingrimes.wordpress.com)

• Taming the Jungle of Endevor Processor Groups – Part 1
• Taming the Jungle of Endevor Processor Groups – Part 2
• Taming the Jungle of Endevor Processor Groups – Part 3
• Taming the Jungle of Endevor Processor Groups – Part 4
• Taming the Jungle of Endevor Processor Groups – Part 5

CONPARMX Positional Parameters

Photo courtesy of Ben Haley

In the previous blog post, I told you about a relatively new Endevor processor utility program called CONPARMX. This utility program is now provided as part of your Endevor base system and it can be used to simplify your Endevor processor and processor group strategy.

The CONPARMX utility supports multi-level option members which can be combined together to reduce the large number of processor groups. The CONPARMX utility simply builds a parm string based on the values in the CONPARMX parm string and the options members. And optionally, the CONPARMX utility can then call another program using the resulting parm string. So basically, the idea is to use CONPARMX in your Endevor processors to dynamically build the parm strings and then call the utility programs such as the COBOL compiler and linkage editor using the resulting parm string.

As I mentioned in the last post, the CONPARMX utility requires 8 positional parameters. Today, I’m going to tell you about each of the parameters. But before reviewing the parameters, let’s begin by looking at a sample options member first:

***************************** Top of Data ************************

ASMA90 = ‘RENT,TERM,XREF(SHORT),USING(MAP,WARN(13)),LIST(133),‘

IGYCRCTL = ‘OBJECT,APOST,AWO,DATA(24),FASTSRT,LIB,FLAG(W),’+

‘RESIDENT,LIST,RENT,TRUNC(BIN),’+

‘NODBCS,SOURCE,MAP,NOSEQ,XREF,NONUMBER,LIST,‘

IEWL = ‘LIST,MAP,RENT,REUS,NOLET,XREF,SIZE=(256K,64K),‘

***************************** Bottom of Data ********************

In the sample options member above, there are 3 records: ASMA90, IGYCRCTL, and IEWL. The options for ASMA90 and IEWL are contained on a single line for each record. But the options for IGYCRCTL span 3 lines. The “+” at the end of the first 2 lines of this record indicate that this record is continued onto another line.

Now let’s take a look at the format of the CONPARMX parameters:

PARM=(parm1,’(parm2)’,parm3,parm4,parm5,’(parm6)’,'parm7′,’parm8′)

1. The first parameter (parm1) is the key used to find the options values within the options member. Therefore, this parameter is required. If the last positional parameter (parm8) is set to: “N”, then the key is also the program name that CONPARMX will execute such as the Assembler name (ASMA90), COBOL compiler name (IGYCRCTL), or IBM Linkage Editor name (IEWL), etc.
2. The second parameter (parm2) is optional. If used, this parameter specifies a literal string or a processor symbolic (for example &PARMCOBA) that is always placed first in the output options string. When used, this parameter must be coded within parentheses. Let’s say by default, you want to use the APOST option for all your COBOL processor groups so you could set parm2 to APOST or use an Endevor symbolic such as &PARMCOBA and then set the &PARMCOBA symbolic to the value of APOST. Then you would not need to code the APOST option in all of your COBOL processor groups.
3. The third parameter (parm3) specifies the default options member name such as the sample options member described above. If parm7 is set to “Y”, then the default options values are added to the resulting output options string after the parm2 options values. But if parm7 is set to “N”, then the default options values are only used if there are no element options member or processor group options member found.
4. The forth parameter (parm4) specifies the processor group options member name. You can create a processor group options member for each processor group. If parm7 is set to “Y”, then the processor group option values are added after the default options in the output options string. So therefore, you only need to code the options that are to be overriden for this processor group in the processor group options member.  On the other hand, if parm7 is set to “N”, then the options from the processor group options member are used only if there is no element options member.
5. The fifth parameter (parm5) specifies the element options member name. You can create an options member for any element in the Endevor inventory. If parm7 is set to “Y”, then the element options values are added to the resulting output options string after the processor group options. So again, only the options that need to be overriden for this specific element should be included in the element options member. However, if parm7 is set to “N”, then the options values from this element options member are added to the resulting output options string.
6. The sixth parameter (parm6) is an optional parameter and is similar to parm2 except the options are added to the end on the resulting parm string instead of the beginning of the parm string.  When used, the value for parm6 must be coded within parentheses. It can be a literal string or an Endevor symbolic such as &PARMCOBB.
7. The seventh parameter (parm7) is also an optional parameter. Parm7 is an indicator used to specify whether to concatenate options values in the resulting output options string or not. Valid values for this indicator are “Y” or “N” and if not coded the default value is “N”.  Basically, this parm lets you choose to concatenation options from parm3, parm4, and parm5 or to use the highest precedence option as described in parms above. Once again, parm2 and parm6 option values are always included in the output options string if coded, and parm3 thru parm5 option values are included between parm2 and parm6 in the output options member.
8. The eighth and final parameter (parm8) is also an optional parameter. It’s an indicator to build an options output file or to call the program specified in parm1. Valid values for parm8 are” “Y or ”N” and if not coded the default value is “N”.  If parm8 is set to “Y”, then the resulting output options string is written to the PARMS DD output statement and the program key specified in parm1 is not executed. You could then use the PARMS output options dataset as input to a subsequent step. NOTE: for the Assembler ASMA90, this option data is read from the ASMAOPT DD statement, and for the COBOL and PL1 compilers, the options should be placed first within the SYSIN DD statement.  On the other hand, when parm8 is set to “N”, the CONPARMX utility will call the program specified in parm1 using the resulting output options string.

Come back next week and I will finish up this discussion of CONPARMX with a few additional considerations.

Kevin Grimes, Sr. Endevor Consultant

Computer Technology Solutions, Inc.

http://www.kevingrimes.me

Related articles

• Taming the Jungle of Endevor Processor Groups – Part 1 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 2 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 3 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 4 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 5 (kevingrimes.wordpress.com)

• Taming the Jungle of Endevor Processor Groups – Part 1
• Taming the Jungle of Endevor Processor Groups – Part 2
• Taming the Jungle of Endevor Processor Groups – Part 3
• Taming the Jungle of Endevor Processor Groups – Part 4

Introducing CONPARMX

Photo courtesy of Alan Kotok

In the earlier discussion of Endevor processor groups, I spoke about how out of control the number of processor groups can get. And I also gave you some ideas for reducing the number of Endevor processor groups using some 3rd party utilities or custom written utilities of your own. Today, I want to introduce you to a relatively new Endevor feature to help you sort through the mess and combat the growing proliferation of Endevor Processor Group definitions.

CONPARMX is a new Endevor Processor utility program available in Endevor r14. It is also available as a PTF for Endevor r12. The PTF number is RO14693. See Technical Bulletin TEC513119 for more information about the CONPARMX utility.

By the way, Endevor r12 will go out of support on November 30 2011. Endevor r14 is the current GA release, but Endevor v15 is in the end stages of customer beta testing. So if you’re still running Endevor r12 or an earlier release, you should really start planning to upgrade to Endevor v15 in the near future.  Watch my blog for more information about some of the great new features available in Endevor v15.

The purpose of the CONPARMX utility is to reduce processor complexity and the number of processor groups. CONPARMX supports varying program options by allowing option members to be included at processor execution time. And CONPARMX also supports multi-level option members at the element level, processor group level and a default level to avoid the need to create and update large numbers of processors or processor groups. And the options members can and should be monitored and tracked as part of an element’s input component list when the Generate processor for the element is executed.

How does CONPARMX utility actually work?

Let’s start by taking a look at a sample Default Options member to give you an idea of what I’m talking about.

Options members contain the options that can be passed by the PARM parameter to the CONPARMX utility. The options members is really just a file of 80-byte records that contain the options for each program key specified. As we can see in this example here, this particular Default options member contains the default options for 3 different processor steps which includes the Assembler ASMA90, the COBOL Compiler IGYCRCTL, and the Binder or Linkage Editor IEWL.

The program name or an options key value must begin in column 1. The options values can be enclosed in single or double quotes, span multiple lines, and end with a comma. A Plus sign or dash at the end of a line indicates that an option value is continued on the next line. Continuation lines can begin in any column. A blank in column 1 is treated as a comment line unless the previous line contains a continuation character. And an asterisk in column 1 always indicates a comment line and is ignored. Single or double quotes can be used to enclose the option member’s options values. If an options value requires single quotes, then you can enclose the value in double quotes.

Since CONPARMX is designed as a processor utility, you modify your Endevor processors to execute the CONPARMX utility instead of the compiler or linkage editor. Then you must pass a series of 8 positional parameters to the CONPARMX utility on the PARM statement to direct how CONPARMX will operate. We will take a look at all 8 positional parameters in more detail in the next blog post.

The CONPARMX utility then produces an output options string from the option values in the option members specified.  Depending on the value specified in the 8^th option position, CONPARMX can directly call the program specified in the first option position using the options string or CONPARMX can write the options string to the output PARMS DD statement that can then be used as input to a subsequent step in the processor.

The CONPARMX limit for the total length of the output options string using all options values coded in parm2 thru parm6 must be less than 512 characters or the limit that is supported by the parm1 program, whichever is less.

Visit my blog next time as I describe all 8 positional CONPARMX parameters in more detail.

Kevin Grimes, Sr. Endevor Consultant

Computer Technology Solutions, Inc.

http://www.kevingrimes.me

Related articles

• Taming the Jungle of Endevor Processor Groups – Part 2 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 1 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 3 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 4 (kevingrimes.wordpress.com)

• Taming the Jungle of Endevor Processor Groups – Part 1
• Taming the Jungle of Endevor Processor Groups – Part 2
• Taming the Jungle of Endevor Processor Groups – Part 3

A better way

Photo courtesy of keepps

In the previous discussion of Endevor processor groups, I’ve spoke about the complex jungle of Endevor processor groups. Many Endevor shops manage Endevor processor groups this way. But as we’ve already seen, this method of cloning and duplicating Endevor processor groups can explode out of hand and create a complex jungle of processor groups.

To address the growing problem of Endevor processor groups, some Endevor shops have created other methods to reduce the number of Endevor processor groups by removing the compile and linkedit options from the processor group.

If we go back to the CA suggested processor naming convention but we eliminate position 7^th & 8^th to remove the compile and linkedit options from the processor group name then the number of processor groups will be a significantly smaller factor of the number of other possible  combinations. For example: COBOL with IMS database and Batch, or COBOL-II with DB2 Database and CICS.

But if we remove compile and linkedit options from the Endevor processor group, then how do we setup Endevor to support multiple compile and linkedit options?

In fact, there are a couple of ways to do this.

For COBOL programs, you can use CBL PROCESS statements to specify the compile options at compilation time. The CBL PROCESS statement is placed before the identification division header of an outermost program. The COBOL compile options cannot be continued across multiple CBL PROCESS statements, but you can use more than one CBL PROCESS statement. If you use multiple CBL PROCESS statements, then they must follow one after another with no intervening statements of any other type. The CBL PROCESS statement must be placed before any comment lines or other compiler-directing statements.

The programmer could code the CBL PROCESS statements directly in the COBOL source code that is stored in Endevor. Or the programmer could code the CBL PROCESS statements in a separate element type like COBPARM for example. Then the Endevor Administrator could code the Endevor Generate processor in such a manner that the processor could get the compile options stored in Endevor and concatenate the options to the front of the source code which the processor also gets from Endevor.

Another common method to eliminate compile options from the processor group is to purchase and implement a 3^rd party product such as ISCPASS from Intracoastal Software, EDVPARM from Nexio, or CTSPARM which I wrote myself.  Or you could simply write your own processor utility.  The way that these types of utilities work is that you modify your processors to execute the utility program and then the utility program gets the compile options and calls the specified compiler using the compile options retrieved from a parameter table, Endevor element, pds, or other such file that provides the compile options. On a side note, I’ve also developed another utility called CTSBIND to simplify your DB2 bind process using a similar type of parameter file. Although I no longer offer the CTSPARM product, please send me an email if you would like more information about CTSBIND to improve and simplify your DB2 bind process.

Of course the downside to processor utilities like ISCPASS, EDVPARM, and CTSPARM is that you need to pay for a software license and ongoing maintenance fees to purchase and implement these utilities in your Endevor processors.  So there’s an initial cost and some recurring costs to this type of solution. And with budgets already stretched very thin, then it can be difficult to justify spending your limited financial resources on this type of solution.

On the other hand, with some knowledge, time, and patience you could write your own processor utility and save yourself some money, but the downside to writing your own utility is that you alone are responsible for maintaining and supporting your own utility.  And these days with cutbacks and staff reductions, who has the time and expertise to write, test, maintain, and support a custom solution like this.

The great news is now you don’t have too do either. Custom in-house developed solutions and 3^rd party utilities like these are now obsolete because CA Technologies now provides another solution. Come back next week and I will tell you more about this relatively new Endevor processor utility provided by CA Technologies.

Kevin Grimes, Sr. Endevor Consultant

Computer Technology Solutions, Inc.

http://www.kevingrimes.me

Related articles

• Taming the Jungle of Endevor Processor Groups – Part 1 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 2 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 3 (kevingrimes.wordpress.com)

• Taming the Jungle of Endevor Processor Groups – Part 1
• Taming the Jungle of Endevor Processor Groups – Part 2

How did this explosion happen?

Photo courtesy of Husein Kadribegic

In the first two parts of this series focused on Endevor Processor Groups, I’ve spoke about how complex Endevor Processor Groups can get. Many Endevor shops have way to many Endevor Processor Groups and this makes it very difficult for your Application Developers to select the correct Endevor Processor Group.  But how could this explosion of Endevor processor groups happen?  Well, it all starts so innocently. No one intends to create a jungle. It just happens. Every time your shop gets a new development tool, or testing environment, DB2 subsystem, or CICS region, or when you need some new compile or linkedit options – then the number of processor groups can grow exponentially.

Say you have only 9 COBOL processor groups, but you need a new set of COBOL compile options, what do you do? Clone your existing 9 processor groups and now you’ve got 18 processor groups. Need some a new linkedit options, and the 18 processor groups becomes 36 processor groups. Add another new testing or development tool and your 36 processor groups become 72 processor groups. Need to support a new DB2 subsystem or CICS region and the 72 processor groups can quickly grow to over 100 processor groups. So you can see that this method of duplication and cloning processor groups can quickly grow out of control.

Another way to help identify processor groups is to implement a Processor Group naming convention. Processor Group names are limited to 8-characters. Not much room to work with, but you should implement a processor group naming standard where the name of the processor group helps to identify what the processor group is used for.  Say for example, the first 3 characters of the processor group name could identify which version of the COBOL compiler to use, and the 4th position of the processor group name could identify the database such as DB2, IMS, or IDMS, the 5th position of the processor group name could identify the operating environment such as batch or CICS, and the 6th position could identify the output library type such as pds, load, or listing.  In fact, this the very processor group naming convention as suggested in the CA Endevor Extended Processor Guide.  Even though there needs to be some organization and there is some logic in the processor group naming convention, processor group names are often cryptic to the Application Developers who are not Endevor experts. COBNBL08 – what in the world does that mean to an Application Developer? Even following the suggested CA naming convention, how’s anyone supposed to know the difference between COBNBL15 and COBNBL23?

There has to be a better way to manage Endevor Processor Groups.  Come back week and I will continue this discussion of Endevor Processor Groups.

Kevin Grimes, Sr. Endevor Consultant

Computer Technology Solutions, Inc.

http://www.kevingrimes.me

Related articles

• Taming the Jungle of Endevor Processor Groups – Part 1 (kevingrimes.wordpress.com)
• Taming the Jungle of Endevor Processor Groups – Part 2 (kevingrimes.wordpress.com)

• Taming the Jungle of Endevor Processor Groups – Part 1

It’s a jungle out there

Photo courtesy of Caneadea

As I mentioned in my blog post last week, if you’ve ever been intimately involved in managing and administering Endevor Processor Groups, then you already know how ridiculously complicated Endevor Processor groups can get.  It’s a jungle out there.

I was once in one shop a few years back that actually had over 500 processor groups. And it’s very common that I find Endevor shops with over 100 processor groups for a single COBOL type.  How in the world can anyone actually memorize 500 different processor groups, or for that mater, even 100 different processor groups? How in the world? It’s nearly impossible. And figuring out which processor group to use can get pretty complicated for anyone, not to mention for an Application Developer whose job it is to write, maintain, and support computer programs; not someone who is an Endevor Administration expert.

So how can you tell the difference between one processor group and another processor group? And when you’ve got hundreds of processor groups to choose from, how do your Application Developers know which Processor Group to use when they add a new program to Endevor?

Well, there’s a couple of ways. But none of them seem very ideal.

If your programmers are like many programmers I’ve seen, then they may have a tendency to just find a program that’s similar to what they want to develop. Why reinvent the wheel? Right. Just find something close and then clone it. But what if they don’t know what processor group top use? Well same thing, they will probably just use the same processor group as another program they already use.

It’s also rather common to find that new programmers in a shop will often ask an old-timer who’s been around for a while. The old-timer might even have a “cheat-sheet” that they will share with the new kid on the block. So the new programmer really doesn’t know what processor group to use, they just know that this is what someone else told them to use. But that information may or may not be correct for this situation. Then you have a snowball effect. No one knows why it’s done this way, but this is the way we always do it. Ever heard that one before?

Maybe teaching the programmers how to display and select a processor group is a better way. As an Endevor Administrator, you can create or update the Description for every processor group; so you can use the Processor Group Description field to help identify the Processor Group. Well that doesn’t sound so bad does it?  Unfortunately, the size of the processor group description field is limited to 50-characters and it can be pretty difficult to identify all the characteristics of each processor group in just 50-bytes.

Is this processor group for COBOL II or Enterprise COBOL? Is it CICS or Batch? Is it both? How about DB2, and if so which DB2 subsystem? How about MQ Series? Xpediter? IDMS? IMS? Sapiens? Or any one of a large number of other development tools that are supposed to make the programmer’s life easier? And even if it’s as simple as selecting the right processor group for Batch COBOL, how does the programmer know which processor group is for DATA(24) vs DATA(31), or APOST vs QUOTE, or AMODE(24), or to INCLUDE certain vendor application libraries in the Link-Edit? It seems like the list goes on and on.

How can Endevor Processor Groups get so out of hand? How does this happen? Visit my blog later this week as I continue this discussion of Endevor Processor Groups.

Related articles

• Taming the Jungle of Endevor Processor Groups – Part 1 (kevingrimes.wordpress.com)

Photo Courtesy of Accretion Disc

Lost in a jungle of Endevor Processor Groups

Are your mainframe application developers lost in a complex and bewildering jungle of CA Endevor processor groups?  If so, now you can tame the jungle and bring back some sanity and order with a relatively new Endevor utility.  And the best part is – the new utility is absolutely free with your current Endevor maintenance and support agreement from CA Technologies, so there is no need to buy a 3^rd party  product and there’s no need to write your own utility.

If you already bought another 3^rd party product, now you can consider decommissioning that product, stop paying maintenance and save your company some money today. If you’ve already written your own utility, then save yourself some time, energy, and hassle and stop worrying about maintaining your own program and having to update or re-test your utility every time you upgrade Endevor.

If you’ve ever been intimately involved in managing and administering Endevor Processor Groups in your shop, then you know how ridiculously complicated processor groups can get. Over the last 19 years, I’ve seen so many ways to manage Endevor Processor Groups. But now there’s a better way. Now you can tame the jungle of Endevor processor groups and replace your customized and unsupported methods and your 3^rd party add-on products with a CA Technologies provided solution that is fully supported by CA and maybe even save your company some money in the process – and saving money is good for everyone.

So how bad is the problem of Endevor processor groups?  Come back next week and I will continue this discussion of Endevor Processor Groups.

Kevin Grimes, Sr. Endevor Consultant

Computer Technology Solutions, Inc.

http://www.kevingrimes.me

Related articles

• Taming the Jungle of Endevor Processor Groups – Part 2 (kevingrimes.wordpress.com)

Happy Birthday MyCA

I fondly remember celebrating each of my 3 children’s 1st birthday even 15, 16 and 18 years later because each was such a very special day. The family gathered around the kitchen table and celebrated the special occasion with a birthday cake and ice cream. It was such a joy to share the special day with our extended family and our closest and most beloved friends. We celebrated with loved ones because we wanted to share our joy and commemorate an important milestone in our children’s lives.

Today, MyCA marks a very important milestone. Today, MyCA is one year old. And today, CA Technologies shared the special occasion with the CA Community Advisory Council.   Congratulations to the entire @CA_Community on reaching this significant milestone. And special kudos to JJ Lovett (@lovettjj) for leading the CA Community in such a positive way.

One year ago today, CA Technologies officially launched the all new MyCA online community portal with much fanfare at the CA World 2010 conference in Las Vegas.  The new MyCA online community has been a great leap forward from the earlier system. I remember the excitement I had when I first learned about MyCA in the pre-announcement meeting for CA Community leaders at the CA Regional Exchange (CARE) conference on May 15th 2010.

With the launch of MyCA, CA Technologies clearly demonstrated a renewed interest and commitment in supporting the CA user community. Even though I wasn’t familiar with the underlying technology, I was very excited about the launch of MyCA. As president of the CA Endevor Global User Community, I saw that MyCA was going to allow me and other CA Community leaders to have better control in configuring and managing our online communities.

Over the past 12 months, CA Technologies has introduced a number of improvements to MyCA. And they continue to enhance the system with new features and more integration. Very soon, CA online support will also move over to MyCA providing a better online support experience allowing users to search the support knowledge base and open, view, and update support cases from within MyCA.

Look at you MyCA, you’re already one year old and you are growing so fast. Happy Birthday.

• Who am I?
• Why have I decided to start this blog?
• What will I be blogging about?
• How you can contact me or provide feedback about this blog?

1. Who am I?

My name is Kevin Grimes, founder and President of Computer Technology Solutions, Inc. I am an Endevor Consultant, CA Endevor Global User Community President, Change Agent, Expert, Project Manager, Leader, Influencer, Problem Solver, Mentor, Business Technologist, Mainframe Evangelist, Social Media Advocate, Speaker, and now blogger.

I am a mainframe expert with advanced technical knowledge in the use and configuration of CA Endevor Software Change Manager. I am also a prominent leader in the Endevor user group community; currently serving as President of the CA Endevor Global User Community, the International User Group for Endevor (INUGE), and the Southeastern User Group for Enterprise (SUGE).

I work with many Fortune 500 companies and government agencies nationwide to implement mainframe software change management systems based on ITIL and industry best practices. I have converted thousands of mainframe application systems to CA Endevor from other source management systems.

2. Why have I decided to start this blog?

I have a great passion for CA Endevor, software change management, and the Endevor user community.  I want to share my knowledge, experience, and opinions, serve my community, and help others to overcome some of the challenges that I have already learned how to overcome.

Endevor is the leading mainframe software change management system today and has been for many many years. But Endevor is much more than just a software change management system. It is a large, complex, and very power mainframe system software product that manages mainframe source code and provides version control, software configuration management, build and output management, inventory control, release management, and code deployment. While Endevor is very easy to learn and use, it can take years to truly master the product and become an Endevor expert.

The CA Endevor Global User Community is an online virtual community of Endevor users from around the globe. We are an open community and we encourage all Endevor users to join us on “MyCA”. Membership is Free and you do not need to provide a CA site ID to join our community.  Visit our online community and join us today athttps://communities.ca.com/web/ca-endevor-global-user-community.

The Endevor user community can also be found on Facebook (http://www.facebook.com/EndevorGUC), LinkedIn (http://www.linkedin.com/groups/Endevor-Global-User-Community-3300220), Twitter (http://twitter.com/EndevorUG), and YouTube (http://www.youtube.com/user/EndevorUG). So I invite you to follow us on our social media outposts and I encourage you to get involved in our user community.

While our MyCA home base and our social media outposts all provide some very good information and great opportunities to network and interact with other members of our community, this blog gives me the opportunity to share my voice and my experience with the whole world.

3. What I will be blogging about?

This blog will focus on sharing technical “how-to” information, news and announcements, best practices, comments, opinions, and suggestions related to CA Endevor or the Endevor user community, change management, project management, leadership, technology, social media, consulting, or any one of the many other hats I wear.

4. How can you contact me or provide feedback about this blog?

I sincerely hope that you find this blog useful and informative. I encourage you to follow along and subscribe to my blog. I also welcome and encourage your feedback – even if you disagree with something that I may say. So please feel free to comment on any blog post. I just ask that you be professional in your critique.

I invite you to visit http://www.kevingrimes.me for more information about me, to send me an email or connect with me on LinkedIn, Facebook, and Twitter.

I hope that you will enjoy my blog.

Best wishes,

Kevin