|
View previous topic :: View next topic
|
| Author |
Message |
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
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 |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| What is the actual block size of the output? |
|
| Back to top |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
Hi CICS Guy,
The acutal Block Size of the output file created is 27872.
Thanks |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| What does the SELECT look like? |
|
| Back to top |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
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 |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| 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 |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
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 |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
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 |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
Hi CICS Guy,
I tried initializing individual variables instead of the group. However still the over-lapping remains.
Thanks |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| 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 |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
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. 
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
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 |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
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 |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| 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 |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| 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 |
|
|
Learncoholic
New User
Joined: 20 Sep 2007
Posts: 97
Location: India
|
|
|
|
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 |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I am reporting some numeric data also (which I didn't mention in my post earlier). So moving spaces will result in compilation error. |
If you move spaces to the entire print line (not the individual fields), there will be no compile error. |
|
| Back to top |
|
|
|
|
