|
View previous topic :: View next topic
|
| Author |
Message |
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
Hi,
I have just hit a strange problem.
(1)
I am working on a very old cobol program(80's). The program has an output file that is of VB type. There are 8-10 different record types and lengths on this file.
On one of the records, There a filler on far right of the record(last 3 bytes). This filler is getting overwritten with zero as soon as the "write o-rec-typ1" statement is done.
I did a little research and figured out that this 0 comes from the "File status" which is updated somewhere in FCB as soon as the file write is completed.
(2) Out of curiosity, I changed the blksize on JCL to max_record_length+4. And to my surprise, after this change, all the previously affected records now have an altogther different value in the last 3 bytes!!
I would like to know expert's opinion about this.
Cheers,
Nigel. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
You are not providing anywhere near the amount nor type of information needed to provide you much assistance. For example, you said
| Quote: |
| On one of the records, There a filler on far right of the record(last 3 bytes). This filler is getting overwritten with zero as soon as the "write o-rec-typ1" statement is done. |
which raises these questions:
1) Are all 3 bytes being overwritten or just 2 or just 1?
2) Binary zero (X'00') or character zero (X'F0') or something else?
3) Are you talking about data in the buffer (any 01-level in the FD)? If so, WHY ARE YOU LOOKING AT IT AFTER A WRITE? Once the data is written, a buffer may contain garbage, or it may contain data from the last record that was in that area of the buffer (if your program is doing enough writing). But in any case, that data should not be considered valid and you don't need to worry about it.
So the first observation I have, pending your answers to these questions, is that if you are looking at any buffer data after a write then you should expect what you see -- nothing more, nothing less -- since that data is controlled by the operating system via COBOL and you don't even need to be looking at it. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
After reading 3 times the original question, I recall "the sky is falling, the sky is falling" from the Ice Age movie. Before I also start rushing, I feel very confused about what are you asking after all? And I agree with Robert that information is too less to start with an answer.
| Quote: |
| On one of the records, There a filler on far right of the record(last 3 bytes). This filler is getting overwritten with zero as soon as the "write o-rec-typ1" statement is done. |
How do you know this?
You say, you changed the Block-size - what was it before? |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Quote: |
1) Are all 3 bytes being overwritten or just 2 or just 1?
|
The first 2 bytes getting overwritten with characters '00' i.e. X'F0F0'
| Quote: |
2) Binary zero (X'00') or character zero (X'F0') or something else?
|
X'F0'
| Quote: |
3) Are you talking about data in the buffer (any 01-level in the FD)?
|
yes the record i am talking about is defined under 01 in FD
Below are the detailed description of records:
| Code: |
** the first record type ** this is written after typ2
01 FR-typ1.
05 FILLER PICTURE X(12).
05 FR-typ1-data PICTURE X(110).
05 FR-typ1-line PICTURE X(56).
05 FR-typ1-DESC1 PICTURE X(219).
05 FR-typ1-DESC2 PICTURE X(62).
05 FR-typ1-FLG PICTURE X.
05 FILLER PICTURE X(3).
03 FR-typ1-ALL.
05 FR-typ1-CODES OCCURS 100 TIMES DEPENDING
ON FR-OCC-COUNT.
10 filler pic x(10).
** the second record type **
01 FR-typ2.
05 FR-typ2-RECORD-HEAD.
10 FR-typ2-SCODE1 PIC S9(4) COMP.
10 FR-typ2-SCODE2 PIC S9(4) COMP.
10 FR-typ2-REC-ID PIC 9(3) COMP-3.
10 FR-typ2-CD PIC X.
10 FR-typ2-DEL PIC X.
10 FILLER PIC S9(4) COMP.
10 FILLER PIC S9(4) COMP.
05 FR-typ2-TABLE-NAME PIC X(12).
05 FR-typ2-DESCRIPTION PIC X(70).
05 FR-typ2-TABLE-DATA.
10 FR-typ2-TABLE-ENTRY OCCURS 50 TIMES
DEPENDING ON FR-OCC-COUNT
INDEXED BY FR-TBL-IDX.
15 FR-typ2-START PIC X(07).
15 FR-typ2-END PIC X(07). |
As soon as the typ2 record is written, FR-typ1-FLG populates with C'0' and the next byte with another C'0'. I dont have any problem now as FR-typ2 is written ok.
But the problem arises when I have populated typ1 and about to write FR-typ1. The filler still retains the '0' and it is written onto the file which I dont want.
This is an old program and has been working in production for 20+ years. I dont want to add a fresh initialize statement because then I will need to thoroughly test everything with old data as well. |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Anuj Dhawan wrote: |
You say, you changed the Block-size - what was it before? |
it was 0000. i changed it to max-record-length + 4. |
|
| Back to top |
|
|
Naish
New User
Joined: 07 Dec 2006
Posts: 82
Location: UK
|
|
|
|
Not an expert (also difficult to comprehend your question  ).
Could you check if you have VALUE INITIALIZED your FILLER (with zeroes, maybe)? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
If you are working with code that did not ensure the initial values of every byte of the record before writing (i.e. MOVE SPACES TO OUT-REC), the content of these fields will often be quite unpredictable. . .
To make sure they are spaces or zeros or whatever, the code must make rure the values are there before each write (usually done when the record is being formatted). |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
1. FR-TYP1-CODES and FR-TYP2-TABLE-ENTRY both depend upon FR-OCC-COUNT. This is bad coding -- they should each have their own variable.
2. How on earth will a program using this data as an input file know how long the record is (how many occurrences of FR-TYP1-CODES and FR-TYP2-TABLE-ENTRY respectively) since the occurs is not based upon anything in the actual record? This is EXTREMELY BAD CODING to not include the length variable in the actual record when writing it.
3. Your statement here is complete and utter garbage:
| Quote: |
| As soon as the typ2 record is written, FR-typ1-FLG populates with C'0' and the next byte with another C'0'. I dont have any problem now as FR-typ2 is written ok. |
since it does not matter what is in FR-TYP1-FLG after a WRITE is executed -- you place the correct data in the variable before the WRITE occurs, so why even look at it? If you are not placing anything into that variable, that is part of your coding problem.
4. I suspect most of your problems are because you have no clue about how variable length (OCCURS DEPENDING ON) tables work in COBOL, and even less of a clue about how they impact buffers. You really need to spend the hours -- or days -- required to read the COBOL Language Reference and Application Programming Guide manuals until you understand these topics. Then you need to change your code to do the MOVE of data to the 01 levels correctly -- setting the appropriate FR-OCC-COUNT value first before moving anything to the tables. And, finally, you MUST stop looking at output buffers before you place data in them -- this is an ABSOLUTELY bad idea since you are supposed to place the data in them yourself. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Nihal,
I know it is an old program, but that is horrible. Not only no occurence count on the records, both records use the same ODO value, even though one occurs 100 and the other 50!
Do you have an actual problem or is this just something you "noticed" when using a debugger. This has been covered previously. Concentrate on what Robert has said and forget/revisit your researches. |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Bill Woodger wrote: |
Nihal,
I know it is an old program, but that is horrible. Not only no occurence count on the records, both records use the same ODO value, even though one occurs 100 and the other 50!
Do you have an actual problem or is this just something you "noticed" when using a debugger. This has been covered previously. Concentrate on what Robert has said and forget/revisit your researches. |
As I said earlier, there are 10 different record types. what I have pasted above are just 2 of those.
The "occurance count" variable is in the "fixed" part of the record which will be the same for all 10 types(the first 12 bytes). This variable will be involved in the calculation of RDW when a particular type of record is written There is no problem with the occurance count variable at all. Maybe I have not explained my question well.
Anyway, I have now figured out a way to solve this problem. I will post the solution once I am done. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Nihal,
You never got to tell us the actual problem this was giving you, as far as you are concerned.
This is how it works, so if you have a problem you'll have to look elsewhere.
The very-old-profgram is using the same data-name for two (up to 10) different purposes. This makes understanding the program more difficult in all the senses of that. |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Bill Woodger wrote: |
Nihal,
You never got to tell us the actual problem this was giving you, as far as you are concerned.
This is how it works, so if you have a problem you'll have to look elsewhere.
The very-old-profgram is using the same data-name for two (up to 10) different purposes. This makes understanding the program more difficult in all the senses of that. |
I am sorry if I sounded rude earlier.
Yes there are a lot of maintainability issues with this program. I agree. And this is certainly not the right way to code FD of VB records. This is an existing program and I had no other option but to code my changes the way other changes were done in the program. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Nihal,
Don't worry about how you think you might sound to someone else.
Please tell us what your problem was, which led you to thinking you had resolved it after looking at the record buffer after a record has been written. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Nihal,
Is this program OS/VS COBOL or VS COBOL II? |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Bill O'Boyle wrote: |
| Is this program OS/VS COBOL or VS COBOL II? |
Its VSII COBOL |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Bill Woodger wrote: |
Nihal,
Don't worry about how you think you might sound to someone else.
Please tell us what your problem was, which led you to thinking you had resolved it after looking at the record buffer after a record has been written. |
As you all said the problem was not really buffer. But it took me a little time to figure out.
An initialize statement if being used to "blank out" the record before populating. Initialize does not work on filler so the filler retains the junk value from the previous record(s). |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Nihal,
Glad you got it.
I think this has been throwing us off:
| Quote: |
| This filler is getting overwritten with zero as soon as the "write o-rec-typ1" statement is done. |
If you'd first explained like you did just now, you'd have got there sooner.
Have a good weekend. |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Quote: |
| This filler is getting overwritten with zero as soon as the "write o-rec-typ1" statement is done. |
At times I get too much into system area's details. and unnecessarily so.
Thanks Bill, and have a good weekend. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
A simple method of determining the record-length of a variable-length file after a READ was introduced with VS COBOL II -
www.ibmmainframes.com/viewtopic.php?p=191731&highlight=#191731
In the above link, field 'WS-INPUT-LGTH' would equal the length of the record just read. No muss, no fuss.
However, what you're proposing, in changing the BLKSIZE is not a good idea and not too sure if it would work....  |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| nigelosberry wrote: |
| I dont want to add a fresh initialize statement because then I will need to thoroughly test everything with old data as well. |
Now, this got me worried... |
|
| Back to top |
|
|
|
|
