Variable Length Input File
in [Cobol]
|
From: Anonymous on 23 Dec 2006 10:33 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. DD
From: William M. Klein on 23 Dec 2006 14:28 I must have been mixing it up (in my mind) with another post. Sorry about that. -- Bill Klein wmklein <at> ix.netcom.com "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message news:1166882146.914548.50570(a)80g2000cwy.googlegroups.com... > > William M. Klein wrote: >> Again, I don't think this will work for TAPE input. Also, remember that IBM >> processing of "RECFM U" *has* changed in recent years. See: >> >> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG31/3.5.4 >> > > Bill, the initiator's four posts on this subject do not mention TAPE. > Where did you get the idea that he is referring to tape? >
From: Alistair on 23 Dec 2006 17:54 William M. Klein wrote: > I must have been mixing it up (in my mind) with another post. Sorry about that. No problem, I just thought that I was missing the obvious. Thanks. > > -- > Bill Klein > wmklein <at> ix.netcom.com > "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message > news:1166882146.914548.50570(a)80g2000cwy.googlegroups.com... > > > > William M. Klein wrote: > >> Again, I don't think this will work for TAPE input. Also, remember that IBM > >> processing of "RECFM U" *has* changed in recent years. See: > >> > >> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG31/3.5.4 > >> > > > > Bill, the initiator's four posts on this subject do not mention TAPE. > > Where did you get the idea that he is referring to tape? > >
From: Clark F Morris on 23 Dec 2006 19:39 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. > >DD 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. 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.
From: Anonymous on 23 Dec 2006 20:13
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. DD |