Re: Questions about COBOL debugging lines in subroutines

[Steve Thompson]

Honestly, I was thinking of separate source for the "sub 
program/routine" not all of it in a single source "deck".


I'd only recently been working with multiple Procedure Divisions 
within a single source [I've been working with some IBM provided 
samples for invoking REXX from COBOL, call and data return...]


Guess I'll need to do some more experimenting.

And I don't think you wasted bandwidth. This short discussion 
might answer a question for someone else.


BTW - some of what I said was copied from either the COBOL 6.2 
REF or User Guide.


Steve Thompson

On 1/1/2024 10:36 AM, Paul Feller wrote:

Peter, I'm glad it worked.  Don't you just hate it when you try something and 
it fails only to try again later and it works.  I've had that happen to me a 
time or two over the years.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, January 1, 2024 1:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions about COBOL debugging lines in subroutines

Steve and Paul,

I tried using the “SOURCE-COMPUTER” paragraph and WITH DEBUGGING clause in the 
subroutine in an earlier iteration of this testing, but at that time I saw that 
the compiler did not allow that – I gave a severe error if more than one 
CONFIGURATION SECTION occurred in the same compiler input file.

However, I just re-added the CONFIGURATION SECTION and WITH DEBUGGING clause to 
the subroutine as posted earlier and it Just Works (tm).

Probably PEBCAK.  Mea culpa for wasting bandwidth.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Sunday, December 31, 2023 8:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions about COBOL debugging lines in subroutines


Each program/subprogram, that you need to debug, you must specify

in its source



"WITH DEBUGGING MODE"



That "Activates a compile-time switch for debugging lines written

in the source text.



"A debugging line is a statement that is compiled only when the

compile-time switch is activated."



So If you only need to debug a subprogram, then you only compile

and link it with the debug logic generated/activated.



HTH

Steve Thompson



On 12/31/2023 7:22 PM, Paul Feller wrote:


Peter, I'll start by saying I've never used this option.  It does
sound
interesting.  From what I have read would you not also need the "WITH
DEBUGGING MODE" setup in the called program.
Paul
-Original Message-
From: IBM Mainframe Discussion List
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
Of
Farley, Peter
Sent: Sunday, December 31, 2023 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions about COBOL debugging lines in subroutines
P.S. - COBOL compiler is Enterprise COBOL V6.4.
From: IBM Mainframe Discussion List
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
Of
Farley, Peter
Sent: Sunday, December 31, 2023 6:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Questions about COBOL debugging lines in subroutines
I have a little mystery concerning debugging lines ("D" in column 7)
in
COBOL subroutines compiled in the same input file as the main program.
Sample output and code are pasted below.
The execution JCL for this sample program includes a CEEOPTS DD with
the LE
"DEBUG" option set so debugging lines SHOULD display on SYSOUT.  In my
little test, only the debugging line in the main program displays on SYSOUT.
Q1: Can anyone tell me why the debugging line in the subroutine does
not
execute at run time?
Q2: Is there any way I can adjust the code or the compile process to
cause
the subroutine debugging line to execute at run time?
Peter
Sample SYSOUT output:
DBGSAMPL I=+3,J=+4,K=+2
Sample COBOL code compiled as a single SYSIN file to the compiler,
using
options 'AR(EX),DS(S),NOSEQ':
 IDENTIFICATION DIVISION.
 PROGRAM-ID. DBGSAMPL.
 ENVIRONMENT DIVISION.
 CONFIGURATION SECTION.
 SOURCE-COMPUTER.
 Z-SYSTEM
 WITH DEBUGGING MODE
 .
 DATA DIVISION.
 LOCAL-STORAGE SECTION.
 01  IPIC S9(9) BINARY VALUE 1.
 01  JPIC S9(9) BINARY VALUE 2.
 01  KPIC S9(9) BINARY VALUE 3.
 PROCEDURE DIVISION.
 MAIN-PARAGRAPH.
 CALL "SUBSAMP1" USING I, J, K
DDISPLAY "DBGSAMPL I=" I ",J=" J ",K=" K
 GOBACK
 .
 END PROGRAM DBGSAMPL.
 IDENTIFICATION DIVISION.
 PROGRAM-ID. SUBSAMP1.
 ENVIRONMENT DIVISION.
 DATA DIVISION.
 LINKAGE SECTION.
 01  I1   PIC S9(9) BINARY VALUE 1.
 01  J1   PIC S9(9) BINARY VALUE 2.
 01  K1   PIC S9(9) BINARY VALUE 3.
 PROCEDURE DIVISION USING I1, J1, K1.
 MAIN-PARAGRAPH.
 MOVE K1 TO I1
 MOVE J1 TO K1
 MOVE 4  TO J1
