Variable Length Record
sri
I am not able to use Variable Length Records.
I get the Input file(INPUT-FILE) from some other program and based on
the value of a particular field I get through Linkage, the length of
the Input file varies.
Like if SEQ-NUM = '01' then Record Length will be 255 Characters
= '02' then Record Length will be 356 Characters
The First 255 characters are same.
In the FILE SECTION, FD CONTROL I used "RECORDING MODE IS V" AND
"RECORD VARIES FROM 255 TO 356 BASED ON WS-RECORD-LENGTH
and I declared WS-RECORD-LENGTH in WORKING-STORAGE section and moved
the length in Procedure Division.
When I tried to open the File, I got "File Status = 39"
Any Ideas!!!!!
Thanks
lsu...@mb.sympatico.ca
Your file definition does not match the file on disk....
--
Lorne Sunley
Jeff Raben
>Hi,
>
>I am not able to use Variable Length Records.
>
a record length has no meaning on INPUT files you get what is there.
Declaring a "DEPENDING" on some working storage entry has no meaning
for INPUT.
DEPENDING is used for output definition so that "WRITE" knows how much
to write.
Jeff
and stir with a Runcible spoon...
William M. Klein
If you use the RECORD VARYING IN SIZE DEPENDING ON ws-item
structure, then the ws-item *does* include the length of the record that is
read (on INPUT). It is true, that it only "determines" the length of the
record on OUTPUT (WRITE or REWRITE).
If you use the VARYING IN SIZE DEPENDING ON ws-item syntax, then you CAN use
the length in ws-item to determine which "structure" as been read (assuming
each is defined as a separate 01-level under your FD)
NOTE: The RECORD CONTAINS n TO m syntax (available before the '85 Standard
introduced the RECORD VARYING IN SIZE syntax) does NOT provide any way to
(legally) determine the size of a record that is read in.
--
Bill Klein
wmklein <at> ix.netcom.com
"Jeff Raben" <jra...@cascinc.com> wrote in message
news:3c2ce0e8...@news.bullseyetelecom.net...
Alain.FELER
IDENTIFICATION DIVISION.
PROGRAM-ID. VARIA.
* ( WORKS WITH COBOL MICROSOFT (IN FACT MICROFOCUS) V 4.5 )
* ( BUT THE ONLY NON-STANDARD ITEM IS THE LINE SEQUENTIAL CLAUSE)
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT FVAR ASSIGN TO "INPUT.TXT"
ORGANIZATION IS LINE SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS FS-FVAR.
DATA DIVISION.
FILE SECTION.
FD FVAR RECORD VARYING.
01 ST-BIG.
02 SEQ-NUM PIC 99.
02 FILLER PIC X(354).
01 ST-SHORT PIC X(255).
WORKING-STORAGE SECTION.
01 FS-FVAR PIC XX VALUE SPACES.
88 OK-FVAR VALUE "00".
88 EOF-FVAR VALUE "10".
PROCEDURE DIVISION.
MAIN-PARAGRAPH.
OPEN INPUT FVAR
READ FVAR AT END CONTINUE END-READ
PERFORM UNTIL EOF-FVAR
EVALUATE SEQ-NUM
WHEN "01" PERFORM USE-ST-SHORT
WHEN "02" PERFORM USE-ST-BIG
WHEN OTHER PERFORM SOMETHING-ELSE
END-EVALUATE
READ FVAR AT END CONTINUE END-READ
END-PERFORM
CLOSE FVAR
STOP RUN.
USE-ST-SHORT.
DISPLAY ST-SHORT.
USE-ST-BIG.
DISPLAY ST-BIG.
SOMETHING-ELSE.
DISPLAY "???".
sri <srip...@netzero.net> a écrit dans le message :
24df60cb.01122...@posting.google.com...
John H Sleight Jr
A var len record is not such (recfm=V or VB) because the recs in the file vary
in length. A VLR must start w/a 4 byte record descriptor word (RDW) that
contains the # of bytes in the rec, as well as the Block). If it is variable in
length but doesn't contain a RDW, it is an Undefined Record (recfm=U). Have you
determined this?
HTH, Jack.
In article <24df60cb.01122...@posting.google.com>, sri says...
Robert Sales
length, with this fixed length varying according to which file is actually
being opened.
There is no standard way of doing this in COBOL, but there is a trick you
can use in Micro Focus COBOL (probably in other implementations too). Which
COBOL compiler are you using ?
--
Robert Sales, Micro Focus
"sri" <srip...@netzero.net> wrote in message
news:24df60cb.01122...@posting.google.com...
Sff5ky
<Robert...@microfocus.com> writes:
>
>Trouble is the file itself does not have variable length records, but fixed
>length, with this fixed length varying according to which file is actually
>being opened.
>There is no standard way of doing this in COBOL, but there is a trick you
>can use in Micro Focus COBOL (probably in other implementations too). Which
>COBOL compiler are you using ?
>
In the OS\390 environment, it is possible to define the file as the largest
possible input record length and the system will chop off the input area based
on the length of the record specified in the DCB information of the DDname.
Granted that your program must have a means of 'getting' the record length.
I used a SYSIN parameter file that passed the characteristics of the file to be
processed.
I have not found a 'good' way of doing this same thing on the PC platform.
There does not seem to be a way of having the environment 'know' the
LRECL/BLKSIZE of files on the PC as everything seems to be read as
a continuous byte stream up to the internally defined LRECL/BLKSIZE.
Too bad there is not a way to issue a command like CHANGE ATTRIBUTE
MAXRECSIZE to set the internal attributes according to the particular
file requirements.
JerryMouse
"Sff5ky" <sff...@aol.comxxx123>
>
> I have not found a 'good' way of doing this same thing on the PC platform.
> There does not seem to be a way of having the environment 'know' the
> LRECL/BLKSIZE of files on the PC as everything seems to be read as
> a continuous byte stream up to the internally defined LRECL/BLKSIZE.
> Too bad there is not a way to issue a command like CHANGE ATTRIBUTE
> MAXRECSIZE to set the internal attributes according to the particular
> file requirements.
We've got a way, making use of the CBL_READ_FILE routines. In summary, it
works like this:
Set BEGIN to 0
LOOP:
Read file starting at BEGIN for maximum record length into buffer
Figure out length of record and move that many bytes from buffer to work
area
<process record>
add length to BEGIN
go to LOOP
I can send you a copy of the code if you like.
Sff5ky
<jerry...@invalid.com> writes:
>
>We've got a way, making use of the CBL_READ_FILE routines. In summary, it
>works like this:
>
>Set BEGIN to 0
>
>LOOP:
>Read file starting at BEGIN for maximum record length into buffer
>Figure out length of record and move that many bytes from buffer to work
>area
><process record>
>add length to BEGIN
>go to LOOP
>
>I can send you a copy of the code if you like.
>
This sounds much like some of the 'big block' logic we have where
we physically read a block as a record and manually process each
logical record as an occurrence within the physical record.
JerryMouse
"Sff5ky" <sff...@aol.comxxx123>
>
> This sounds much like some of the 'big block' logic we have where
> we physically read a block as a record and manually process each
> logical record as an occurrence within the physical record.
Sure. We have an additional refinement.
Each "word" in each record of our file is part of a key in an ISAM file and
coupled with the beginning byte of the record. So, if "DON'T EAT FEATHERS"
is a phrase in a record beginning at offset 1234567 bytes into the file, the
ISAM entries look like:
DONT 1234567
EAT 1234567
FEATHERS 1234567
The program looks up, say, "EAT," retrieves the file offset from the ISAM
file, then reads the data file starting at the supplied offset.
John H Sleight Jr
255-file and 356-file and uses SEQ-NUM to decide which one to process, the
problem becomes trivial, e.g.:
if seq-num = '01' open input 255-file else open input 356-file
if seq-num = '01' read 255-rec else read 356-rec
etc.
In article <24df60cb.01122...@posting.google.com>, sri says...
>
Sff5ky
<nos...@newsranger.com> writes:
>
>I think we're over-complicating Siri's problem. If he defines 2 files:
>255-file and 356-file and uses SEQ-NUM to decide which one to process, the
>problem becomes trivial, e.g.:
>
>if seq-num = '01' open input 255-file else open input 356-file
>
>if seq-num = '01' read 255-rec else read 356-rec
>
>etc.
I suppose that we could very well be over-complicating the issue,
but at what point are we able to determine the value of seq-num?
If seq-num is part of the record being read, it would seem that we
must have an initialization process to open the file and read the first
record to decide which file will be processed in mainline.
John H Sleight Jr
the file I/P itself. He also mentions that he codes the FD for the file. This
leads me to believe he must be opening and reading the file in toto as a result
of one call from a higher level module that passes him the record type (i.e.
length).
My take is that the SEQ-NUM fld serves to tell the CALLed module what FILE (not
record) to use as input.
In article <20020101193024...@mb-fb.aol.com>, Sff5ky says...
Sff5ky
<nos...@newsranger.com> writes:
>
>If I'm reading Sri correctly, he gets the SEQ-NUM from the Linkage Section,
>not
>the file I/P itself. He also mentions that he codes the FD for the file. This
>leads me to believe he must be opening and reading the file in toto as a
>result
>of one call from a higher level module that passes him the record type (i.e.
>length).
>
>My take is that the SEQ-NUM fld serves to tell the CALLed module what FILE
>(not
>record) to use as input.
>
MY bad!
Now that you mention it, I do recall reading a mention of LINKAGE.
That's what I get for deleting messages as I read them. :-}
Howard Brazee
bit. But over the years they got rarer and rarer, even though I did
contract work and switched jobs enough to see quite a few shops.
At first they got replaced with files with header and detail records.
Variable numbers of detail records where handled programmatically. Later
on, database records did the same thing.
I'm not sure why all these shops stopped using variable length records - but
believe this is a variation of KISS.
John H Sleight Jr
I know, I did a double take when I saw it myself. My forehead is still
smarting from the smack.
Jack
In article <20020102094350...@mb-fv.aol.com>, Sff5ky says...