I agree I have to look at the program I must be re-setting the GLBC
somewhere
thanks
-Original Message-
From: IBM Mainframe Assembler List On
Behalf Of Peter Relson
Sent: Tuesday, November 19, 2019 8:26 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Global character not keeping
Joe,
You posted the macros. That's a small piece. What about the rest of the
module? Surely you understand that having the macros in isolation is not
helpful.
For all we know, you are fetching the modules via the SYSLIB concatenation
and not getting the copy of the macro that you have
Depends on the company I suppose. I worked at a manufacturing company
and we were considered begrudgingly-tolerated overhead to the real
business of making stuff out of metal and plastic. Operations decided if
they had enough time to run programmer jobs (put cards in reader) during
the day. In
Subject: Re: Global character not keeping value
My technique for debugging this kind of problem is to start with the
just the epilogue and prologue, then add half the code back in, then
half the remaining code, etc., until i get the error again (ignoring all
the other errors), then stripping out
Thanks let me search the program
> On Nov 18, 2019, at 8:12 AM, Jonathan Scott
> wrote:
>
> Ref: Your note of Mon, 18 Nov 2019 07:33:29 -0500
>
> The only way the value could change is if it is modified by
> another macro (or by an open code GBLC and SETC) after the
> DBGRPRLG and
OUCH. I remember those once-a-day runs!
On Mon, Nov 18, 2019 at 11:10 AM Gary Weinhold wrote:
> My technique for debugging this kind of problem is to start with the
> just the epilogue and prologue, then add half the code back in, then
> half the remaining code, etc., until i get the error
My technique for debugging this kind of problem is to start with the
just the epilogue and prologue, then add half the code back in, then
half the remaining code, etc., until i get the error again (ignoring all
the other errors), then stripping out code until I get rid of the
error. Ever since I
Joe Reichman wrote:
>I have a prolog and eplog macros as exit and entry to program
>The prolog is coded as such
> MACRO
> PRLG
> GBLC
> SETC ''
>When used in the prolog
> As such
> AIF ('' EQ '').NODSA
> AHR11,=H''
> .NODSA
On Mon, 18 Nov 2019 08:17:37 -0500, Peter Relson wrote:
>Due diligence before posting such questions includes trying to eliminate
>the possibility that you made some simple mistake.
Such as assembling the prolog and epilog macros with no intervening code.
--
Tom Marchant
Ref: Your note of Mon, 18 Nov 2019 07:33:29 -0500
The only way the value could change is if it is modified by
another macro (or by an open code GBLC and SETC) after the
DBGRPRLG and before DBGREPLG. This could for example be another
DBGRPRLG call without DSA.
Jonathan Scott, HLASM
IBM Hursley,
:>00013C 58F0 312A001C0 183 L R15,=AD(BAC
:>
:>
:>-Original Message-
:>From: IBM Mainframe Assembler List On
Behalf Of Bernd Oppolzer
:>Sent: Monday, November 18, 2019 2:34 AM
:>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
:>Subject: Re: Global charac
'
00013C 58F0 312A001C0 183 L R15,=AD(BAC
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Bernd Oppolzer
Sent: Monday, November 18, 2019 2:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Global character not keeping value
Hi Joe
MEND
Here is the generated assembler code
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Bernd Oppolzer
Sent: Monday, November 18, 2019 2:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Global character not keeping value
Hi Joe,
IMO
Hi Joe,
IMO, this should work, if you do a PRLG 30 call before the EPLG call
in the open code.
Could you please post the whole relevant part of the code
(complete macro definitions and the snippets of the
open code in the correct sequence), so that we can take
a look at it?
Another suggestion:
I have a prolog and eplog macros as exit and entry to program
The prolog is coded as such
MACRO
PRLG
GBLC
SETC ''
When used in the prolog
As such
15 matches
Mail list logo