DDISPLAY "SUBSAMP1 I=" I1 ",J=" J1 ",K=" K1
 GOBACK
 .
 

Re: Help Trying to determine where abend occurred

[Joseph Reichman]

Peter thank you 

Just thinking out loud if I wanted to get infoformation about the load module / 
pc rtn 

As the Estae recovery is now running in the home address space and when it is 
running home=primary=secondary 

I am thinking the doc says I can issue CSVQUERY in AR mode I might try to put 
SDWAPRIM on my DU-AL 

And and maybe get the name of the PC routine 

> On Jan 1, 2024, at 10:56 AM, Peter Relson  wrote:
> 
> Joe R wrote
> 
> Seems that sdwaec2 points to the code in the pc routine while sdwaec1 points 
> the home address space right after the pc instruction wondering if I can 
> always make this assumption
> 
> 
> As Walt F pointed out, there is documentation about these fields in the 
> assembler services guide. I think that makes it clear what is in SDWAEC1 and 
> SDWAEC2 under which circumstances.
> 
> As to the assumption about "the home address space", that would be a valid 
> assumption only if you know that the primary address space equaled the home 
> address space at the time of the instruction (PC in this case), which is not 
> in general the case. The PC would have been an instruction in the pre-PC 
> primary address space.
> 
> Do note that instructions are fetched from the home address space (not the 
> primary address space if the two differ) for home ASC mode.
> But since you cannot issue a PC in home ASC mode, that does not apply to your 
> case. And in practice, all code that uses Home ASC mode is in common storage.
> 
> 
> My question is there any field in the SDWA or extensions that would tell me
> in what ASID the abend occurred
> 
> I'd look at SDWAXM, specifically SDWAPRIM, unless the error was in home ASC 
> mode in which case you don't need to look at the SDWA but can use PSAAOLD -> 
> ASCBASID. SDWAPRIM is the primary ASID at the time of error. Is that what you 
> mean by "in what ASID the abend occurred"? If the error was a storage access 
> using an ALET, the erroneous reference could have been to any number of 
> (address or data) spaces.
> 
> You seem to be pursuing something that might not be overly useful for a 
> recovery routine. The recovery routine of the PC issuer would typically rely 
> on footprints set by the PC issuer's mainline to understand what the mainline 
> was last doing (and thus how the recovery routine needed to react). The 
> recovery routine of the PC target would typically not care about where the PC 
> was issued from. A diagnostician, of course, might well care about both, but 
> they would typically be looking at a dump.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help Trying to determine where abend occurred

[Peter Relson]

Joe R wrote

Seems that sdwaec2 points to the code in the pc routine while sdwaec1 points 
the home address space right after the pc instruction wondering if I can always 
make this assumption


As Walt F pointed out, there is documentation about these fields in the 
assembler services guide. I think that makes it clear what is in SDWAEC1 and 
SDWAEC2 under which circumstances.

As to the assumption about "the home address space", that would be a valid 
assumption only if you know that the primary address space equaled the home 
address space at the time of the instruction (PC in this case), which is not in 
general the case. The PC would have been an instruction in the pre-PC primary 
address space.

Do note that instructions are fetched from the home address space (not the 
primary address space if the two differ) for home ASC mode.
But since you cannot issue a PC in home ASC mode, that does not apply to your 
case. And in practice, all code that uses Home ASC mode is in common storage.


My question is there any field in the SDWA or extensions that would tell me
in what ASID the abend occurred

I'd look at SDWAXM, specifically SDWAPRIM, unless the error was in home ASC 
mode in which case you don't need to look at the SDWA but can use PSAAOLD -> 
ASCBASID. SDWAPRIM is the primary ASID at the time of error. Is that what you 
mean by "in what ASID the abend occurred"? If the error was a storage access 
using an ALET, the erroneous reference could have been to any number of 
(address or data) spaces.

You seem to be pursuing something that might not be overly useful for a 
recovery routine. The recovery routine of the PC issuer would typically rely on 
footprints set by the PC issuer's mainline to understand what the mainline was 
last doing (and thus how the recovery routine needed to react). The recovery 
routine of the PC target would typically not care about where the PC was issued 
from. A diagnostician, of course, might well care about both, but they would 
typically be looking at a dump.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Questions about COBOL debugging lines in subroutines

[Paul Feller]

Peter, I'm glad it worked.  Don't you just hate it when you try something and 
it fails only to try again later and it works.  I've had that happen to me a 
time or two over the years.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, January 1, 2024 1:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions about COBOL debugging lines in subroutines

Steve and Paul,

I tried using the “SOURCE-COMPUTER” paragraph and WITH DEBUGGING clause in the 
subroutine in an earlier iteration of this testing, but at that time I saw that 
the compiler did not allow that – I gave a severe error if more than one 
CONFIGURATION SECTION occurred in the same compiler input file.

