Writing Variable File In Cobol

1. What Should Be The Record Length For A Variable Length File In Jcl
2. File Declaration In Cobol

HeyI have a problem.I use the following structure:01 B-Rec. Length FixPart: 34 B. Lenght VariablePart:+80 B x Num. Of Drivers / Truck. +20 B x Num. Of ServicePeriod/Driver/Truck. FixPart: fix 34 B.05 B-FixedPart.15 B-TruckPart PIC X(32).

DriverCounter.15 B-VarDCounter PIC 9(2). 1.

VarPart: max. 800 B. Installing tempco replacement windows. min.

80 B.05 B-VarPart OCCURS 1 TO 10DEPENDING ON B-VarFCounter.15 B-V-DriverPart PIC X(78).15 B-V-VarDCounter PIC 9(2). 2. VarPart: max. 2000 B. min. Hey I have a problem.I use the following structure:Which compiler are you using?

The following wouldn't compile for me, (NetExpress) until I used the ODOSLIDE directive; the compiler would give anerror on the second occurs.-$set ODOSLIDEProgram-id. RecVarying.Working-Storage Section.01 B-VarFCounter pic 9(03).01 TmpDCounter pic 9(03).01 B-Rec.05 B-FixedPart.15 B-TruckPart PIC X(32).15 B-VarDCounter PIC 9(2).05 B-VarPart OCCURS 1 TO 10DEPENDING ON B-VarFCounter.15 B-V-DriverPart PIC X(78).15 B-V-VarDCounter PIC 9(2).15 B-V-ServicePart OCCURS 1 TO 10DEPENDING ON TmpDCounter.20 B-V-SFrom PIC 9(10).20 B-V-STo PIC 9(10).Now before we go further, what's with your counters. As shown in my code thecounters are defined separately as 01 Levels.

So what's the purpose of:-15 B-VarDCounter PIC 9(2).15 B-V-VarDCounter PIC9(2).?Either move values to the 'separate' counters, or if using the 'in-tablecounters' move values into them to control the number of current occurs.Unless you are doing something really tricky, can't see the need for twopairs of counters.Now - if your tables were FIXED, both 'OCCURS' occurring ten, then you couldmove values into the counters to control the active set of occurs, and ensureyou don't do an invalid subscript access e.g. (6, 8) when you have previouslyset the occurs to say 3 and 4.Two the second part of your question. As a general guide it makes sense tohave your counters outside of the table.

However, if you were passing thetable to another program with a CALL, then it makes sense to have yourcounters INCLUDED in the table - then the receiving program knows what thecounter values are. Alternatively, when CALLING, you could pass both theexternal counters and the table (no inclusive counters).Yours is a fairly simple table, but as an exercise in XP(eXtremeProgramming), when moving values to counters, ENSURE they don't exceed themaximums you have set - report as an error if this happens.HTHJimmy, Calgary AB. 01 B-Rec.

Length FixPart: 34 B. Lenght VariablePart:+80 B x Num. Of Drivers / Truck. +20 B x Num. Of ServicePeriod/Driver/Truck. FixPart: fix 34 B. 05 B-FixedPart.

15 B-TruckPart PIC X(32). DriverCounter.

15 B-VarDCounter PIC 9(2). 1.

VarPart: max. 800 B. min. 80 B. 05 B-VarPart OCCURS 1 TO 10 DEPENDING ON B-VarFCounter. 15 B-V-DriverPart PIC X(78). 15 B-V-VarDCounter PIC 9(2).

2. VarPart: max. 2000 B. min. Any suggestion how to implement a 2 level variable record?The short answer is 'don't'. The long answer rants on about proper dataanalysis, normalisation, and how it would be done in a sane wnvironment,the conclusion of which is 'don't'.Variable records because of occurs depending on may have been requiredwhen there was a limit to the number of tape decks available for writingdata, but in modern systems (such as the last quarter century), thereshould be no excuse for not structuring the data properly in separatefiles.Fri, 01 Oct 2004 23:06:29 GMT. Others have already asked which compiler you are using.

