Re: Program now working, but why?

"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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

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

Re: Program now working, but why?

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?

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?

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.

Re: Program now working, but why?

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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

Re: Program now working, but why?

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.

Re: Program now working, but why?

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 >

Re: Program now working, but why?

: 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

Re: Program now working, but why?

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

Re: Program now working, but why?

@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

Re: Program now working, but why?

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

Re: Program now working, but why?

@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

Re: Program now working, but why?

: 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

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

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

Re: Program now working, but why?

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:

Re: Program now working, but why?

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

Re: Program now working, but why?

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 WO

Re: Program now working, but why?

. 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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

Re: Program now working, but why?

-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

Re: Program now working, but why?

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

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

Re: Program now working, but why?

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

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

Re: Program now working, but why?

. 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

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)

Re: Program now working, but why?

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

Re: Program now working, but why?

- 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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

Re: Program now working, but why?

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

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