From: Pete Dashwood on

"Howard Brazee" <howard(a)brazee.net> wrote in message
news:2455p25b0d7efq4tg4k8bdrd1o6d3qa3ih(a)4ax.com...
> Shops I was with used to use variable length files quite a bit until
> around a couple of decades ago - when they switched to files with
> header and detail records for variable data - which dominated for a
> decade or so until they switched to external databases for the same
> kind of data.

Yes, that is certainly my approach; let the DBMS sort it out...

Pete


From: Anonymous on
In article <4vglitF1cepuaU1(a)mid.individual.net>,
Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>
><docdwarf(a)panix.com> wrote in message news:emtr65$6b5$1(a)reader2.panix.com...

[snip]

>> Therein lies the difficulty, Mr Dashwood... as I understand the original
>> poster's request the LRECL of TESTA changes from one run to the next;
>> there is no *the* LRECL size. Once again, from
>>
><http://groups.google.com/group/comp.lang.cobol/msg/e2bd0f47c45850c8?dmode=source>
>>
>> --begin quoted text:
>>
>> TESTA doesn't always have the same LRECL. Sometime TESTA will be defined
>> in the JCL with LRECL=30. Other times, it will be have LRECL=70. And so
>> on. My problem is how should TESTA be represented in FD?
>>
>> --end quoted text
>
>Ah, yes...I had overlooked that. Thanks for clarifying. It looks to me like
>RECFM=VB has to be a requisite (maybe RECFM=U, though I've not had any
>experience with that...). If it CAN be done with RECFM=FB, it'll be very
>interesting to see how...
>
>Thanks for your time.

You're most welcome, Mr Dashwood... would that the originator of this
thread might be equally as gracious but... perhaps the due-date for this
particular homework assignment has passed.

DD

From: Roger While on
Doesn't help for mainframe presumably but MicroFocus
(also OpenCOBOL) have CBL_OPEN_FILE, CBL_READ_FILE,
CBL_WRITE_FILE, CBL_CLOSE_FILE calls to manipulate files at the
"raw" level without any SELECT/FD's.
The length is passed as a parameter to read any specific chunk.


From: Robert Jones on

manubay(a)pacbell.net wrote:
> Is there a way in Cobol to handle an input file that has variable
> LRECL? If there is, how would it be defined in the FD section? Thank
> you.

I wrote a program in 1979 with the folowing input FDs, on an IBM
mainframe, presumably with OS/VS2 COBOL.


* fixed length record FD
FD FILE1
RECORDING MODE IS F
LABEL RECORDS ARE STANDARD
BLOCK CONTAINS 0 RECORDS
RECORD CONTAINS 0 CHARACTERS.
01 IFAREC.
03 IFABYTE PIC X OCCURS 10000.
SKIP3
* variable length record FD
FD VILE1
RECORDING MODE IS V
LABEL RECORDS ARE STANDARD
BLOCK CONTAINS 0 RECORDS
RECORD CONTAINS 0 CHARACTERS.
01 IVAREC.
03 IVABYTE PIC X OCCURS 10000.
SKIP3

It was still working in the late 1980s.

It is quite likely that it would still work, though the current
standard and maybe the 1985 one too, has made the RECORDING MODE
clause obsolete (as well as the LABEL clause), thereby apparently
making it impossible for the compiler to usefully detect whether the
mode is fixed or variable in these cases. However, IBM still permits
their use as an extension, but for how long and whether with the same
effect, I don't know.

A format 3 RECORD clause (aa per 2002 standard) might do the trick
depending on the compiler (as the standard says that it is implementor
defined how it is actually implemented with respect to some of hte
details)
i.e.

RECORD CONTAINS integer-4 TO integer-5 CHARACTERS, where integer-4 must
be greater than or equal to zero (anyone like to tell me how to
detect/write a zero length record, when it doesn't have a 4byte RDW and
what its use might be!) and integer-5 must be greater than integer-4.
This construct might make it possible for the same FD statement to read
either fixed or variable record length files for some implementors.


Robert

From: Vivian on

manubay(a)pacbell.net wrote:
> Is there a way in Cobol to handle an input file that has variable
> LRECL? If there is, how would it be defined in the FD section? Thank
> you.

..........
The problem is all inside your head
She said to me
The answer is easy if you
Take it logically
I'd like to help you in your struggle
.........

Sorry, the song got stuck in my head while reading through this
one......

The answer is to find yourself a real veteran, do it in assembler on
the mainframe, and call the assembler routine from your cobol program.