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
 

 

COBOL moving header automatically after ever 670 record
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Wed Jan 27, 2010 3:04 pm    Post subject: COBOL moving header automatically after ever 670 record
Reply with quote

Hi,
This seems strange. But actually COBOL is moving header record to output after writing every 670 records. I am generating a report wherein I am moving a header record to the output file at the start of the program. Then I go on writing the output with detail record populated under the header but I do not explicitly move header record to the output data before writing. But however the header is being moved to output record area & then over written with the original data. Please find below a sample record:

Code:
POLICY NUMBER  |NEWGRP|STATUS|PORT CODE|PORT EFF DATE
xxxxxxxxxxxxxxx|12345P|STAOUS|PORTEEODE|POR20100701TE


The first of the above record is the header. The second record is detail record with data showing the part of the header that should not have been present. This is the case after every 670 records.

Please find the FD entry for the output file below:
Code:
FD  REPORT-FILE                       
    RECORDING MODE IS F               
    BLOCK CONTAINS 0 RECORDS         
    RECORD CONTAINS 208 CHARACTERS   
    LABEL RECORDS ARE STANDARD.       
01  DUP-BILLING-FILE-RECORD.         
    05 RPT-DATA1        PIC X(15).
    05 FILL1                PIC X(01).
    05 RPT-DATA2        PIC X(05).
    05 FILLER               PIC X(01).
    05 FILL2                PIC X(01).
    05 FILLER               PIC X(03).
    05 RPT-DATA3    PIC X(01).
    05 FILLER               PIC X(02).
    05 FILL3                PIC X(01).
    05 FILLER               PIC X(04).
    05 RPT-DATA4        PIC X(02).
    05 FILLER               PIC X(03).
    05 FILL4                PIC X(01).
    05 FILLER               PIC X(03).
    05 RPT-DATA5    PIC X(08).


Please let me know a way to get around this problem.
Thanks
Back to top
View user's profile Send private message

CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Wed Jan 27, 2010 5:10 pm    Post subject:
Reply with quote

What is the actual block size of the output?
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Wed Jan 27, 2010 5:15 pm    Post subject:
Reply with quote

Hi CICS Guy,

The acutal Block Size of the output file created is 27872.

Thanks
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Wed Jan 27, 2010 5:17 pm    Post subject:
Reply with quote

What does the SELECT look like?
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Wed Jan 27, 2010 5:33 pm    Post subject:
Reply with quote

Hi CICS Guy,

Please find below the usage of the SELECT verb as defined in the program:

Code:
SELECT REPORT-FILE   ASSIGN TO UT-S-REPORT


Thanks
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Wed Jan 27, 2010 6:05 pm    Post subject:
Reply with quote

Code:
xxxxxxxxxxxxxxx|12345 |   O  |    EE   |   20100701 
If this is what the non-corrupted data looks like, what hex values are the apparent blanks actually?
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Wed Jan 27, 2010 6:15 pm    Post subject:
Reply with quote

Hi CICS Guy,

The blanks is populated with Hex Value as below:

Code:
0004444444400
0000000000000


I am initializing DUP-BILLING-FILE-RECORD before each write & hence Blanks should be present in places where no data is being populated.

Thanks
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Wed Jan 27, 2010 6:26 pm    Post subject:
Reply with quote

That kind of explains it, the FILLERS will not will not be initialized and old data will still be there. Maybe just a move spaces would work better....
I just don't understand why five buffers are being used since every 670th record is the first record after outputting five blocks and restarting at the first block again, the record with the header.....
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Thu Jan 28, 2010 1:02 pm    Post subject:
Reply with quote

Hi CICS Guy,

I tried initializing individual variables instead of the group. However still the over-lapping remains.

Thanks
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Thu Jan 28, 2010 1:26 pm    Post subject: Reply to: COBOL moving header automatically after ever 670 r
Reply with quote

Quote:
Please let me know a way to get around this problem.


in the whole thread You told absolutely nothing useful,
You simply told that every 670 record You get a <data overlay>

very little we can do with such scarce info!
does the repetitive 670 pattern hint anything to You??

as I said in another thread
Quote:
very little we can do from here without having first hand access to Your environment

debugging is easy when You see everything with Your eyes, peripheral vision gives lots of hints

in this case a question/answers back and forth will simply be an unpleasant waste of time and a delay in getting a solution
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Thu Jan 28, 2010 3:33 pm    Post subject:
Reply with quote

Hi Enrico,

I am aware that I am not able to provide sufficient information for this defect in this thread, but I myself could not find nothing relevant with this defect. So at the end I posted it. icon_confused.gif

