Re: Program now working, but why?

[Bill Woodger]

"Thank Steve, I only mentioned it because Bill had discounted the idea and I 
was pleased with your confirmation it was possible. 
 
:) "

"Discounted" for a reason. The AMBLIST outputs were compared. AMODE is in the 
heading. I'd be more than mildly surprised if the OS/VS COBOL program with an 
Assembler program last assembled in 1989 has an AMODE other than 24. With an 
AMODE of 24, how could you possibly get 31-bit-addressed IO areas from a COBOL 
program? 

On the available evidence, and subject to review if the evidence changed, I 
didn't discount it, I *utterly dismissed it*. Following a fluffy puppy up a 
country lane because in an entirely different situation (causes of S0C4 are 
hardly of a limited number of specific things) a fluffy puppy was the answer 
is... how useful?

Multiple people concurring on a suggestion doesn't in itself make it any more 
valid. In other situations it is spot on, but here?

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

Re: Program now working, but why?

[Bill Woodger]

On Wed, 8 Feb 2017 10:34:28 -0600, Peter Ten Eyck 
 wrote:

>At this point I am thinking the coding change is required due a difference in 
>how the COBOL compilers work. I was attempting to identify what that 
>difference may be or find something in the migration guide that highlighted 
>it. ...

I think that is essentially correct. The compiler, or the runtime - a more 
slight chance. You've eliminated "data" as an issue, and, except as an 
incidental, the Assembler program.

If R4 is zero and you review my requests, I think you will be there. I don't 
think it is documented in a Migration Guide, but there is some "supporting 
material". 

Of course, I can be wrong :-) There's not enough information to fully support 
what I think, but nothing has countered it yet. Other evidence could do so.

If R4 is zero, then I'm still 100% (that's rounded), sure it is not DATA(31) 
being an issue (unless there is weird code in the Assembler program which 
coincidentally makes R4 zero when whatever circumstances cause this - never say 
never).

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

Re: Program now working, but why?

[Elardus Engelbrecht]

Time for me to jump in in this thread.

Bill Woodger wrote:

>And Abend-Aid shows R4 as zero?

Hmmm, first B somewhere, then MVI 0(R4),X'40' then B same place, then MVI   
  0(R4),X'00'.

What Source Code + what Variable is used for above? Is that about some padding 
with space and then with zero?



To Peter (OP), what is inside that header record which is causing a S0C4? 
Please post it if you can.

I believe you have never posted the full and all related messages and the 
relevant COBOL statements [1] and declarations about that Abend. If I missed 
it, just tell me, I'll search again to see if I can help you.

Please post what I asked if you can. Then we can look again at RMODE and AMODE 
and friends and other suggestions kindly given by others.


Peter, you said: 'Using the shops default compile and link settings'. Are they 
really, really, really the defaults? Could you review them again and perhaps 
post them if they differ from IBM's own defaults?

Trust me, someone changed a default thing and you're then SOL.

Also, 'Program moves from the FD to WORKING-STORAGE before the call to the 
assembler program for all “input” parameters.' Please post the statements and 
all keywords which calls that assembler program.


PS: I am at v2.1, not v2.2 where Peter is working on. 

PS2: I have encountered S0C4 abends in COBOL progs in the past, but that was 
usually related to something 'unexpected'. Trust me. ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - yes, you have posted that 2 lines of bypass statements, but that is not 
helping here.

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

AW: Re: Program now working, but why?

[Peter Hunkeler]

>Rather than trying to infer the cause by tweaking everything in sight, how 
>about this: Set a SLIP PER trap to catch an SVC dump for the first abend of 
>any kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
>quickly than trial-and-error with recompiles/reassemblies/logic-changes.


In case it is not so easy for the developer to have the friendly sysprog set a 
slip trap, the following might also give you what you need:


//CEEOPTS DD *
  TERMTHDACT(UAIMM,,96)
