View previous topic :: View next topic
|
Author |
Message |
apandey
New User
Joined: 31 Aug 2009 Posts: 73 Location: Mumbai
|
|
|
|
Hi,
Is it necessary to have same LRECL of a input file in Cobol and JCL for a
variable block file.
Like I have a variable block file whose length is 133.
so I declared in FD section as below:
Code: |
FD INPUT-INTELLI-FILE
RECORDING MODE IS V
BLOCK CONTAINS 0.
01 INPUT-RECORD PIC X(129). |
But my this file's length would be changing day by day.
So how to declare tht length in cobol. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
What do you mean your file's length keeps chaging? Do you mean number of records?
If you define your variable-length records in the Cobol program such that the largest record on your file can fit inside, then you'll be OK.
Realise that the LRECL in the DCB contains the length of the RDW. Your Cobol definition will not include the RDW.
EDIT: By the way, you remember that discussion about "thanks" and all that stuff. What happened with your Sort question? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
But my this file's length would be changing day by day.
So how to declare tht length in cobol. |
The answer partly depends upon what you mean.
If you want the maximum length to change every day, then you must recompile the program every day. COBOL files, even variable length files, have a maximum length that is set WHEN THE PROGRAM IS COMPILED and that length cannot be changed unless you recompile the program. For a variable length file, each individual record length can be anywhere up to the maximum record length (subject to system limitations, of course).
If you want to use different length records with this file, there are two traditional ways to do so:
1. Code mutliple 01 levels under the FD, one for each length you want.
2. Use OCCURS DEPENDING ON
Each has advantages and drawbacks -- which to use depends upon your code. |
|
Back to top |
|
|
apandey
New User
Joined: 31 Aug 2009 Posts: 73 Location: Mumbai
|
|
|
|
Nopes ..!
My file can contain maximum of 12077 length.
But since its a variable block file, today its length is 133. NO I am not talking abt record here.
Since it will be picked up from a server and trasnferred to mainframe thru XCOM utility.
Initially I kept the FD definition of input file as :
Code: |
FD INPUT-INTELLI-FILE
RECORDING MODE IS V
BLOCK CONTAINS 0
RECORD IS VARYING FROM 1 TO 12077.
01 INPUT-RECORD PIC X(12077). |
but the job abended giving below reason:-
" A file attribute mismatch was detected. File INPUT-INTELLI-FILE in program LR930 had a record length of 12081
and the file specified in the ASSIGN clause had a record length of 133. "
So after that I have given above Declaration which is mentioned in my 1st post and program executed. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
I think you are very terribly confused. A variable length file with LRECL 12077 can have individual records that are 133 bytes long -- no problem. However, if the XCOM utility is creating records that have LRECL 133 then you have a MAJOR problem. You best solution in such a case would be to change the XCOM process to force the created files to each have LRECL 12077. Otherwise, you COULD use an IEBGENER step to copy the data uploaded from XCOM into a fixed file that is defined as RECFM=VB,LRECL=12081,BLKSIZE=0 and change your COBOL program to handle different length records. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Are you saying the file's LRECL is changing on a daily basis?
You can have a dataset with LRECL 12081 which solely contains records of 133 bytes, or indeed any combination of any number of bytes from 1 to 12077.
However, if you give your program a dataset with an LRECL of 133... your program is going to think "hey, there could be a 12077-length-of-data record coming along according to my coder, so I'd better take a quick dump, that must be the wrong file..." |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Review this previous post -
Variable length File
After a record is READ, field WS-INPUT-LGTH will contain the actual record-length.
If you're going to WRITE a record, define another field, such as WS-OUTPUT-LGTH and populate it with the actual record-length, before the WRITE.
If you're still on OS/VS COBOL, obtaining the record-length after a READ can be done, but the code is unsupported. |
|
Back to top |
|
|
apandey
New User
Joined: 31 Aug 2009 Posts: 73 Location: Mumbai
|
|
|
|
I have a text file kept at one server. Thru Xcom
Tht file will be picked and trasferred to mainframe.
Text file contains a characters as '\r\n'
I have to read this file in cobol write the record until '\r\n' char is found.
read the file again and write it to ouptut untill '\r\n' is found.
Do this processing till EOF.
Actually \r\n denotes the end of 1 complete record.
Here in text file it is present in 2-3 lines. But in output I want in Single line.
Attached is the text file. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Well, that's all very nice. What are you expecting us to do?
If the lrecl of your report is 12081, you should be able to read it in the Cobol program. |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
Please do not post attachments - I, for one, cannot, or will not, download them. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
the attachment was deleted,
any reason to post a record wit 3500 bytes of garbage,
if You need to split on \r \n verbatim a shorter record would have been more than enough |
|
Back to top |
|
|
apandey
New User
Joined: 31 Aug 2009 Posts: 73 Location: Mumbai
|
|
|
|
Bill, Enrico
As i said, a text file will be XCommed from a server to mainframe.
When i get this text file in mainframe its length is 133 and its variable block. But its maximum length can be 12077(excluding 4 bytes).
Here is input file:
Code: |
VIEW ZJ00.PA2806.EXPORT.FILE Columns 00001 00072
Command ===> Scroll ===> CSR
****** ***************************** Top of Data ******************************
000001 mark.van.rooijen@nl.abnamro.com|martin.eckhardt@nl.abnamro.com|PB1207510
000002 t|Goedemorgen collega's,
000003
000004 Ik stuur jullie deze mail naar aanleiding van de volgende ingevoerde nav
000005
000006 quote
000007 Blijkt bij buitenland overboeking dat tussen bank ( de Barclays Bank ) c
000008 plaats vinden van euro naar sterling. Dit is was niet de bedoeling. Zou
000009 eurobetaling moeten zijn/blijven. Kunnen jullie dit uitzoeken want is nu
000010 opgetreden.15-11-2011* EL1511003529906I BETAALD EUR 3.690,00 /GB07YORK0
000011 TURFTECH INTERNATIONAL LTD. INV. FP05 NAVRAAGRUBR: EL1511003529906I OVER
000012 BUITENLAND (mut. code:785) -3.690,00 EUR
000013 unquote
000014
000015 Er is een bericht ( antwoord ) binnengekomen van de Barclays Bank op 29
000016
000017 quote
000018 PLEASE BE ADVISED THAT FUNDS HAVE
000019 BEEN CONVERTED AS PER FX
000020 PROCEDURES AS THIS IS A FALSE
000021 CONVERSION WE WILL CONTACT THE
000022 BENE BANK TO ADVISE OF SHORTFALL
000023 AND UPDATE OUR SYSTEM FOR FUTURE
000024 PAYMENTS. REGARDS
000025 unquote |
Code: |
VIEW ZJ00.PA2806.EXPORT.FILE Columns 00001 00072
Command ===> Scroll ===> CSR
000025 unquote
000026
000027 Vrij vertaald zeggen zij dus dat ze het tekort zullen overmaken naar ban
000028 oekomst dit zullen proberen te voorkomen.
000029
000030 Ik vertrouw erop jullie afdoende te hebben geinformeerd.
000031
000032
000033 Met vriendelijke groet,
000034
000035 Investigations unit 1
000036 |2012-03-30 11:22:21.560\R\N |
So In above input file, last record contains '\R\N' , so till that I want to write all the data in output file as 1 single record.
Here is what i coded:
Code: |
*
FD INPUT-INTELLI-FILE
RECORDING MODE IS V
BLOCK CONTAINS 0
RECORD IS VARYING FROM 1 TO 129.
01 INPUT-RECORD PIC X(129).
*
FD OUTPUT-LOAD-FILE.
01 WS-OUTPUT-RECORD PIC X(12036). |
Here I hv given length as 129 coz earlier when i hv given 12077, it was throwing error as menitoned in my last post.
Keeping this LRECL 129 pgm got executed.
Procedure division :
Code: |
-------------------------------------------------------------
2000-PROCESS-LR930.
-------------------------------------------------------------
DISPLAY '2000-PROCESS-LR930'
INITIALIZE WS-OUTPUT-RECORD
CTR-FIELD
DISPLAY 'INPUT-RECORD : ' INPUT-RECORD
INSPECT INPUT-RECORD TALLYING CTR-FIELD FOR CHARACTERS
BEFORE INITIAL '\R\N'
DISPLAY 'CTR-FIELD: ' CTR-FIELD
MOVE INPUT-RECORD(1:CTR-FIELD) TO WS-OUTPUT-RECORD
PERFORM 9999-WRITE-OUTPUT-FILE
INITIALIZE INPUT-RECORD
PERFORM 1500-READ-INPUT.
|
SYSOUT is:
Code: |
BROWSE - SYSOUT STEP01 - Record 1 Columns 1-80
COMMAND ===> SCROLL ===> SCREEN
******************************** Top of Data **********************************
1500-READ-INPUT
2000-PROCESS-LR930
INPUT-RECORD : mark.van.rooijen@nl.abnamro.com|martin.eckhardt@nl.abnamro.com|P
9 EUR BANKREKENING Be
CTR-FIELD: 0000129
9999-WRITE-OUTPUT-FILE
1500-READ-INPUT
2000-PROCESS-LR930
INPUT-RECORD : t|Goedemorgen collega's,
CTR-FIELD: 0000129
9999-WRITE-OUTPUT-FILE
1500-READ-INPUT
2000-PROCESS-LR930
INPUT-RECORD :
CTR-FIELD: 0000129
9999-WRITE-OUTPUT-FILE
1500-READ-INPUT
2000-PROCESS-LR930
INPUT-RECORD : Ik stuur jullie deze mail naar aanleiding van de volgende ingevo
CTR-FIELD: 0000129
9999-WRITE-OUTPUT-FILE
1500-READ-INPUT
2000-PROCESS-LR930 |
Bill/Enrico
I didnt get ur last post. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
What is the LRECL of your dataset which contains the records which are 129 bytes long, plus RDW?
Are you saying you have two "problems"? First, how to define the input file and second how to put all the records together until you get the "/R/N"? |
|
Back to top |
|
|
apandey
New User
Joined: 31 Aug 2009 Posts: 73 Location: Mumbai
|
|
|
|
Ur answers
1st - LRECL is 133
2nd - YES |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Ok, if your 129+4 byte file had an LRECL of 12081 then you'd be able to read it with your original definition. Look back through previous comments in this topic.
Then you need some way to identify the trailing spaces, to not leave big lumps of space in the output, and the "\R\N" to know when you have finished.
The "modern" way seems to be to use FUNCTION REVERSE, INSPECT TALLYING for LEADING SPACE, calculate the length of the field minus the number of trailing blanks, and then use reference-modification. You'd need to have, presumably also reference-modified, a test for the last two bytes of data. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
COBOL is a "compiled language" - once the program is compiled, everything is written to stones - you can't change it, as Robert has also indicated. Having said that, if as a programmer, you expect that the input can vary up to 12077 - with COBOL you've got no choice -- "hard code" it in your program and JCL.
In FD you've to have RECORD IS VARYING FROM 1 to 12077 - now if for the given case, today you've got record of length with 133 - this will be taken care, because the COBOL definition says that program can deal up to 12077 of LERECL - but vice versa is not true. You're working with COBOL, not JAVA or C++, you don't have "control" what happens at run-time, from LERECL per se. |
|
Back to top |
|
|
|