When I change the block size of the data set, this defect remains only 670 varies.
So can you please suggest me a way to set a specific blocksize to overcome this problem.
One way I believe is to move the header into a seperate Temporary file & then append the rest of the data & create a permanent file using a utility outside Cobol.

Thanks
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Thu Jan 28, 2010 4:07 pm    Post subject:
Reply with quote

Quote:
When I change the block size of the data set, this defect remains only 670 varies.
So can you please suggest me a way to set a specific blocksize to overcome this problem.
One way I believe is to move the header into a seperate Temporary file & then append the rest of the data & create a permanent file using a utility outside Cobol.
Does this not indicate to you that the problem is not the block size? Until you change your code to get rid of the root problem, there is no block size you can use that will prevent the problem.
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Thu Jan 28, 2010 5:25 pm    Post subject:
Reply with quote

Hi,

I changed the FD section to remove Fillers with declared datatypes & then later initialized them along with the rest of the data. This solved the problem.

Thanks for all your support.
Back to top
View user's profile Send private message
Kjeld

Active User


Joined: 15 Dec 2009
Posts: 365
Location: Denmark

PostPosted: Thu Jan 28, 2010 5:44 pm    Post subject:
Reply with quote

The problem is that LOW VALUES in the output record obviously do not get written to the output file buffer areas.

That means that the first line with the header in the first of 5 buffer areas will not get reset to the data lines format as fillers continue to hold low value.

I will suggest that you just move spaces to the DUP-BILLING-FILE-RECORD group instead of initialising it before writing each line. After all, non-printable characters are of no use in printed outut (provided you are not embedding printer control code in your print).
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Thu Jan 28, 2010 5:55 pm    Post subject:
Reply with quote

Quote:
I just don't understand why five buffers are being used
CICS Guy, the default buffering for QSAM files is 5 buffers per file. Horribly out of date and inefficient, but still the default.
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Thu Jan 28, 2010 5:57 pm    Post subject:
Reply with quote

Hi Kjeld,

I at first initialized the group DUP-BILLING-FILE-RECORD which showed this problem. Next I tried to initialize individual data items & still it retained the problem because the FILLERs were never initialized as rightly pointed by you & earlier by CICS Guy.
So I changed the FILLERs to data items like FILLERS01, FILLERS02 etc. & then initialized DUP-BILLING-FILE-RECORD. This worked out fine.

All I wanted to know whether there is any short-cut or easier alternative method of doing this because if the report contained many fields, we have to use many data items to replace the FILLERs.

Thanks
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Thu Jan 28, 2010 6:10 pm    Post subject:
Reply with quote

Robert Sample wrote:
CICS Guy, the default buffering for QSAM files is 5 buffers per file. Horribly out of date and inefficient, but still the default.
OK, that explains it (said the old VSE guy)....grin.....
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Thu Jan 28, 2010 6:14 pm    Post subject:
Reply with quote

Learncoholic wrote:
I changed the FD section to remove Fillers with declared datatypes & then later initialized them along with the rest of the data. This solved the problem.
Thanks for the feedback.
BTW, a simple move spaces will be a lot simpler than the initialize and then the fillers can remain just fillers.
Back to top
View user's profile Send private message
Learncoholic

New User


Joined: 20 Sep 2007
Posts: 73
Location: India

PostPosted: Thu Jan 28, 2010 6:21 pm    Post subject:
Reply with quote

Hi CICS Guy,

I am reporting some numeric data also (which I didn't mention in my post earlier). So moving spaces will result in compilation error.

Thanks
Back to top
View user's profile Send private message
Kjeld

Active User


Joined: 15 Dec 2009
Posts: 365
Location: Denmark

PostPosted: Thu Jan 28, 2010 6:21 pm    Post subject:
Reply with quote

Hi Learncoholic,
Learncoholic wrote:

All I wanted to know whether there is any short-cut or easier alternative method of doing this because if the report contained many fields, we have to use many data items to replace the FILLERs.

As I wrote, the short-cut would be to code at the start of each print line iteration:

Code:
MOVE SPACES TO DUP-BILLING-FILE-RECORD


With that you can define as many FILLER items you like and still get them blanked with the rest of the record. This is a group move, and you will not get compilation errors in numeric items.
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
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts How to update a portion of text in a ... Bill Woodger DFSORT/ICETOOL 25 Wed Nov 09, 2016 9:41 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts COBOL Version 6.1 Virendra Shambharkar COBOL Programming 5 Tue Nov 01, 2016 11:24 am
No new posts Cobol list of programs being called biswajit.dattagupta COBOL Programming 5 Tue Nov 01, 2016 2:10 am


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