Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Changing blksize on JCL is changing a filler on output rec!!

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 5:22 pm    Post subject: Changing blksize on JCL is changing a filler on output rec!!
Reply with quote

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
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Jul 13, 2012 6:21 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Fri Jul 13, 2012 6:41 pm    Post subject:
Reply with quote

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
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 7:07 pm    Post subject:
Reply with quote

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
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 7:12 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Naish

New User


Joined: 07 Dec 2006
Posts: 82
Location: UK

PostPosted: Fri Jul 13, 2012 7:31 pm    Post subject:
Reply with quote

Not an expert (also difficult to comprehend your question icon_redface.gif ).

Could you check if you have VALUE INITIALIZED your FILLER (with zeroes, maybe)?
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Jul 13, 2012 7:50 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Jul 13, 2012 7:51 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Fri Jul 13, 2012 8:11 pm    Post subject: Reply to: Changing blksize on JCL is changing a filler on ou
Reply with quote

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
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 8:45 pm    Post subject: Re: Reply to: Changing blksize on JCL is changing a filler o
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Fri Jul 13, 2012 8:53 pm    Post subject: Reply to: Changing blksize on JCL is changing a filler on ou
Reply with quote

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
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 9:04 pm    Post subject: Re: Reply to: Changing blksize on JCL is changing a filler o
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Fri Jul 13, 2012 9:06 pm    Post subject: Reply to: Changing blksize on JCL is changing a filler on ou
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Fri Jul 13, 2012 9:25 pm    Post subject: Reply to: Changing blksize on JCL is changing a filler on ou
Reply with quote

Nihal,

Is this program OS/VS COBOL or VS COBOL II?
Back to top
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 9:29 pm    Post subject: Re: Reply to: Changing blksize on JCL is changing a filler o
Reply with quote

Bill O'Boyle wrote:
Is this program OS/VS COBOL or VS COBOL II?


Its VSII COBOL
Back to top
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 9:32 pm    Post subject: Re: Reply to: Changing blksize on JCL is changing a filler o
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Fri Jul 13, 2012 9:38 pm    Post subject: Reply to: Changing blksize on JCL is changing a filler on ou
Reply with quote

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
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Fri Jul 13, 2012 9:43 pm    Post subject: Re: Reply to: Changing blksize on JCL is changing a filler o
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sun Jul 15, 2012 2:28 am    Post subject: Reply to: Changing blksize on JCL is changing a filler on ou
Reply with quote

A simple method of determining the record-length of a variable-length file after a READ was introduced with VS COBOL II -

http://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.... icon_eek.gif
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1219
Location: Israel

PostPosted: Sun Jul 15, 2012 6:56 pm    Post subject: Reply to: Changing blksize on JCL is changing a filler on ou
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Problem in writing Output file vickey_dw COBOL Programming 5 Mon Nov 14, 2016 11:14 pm
No new posts Syncsort - Hard coded Value in output PORYES SYNCSORT 1 Thu Nov 03, 2016 9:23 am
No new posts output data in CSV Format janmejay COBOL Programming 8 Sat Oct 15, 2016 2:20 pm
This topic is locked: you cannot edit posts or make replies. output data in CSV Format janmejay DFSORT/ICETOOL 3 Sat Oct 15, 2016 2:16 pm
No new posts ICETOOL/SYNCSORT - SYSPRINT output nartcr DFSORT/ICETOOL 17 Wed Oct 05, 2016 10:46 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us