Variable Length Input File
in [Cobol]
|
From: William M. Klein on 2 Jan 2007 02:02 DD, I wasn't one of the people who suggested this code (or approach) but do you get the same ABEND if your run-time JCL has: //TESTA DD DSN=USERID.TESTA,DISP=SHR,DCB=(LRECL=32767,BLKSIZE=32767) I *know* that your IEFBR14 created it with // DCB=(RECFM=FB,LRECL=30,BLKSIZE=27990) but I *do* have a vague memory of being able to override LRECL via a DCB for an INPUT file. If this approach DOES work, then the next question would be if it would work with a "real" input file rather than just a "marker" file created with IEFBR14. -- Bill Klein wmklein <at> ix.netcom.com <docdwarf(a)panix.com> wrote in message news:encf48$kvk$1(a)reader2.panix.com... > 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 >
From: coot_jg on 2 Jan 2007 10:25 William M. Klein wrote: > DD, > I wasn't one of the people who suggested this code (or approach) but do you > get the same ABEND if your run-time JCL has: > > //TESTA DD DSN=USERID.TESTA,DISP=SHR,DCB=(LRECL=32767,BLKSIZE=32767) > > I *know* that your IEFBR14 created it with > > // DCB=(RECFM=FB,LRECL=30,BLKSIZE=27990) > > but I *do* have a vague memory of being able to override LRECL via a DCB for an > INPUT file. If this approach DOES work, then the next question would be if it > would work with a "real" input file rather than just a "marker" file created > with IEFBR14. > Just out of curiosity, we were previously able to solve this - but I am not aware as to whether the solution is still implementable. The input file records were created as fixed - (no leading length attribute on each record/block) - and all records within a particular file had an identical length, so we asked the console (or a parameter file/card) for the required length(s). Prior to issuing an "OPEN" for the FD, we issued a "CALL" to the COBOL program "TAMPER", passing the FD name and the record length(s) as parameters. The "TAMPER" routine received a pointer to the DCB of the calling program as it's first parameter, and was able to set the parameters within that DCB to match the record length/block sizes to the expected values, and pass the modified DCB back to the calling program for a successful "OPEN". If this isn't valid anymore, I'd be curious as to the reason. Thanx in advance.
From: Anonymous on 2 Jan 2007 11:33 In article <Yrnmh.224296$0t1.104686(a)fe04.news.easynews.com>, William M. Klein <wmklein(a)nospam.netcom.com> wrote: >DD, > I wasn't one of the people who suggested this code (or approach) but do you >get the same ABEND if your run-time JCL has: > >//TESTA DD DSN=USERID.TESTA,DISP=SHR,DCB=(LRECL=32767,BLKSIZE=32767) JCL error. Given: //TESTA DD DSN=USERID.TESTA, // DISP=(SHR), // DCB=(LRECL=32767,BLKSIZE=32767) .... I get: IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL SUBPARAMETER OF THE DCB FIELD [snip] ><docdwarf(a)panix.com> wrote in message news:encf48$kvk$1(a)reader2.panix.com... >> 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
From: William M. Klein on 2 Jan 2007 14:35
"coot_jg" <breany(a)csc.com> wrote in message news:1167751524.129289.7460(a)n51g2000cwc.googlegroups.com... > > William M. Klein wrote: <snip> > Just out of curiosity, we were previously able to solve this - but I > am not aware as to whether the solution is still implementable. The > input file records were created as fixed - (no leading length attribute > on each record/block) - and all records within a particular file had an > identical length, so we asked the console (or a parameter file/card) > for the required length(s). Prior to issuing an "OPEN" for the FD, we > issued a "CALL" to the COBOL program "TAMPER", passing the FD name and > the record length(s) as parameters. > The "TAMPER" routine received a pointer to the DCB of the calling > program as it's first parameter, and was able to set the parameters > within that DCB to match the record length/block sizes to the expected > values, and pass the modified DCB back to the calling program for a > successful "OPEN". > > If this isn't valid anymore, I'd be curious as to the reason. > > Thanx in advance. > As an IBM extension, one may pass the FD-name to a subroutine *IF* the file is a "QSAM" (I think this also works for SAM on VSE, but won't swear to it) file. This passes the address of the DCB, so a subprogram (usually - but not required to be - Assembler) can "play" with the attributes. With OS/VS COBOL, one could also pass the FD-name of a VSAM file to get the ACB accessed in a subprogram. This is NO LONGER valid syntax (and will get a compile error) with all IBM compilers since VS COBOL II. I think I suggested this approach early on (when we still thought the original poster was paying attention <G>) -- Bill Klein wmklein <at> ix.netcom.com |