/*


and make sure the last "dump" DD statement is what you prefer, either 
//SYSMDUMP if you know how to use IPCS, or //SYSABEND DD SYSOUT=* if you do 
not. The beauty with SYSMDUMP: You don't need access permission to the SVC dump 
data sets; you can choose your own name.


That will give you a dump before LE starts with its condition handling. The 
system trace listing is worth a look.


Code //SYSMDUMP something like:


//SYSMDUMP DD DISP=(NEW,CATLG),DSN=your.dump.dsn,
//   RECFM=FBS,LRECL=4160,
//   SPACE=(1,(50,200),RLSE),AVGREC=M


--
Peter Hunkeler



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

Re: Program now working, but why?

[Bill Woodger]

And Abend-Aid shows R4 as zero?

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

Re: Program now working, but why?

[Bill Woodger]

Ah, but we enjoy it. Please don't take it away from us...

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

Re: Program now working, but why?

[Bill Woodger]

Thanks Peter.

Can you provide the COBOL compile options, the linkedit map for the EXEC PGM= 
program and the AMBLIST output for the original program?

Did you discover why someone suspected the header?

Any code (including whether it is PERFORMed) which CALLs the Assembler program.

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

Re: Program now working, but why?

[Peter Ten Eyck]

Sorry not much help here, I do not know assembler.

Here is the code snippet shown in Abend-Aid for the SOC4:

   0072  47F0C0AC  B   172(,R12)
   0076  92404000  MVI 0(R4),X'40'  
   007A  47F0C0AC  B   172(,R12)
   007E  92004000  MVI 0(R4),X'00'  
NSI==> 0082  47F0C0AC  B   172(,R12)
   0086  1884  LR  R8,R4
   0088  5B80C178  S   R8,376(,R12) 
   008C  D20040008000  MVC 0(1,R4),0(R8)
   0092  47F0C0AC  B   172(,R12)

Note: NSI is next sequential instruction.

At this point I am thinking the coding change is required due a difference in 
how the COBOL compilers work. I was attempting to identify what that difference 
may be or find something in the migration guide that highlighted it. I do not 
want to take up more of other's time. Thank you for all the input and 
suggestions.

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

Re: Program now working, but why?

[Lou Losee]

What are the details of the 0C4 in the assembler program:

- what was it trying to access?
- was it a read or a write?


Lou

--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown

On Wed, Feb 8, 2017 at 9:26 AM, Peter Ten Eyck <
peter.tene...@americannational.com> wrote:

> Job TNCA1300 runs three times on the same LPAR with the same data and id.
>
> Run 1 – production COBOL program, calls production assembler program, runs
> successfully.
>
> Bring production COBOL program into a development PDS and compile program
> without changes.
>
> Run 2- development program, calls production assembler program, fails with
> SOC4 in assembler program.
>
> Add these two lines of code to COBOL program to bypass header record on
> input dataset:
>
>  IF WS-NA-RECORDS-READ EQUAL 1
> GO TO 1200-READ-MASTER.
>
> Compile COBOL program with change. Compile output messages identical to
> first compile.
>
> Run 3 – development COBOL program (changed), calls production assembler
> program, runs successfully.
>
> Note: No overrides or changes to AMODE, RMODE or DATA during the test.
> Using the shops default compile and link settings.
>
> Program moves from the FD to WORKING-STORAGE before the call to the
> assembler program for all “input” parameters.
>
> I am missing something here; I do not see why this code would resolve the
> SOC4. Or has mentioned, missing something else… the unknown unknowns
>
> --
> 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: Program now working, but why?

[Massimo Biancucci]

Is the program reading INTO variable or not ?

If not, double check the FD definition, the length of the record and
"normal strange conditions" like empty file.

There're lot of difference in such area between OSVS or Cobol2 and
Enterprise compilers.

Best regards.
Massimo

2017-02-08 16:26 GMT+01:00 Peter Ten Eyck <
peter.tene...@americannational.com>:

> Job TNCA1300 runs three times on the same LPAR with the same data and id.
>
> Run 1 – production COBOL program, calls production assembler program, runs
> successfully.
>
> Bring production COBOL program into a development PDS and compile program
> without changes.
>
> Run 2- development program, calls production assembler program, fails with
> SOC4 in assembler program.
>
> Add these two lines of code to COBOL program to bypass header record on
> input dataset:
>
>  IF WS-NA-RECORDS-READ EQUAL 1
> GO TO 1200-READ-MASTER.
>
> Compile COBOL program with change. Compile output messages identical to
> first compile.
>
> Run 3 – development COBOL program (changed), calls production assembler
> program, runs successfully.
>
> Note: No overrides or changes to AMODE, RMODE or DATA during the test.
> Using the shops default compile and link settings.
>
> Program moves from the FD to WORKING-STORAGE before the call to the
> assembler program for all “input” parameters.
>
> I am missing something here; I do not see why this code would resolve the
> SOC4. Or has mentioned, missing something else… the unknown unknowns
>
> --
> 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: Program now working, but why?

[Peter Ten Eyck]

Job TNCA1300 runs three times on the same LPAR with the same data and id.

Run 1 – production COBOL program, calls production assembler program, runs 
successfully.

Bring production COBOL program into a development PDS and compile program 
without changes.

Run 2- development program, calls production assembler program, fails with SOC4 
in assembler program.

Add these two lines of code to COBOL program to bypass header record on input 
dataset:

 IF WS-NA-RECORDS-READ EQUAL 1
GO TO 1200-READ-MASTER.

Compile COBOL program with change. Compile output messages identical to first 
compile.

Run 3 – development COBOL program (changed), calls production assembler 
program, runs successfully.

Note: No overrides or changes to AMODE, RMODE or DATA during the test. Using 
the shops default compile and link settings.

Program moves from the FD to WORKING-STORAGE before the call to the assembler 
program for all “input” parameters.

I am missing something here; I do not see why this code would resolve the SOC4. 
Or has mentioned, missing something else… the unknown unknowns

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

Re: Program now working, but why?

[Peter Ten Eyck]

Good morning, great feedback overnight. I am going to go back to the beginning, 
reproduce the successful run and error run myself. Not that I do not trust the 
programmer, but I need to be sure of the order of events and the changes made. 
I will report back my findings.

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

Re: Program now working, but why?

[Gibney, Dave]

Thank Steve, I only mentioned it because Bill had discounted the idea and I was 
pleased with your confirmation it was possible.

:)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Thompson
> Sent: Tuesday, February 07, 2017 5:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Program now working, but why?
> 
> Cave:
> 
> Great minds By the time I saw your post, I had already sent mine.
> 
> Also, someone else suggested a SLIP trap. I like that idea. But then I've been
> an IPCS user for decades. And still use it for diagnosing problems today 
> (after
> I put in the DD for ABEND-aid to ignore the ABEND).
> 
> 
> Regards,
> Steve Thompson
> 
> 
> On 02/07/2017 06:28 PM, Gibney, Dave wrote:
> > I think I said this :)
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On Behalf Of Steve Thompson
> >> Sent: Tuesday, February 07, 2017 2:53 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Program now working, but why?
> >>
> >> On 02/07/2017 02:33 PM, Peter Ten Eyck wrote:
> >>> The production assembler program is AM 24 and RM 24.
> >>>
> >>> The production COBOL program is AM 24 and RM 24. (runs, calls
> >>> assembler program)
> >>>
> >>> The development COBOL program is AM ANY and RM 24. (does not run
> >> (SOC4
> >>> in assembler program), does run with mentioned coding change, calls
> >>> assembler program)
> >>>
> >>> 
> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO
> >>> IBM-MAIN
> >>>
> >> I'm going to take an educated guess since I've been working at
> >> solving things like this myself (on a gotta have it by the end of the
> >> week basis -- no pressure).
> >>
> >> But in my case, I'm changing ALC programs to be RENT, AMODE any to
> >> give VSCR (Virt Stor Constraint Relief) so all the COBOL programs can
> >> go AMODE 31, RMODE 31.
> >>
> >> The COBOL 4.2 code can obtain buffers above the line (AMODE
> >> any/31) while being RMODE 24.
> >>
> >> So, the data being passed (header record) could be passed from the
> >> FD's data area, which would have it not-addressable by the ALC
> >> program (the data is pointed to in the above the line buffer).
> >>
> >> However, the other records are moved to Working Storage which is
> >> below the line.
> >>
> >> Or it could be vice-versa.
> >>
> >> But that is the kind of thing I would look for.
> >>
> >> Regards,
> >> Steve Thompson
> >>
> >> -
> >> - 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
> >
> 
> --
> 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: Program now working, but why?

[Steve Thompson]

Cave:

Great minds By the time I saw your post, I had already sent mine.

Also, someone else suggested a SLIP trap. I like that idea. But 
then I've been an IPCS user for decades. And still use it for 
diagnosing problems today (after I put in the DD for ABEND-aid to 
ignore the ABEND).



Regards,
Steve Thompson


On 02/07/2017 06:28 PM, Gibney, Dave wrote:

I think I said this :)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Steve Thompson
Sent: Tuesday, February 07, 2017 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

On 02/07/2017 02:33 PM, Peter Ten Eyck wrote:

The production assembler program is AM 24 and RM 24.

The production COBOL program is AM 24 and RM 24. (runs, calls
assembler program)

The development COBOL program is AM ANY and RM 24. (does not run

(SOC4

in assembler program), does run with mentioned coding change, calls
assembler program)

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


I'm going to take an educated guess since I've been working at solving things
like this myself (on a gotta have it by the end of the week basis -- no
pressure).

But in my case, I'm changing ALC programs to be RENT, AMODE any to give
VSCR (Virt Stor Constraint Relief) so all the COBOL programs can go AMODE
31, RMODE 31.

The COBOL 4.2 code can obtain buffers above the line (AMODE
any/31) while being RMODE 24.

So, the data being passed (header record) could be passed from the FD's
data area, which would have it not-addressable by the ALC program (the data
is pointed to in the above the line buffer).

However, the other records are moved to Working Storage which is below
the line.

Or it could be vice-versa.

But that is the kind of thing I would look for.

Regards,
Steve Thompson

--
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



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

Re: Program now working, but why?

[Hank Oerlemans1]

Gee, what does Fault Analyzer say about  it ?

I am completely unbiased of course

Hank @  IBM @ FA Development


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

Re: Program now working, but why?

[Jesse 1 Robinson]

Here's why I suggest a SLIP trap. Except in the simplest of environments, I 
don’t trust SYSUDUMP necessarily to capture the first error. I mentioned here 
before how I once used SLIP trap to diagnose a COBOL S0C4 that actually started 
out as a S0C7 that got screwed up by a bad STAE routine. In the case of SLIP, 
you'll most likely capture the original error before LE has had its way with 
environment.

Second, I would want to use IPCS. That means an unformatted dump in a data set. 
You could do that with SYSMDUMP and a DASD allocation, but really, why not let 
the system do it for you? You pay the same MLC either way. ;-)

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Tuesday, February 07, 2017 3:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Program now working, but why?

"Rather than trying to infer the cause by tweaking everything in sight, how 
about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any 
kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
quickly than trial-and-error with recompiles/reassemblies/logic-changes."

Isn't there already a dump?

If there isn't, I absolutely agree. Todge about with things, and you change 
things.

Program A CALLs Program B. Program B goes into a Big Fat Loop.

LOOP.
do some stuff
IF loopcounter NOT GREATER THAN +5
ADD 1 TO loopcounter
GO TO LOOP.

Programmer "adds a DISPLAY" to B.
No loop.
Programmer removes added DISPLAY.
Loop.
Programmer adds DISPLAY to A.
No loop.
Programmer removes added DISPLAY.
Loop.
Programmer adds DISPLAY to both programs (yes, they did) No loop.

Faffing-about continues for a couple of days, but the only time it loops is 
with the programs unchanged.

Comes to me with a big smile and "I've found a compiler bug ".

I looked at the above code, and ask what was the last code change he'd made 
before the first loop. He showed me in Program A. Utterly wild subscript, 
MOVEing LOW-VALUES to a one-byte field within a large group item subordinate to 
an OCCURS, conditionally.

Just happened to hit the low-order part of the binary one in the Literal Pool 
of Program B. So, adding the "constant" literal value one, was actually adding 
zero, so the loop could never terminate.

A handful of other scattered single-byte binary-zeros had had no obvious affect 
amongst all his "compiler bug" hunting.

But. Put in a DISPLAY, with a nice literal, prior to the use of +1, and the 
location of the +1 is changed (OS/VS COBOL doesn't define literals in reverse 
order), so now, for the loop, it is +1. Add a DISPLAY to Program A, and the 
Program B code "moves", and again the +1 in the literal pool is preserved.

Cancel, with a dump. Look at the dump. Look at the code for the loop, and 
there's X'' where X'0001' should be in the Literal Pool of Program B.

If ever overwiting of executable code is suspected, adding code in front of the 
problem is going to shift it at best, and mask it at worse.

Bust that dump. Guessing and DISPLAY I find of little value. Obtaining all the 
information possible, and going forward with what matches all the information 
(cue various Sherlock Holmes quotes) I find of great value. A dump (and for 
sure a full one) mostly has all the information needed.

Having said that, something that happens with record 17, which causes a failure 
when record 291,347 is reached, is more problematic - except that deduction 
leads you there, and at times surprisingly fast.

The information available so far does not indicate that this can be an 
addressing problem due to 31/24. The AMBLIST Module Summaries are the same. 

OK, if Peter Ten Eyck remains quiet on the subject from now on, there's that 
outside possibility that the same report was compared to itself, and the actual 
new report reveals exactly what people have been suggesting is possible :-)


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

Re: Program now working, but why?

[Gibney, Dave]

I think I said this :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Thompson
> Sent: Tuesday, February 07, 2017 2:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Program now working, but why?
> 
> On 02/07/2017 02:33 PM, Peter Ten Eyck wrote:
> > The production assembler program is AM 24 and RM 24.
> >
> > The production COBOL program is AM 24 and RM 24. (runs, calls
> > assembler program)
> >
> > The development COBOL program is AM ANY and RM 24. (does not run
> (SOC4
> > in assembler program), does run with mentioned coding change, calls
> > assembler program)
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> I'm going to take an educated guess since I've been working at solving things
> like this myself (on a gotta have it by the end of the week basis -- no
> pressure).
> 
> But in my case, I'm changing ALC programs to be RENT, AMODE any to give
> VSCR (Virt Stor Constraint Relief) so all the COBOL programs can go AMODE
> 31, RMODE 31.
> 
> The COBOL 4.2 code can obtain buffers above the line (AMODE
> any/31) while being RMODE 24.
> 
> So, the data being passed (header record) could be passed from the FD's
> data area, which would have it not-addressable by the ALC program (the data
> is pointed to in the above the line buffer).
> 
> However, the other records are moved to Working Storage which is below
> the line.
> 
> Or it could be vice-versa.
> 
> But that is the kind of thing I would look for.
> 
> Regards,
> Steve Thompson
> 
> --
> 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: Program now working, but why?

[Bill Hitefield]

Also, the user may not need a full SVC dump.

If the user has access to the JCL, they can modify the step's parm field as 
follows:
PARM='Your parms/TRAP(OFF)'

Insert a SYSABEND DD statement into the JCL.

That parameter should cause LE to remove its trapping of the abend - and let 
the S0C4 produce a dump.

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, February 07, 2017 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

S0C4's don't just happen: they happen on a particular machine instruction and 
with particular register contents. You look at the instruction, the register 
contents and the addressing mode and deduce the cause.

A SLIP trap will be no more help than a SYSUDUMP if you are unwilling or unable 
to do the above.

Is the assembly listing unavailable? Did I miss that part?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, February 07, 2017 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

Rather than trying to infer the cause by tweaking everything in sight, how 
about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any 
kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
quickly than trial-and-error with recompiles/reassemblies/logic-changes.

--
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: Program now working, but why?

[Charles Mills]

S0C4's don't just happen: they happen on a particular machine instruction and 
with particular register contents. You look at the instruction, the register 
contents and the addressing mode and deduce the cause.

A SLIP trap will be no more help than a SYSUDUMP if you are unwilling or unable 
to do the above.

Is the assembly listing unavailable? Did I miss that part?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, February 07, 2017 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

Rather than trying to infer the cause by tweaking everything in sight, how 
about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any 
kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
quickly than trial-and-error with recompiles/reassemblies/logic-changes.

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

Re: Program now working, but why?

[Bill Woodger]

"Rather than trying to infer the cause by tweaking everything in sight, how 
about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any 
kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
quickly than trial-and-error with recompiles/reassemblies/logic-changes."

Isn't there already a dump?

If there isn't, I absolutely agree. Todge about with things, and you change 
things.

Program A CALLs Program B. Program B goes into a Big Fat Loop.

LOOP.
do some stuff
IF loopcounter NOT GREATER THAN +5
ADD 1 TO loopcounter
GO TO LOOP.

Programmer "adds a DISPLAY" to B.
No loop.
Programmer removes added DISPLAY.
Loop.
Programmer adds DISPLAY to A.
No loop.
Programmer removes added DISPLAY.
Loop.
Programmer adds DISPLAY to both programs (yes, they did)
No loop.

Faffing-about continues for a couple of days, but the only time it loops is 
with the programs unchanged.

Comes to me with a big smile and "I've found a compiler bug ".

I looked at the above code, and ask what was the last code change he'd made 
before the first loop. He showed me in Program A. Utterly wild subscript, 
MOVEing LOW-VALUES to a one-byte field within a large group item subordinate to 
an OCCURS, conditionally.

Just happened to hit the low-order part of the binary one in the Literal Pool 
of Program B. So, adding the "constant" literal value one, was actually adding 
zero, so the loop could never terminate.

A handful of other scattered single-byte binary-zeros had had no obvious affect 
amongst all his "compiler bug" hunting.

But. Put in a DISPLAY, with a nice literal, prior to the use of +1, and the 
location of the +1 is changed (OS/VS COBOL doesn't define literals in reverse 
order), so now, for the loop, it is +1. Add a DISPLAY to Program A, and the 
Program B code "moves", and again the +1 in the literal pool is preserved.

Cancel, with a dump. Look at the dump. Look at the code for the loop, and 
there's X'' where X'0001' should be in the Literal Pool of Program B.

If ever overwiting of executable code is suspected, adding code in front of the 
problem is going to shift it at best, and mask it at worse.

Bust that dump. Guessing and DISPLAY I find of little value. Obtaining all the 
information possible, and going forward with what matches all the information 
(cue various Sherlock Holmes quotes) I find of great value. A dump (and for 
sure a full one) mostly has all the information needed.

Having said that, something that happens with record 17, which causes a failure 
when record 291,347 is reached, is more problematic - except that deduction 
leads you there, and at times surprisingly fast.

The information available so far does not indicate that this can be an 
addressing problem due to 31/24. The AMBLIST Module Summaries are the same. 

OK, if Peter Ten Eyck remains quiet on the subject from now on, there's that 
outside possibility that the same report was compared to itself, and the actual 
new report reveals exactly what people have been suggesting is possible :-)

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

Re: Program now working, but why?

[Steve Thompson]

On 02/07/2017 02:33 PM, Peter Ten Eyck wrote:

The production assembler program is AM 24 and RM 24.

The production COBOL program is AM 24 and RM 24. (runs, calls assembler program)

The development COBOL program is AM ANY and RM 24. (does not run (SOC4 in 
assembler program), does run with mentioned coding change, calls assembler 
program)

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

I'm going to take an educated guess since I've been working at 
solving things like this myself (on a gotta have it by the end of 
the week basis -- no pressure).


But in my case, I'm changing ALC programs to be RENT, AMODE any 
to give VSCR (Virt Stor Constraint Relief) so all the COBOL 
programs can go AMODE 31, RMODE 31.


The COBOL 4.2 code can obtain buffers above the line (AMODE 
any/31) while being RMODE 24.


So, the data being passed (header record) could be passed from 
the FD's data area, which would have it not-addressable by the 
ALC program (the data is pointed to in the above the line buffer).


However, the other records are moved to Working Storage which is 
below the line.


Or it could be vice-versa.

But that is the kind of thing I would look for.

Regards,
Steve Thompson

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

Re: Program now working, but why?

[Bill Woodger]

Remember, the AMBLIST Module Summary has been checked and confirmed. Even if 
NORENT is not used, dynamic CALLs, multiple load modules, how would they look 
the same, and yet have such a difference?


On Tue, 7 Feb 2017 16:27:14 -0500, Farley, Peter x23353 
 wrote:

>But a COBOL V4.2 recompile with compiler option DATA(31) will put 
>WORKING-STORAGE in 31-bit address ranges rather than 24-bit, causing the 
>24-bit assembler program to fail  S0C4.
>
>I think that is the OP's real issue, but he has to verify the compiler options 
>actually used for the recompile.
>
>Peter
>

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

Re: Program now working, but why?

[Bill Woodger]

To get the S0C4, something has to reference something outside the buffer 
maintained by QSAM.

I know no details of the internals of QSAM, but it seems reasonable to believe 
that it allocates storage for buffers which are equal in size to the BLKSIZE.

Although it would be possible to construct a scenario where the header is in a 
block of its own (file written by a COBOL program without APPLY WRITE ONLY or 
compiler option AWO, LRECL plus length of header exceeds BLKSIZE, so header 
written in a block of its own), it would not be possible to have the header 
"overdefined" in the program such that referencing the entire header would 
cause storage outside the buffer to be accessed. OK, it could be done with 
reference-modification with an erroneously calculated length, but I can't think 
how otherwise. If it was the 17th record, 23rd, 492nd, possible. With the 
first? I can't get that.

If the header is just shorter than its definition, that won't matter at all, 
because the data picked up will just be from the next record. With the header 
the only record in the block, the data will be just whatever was lying around, 
but it can be referenced without the S0C4. I doubt there is any protection from 
QSAM for "outside the block, but inside the buffer".


On Tue, 7 Feb 2017 14:22:42 -0700, Sri h Kolusu  wrote:

 In this case, because it is the behavior of the header record  (which 
>for one I'm assuming is the first record), these would only  be potential 
>issues if the file only consisted of the header, no  other records.
>
>Bill,
>
>Not really.  Assuming that OP's program is indeed dealing with VB files, 
>the header might be a Short record and the MOVE resulted in moving the 
>full length than the actual short record length and hence the S0C4. The 
>detailed records following the Header record *may* be of full length and 
>MOVE statements worked fine. Skipping the short header record *might* have 
>solved the issue. (Just a guess)
>
>Kolusu
>

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

Re: Program now working, but why?

[Jesse 1 Robinson]

Rather than trying to infer the cause by tweaking everything in sight, how 
about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any 
kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
quickly than trial-and-error with recompiles/reassemblies/logic-changes.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Tuesday, February 07, 2017 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Program now working, but why?

"My guess is that the call for the header record passed the record from the FD 
buffer. And subsequent calls pass the record after it's moved to WORKING 
STORAGE".

If the AMBLIST output looks good (comparison of new to Production), then I'm 
pretty sure there is no direct problem with addressability of the data "under" 
the FD as far as the Assembler program is concerned. The IO areas will be 
within the addressable area of where the program is loaded.

However, it can't hurt to see the compiler options used, and the 
linkedit/binder options used (used, not just those supplied to override).


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

Re: Program now working, but why?

[Farley, Peter x23353]

But a COBOL V4.2 recompile with compiler option DATA(31) will put 
WORKING-STORAGE in 31-bit address ranges rather than 24-bit, causing the 24-bit 
assembler program to fail  S0C4.

I think that is the OP's real issue, but he has to verify the compiler options 
actually used for the recompile.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Tuesday, February 07, 2017 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

>>> In this case, because it is the behavior of the header record  (which 
for one I'm assuming is the first record), these would only  be potential 
issues if the file only consisted of the header, no  other records.

Bill,

Not really.  Assuming that OP's program is indeed dealing with VB files, 
the header might be a Short record and the MOVE resulted in moving the 
full length than the actual short record length and hence the S0C4. The 
detailed records following the Header record *may* be of full length and 
MOVE statements worked fine. Skipping the short header record *might* have 
solved the issue. (Just a guess)

Kolusu

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
02/07/2017 02:13:13 PM:

> From: Bill Woodger <bill.wood...@gmail.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/07/2017 02:13 PM
> Subject: Re: Program now working, but why?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> In this case, because it is the behaviour of the header record 
> (which for one I'm assuming is the first record), these would only 
> be potential issues if the file only consisted of the header, no 
> other records.
> 
> 
> 
> Of course, the header record can be a coincidence. In changing the 
> code, the size of 
> 
> On Tue, 7 Feb 2017 13:39:11 -0700, Sri h Kolusu <skol...@us.ibm.com> 
wrote:
> 
> >>>> The programmer added code to bypass the header record on the first 
> >file read, now it runs at the development level.
> >
> >You may want to check this out
> >
> >http://www-01.ibm.com/support/docview.wss?uid=swg21242182
> >
> >
> >Kolusu
> >
--

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 is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Program now working, but why?

[Sri h Kolusu]

>>> In this case, because it is the behavior of the header record  (which 
for one I'm assuming is the first record), these would only  be potential 
issues if the file only consisted of the header, no  other records.

Bill,

Not really.  Assuming that OP's program is indeed dealing with VB files, 
the header might be a Short record and the MOVE resulted in moving the 
full length than the actual short record length and hence the S0C4. The 
detailed records following the Header record *may* be of full length and 
MOVE statements worked fine. Skipping the short header record *might* have 
solved the issue. (Just a guess)

Kolusu

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
02/07/2017 02:13:13 PM:

> From: Bill Woodger <bill.wood...@gmail.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/07/2017 02:13 PM
> Subject: Re: Program now working, but why?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> In this case, because it is the behaviour of the header record 
> (which for one I'm assuming is the first record), these would only 
> be potential issues if the file only consisted of the header, no 
> other records.
> 
> 
> 
> Of course, the header record can be a coincidence. In changing the 
> code, the size of 
> 
> On Tue, 7 Feb 2017 13:39:11 -0700, Sri h Kolusu <skol...@us.ibm.com> 
wrote:
> 
> >>>> The programmer added code to bypass the header record on the first 
> >file read, now it runs at the development level.
> >
> >You may want to check this out
> >
> >http://www-01.ibm.com/support/docview.wss?uid=swg21242182
> >
> >
> >Kolusu
> >
> 
> --
> 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: Program now working, but why?

[Bill Woodger]

In this case, because it is the behaviour of the header record (which for one 
I'm assuming is the first record), these would only be potential issues if the 
file only consisted of the header, no other records.



Of course, the header record can be a coincidence. In changing the code, the 
size of 

On Tue, 7 Feb 2017 13:39:11 -0700, Sri h Kolusu  wrote:

 The programmer added code to bypass the header record on the first 
>file read, now it runs at the development level.
>
>You may want to check this out
>
>http://www-01.ibm.com/support/docview.wss?uid=swg21242182
>
>
>Kolusu
>

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

Re: Program now working, but why?

[Jesse 1 Robinson]

A hugely frustrating corollary is that even if you conclude that changing x to 
y caused the problem, changing y back to x does not necessarily fix it. ;-)

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, February 07, 2017 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Program now working, but why?

One important lesson of life in computer programming is that "it worked when I 
changed 'x' to 'y'" does not mean that 'x' is the problem and 'y' is the 
solution. 

Some aspect of your development compile (lack of optimization?) or test 
environment may be masking the real problem.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: Tuesday, February 07, 2017 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

The production assembler program is AM 24 and RM 24.

The production COBOL program is AM 24 and RM 24. (runs, calls assembler program)

The development COBOL program is AM ANY and RM 24. (does not run (SOC4 in 
assembler program), does run with mentioned coding change, calls assembler 
program)


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

Re: Program now working, but why?

[Sri h Kolusu]

>>> The programmer added code to bypass the header record on the first 
file read, now it runs at the development level.

You may want to check this out

http://www-01.ibm.com/support/docview.wss?uid=swg21242182


Kolusu

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
02/07/2017 11:45:05 AM:

> From: Peter Ten Eyck <peter.tene...@americannational.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/07/2017 11:45 AM
> Subject: Program now working, but why?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> We have an OS/VS COBOL program that calls an assembler program that 
> runs fine in production (z/OS 2.2).
> 
> We brought down the COBOL program to development and compiled the 
> program using Enterprise COBOL 4.2. The compile output and link 
> output look good, no concerning messages. I ran an AMBLIST on both 
> the production and the newly created development load modules and 
> they are identical in the "M O D U L E   S U M M A R Y" report.
> 
> The program gets a SOC4 (in the called assembler program) when run 
> at the development level and runs fine at the production level, the 
> only change is the compile.
> 
> The programmer added code to bypass the header record on the first 
> file read, now it runs at the development level.
> 
> Scratching my head why... did not see anything in the migration 
> guide that explained it to me.
> 
> --
> 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: Program now working, but why?

[Bill Woodger]

"My guess is that the call for the header record passed the record from the FD 
buffer. And subsequent calls pass the record after it's moved to WORKING 
STORAGE".

If the AMBLIST output looks good (comparison of new to Production), then I'm 
pretty sure there is no direct problem with addressability of the data "under" 
the FD as far as the Assembler program is concerned. The IO areas will be 
within the addressable area of where the program is loaded.

However, it can't hurt to see the compiler options used, and the 
linkedit/binder options used (used, not just those supplied to override).

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

Re: Program now working, but why?

[Gibney, Dave]

My guess is that the call for the header record passed the record from the FD 
buffer. And subsequent calls pass the record after it's moved to WORKING STORAGE

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Tuesday, February 07, 2017 12:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Program now working, but why?
> 
> Let's guess that the program is statically binderered/linkedited.
> 
> Firstly, it is entirely possible that even 100% identical programs in 
> Production
> and Test "work" and "fail". After all, that's how we get Production failures. 
> So,
> same data, or not?
> 
> You seem just ever-so-slightly guarded about messages. Were there *any*
> messages from the COBOL program?
> 
> There are some "behavioural" changes from OS/VS COBOL to later ones, but
> they are in the Migration Guide (or at least "a" Migration Guide).
> 
> Why did someone decide to code-around the header record? Part of a
> strategy of ignoring all records one by one, or something more purposeful?
> 
> It sounds like the header is causing the problem. Is the header the "same"
> (length, types of values) in Production? My guess for now is that something
> about the header is causing an issue in the Assembler program.
> 
> Mmm... single CALL to the Assembler (in a PERFORMed procedure)? Multiple
> physical CALLs? If the latter, do all CALLs have the same number of
> parameters? There's a possibility there, but stretching to make it a guess 
> with
> information so far.
> 
> --
> 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: Program now working, but why?

[Bill Woodger]

Let's guess that the program is statically binderered/linkedited.

Firstly, it is entirely possible that even 100% identical programs in 
Production and Test "work" and "fail". After all, that's how we get Production 
failures. So, same data, or not?

You seem just ever-so-slightly guarded about messages. Were there *any* 
messages from the COBOL program?

There are some "behavioural" changes from OS/VS COBOL to later ones, but they 
are in the Migration Guide (or at least "a" Migration Guide).

Why did someone decide to code-around the header record? Part of a strategy of 
ignoring all records one by one, or something more purposeful?

It sounds like the header is causing the problem. Is the header the "same" 
(length, types of values) in Production? My guess for now is that something 
about the header is causing an issue in the Assembler program.

Mmm... single CALL to the Assembler (in a PERFORMed procedure)? Multiple 
physical CALLs? If the latter, do all CALLs have the same number of parameters? 
There's a possibility there, but stretching to make it a guess with information 
so far.

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

Re: Program now working, but why?

[Charles Mills]

One important lesson of life in computer programming is that "it worked when I 
changed 'x' to 'y'" does not mean that 'x' is the problem and 'y' is the 
solution. 

Some aspect of your development compile (lack of optimization?) or test 
environment may be masking the real problem.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: Tuesday, February 07, 2017 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

The production assembler program is AM 24 and RM 24.

The production COBOL program is AM 24 and RM 24. (runs, calls assembler program)

The development COBOL program is AM ANY and RM 24. (does not run (SOC4 in 
assembler program), does run with mentioned coding change, calls assembler 
program)

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

Re: Program now working, but why?

[Peter Ten Eyck]

The production assembler program is AM 24 and RM 24.

The production COBOL program is AM 24 and RM 24. (runs, calls assembler program)

The development COBOL program is AM ANY and RM 24. (does not run (SOC4 in 
assembler program), does run with mentioned coding change, calls assembler 
program)

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

Re: Program now working, but why?

[Dale R. Smith]

On Tue, 7 Feb 2017 13:18:53 -0600, Peter Ten Eyck 
 wrote:

>Yes, that is what I thought initial also, but I compiled and linked the 
>program so that the load module is the same in that respect and confirmed with 
>an AMBLIST on each module. The thing that got the program running was that 
>coding change to bypass the header record on the file (not pass it to the 
>assembler program on the call). Does not make sense to me…

Are you saying that the COBOL program is linked RMODE 24?  Is the program 
compiled with RENT or NORENT?  If RENT then the DATA Compiler option controls 
where Working Storage is allocated, not the programs Rmode.  Is the header 
record that is passed to the Assembler program in the COBOL program's Working 
Storage or is it from a record defined in the FD for the file?  If it's in the 
file FD, then it is an external buffer and could very well be allocated above 
the line with Enterprise COBOL.  THe record would have to be moved to an area 
in Working Storage and passed to the Assembler program from that area instead.  
Making the  Assembler program work in Amode 31 would be the best choice, but it 
could involve more work!

-- 
Dale R. Smith 

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

Re: Program now working, but why?

[Jesse 1 Robinson]

One of the first programs I wrote early in my career worked fine until--in this 
case the reverse--the program went from test to production. The load module was 
incorrectly marked RENT. It didn't matter in the test environment, but the 
production library was APF authorized. That caused the RENT program to be 
loaded into store-protected storage. Exactly the same code. S0C4 in execution. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, February 07, 2017 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Program now working, but why?

Is the assembler routine LE Compliant of Compatible?

Does it use the CEE macros to establish the LE environment?

When was it last assembled?

What does the summary dump look like? Is it S0C4-04?  Is it an authorized 
program running in an unauthorized library?

So many questions.  The dump should tell you why the S0C4 occurred.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Peter Ten Eyck
> Sent: Tuesday, February 07, 2017 11:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Program now working, but why?
> 
> We have an OS/VS COBOL program that calls an assembler program that 
> runs fine in production (z/OS 2.2).
> 
> We brought down the COBOL program to development and compiled the 
> program using Enterprise COBOL 4.2. The compile output and link output 
> look good, no concerning messages. I ran an AMBLIST on both the 
> production and the newly created development load modules and they are 
> identical in the "M O D U L E S U M M A R Y" report.
> 
> The program gets a SOC4 (in the called assembler program) when run at 
> the development level and runs fine at the production level, the only 
> change is the compile.
> 
> The programmer added code to bypass the header record on the first 
> file read, now it runs at the development level.
> 
> Scratching my head why... did not see anything in the migration guide 
> that explained it to me.


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

Re: Program now working, but why?

[Peter Ten Eyck]

Yes, that is what I thought initial also, but I compiled and linked the program 
so that the load module is the same in that respect and confirmed with an 
AMBLIST on each module. The thing that got the program running was that coding 
change to bypass the header record on the file (not pass it to the assembler 
program on the call). Does not make sense to me…
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Program now working, but why?

[Dale R. Smith]

On Tue, 7 Feb 2017 12:45:05 -0600, Peter Ten Eyck 
 wrote:

>We have an OS/VS COBOL program that calls an assembler program that runs fine 
>in production (z/OS 2.2).
>
>We brought down the COBOL program to development and compiled the program 
>using Enterprise COBOL 4.2. The compile output and link output look good, no 
>concerning messages. I ran an AMBLIST on both the production and the newly 
>created development load modules and they are identical in the "M O D U L E   
>S U M M A R Y" report.
>
>The program gets a SOC4 (in the called assembler program) when run at the 
>development level and runs fine at the production level, the only change is 
>the compile.
>
>The programmer added code to bypass the header record on the first file read, 
>now it runs at the development level.
>
>Scratching my head why... did not see anything in the migration guide that 
>explained it to me.

My guess would be that the Assembler program is running Amode 24.  OS/VS COBOL 
programs could only run Rmode 24 so any data areas passed to Assembler programs 
are below the line and available to Amode 24 programs.  Enterprise COBOL 4.2 is 
probably creating an Rmode ANY Load Module and now the data area being passed 
to the Assembler program is above the line and only available to Amode 31 and 
above programs.  You can try changing the Assembler program to run Amode 31 or 
you will have to make sure the COBOL program is linked Rmode 24.  (If you are 
using the RENT Compile option, then you would have to specify the DATA(24) 
Compiler option to have your COBOL Working Storage allocated below the line.

-- 
Dale R. Smith

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

Re: Program now working, but why?

[Peter Ten Eyck]

I have been looking at the dump capture in Abend-Aid.


Is the assembler routine LE Compliant of Compatible?

Not sure how to tell. Based on the assemble date (12 MAY 1989) I will say no.


Does it use the CEE macros to establish the LE environment?

No


When was it last assembled?

12 MAY 1989


What does the summary dump look like? Is it S0C4-04?

Just SOC4 according to Abend-Aid

Abend-Aid suggestions:
 -  Reference to a data area of a closed or unopened  
file. (Locate mode)   
 -  Reference to freemained or freepooled storage.
 -  Corrupted base register.  
 -  Incorrect or missing USING or DROP statement. 
 -  Incorrect use of a branching instruction. 
(B, BC, BAL, BALR, BCT, BCTR, BASR, BASSM, etc.)  
Example:  B R14   
instead of:   BRR14   
 -  Failure to supply a SAVEAREA for a subprogram 
or supervisor service which requires one. 
 -  Reference to a JFCB using TIOEJFCB.   
(Look for an odd JFCB address).   
 -  Attempting to access storage above
the 16m line when running amode 24.   


Is it an authorized program running in an unauthorized library?

No

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

Re: Program now working, but why?

[Jousma, David]

Sounds like an AMODE/RMODE problem to me.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: Tuesday, February 07, 2017 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Program now working, but why?

We have an OS/VS COBOL program that calls an assembler program that runs fine 
in production (z/OS 2.2).

We brought down the COBOL program to development and compiled the program using 
Enterprise COBOL 4.2. The compile output and link output look good, no 
concerning messages. I ran an AMBLIST on both the production and the newly 
created development load modules and they are identical in the "M O D U L E   S 
U M M A R Y" report.

The program gets a SOC4 (in the called assembler program) when run at the 
development level and runs fine at the production level, the only change is the 
compile.

The programmer added code to bypass the header record on the first file read, 
now it runs at the development level.

Scratching my head why... did not see anything in the migration guide that 
explained it to me.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Program now working, but why?

[Lizette Koehler]

Is the assembler routine LE Compliant of Compatible?

Does it use the CEE macros to establish the LE environment?

When was it last assembled?

What does the summary dump look like? Is it S0C4-04?  Is it an authorized 
program running in an unauthorized library?

So many questions.  The dump should tell you why the S0C4 occurred.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Ten Eyck
> Sent: Tuesday, February 07, 2017 11:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Program now working, but why?
> 
> We have an OS/VS COBOL program that calls an assembler program that runs fine
> in production (z/OS 2.2).
> 
> We brought down the COBOL program to development and compiled the program
> using Enterprise COBOL 4.2. The compile output and link output look good, no
> concerning messages. I ran an AMBLIST on both the production and the newly
> created development load modules and they are identical in the "M O D U L E
> S U M M A R Y" report.
> 
> The program gets a SOC4 (in the called assembler program) when run at the
> development level and runs fine at the production level, the only change is
> the compile.
> 
> The programmer added code to bypass the header record on the first file read,
> now it runs at the development level.
> 
> Scratching my head why... did not see anything in the migration guide that
> explained it to me.
> 

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

Program now working, but why?

[Peter Ten Eyck]

We have an OS/VS COBOL program that calls an assembler program that runs fine 
in production (z/OS 2.2).

We brought down the COBOL program to development and compiled the program using 
Enterprise COBOL 4.2. The compile output and link output look good, no 
concerning messages. I ran an AMBLIST on both the production and the newly 
created development load modules and they are identical in the "M O D U L E   S 
U M M A R Y" report.

The program gets a SOC4 (in the called assembler program) when run at the 
development level and runs fine at the production level, the only change is the 
compile.

The programmer added code to bypass the header record on the first file read, 
now it runs at the development level.

Scratching my head why... did not see anything in the migration guide that 
explained it to me.

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