Variable Length Input File
in [Cobol]
|
From: Clark F Morris on 24 Dec 2006 08:39 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: >>On Sat, 23 Dec 2006 15:33:32 +0000 (UTC), docdwarf(a)panix.com () wrote: >> >>>In article <1166881498.301512.7030(a)i12g2000cwa.googlegroups.com>, >>>Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >>>> >>>>docdwarf(a)panix.com wrote: >>>>> In article <1166790950.351244.67040(a)42g2000cwt.googlegroups.com>, >>>>> Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >>> >>>[snip] >>> >>>>> >ALTERNATIVELY (and I like this one): set the FD to contain a record of >>>>> >one character length fixed blocked and read repeatedly, building the >>>>> >record in working storage. >>>>> > >>>>> >I can't believe that no-one came up with that one before me. >>>>> >>>>> Perhaps they did, Mr Maclean, and discarded it as being of... questionable >>>>> utility on an IBM-style mainframe. >>> >>>[snip] >>> >>>>> ... the job ABENDs with IEF450I WSXSKEL0 STEP020 - ABEND=S000 U4038 >>>>> REASON=00000001 and the following messages in the SYSOUT: >>>>> >>>>> IGZ0201W A file attribute mismatch was detected. File INFILE in program >>>>> SKELPROG had a record length of 1 and the file specified in the ASSIGN >>>>> clause had a record length of 30. >>>>> IGZ0035S There was an unsuccessful OPEN or CLOSE of file TESTA in program >>>>> SKELPROG at relative location X'0358'. Neither FILE STATUS nor an ERROR >>>>> declarative were specified. The status code was 39. From compile unit >>>>> SKELPROG at entry point SKELPROG at statement 19 at compile unit offset >>>>> +00000358 at entry offset +00000358 at address 000082C8. >>>> >>>>How about over-riding the DCB? >>> >>>I'm not quite sure what technique you might use to accomplish this, Mr >>>Maclean. If you would be so kind as to post an example it might help >>>clarify the matter. >> >>Assuming that you have BLOCK 0 and RECORD VARYING FROM 1 TO 32760 (or >>maximum record size expected) in the COBOL program and assuming the >>file is actually VB or VBS (RECORDING S needed in the COBOL program), >>you would then code RECFM=VB,LRECL='cobol TO LENGTH +4' in the JCL and >>thus be able to read any file regardless of length. > >No problems with that, Mr Morris... that's part of the nature of VB >datasets on Big Iron. I noticed that the original poster has yet to >respond to questions about the DCB; it might be that the time >for this assignment has gone past 'due date'. > >>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. > >DD
From: Anonymous on 26 Dec 2006 08:26 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. 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: CG on 26 Dec 2006 12:19 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. > > 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 > Just to get something to you quickly, in case Clark is otherwise occupied... Just how did you expect to get VARIABLE length records when you explicitly created the file as FIXED length? DCB=(RECFM=FB,LRECL=30,BLKSIZE=27990) The DCB option: RECFM=FB says FIXED BLOCKED. You need: RECFM=VB for VARIABLE BLOCKED. You should also add: RECORDING MODE V See the Enterprise COBOL LRM for specifics about how the compiler determines the recording mode if you do not specify it. Carl
From: Anonymous on 26 Dec 2006 12:39 In article <db00b$45915999$d066072d$11570(a)FUSE.NET>, CG <Carl.Gehr.ButNoSPAMStuff(a)MCGCG.Com> wrote: >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. [snip] >> //TESTA DD DSN=USERID1.TESTA, >> // DISP=(,CATLG,CATLG), >> // UNIT=SYSDA, >> // SPACE=(TRK,(1,1),RLSE), >> // DCB=(RECFM=FB,LRECL=30,BLKSIZE=27990) [snip] >> ... ... the job ABENDs with IEF450I WSXSKEL0 STEP020 - ABEND=S000 U4038 >> REASON=00000001 and the following messages in the SYSOUT: [snip] >> 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? >> >Just to get something to you quickly, in case Clark is otherwise occupied... > >Just how did you expect to get VARIABLE length records when you >explicitly created the file as FIXED length? I didn't expect to get VB records; as per Mr Morris' assertion above, the solution is for FB. 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 had been taught, e'er-so-long ago, that a compiled COBOL module does not readily enjoy having to deal with a fixed-length dataset which contains record-lengths differing from those specified before the compile... and so far all examples I've been able to come up with appear to demonstrate this behavior. DD
From: CG on 26 Dec 2006 16:53
docdwarf(a)panix.com wrote: > In article <db00b$45915999$d066072d$11570(a)FUSE.NET>, > CG <Carl.Gehr.ButNoSPAMStuff(a)MCGCG.Com> wrote: >> 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. > > [snip] > >>> //TESTA DD DSN=USERID1.TESTA, >>> // DISP=(,CATLG,CATLG), >>> // UNIT=SYSDA, >>> // SPACE=(TRK,(1,1),RLSE), >>> // DCB=(RECFM=FB,LRECL=30,BLKSIZE=27990) > > [snip] > >>> ... ... the job ABENDs with IEF450I WSXSKEL0 STEP020 - ABEND=S000 U4038 >>> REASON=00000001 and the following messages in the SYSOUT: > > [snip] > >>> 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? >>> >> Just to get something to you quickly, in case Clark is otherwise occupied... >> >> Just how did you expect to get VARIABLE length records when you >> explicitly created the file as FIXED length? > > I didn't expect to get VB records; as per Mr Morris' assertion above, the > solution is for FB. > > 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 > had been taught, e'er-so-long ago, that a compiled COBOL module does not > readily enjoy having to deal with a fixed-length dataset which contains > record-lengths differing from those specified before the compile... and so > far all examples I've been able to come up with appear to demonstrate this > behavior. > > DD > ???? > 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. Possibly some other platform can resolve this contradiction, but you indicated you are using the Enterprise COBOL compiler. Therefore, pick FIXED or pick VARYING... Bye... Carl |