Endevor dropping new compile proc group & keeping current compile group at the target location.

[James Catalano]

During source promotion a good majority of the time we use the TRANSFER action versus the MOVE action.  I do understand the difference and "Yes" a smack on the hand for letting this occur, but this works very well for our shop when used with care.  Here's my issue and question.  Enterprise COBOL v5 is now off support and we have been converting to COBOL V6.2.  We only compile at the stage-1 entry point and the element is frozen when promoting forward.  When using the TRANSFER action, I need to have Endevor keep the "from/source" new compile processor group and not drop it to keep the current compile processor group at the target location..?

I am aware of placing the new compile PROC GROUP 'name' within the source promotion package SCL, but trying to spread this message out to many different development groups across the world is a major task.  I have COBOL v6 compiled loads sitting in Production and still showing COBOL v5 compile processor groups on the source elements. This is a reporting/conversion issue.  Would it be possible to have an option within the Endevor ENCOPTBL that would keep the compile processor group that is being promoted with the source element.  Or possibly even a "Yes" or "No"
switch for keeping the processor group name within the Endevor ENDICNFG member.  Appreciate any information to assist with this.  Thanks for your time.

[Russ Gunter]

Just wondering.

 

Why cant the processor group be the same name at both locations but point to a different processor or have a symbolic that can be overridden to indicate the differences in COMPILERS?

 

 

Russ Gunter

CA Broadcom Consultant

Internal Revenue Service

Cell: [phone]

(TOD) Mon –  Fri  7:45 AM - 4:15 PM Eastern

 

"Never forget, 'Some gave all, All gave some'"

"It is amazing what you can accomplish if you do not care who gets the credit", Harry S. Truman

 

Planned days away, 6/17 &18

 

[John Dueckman]

I need a little more detail about how you are doing your TRANSFERs because my spidey-sense is tingling.....

My assumption based on your description is that the V6.2 processor group has a different name than the V5 processor group.

Bear with me while I document my thinking.... 

When one sets up TYPE definitions, you tell Endevor which processor group to use during the TRANSFER action; the MOVE processor defined at the source stage or the GENERATE processor at the target stage. The DEFAULT setting for TYPE definition is to set the value to "G" (GENERATE). So the first question is: Did you change this to "M" (MOVE)? If its left as G, then the processor group defined for the element at the "to/source" would be used maybe causing your problem?

In addition, some "clever" sites change the GENERATE processor defined to processor groups at upper stages to NOT do an actual GENERATE but instead execute the MOVE processor defined in the GENERATE processor slot. Conceivably, this could then MOVE the element without changing the TYPE definition for actions during TRANSFER whereby the MOVE processor defined at the target stage would be executed.... so Endevor would THINK its doing a GENERATE, use the processor group previously defined, but just MOVE the element. While seeming clever, this kind of solution causes my eyes to bleed....

Bottom-line: Look at what is actually happening during the TRANSFER. I believe what you want is the MOVE processor to work properly and be executed during TRANSFER; that should preserve any change to processor group defined to element at lower stage(s).

------------------------------
Consultant
John D Consulting Inc.
------------------------------

[James Catalano]

Hi John, great hearing from you.  I hope all is going well.  Yes - the COBOL v5 processors are different names from the COBOL v6 processors.  Within each processor group name whether it being COBOL v4.2, v5.2, or v6.2 we only execute (one GENERATE PROCESSOR = GCOB), (one DELETE PROCESSOR = DELETE), and (one MOVE PROCESSOR = MOVE).  Very easy on maintenance with updates and coded nicely for viewing.

Within each "Processor Group Definition" under OUTPUT MANAGEMENT INFORMATION, I have PROCESSOR to use for MOVE = M for the MOVE PROCESSOR, and Processor to use for TRANSFER = M for the MOVE PROCESSOR.  We only "generate/compile" program types at the stage-1 entry point and the "executable/load" is frozen promoting forward up the Endevor map.  This ensures while testing in the two previous environments, that is what you get when hitting Prod.   

As an example when source element "program-A" working it's way up the Endevor map that was recompiled with v6 CO6B and hits the final resting point in Prod where "program-A" contains Processor group v5 CO5B, the CO6B gets dropped and keeps the target location.  We have a v6 load stating a v5 Processor group. I do know this can be avoided by placing the PROC GROUP 'name' in the package SCL for each program, but you know how that goes.

