|
View previous topic :: View next topic
|
| Author |
Message |
balukanna
New User
Joined: 09 Apr 2008
Posts: 41
Location: USA
|
|
|
|
Hi,
I am passing values from screen 1 to screen 2 thru Dfhcommarea, when returning back from Screen 2 to screen 1. in the program(screen 1), have a move statement to move DFHCOMMAREA to another variable.
on this statement i am getting SOC4, when tried the program in Trace and look into the commare values, it shows "Address error - probable corrupted BL/BLL cell".
The same set of programs/screens are working fine on another dev region.
When searched for this issue, found it can be due to mismatch of AMODE /RMODE in two programs but my case both programs have it 31. no mismatch.
Could someone help on finding the cause for ths error. |
|
| Back to top |
|
 |
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
Hi Balukanna,
Just wanted to confirm. Is this a COBOL or Assembler program ?
How are you returning back to Program 1 (Screen 1) from Program 2(Screen 2) ? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Have screen 1 or screen 2 (which is bad terminology, anyway -- they are actually programs handling maps) changed?
What is the size of DFHCOMMAREA in the first program?
What is the size of DFHCOMMAREA in the second program?
Has the size of DFHCOMMAREA been changed recently?
Despite your best efforts to pin this problem on the system, there is probably a 99.99% chance that the error is something in one or the other of the programs involved. The longer you place the blame on the system, the longer it will take you to resolve the issue. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
If you put the same data through the same programs at different times or in different places, they will behave the same.
If they don't behave the same, the programs are not the same.
Did you follow up on this dumb message "Address error - probable corrupted BL/BLL cell", by checking the value in the BLL cell for your DFHCOMMAREA? If the BLL is valid, then yes, I'd go for "corrupted" BL cell, but most likely the BLL is just "wrong" and you'll need to find out why, and at the same time you'll fix your problem. |
|
| Back to top |
|
|
balukanna
New User
Joined: 09 Apr 2008
Posts: 41
Location: USA
|
|
|
|
Hi,
This is a CICS-COBOL program, navigation between screen 1 & 2 are done thru XCTL.
Commarea of first program is 4000 and second one is 3000. |
|
| Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
Hi balukanna,
| Quote: |
| This is a CICS-COBOL program, navigation between screen 1 & 2 are done thru XCTL. |
You really need to understand what XCTL is... Try to understand the difference between XCTL and LINK - and then you would understand what you said does not make sense.
and again...  ...there is no XCTL navigations betweens screens... only programs navigate... |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
If you pass a 3000-byte DFHCOMMAREA from one program to another, and you then try to move 4000 bytes of a 3000-byte area within the second program, you WILL have problems.
Based upon your complete lack of understanding of basic terminology and you inability to answer the simple questions you've been asked, you really need to leave this forum and go to Beginners and Students Forum as you are a rank beginner, no matter how many years "experience" you claim. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
You should find a transaction-dump in the region's "Active" Dump Dataset, either DMPA or DMPB.
In this dump, you will find (amongst others), a TRACE.
Search for an "*EXC*" and this is where the S0C4 has occurred. Then, go up in the TRACE and begin reviewing the logic path and perhaps you may find the error, via Eyeballing 
Your CICS System Programmer and/or Tech Services personnel should have a JOB setup to print this transaction-dump and should assist you in determining the abend.
The program causing the S0C4 is attempting to address a piece of storage in LINKAGE which it doesn't have addressability. |
|
| Back to top |
|
|
|
|
