View previous topic :: View next topic
|
Author |
Message |
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
Hey
I'm writing a record of lenth 117 in a file. The below is the DD card for the output file in the JCL.
//IHSTEXCP DD DSN=XXXXXX.MASTIHST.EXCD,
// DISP=(NEW,CATLG,CATLG),
// DCB=(DSORG=PS,RECFM=FB,LRECL=117,BLKSIZE=0),
// UNIT=SMALL,SPACE=(TRK,(200,10),RLSE)
When I open the output file, the 1st column of all the records are blank. ideally it should have value. But When i tried displaying the record in the COBOL code. I'm getting proper data.
Can anyone please tell me what would have gone wrong ? why column 1 is getting blanked ?
Thanks
Angeline |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
the 4th instruction in the write section has a problem. |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
you mean to say
// UNIT=SMALL,SPACE=(TRK,(200,10),RLSE) has some problem ? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
define blank and proper data
when You say open I guess that You really mean something like ISPF browse , don' t You ?
use HEX on and tell us what You see !
using the exact terminology is essential for good communication and understanding! |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
The proper data is something like this.
Code: |
23032972002002 XXXXX XXXX XXXX |
But the output I'm getting is
Code: |
3032972002002 XXXXX XXXX XXXX |
So the tow is being replaced with Blank. When I open the file is Dsu 4, and put hex on, I get the below data.
Code: |
3032972002002 3032972002 SUS SUS-SSID
4FFFFFFFFFFFFF4FFFFFFFFFF44444444EEE44EEE6EECC
0303297200200203032972002000000002420024202294
|
Hope I made the pbm sound clear.
Thanks |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
what the heck is Dsu 4 ?
and how does the HEX data relate to the other two ?
and
Quote: |
But When i tried displaying the record in the COBOL code. |
what does it mean ? |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
i mean in ISPF. Sorry!!! |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
well we now know everything except - control cards?
- example of input data records
- example of expected output datarecords
probably time to address the issue - incorrect sort control card
instead of spending time listening to your analysis. (have you noticed the first 4 letters of analysis?) |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
1. No control card is used.
2. I have two input files which are processed and the output records are written in a file of fixed size using cobol code.
3. The output records is expected to look as
23032972002002 XXXXX XXXX XXXX
but what I'm getting in the file is
b3032972002002 XXXXX XXXX XXXX
where b in red is blank. |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
When I give display command in teh COBOL code just before the code writes the records into the file, I'm getting the expected output.
But once wriirten in the file, when I check the file, I have all banks in the 1st column of the file.
I dont understand which 4letters you are talking about ?
Thanks |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2454 Location: Hampshire, UK
|
|
|
|
Why are you posting this in the dfsort forum if it is a cobol program? You were asked questions, and had comments mde, that were relevant for a sort question. You have not only wated your time but that of several other people. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
Topic moved to COBOL forum |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
ok- COBOL problem.
1. need to analyse (we need to see - please cut & paste) the - FD definition
- Cobol display statement
- write statement
- relevent Structure definitions
|
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
Please find the details.
1. FD IHSTEXCP
LABEL RECORDS ARE STANDARD
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS.
01 IHSTEXCP-REC PIC X(117).
2. WRITE IHSTEXCP-REC FROM WS-IHSTEXCP-DTL
3. 01 WS-IHSTEXCP-DTL.
05 WS-EXCP-BXX PIC X(14) VALUE SPACES.
05 FILLER PIC X(01) VALUE SPACES.
05 WS-EXCP-WXX PIC X(10) VALUE SPACES.
05 FILLER PIC X(01) VALUE SPACES.
05 WS-EXCP-UXXX PIC X(05) VALUE SPACES.
05 FILLER PIC X(01) VALUE SPACES.
05 WS-EXCP-DESC PIC X(43) VALUE SPACES.
05 FILLER PIC X(01) VALUE SPACES.
05 WS-EXCP-MSG PIC X(40) VALUE SPACES.
05 FILLER PIC X(01) VALUE SPACES.
4. DISPLAY "B4 WRITE EXCP: "WS-IHSTEXCP-DTL
WRITE IHSTEXCP-REC FROM WS-IHSTEXCP-DTL
DISPLAY "AFTER WRITE EXCP: "WS-IHSTEXCP-DTL
Also, in the JCL, for the output file DD card, the file type is specified as FB.
//IHSTEXCP DD DSN=XXXXXX.MASTIHST.EXCD,
// DISP=(NEW,CATLG,CATLG),
// DCB=(DSORG=PS,RECFM=FB,LRECL=117,BLKSIZE=0),
// UNIT=SMALL,SPACE=(TRK,(200,10),RLSE)
But when i checked the output file created, it was of type FBA.
Thanks
Angeline |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
The first byte of an FBA file will always be the carriage control byte -- blank for single space, 0 for double space, 1 for top of form, + for overprint, and so forth. So the mystery of where your first byte is going is resolved -- it is being changed to space for carriage control.
Now the question becomes, why is the file FBA instead of FB? What does your SELECT statement look like? |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
that looks simple though...
SELECT IHSTEXCP ASSIGN TO UT-S-IHSTEXCP. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
How many WRITE statements for the file are in the program? Do any of them have the AFTER phrase? |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
The WRITE statement is used quite a few times for writing header, footer and data. But none of the WRTIE has AFTER phrase. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
Is the ADV compile option set? If so , use NOADV and try again. |
|
Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010 Posts: 121 Location: Puerto Rico
|
|
|
|
Good day to all!
In your DCB the BLKSIZE should be 117 because you have one record per block and your LRECL is 117 which in this case the BLKSIZE equal LRECL. |
|
Back to top |
|
|
Angeline
New User
Joined: 22 Jul 2010 Posts: 10 Location: India
|
|
|
|
Hey
No Luck... Still the file is created as FBA... |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
Jose Mateo: actually, you're not right in stating BLKSIZE should be 117. The COBOL code has BLOCK CONTAINS 0 RECORDS, which indicates that the block size will be set by the JCL and COBOL will use the system block size. The JCL has BLKSIZE=0, which is used by the system to indicate that the maximum block size for the device should be used. For disk, the block size will be as close to 27998 (half-track) as possible while for tape the block size will be as close to 32760 as possible. Block size will be 27963 for a disk file, which is implied by the UNIT and SPACE parameters of the JCL. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
Angeline: something is causing the COBOL program to use the first byte of the record as carriage control. It is not obvious from your posts what that something is. Your best workaround, in the absence of a solution, is to add a filler byte to the beginning of the record and change the file to 118 bytes instead of 117. The original 117 bytes are preserved in bytes 2 through 118 of the output record -- you'll have to make the code change(s) to support this. You can add a step to your job after the program execution to use IEBGENER to copy the 118-byte-record file to a 117-byte-record file. |
|
Back to top |
|
|
ridgewalker58
New User
Joined: 26 Sep 2008 Posts: 51 Location: New York
|
|
|
|
I have nothing to add in the way of a solution, all of you have given your input.
BUT, I have seen too many times where the REQUESTER gives incomplete information and you folks have to keep asking for more information.
For this one - the request came in --- Fri Apr 01, 2011 12:10 pm and you folks started answers within 3 minutes. With back and forth conversations, it took 4 hours for the requester to give you enough data to solve the problem.
You folks are very patient. Congratulations |
|
Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009 Posts: 365 Location: Denmark
|
|
|
|
Angeline wrote: |
The WRITE statement is used quite a few times for writing header, footer and data. But none of the WRTIE has AFTER phrase. |
What do you mean by that? Is your program writing report lines to another output DD?
If so, check if you by mistake have referenced your data output in any of the statements belonging to report output. |
|
Back to top |
|
|
|