Endevor Processor tracing?

[Steve Blackett]

Background:

I am setting up a sandbox set of environments on a separate Mainframe to mirror our development ones and have replicated this by performing full unloads and reloads.

I have then created a shed load of output datasets eg loadlibraries/copybooks/listing libraries etc, I did think this could have been an issue as some were defined incorrectly originally but all corrected now.

 

Problem:

My Generate for a COBOL program is failing but I only get:

The program name banner (compile options and then the error without a line number or any of the actual code)
        IGYLI0050-U   An input/output error occurred while reading a library member.  The compilation was terminated.

I presume the processor is failing but its complex and I'm unsure where to start looking.
 

What I tried:

I already have a differently named environment on this instance of Endevor that the same program compiles into (so its not the code)

Checked the processor is the same / same group and symbolics the same as the environment where it works

Checked all my input datasets (for correct definitions)

 

Looking for any advice or is there a processor trace?

AI said this - it's so funny :)

------------------------------
Mainframe DevOps
HSBC
United Kingdom
------------------------------

[Bernard Beriau]

//EN$TRAL0 DD DUMMY
//EN$TRPRO DD SYSOUT=*
//EN$TRPRG DD SYSOUT=*


Bernie Beriau
Principal Mainframe Software Engineer
Broadcom CA/Endevor SCM Administrator
Broadcom Inc.
[e-mail]
+1.781.313.3566 - Office (Internal x33566)
+1.508.472.3286 - Mobile

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

[Attila Fogarasi]

If the processor trace doesn't clear it up, another possibility is use of
the Cobol compiler option COPYLOC pointing to the wrong USS path or PDS ...
the lack of other messages suggests security error in access rights to the
copybook.

Attila Fogarasi

Senior Technical Architect | Mainframe Software


[phone] | [e-mail]

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

[Joseph Walther]

The message saying ....

        IGYLI0050-U   An input/output error occurred while reading a library member.  The compilation was terminated.

looks to me like an IBM COBOL compiler message and error. 

You might look at the SYSLIB concatenation, and ensure that the first library in the concatenation has the largest blocksize, compared to the others.

[Dana Crawford]

When I see I/O errors, I typically use the ITE, SYM, and I/O Traces to figure out what's going on. One dot out of place can really muck up things.

//EN$TRITE DD DUMMY         /* IF-THEN-ELSE TRACE

//EN$TRGI1 DD DUMMY         /* GEN I/O TRACE - SHORT

//EN$TRSYM DD DSN=XXX.xxxxx.TRACEOUT,DISP=SHR

[Steve Blackett]

So, I wanted to provide an update, thanks to all of the people who answered here and got in touch separately, it's really the type of thing that adds value to the community.

Short version: problem solved
Long version: I was rushing and had specified the incorrect blocksizes across a copybook/dclgen concatenation (we have 3 different types of each across 6 environments), 36 datasets. So a mixture of these was leading to the error.

I'd like to note, none of the traces assisted. Although the ones Bernie listed aren't actually documented:
https://techdocs.broadcom.com/us/en/ca-mainframe-software/devops/ca-endevor-software-change-manager/19-0/administrating/trace-facilities.html
It would be good for Broadcom one day to get on top of this list and update their documentation.

There isn't a "good" way to debug a processor in the same way you can debug say a Cobol or java program.
The processor in question is over 2000 lines long, although I could focus in on the actual compilation step, it wasn't obvious which dataset there were issues with.

So, I deleted them all and started again, I'm pretty much a PDSE man these days so I baulk at PDS's unless there's a good reason.

Thanks again everyone

------------------------------
Mainframe DevOps
HSBC
United Kingdom
------------------------------