We do clean up in the "From/Source" stage after successfully hitting the target location.  Once again, I appreciate your time and great to hear from you.  I look forward to hearing back. 

Thanks

[John Dueckman]

Hi James! 

Hmmmm.... something does seem funny here. So to state your issue again, program-A exists in the production stage with processor group CO5B. It is added/updated/generated in stage 1 with processor group CO6B. 

You then execute a TRANSFER ELEMENT PROGRAM-A FROM ENV blah blah TO ENV blah blah (no processor group specified in the OPTIONS). Your setup indicates TRANSFER is to use the MOVE processor. You bypass generate at the target stage. 

You execute the command and Endevor does NOT change the processor group at the target stage.

So... i just tried the above scenario on one of our instances and what do you know? I got the same result as what you're reporting! 

To ME, this looks like a bug or at the very least an explanation needs to be provided by CA-Broadcom....


------------------------------
Consultant
John D Consulting Inc.
------------------------------

[John Dueckman]

I just tried an additional test in terms of regenerating the element after doing the above to see if Endevor truly did retain the original processor group... and it does.... so don't do that unless you want to undo all the changes you did at the lower stage! 

I think your scenario REALLY needs an explanation from CA-Broadcom....

------------------------------
Consultant
John D Consulting Inc.
------------------------------

[Roberta Jones]

Jim & Mr. Dueckman 

I am going to open a case under Jim's site-id and test the scenario and do further research. I will keep everyone posted on the findings. 

Roberta 
Broadcom Endevor Support

------------------------------
Technical Support Engineer 4
Broadcom
------------------------------

[Karen Turner]

Hey Jim ..

Have you consulted the tables at the back of the user  guide?  Transfer Elements Action (Using a Move Processor) and Processor Groups.  I'm not sure which combination fits your situation.  Also, curious question #2  - since you are only compiling once are you skipping IBM's "debugging" options in your development stage and only using the "production" options?  opt(0) vs opt(2) etc ...​ interested in how you are handling the differences.

KT

[Russ Gunter]

Hello Karen, I hope you are well and safe

 

You need to revisit the 18.1 guide.

 

The Transfer Elements Action (Using a Move Processor) and Processor Groups is in the middle around page 1500 of a 2500 page doc.

 

 

Russ Gunter

CA Broadcom Consultant

Internal Revenue Service

Cell: [phone]

(TOD) Mon –  Fri  7:45 AM - 4:15 PM Eastern

 

"Never forget, 'Some gave all, All gave some'"

"It is amazing what you can accomplish if you do not care who gets the credit", Harry S. Truman

 

Planned days away, 6/17 &18

 

[James Catalano]

Hi Karen, also great to hear from you..!!  I hope you are doing well.  We use Xpediter as a debugging tool.  I give development the option to pick what flavor of compile processor they would like to use at the stage-1 entry point.  During our conversion of the IBM Enterprise COBOL v4.2 to v5.2 the Optimization of OPT(2) woke up our development teams when trying to debug. This one did caught us by surprise, but made sense.  When debugging there was nothing like seeing your code jump around like it was in a pin-ball machine.  One option I used was If debugging a program was required, development could use a CBL statement of OPT(0) to debug, and then when satisfied remove it & recompile picking up the default of OPT(2).  We definitely wanted the OPT(2) for performance as walking up the Endevor map.  There was also a compile PARM option that could assist TEST(NOEJPD,NOSOURCE).  

I have an Xpediter DDIO source listing file at each location of Endevor.  When source promotion is invoked the Xped DDIO listing created at compile time will follow the source, load, and compile listing to the next Endevor location.  This assists the development teams that are using the Xpediter code coverage with debugging and comparing previous Xped listings.  

When you are at the point of using v6 and using OPT(2), I highly recommend using the ARCH(12) feature if possible, but a note that it does require to have an IBM z14 processor on each LPAR.  IBM has done some wonderful things in COBOL v6 using the ARCH(12) option and utilizing the hardware.  If you are not at the IBM z14 processor option ARCH(10) also provides nice performance. 

I hope this helps and have a great weekend.