However, I just re-added the CONFIGURATION SECTION and WITH DEBUGGING clause to 
the subroutine as posted earlier and it Just Works (tm).

Probably PEBCAK.  Mea culpa for wasting bandwidth.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Sunday, December 31, 2023 8:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Questions about COBOL debugging lines in subroutines


Each program/subprogram, that you need to debug, you must specify

in its source



"WITH DEBUGGING MODE"



That "Activates a compile-time switch for debugging lines written

in the source text.



"A debugging line is a statement that is compiled only when the

compile-time switch is activated."



So If you only need to debug a subprogram, then you only compile

and link it with the debug logic generated/activated.



HTH

Steve Thompson



On 12/31/2023 7:22 PM, Paul Feller wrote:

> Peter, I'll start by saying I've never used this option.  It does 
> sound

> interesting.  From what I have read would you not also need the "WITH

> DEBUGGING MODE" setup in the called program.

>

>

> Paul

>

> -Original Message-

> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf 
> Of

> Farley, Peter

> Sent: Sunday, December 31, 2023 5:50 PM

> To: IBM-MAIN@LISTSERV.UA.EDU

> Subject: Re: Questions about COBOL debugging lines in subroutines

>

> P.S. - COBOL compiler is Enterprise COBOL V6.4.

>

> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf 
> Of

> Farley, Peter

> Sent: Sunday, December 31, 2023 6:46 PM

> To: IBM-MAIN@LISTSERV.UA.EDU

> Subject: Questions about COBOL debugging lines in subroutines

>

>

> I have a little mystery concerning debugging lines ("D" in column 7) 
> in

> COBOL subroutines compiled in the same input file as the main program.

> Sample output and code are pasted below.

>

> The execution JCL for this sample program includes a CEEOPTS DD with 
> the LE

> "DEBUG" option set so debugging lines SHOULD display on SYSOUT.  In my

> little test, only the debugging line in the main program displays on SYSOUT.

>

> Q1: Can anyone tell me why the debugging line in the subroutine does 
> not

> execute at run time?

>

> Q2: Is there any way I can adjust the code or the compile process to 
> cause

> the subroutine debugging line to execute at run time?

>

> Peter

>

> Sample SYSOUT output:

>

> DBGSAMPL I=+3,J=+4,K=+2

>

> Sample COBOL code compiled as a single SYSIN file to the compiler, 
> using

> options 'AR(EX),DS(S),NOSEQ':

>

> IDENTIFICATION DIVISION.

> PROGRAM-ID. DBGSAMPL.

> ENVIRONMENT DIVISION.

> CONFIGURATION SECTION.

> SOURCE-COMPUTER.

> Z-SYSTEM

> WITH DEBUGGING MODE

> .

> DATA DIVISION.

> LOCAL-STORAGE SECTION.

> 01  IPIC S9(9) BINARY VALUE 1.

> 01  JPIC S9(9) BINARY VALUE 2.

> 01  KPIC S9(9) BINARY VALUE 3.

> PROCEDURE DIVISION.

> MAIN-PARAGRAPH.

> CALL "SUBSAMP1" USING I, J, K

>DDISPLAY "DBGSAMPL I=" I ",J=" J ",K=" K

> GOBACK

> .

> END PROGRAM DBGSAMPL.

>

> IDENTIFICATION DIVISION.

> PROGRAM-ID. SUBSAMP1.

> ENVIRONMENT DIVISION.

> DATA DIVISION.

> LINKAGE SECTION.

> 01  I1   PIC S9(9) BINARY VALUE 1.

> 01  J1   PIC S9(9) BINARY VALUE 2.

> 01  K1   PIC S9(9) BINARY VALUE 3.

> PROCEDURE DIVISION USING I1, J1, K1.

> MAIN-PARAGRAPH.

> MOVE K1 TO I1

> MOVE J1 TO K1

> MOVE 4  TO J1

>DDISPLAY "SUBSAMP1 I=" I1 ",J=" J1 ",K=" K1

> GOBACK

> .

> END PROGRAM SUBSAMP1.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication

Re: Question about IEAMSCHD

[Peter Relson]

>Binyamin wrote
:>
:>What is a "non-authorized" address space?
:>

:>Everyone I know would consider that to be an address space for which the 
jobstep program is not both linkedited AC=1 and gotten from an APF-authorized 
concatenation, and is not a system key address space (as could be defined in 
such places as the program properties table).

In the context of SRB?


I'd say "yes" (or "not applicable" since this is about an address space, not 
about whether a work unit is or is not currently running in a system state - 
which I would characterize as supervisor state or PSW key 0-7). SRBs (key 0 
supervisor state typically) can run in unauthorized address spaces. The 
authorization of the address space is not related to the authorization of an 
SRB running within that address space.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN