Published on CMCrossroads (https://www.cmcrossroads.com)

Home > With Endeavor, is there a way to alter the "processor output type" in the definition of the processor group of a new type?
CZerfas's picture

With Endeavor, is there a way to alter the "processor output type" in the definition of the processor group of a new type?

CZerfas asked on June 22, 2011 - 9:51am | Replies (4).

I recently cloned an existing ENDEVOR type JCL and created a new type PJCL. Except the name of the type and the description I changed nothing in the DEFINE SCL statements.

Now both types seem to share the same "processor group output type", since I didn't changed that literal while defining the new type. This is a pity because it shall be possible, that elements with the same name exist in both types. Of course both types have different source and delta libraries.

My question is: Except with deleting and defining the new type again (which would be cruel since already elements are stored under this new type PJCL), is there a way to alter the "processor output type" in the definition of the processor group of that new type?

This is probably a simple or silly question, but though I administer ENDEVOR for a couple of years now, I never ran into something similar.

kind regards
Christian

grc's picture
grc replied on June 27, 2011 - 2:56am.

Ah yes, this is why we have one type "JCL" with two processor groups for that type. This ensures that the user must select between one or the other.

I am not seeing the problem though if you have the two types set with the same O/P LIBRARY value.

BTW, what I meant was that the value in the O/P LIBRARY TYPE (see the processor group display panel.. ) - which can be used to prevent elements of the same name being registered across types.

And yes, if it is set in Prod then look forward to doing a a transfer so that there is no reference to the unwanted processor group - watch out that the delete processor is run as part of the TRANSFER - which can result of Production output library objects being deleted.

However, if you don't have a processor for this type then having TYPE JCL + Processor Group JCL and then TYPE PJCL + Processor Group JCL isn't such a bad situation. It just doesn't line up :)

Our local rule here is that the Processor Group and the Type are the same unless the Type has multiple processor groups.
One day I will have the system configurations fixed to make this true :-)

If your only problem is that the processor group of type PJCL does not match the name of the type.. then ask yourself if it is worth fixing it. Out system has several cases where the Type and PG don't match. Luckily, few of these types are referenced by a processor, and where they do the processor uses the type name for determining processing controls.

CZerfas's picture
CZerfas replied on June 27, 2011 - 1:59am.

Hi grc,

well, the problem I have is, that I can't have elements with the same name in both types. I don't use source output libraries for these types; if needed, the base libraries are accessed.

Your statements concerning the idea to alter type definitions are what I have feared.

many thanks for your time
Christian

grc's picture
grc replied on June 26, 2011 - 11:32pm.

In addition; we have found that using processor groups for this purpose is better than adding new types. Otherwise, we would have over 60 'COBOL' types.

Makes creating and maintaining processors easier as well. YMMV.

grc's picture
grc replied on June 26, 2011 - 11:27pm.

Hi Christian,

Your question is slightly confusing.. What problems are you experiencing?

There should not not be any reason why two types can't share the same PROCESSOR O/P TYPE definition?

All this means is that if you have you can use the ENCOPTBL flags to prevent duplicate elements across types / systems / subsystems.

The standard we have is that the PROCESSOR O/P TYPE is always set to be the same as the output source library name. So, if type types - eg COBOL and ASM - write to SRCLIB then no two elements can have the same name across systems.

Changing the type definition.. well, as long as you have no elements registered you can do a BUILD SCL FOR TYPE PJCL ; modify the value PROCESSOR OUTPUT TYPE "PJCL" ; save the SCL ; apply the SCL with a batch job. Or, if your site is really progressive: Retrieve the Config element from your ADMN or CONF or CNTL environment ; make the config change ; add the element back in ; promote the element.

If your question is 'can this be changed in place' then I believe that the answer is no. The elements need to be transferred or deleted first.

We had a similar program with some ancient COBOL programs in PRD with the wrong (and very invalid) processor group. Our solution was: 1) Backup all libraries involved and execute element unload for affected elements ; 2) Create new COBOL processor group ; 3) Transfer the elements in place (with no output library delete behind) 4) Delete the old (invalid) processor group.

Wash, rinse, repeat for a few hundred elements in Production. Try to ignore the user's screams of agony and pain when this had to be done to ACM linked elements (Copybooks mostly).

4 Answers

grc's picture
grc replied on June 26, 2011 - 11:27pm.

Hi Christian,

Your question is slightly confusing.. What problems are you experiencing?

There should not not be any reason why two types can't share the same PROCESSOR O/P TYPE definition?

All this means is that if you have you can use the ENCOPTBL flags to prevent duplicate elements across types / systems / subsystems.

The standard we have is that the PROCESSOR O/P TYPE is always set to be the same as the output source library name. So, if type types - eg COBOL and ASM - write to SRCLIB then no two elements can have the same name across systems.

Changing the type definition.. well, as long as you have no elements registered you can do a BUILD SCL FOR TYPE PJCL ; modify the value PROCESSOR OUTPUT TYPE "PJCL" ; save the SCL ; apply the SCL with a batch job. Or, if your site is really progressive: Retrieve the Config element from your ADMN or CONF or CNTL environment ; make the config change ; add the element back in ; promote the element.

If your question is 'can this be changed in place' then I believe that the answer is no. The elements need to be transferred or deleted first.

We had a similar program with some ancient COBOL programs in PRD with the wrong (and very invalid) processor group. Our solution was: 1) Backup all libraries involved and execute element unload for affected elements ; 2) Create new COBOL processor group ; 3) Transfer the elements in place (with no output library delete behind) 4) Delete the old (invalid) processor group.

Wash, rinse, repeat for a few hundred elements in Production. Try to ignore the user's screams of agony and pain when this had to be done to ACM linked elements (Copybooks mostly).

grc's picture
grc replied on June 26, 2011 - 11:32pm.

In addition; we have found that using processor groups for this purpose is better than adding new types. Otherwise, we would have over 60 'COBOL' types.

Makes creating and maintaining processors easier as well. YMMV.

CZerfas's picture
CZerfas replied on June 27, 2011 - 1:59am.

Hi grc,

well, the problem I have is, that I can't have elements with the same name in both types. I don't use source output libraries for these types; if needed, the base libraries are accessed.

Your statements concerning the idea to alter type definitions are what I have feared.

many thanks for your time
Christian

grc's picture
grc replied on June 27, 2011 - 2:56am.

Ah yes, this is why we have one type "JCL" with two processor groups for that type. This ensures that the user must select between one or the other.

I am not seeing the problem though if you have the two types set with the same O/P LIBRARY value.

BTW, what I meant was that the value in the O/P LIBRARY TYPE (see the processor group display panel.. ) - which can be used to prevent elements of the same name being registered across types.

And yes, if it is set in Prod then look forward to doing a a transfer so that there is no reference to the unwanted processor group - watch out that the delete processor is run as part of the TRANSFER - which can result of Production output library objects being deleted.

However, if you don't have a processor for this type then having TYPE JCL + Processor Group JCL and then TYPE PJCL + Processor Group JCL isn't such a bad situation. It just doesn't line up :)

Our local rule here is that the Processor Group and the Type are the same unless the Type has multiple processor groups.
One day I will have the system configurations fixed to make this true :-)

If your only problem is that the processor group of type PJCL does not match the name of the type.. then ask yourself if it is worth fixing it. Out system has several cases where the Type and PG don't match. Luckily, few of these types are referenced by a processor, and where they do the processor uses the type name for determining processing controls.
©2011-2013 TechWell Corp.