Having an OccursDepending ON.nested. within another ODO (Occurs Depending On) is.illegal.according to current (and draft) ANSI/ISO Standards. Some compilers DOallow this (as an extension) but not all compilers even agree on thesemantics when it is allowed.I believe that MOST compilers that do allow nested ODO's do require that the'object of the ODO' be in fixed storage - either in the fixed part of arecord or in another part of storage (such as working-storage).I think the recommendation that I would make (agreeing with at least oneother already posted) is to NOT try an do this with nested variable lengthtables. Rather use fixed length tables - but with a 'counter' field thattells how many entries are 'useful' and where 'empty' entries begin - ateach level of the table.-Bill Kleinwmklein ix.netcom.com. Hey I have a problem.I use the following structure: 01 B-Rec.

Length FixPart: 34 B. Lenght VariablePart:+80 B x Num. Of Drivers / Truck. +20 B x Num.

Of ServicePeriod/Driver/Truck. FixPart: fix 34 B. 05 B-FixedPart. 15 B-TruckPart PIC X(32).

DriverCounter. 15 B-VarDCounter PIC 9(2). 1.

VarPart: max. 800 B.

min. 80 B. 05 B-VarPart OCCURS 1 TO 10 DEPENDING ON B-VarFCounter.

15 B-V-DriverPart PIC X(78). 15 B-V-VarDCounter PIC 9(2). 2. VarPart: max. 2000 B. min. Others have already asked which compiler you are using.

Having an Occurs Depending ON.nested. within another ODO (Occurs Depending On) is.illegal. according to current (and draft) ANSI/ISO Standards.

Some compilers DO allow this (as an extension) but not all compilers even agree on the semantics when it is allowed. I believe that MOST compilers that do allow nested ODO's do require that the 'object of the ODO' be in fixed storage - either in the fixed part of a record or in another part of storage (such as working-storage). I think the recommendation that I would make (agreeing with at least one other already posted) is to NOT try an do this with nested variable length tables. Rather use fixed length tables - but with a 'counter' field that tells how many entries are 'useful' and where 'empty' entries begin - at each level of the table.To add to what Bill says above, having sent my message, I then realized (Oops!)you were asking about 'WRITING.' As Richard says.DON'T. As Ianticipated you might come back and ask, I tried to write your table to a file -what a NIGHTMARE - I gave up!!!It's OK to use this varying approach for tables in memory, but it doesn'treally gain you anything.

What Should Be The Record Length For A Variable Length File In Jcl

Specify a table up to a maximum of say 3,000characters and whether or not you actually use the full table, memory is stillallocated. (Ignore the 'varying' and just use a counter for elements in thetable which are currently active - reiterating what Bill says above).It's a different ball game with OO collections/dictionaries where you onlyabsorb the memory you actually need for the elements included in yourcollection(table). Add new elements and your collection size increases; deleteelements - no change, not until you tell the collection to resize itself.Jimmy, Calgary ABFri, 01 Oct 2004 14:43:59 GMT.

File Declaration In Cobol

IBM MAINFRAME: Variable length file in cobol -::::AuthorMessageapandeyNew UserJoined: 31 Aug 2009Location: MumbaiPosted: Fri Apr 06, 2012 6:28 pm Post subject: Variable length file in cobolHi,Is it necessary to have same LRECL of a input file in Cobol and JCL for avariable 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-FILERECORDING MODE IS VBLOCK 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. Bill WoodgerDFSORT ModeratorJoined: 09 Mar 2011Posted: Fri Apr 06, 2012 6:34 pm Post subject: Reply to: Variable length file in cobolWhat 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?Robert SampleGlobal ModeratorJoined: 06 Jun 2008Location: Dubuque, Iowa, USAPosted: Fri Apr 06, 2012 6:40 pm Post subject: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 ONEach has advantages and drawbacks - which to use depends upon your code.apandeyNew UserJoined: 31 Aug 2009Location: MumbaiPosted: Fri Apr 06, 2012 6:54 pm Post subject: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-FILERECORDING MODE IS VBLOCK CONTAINS 0RECORD 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 12081and 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.Robert SampleGlobal ModeratorJoined: 06 Jun 2008Location: Dubuque, Iowa, USAPosted: Fri Apr 06, 2012 7:06 pm Post subject: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.