Variable Length Input File
in [Cobol]
|
From: Pete Dashwood on 29 Dec 2006 18:56 "Vivian" <vsaegesser(a)infogix.com> wrote in message news:1167408108.184588.285750(a)79g2000cws.googlegroups.com... > > 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. > It's really not my habit to intrude Furthermore, I hope my meaning won't be lost or misconstrued But speaking as such a veteran And not meaning to be rude, I wouldn't use Assembler as a solution. Check out the post from Michael Matthias on this (MCM), 28/12/2006 in this thread. As for you, Vivian, get over it... there's more than 50 ways :-) Pete.
From: HeyBub on 29 Dec 2006 20:18 Vivian wrote: > > 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. I remember when we our company read (appx. it varies) 250,000 byte records, spilling them to disk, demultiplexing, and applying binary gain, on a machine with only 64K of core. It was done with channel programming by a "veteran." He was paid (in today's dollars) about $100/minute. Some don't have the resources to devote to a piddly problem like a maverick tape file issue.
From: Clark F Morris on 1 Jan 2007 18:38 On Tue, 26 Dec 2006 13:26:38 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <nf0to21l7sn57s6qjkocj493emf0bgfiv4(a)4ax.com>, >Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >>On Sun, 24 Dec 2006 01:13:42 +0000 (UTC), docdwarf(a)panix.com () wrote: >> >>>In article <lairo250619raljqhu1d545id7c5rbsan0(a)4ax.com>, >>>Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: > >[snip] > >>>>For FB code the >>>>maximum size 01 level expected for the FD and RECORD 0 in addition to >>>>BLOCK 0 and the actual record length will be determined at run time. >>>>Unfortunately this only works for INPUT. I don't think that you can >>>>use RECORD 0 VARYING DEPENDING ON for fixed length records. >>> >>>I'm not sure how this 'over-rides the DCB', as Mr Maclean suggested... but >>>perhaps sometime next week, if I remember, I'll cobble together some code >>>and see if this flies. >> >>If RECORD 0 is coded, then filling in of the field in the DCB is >>deferred to the OPEN. Since LRECL in the program's DCB normally >>overrides both JCL supplied LRECL and tape or disk label DCB, the >>coding of RECORD 0 allows the program to use an external source for >>the record length and eliminates the need for checking the program >>supplied value against the external source. This only works for input files. Since the WRITE statement refers to records, it won't work for output. > >Hmmmmm... perhaps I am doing something wrong, Mr Morris... given > >FILE-CONTROL. > SELECT INFILE > ASSIGN TESTA > ORGANIZATION SEQUENTIAL. >DATA DIVISION. >FILE SECTION. >FD INFILE > RECORD CONTAINS 0 > BLOCK CONTAINS 0. >01 INFILE-RECORD PIC X(32767). >WORKING-STORAGE SECTION. >PROCEDURE DIVISION. > OPEN INPUT INFILE. >THE-READ. > READ INFILE. > CLOSE INFILE. >THE-GOBACK. > GOBACK. > >... compiled with IBM Enterprise COBOL for z/OS and OS/390 3.2.1 and my >sites's usual compiler invocation parms... > >... and a TESTA dataset defined (via IEFBR14) as > > >//TESTA DD DSN=USERID1.TESTA, >// DISP=(,CATLG,CATLG), >// UNIT=SYSDA, >// SPACE=(TRK,(1,1),RLSE), >// DCB=(RECFM=FB,LRECL=30,BLKSIZE=27990) > > >... and run-JCL of: > > >//STEP020 EXEC PGM=SKELPROG >//TESTA DD DSN=USERID.TESTA,DISP=SHR >//SYSPRINT DD SYSOUT=* >//SYSOUT DD SYSOUT=* >//SYSUDUMP DD SYSOUT=* >//SYSABOUT DD SYSOUT=* > >... ... the job ABENDs with IEF450I WSXSKEL0 STEP020 - ABEND=S000 U4038 >REASON=00000001 and the following messages in the SYSOUT: > >IGZ0002S WSXSKEL0,STEP020 ,0797,D,TESTA ,GET >,WRNG.LEN.RECORD,00000006000D00,QSAM > >From compile unit SKELPROG at entry point SKELPROG at statement 24 at >compile unit offset +00000382 at entry offset +00000382 at address >0000829A. > >This differs slightly from the first run attempted... but it is an ABEND >nontheless; a bit farther down in the dump I find: > >14 INFILE FILE SPECIFIED AS: ORGANIZATION=QSAM SEQUENTIAL, ACCESS >MODE=SEQUENTIAL, RECFM=FIXED BLOCKED. CURRENT STATUS OF FILE IS: OPEN >STATUS=INPUT, FILE STATUS CODE=30. > >... which indicates to me that the load module is not very happy with what >it was told to process as the INFILE. > >Would you be so kind as to point out what you see as being the errors I've >made in attempting to implement your suggestion? > >DD
From: Clark F Morris on 1 Jan 2007 18:47 On Wed, 27 Dec 2006 12:54:09 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >I have a question, please, Doc. > >(It is many years since I worked in this environment (actually, it was an >environment LIKE this one because this environment was not then available, >if you catch my drift...)) > >I have retained enough of what I learned there to understand the >comprehensive samples you posted, and note in passing that nothing much >appears to have changed as far as JCL is concerned... > >I too, would have expected RECFM=VB, but I understand why you didn't put >that. > >My question is this (and forgive my ignorance if there is some obvious >reason that I simply haven't tumbled to): > >If the JCL specifies a block size of 27990 (nicely divisible by 30, 933 >times), and the COBOL program is specifying a block/record size of 32767, >wouldn't this be likely to cause an IO error when the dataset is opened? > >Just a thought... > >Pete. > >TOP POST - nothing more below > ><docdwarf(a)panix.com> wrote in message news:emsa6g$n0j$1(a)reader2.panix.com... >> In article <2cafe$459199e9$d066072d$978(a)FUSE.NET>, >> CG <Carl.Gehr.ButNoSPAMStuff(a)MCGCG.Com> wrote: >>>docdwarf(a)panix.com wrote: >> >> [snip] >> >>>> Dealing with a VB dataset with different-length records has not >>>> presented, >>>> at least to me, very much of a problem... the difficulty is, I believe, >>>> in >>>> dealing with a fixed length dataset which has different-length records. I (Clark Morris) interpreted the request as one that dealt with an input file that was fixed block but depending on the day could have different record lengths. RECORD 0, BLOCK 0 handles that for input with the interesting caveat that there must be something in the data that defines how long the actual record is (records with "A" in position 1 are always 80 bytes while records with "B" in position 1 are always 3000 bytes). When doing this the code must never attempt to address parts of the record that are not there. If the actual record is only 80 bytes, the code actually working with that record must not address the 200th byte. >> >> [snip] >> >>>???? > fixed length dataset which has different-length records. ???? >>> >>>That is a total contradiction! Either the file has FIXED LENGTH records >>>or the records VARY in length. >> >> You might want to inform the person who started this thread about that... >> but the last heard was from that account in this thread seems to have been >> as follows. From >> <http://groups.google.com/group/comp.lang.cobol/msg/e2bd0f47c45850c8?dmode=source> >> >> --begin quoted text: >> >> I think I didn't explain my problem well. Maybe it'll be better with >> an example. Let's say, I have file called TESTA. 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 >> >> I was able to find the entire thread beginning at >> <http://groups.google.com/group/comp.lang.cobol/browse_thread/thread/5f5078dee2ab20f1/1418ce24a2de8ee3?q=%22BLOCK+0+and+the+actual+record+length%22&lnk=ol&> >> >> DD >> >
From: Anonymous on 1 Jan 2007 21:13
In article <6p6jp2drgef3s0503ku600qmer9hnu9jqh(a)4ax.com>, Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >On Tue, 26 Dec 2006 13:26:38 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>In article <nf0to21l7sn57s6qjkocj493emf0bgfiv4(a)4ax.com>, >>Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >>>On Sun, 24 Dec 2006 01:13:42 +0000 (UTC), docdwarf(a)panix.com () wrote: >>> >>>>In article <lairo250619raljqhu1d545id7c5rbsan0(a)4ax.com>, >>>>Clark F Morris <cfmpublic(a)ns.sympatico.ca> wrote: >> >>[snip] >> >>>>>For FB code the >>>>>maximum size 01 level expected for the FD and RECORD 0 in addition to >>>>>BLOCK 0 and the actual record length will be determined at run time. >>>>>Unfortunately this only works for INPUT. I don't think that you can >>>>>use RECORD 0 VARYING DEPENDING ON for fixed length records. [snip] >>>If RECORD 0 is coded, then filling in of the field in the DCB is >>>deferred to the OPEN. Since LRECL in the program's DCB normally >>>overrides both JCL supplied LRECL and tape or disk label DCB, the >>>coding of RECORD 0 allows the program to use an external source for >>>the record length and eliminates the need for checking the program >>>supplied value against the external source. > >This only works for input files. Since the WRITE statement refers to >records, it won't work for output. >> >>Hmmmmm... perhaps I am doing something wrong, Mr Morris... given >> >>FILE-CONTROL. >> SELECT INFILE >> ASSIGN TESTA >> ORGANIZATION SEQUENTIAL. >>DATA DIVISION. >>FILE SECTION. >>FD INFILE >> RECORD CONTAINS 0 >> BLOCK CONTAINS 0. >>01 INFILE-RECORD PIC X(32767). >>WORKING-STORAGE SECTION. >>PROCEDURE DIVISION. >> OPEN INPUT INFILE. >>THE-READ. >> READ INFILE. >> CLOSE INFILE. >>THE-GOBACK. >> GOBACK. >> >>... compiled with IBM Enterprise COBOL for z/OS and OS/390 3.2.1 and my >>sites's usual compiler invocation parms... >> >>... and a TESTA dataset defined (via IEFBR14) as >> >> >>//TESTA DD DSN=USERID1.TESTA, >>// DISP=(,CATLG,CATLG), >>// UNIT=SYSDA, >>// SPACE=(TRK,(1,1),RLSE), >>// DCB=(RECFM=FB,LRECL=30,BLKSIZE=27990) >> >> >>... and run-JCL of: >> >> >>//STEP020 EXEC PGM=SKELPROG >>//TESTA DD DSN=USERID.TESTA,DISP=SHR >>//SYSPRINT DD SYSOUT=* >>//SYSOUT DD SYSOUT=* >>//SYSUDUMP DD SYSOUT=* >>//SYSABOUT DD SYSOUT=* >> >>... ... the job ABENDs with IEF450I WSXSKEL0 STEP020 - ABEND=S000 U4038 >>REASON=00000001 and the following messages in the SYSOUT: >> >>IGZ0002S WSXSKEL0,STEP020 ,0797,D,TESTA ,GET >>,WRNG.LEN.RECORD,00000006000D00,QSAM Mr Morris, in the code shown above the file is not addressed with a WRITE and encounters its ABEND based solely on input functions (OPEN INPUT and READ). Also note the GET specified in the IGZ0002S message. Second request, then: Would you be so kind as to point out what you see as being the errors I've made in attempting to implement your suggestion? DD |