Variable Length Input File
in [Cobol]
|
From: Anonymous on 22 Dec 2006 07:57 In article <1166790950.351244.67040(a)42g2000cwt.googlegroups.com>, Alistair <alistair(a)ld50macca.demon.co.uk> wrote: > >Alex Flinsch wrote: >> On Thu, 21 Dec 2006 18:58:39 -0600, P. Raulerson wrote: >> >> > Wow -that's a slightly different animal than what I took you to originally >> > mean. Each run is essentially brand new file, huh? [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. Given: FILE-CONTROL. SELECT INFILE ASSIGN TESTA ORGANIZATION SEQUENTIAL. DATA DIVISION. FILE SECTION. FD INFILE. 01 INREC PIC X(01). 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: 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. DD
From: HeyBub on 22 Dec 2006 10:47 Alistair wrote: > > 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. I did this once. The overhead was incredible. We deal with this problem routinely. Here's how. 1. Set the starting byte to 0. 2. Do a physical read of the disk at START-BYTE for MAX-LENGTH. 3. Examination of the buffer tells us what kind of type to process and that type determines the length of the record. For example, the record consists of everything from START-BYTE to, and including, a trailing double-tab or smiley-face. Whatever. 4. Add that length to START-BYTE. 5. Repeat steps 1-4 until coffe break time.
From: Pete Dashwood on 22 Dec 2006 15:35 "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message news:1166790950.351244.67040(a)42g2000cwt.googlegroups.com... > > Alex Flinsch wrote: >> On Thu, 21 Dec 2006 18:58:39 -0600, P. Raulerson wrote: >> >> > Wow -that's a slightly different animal than what I took you to >> > originally >> > mean. Each run is essentially brand new file, huh? >> > >> > The simple answer is to define the dataset as variable with the largest >> > possible record size set as the Max, then just use standard variable >> > records >> > in COBOL. >> > >> > That's a non-trivial challenge. >> > >> > >> >> 2 ways to go about it I can think of before more coffee -- >> >> The first is to set the record size in the program to the maximum, and >> the >> record type to fixed. Then have a conversion step before executing the >> program which uses a utility to convert the file to the lrecl used in the >> program >> >> The other is to set the record size in the program to the maximum and use >> a record type of undefined. > > > 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. > Merry Xmas, Alistair! Pleased to see you haven't lost your sense of humour... :-) Pete.
From: William M. Klein on 22 Dec 2006 16:04 Remember, the original question indicated the input was on TAPE. I don't think this will work -- Bill Klein wmklein <at> ix.netcom.com "HeyBub" <heybubNOSPAM(a)gmail.com> wrote in message news:12onvfo5m3vhv58(a)news.supernews.com... > Alistair wrote: >> >> 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. > > I did this once. The overhead was incredible. > > We deal with this problem routinely. Here's how. > > 1. Set the starting byte to 0. > 2. Do a physical read of the disk at START-BYTE for MAX-LENGTH. > 3. Examination of the buffer tells us what kind of type to process and that > type determines the length of the record. For example, the record consists of > everything from START-BYTE to, and including, a trailing double-tab or > smiley-face. Whatever. > 4. Add that length to START-BYTE. > 5. Repeat steps 1-4 until coffe break time. >
From: William M. Klein on 22 Dec 2006 16:07
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 Klein wmklein <at> ix.netcom.com "Alistair" <alistair(a)ld50macca.demon.co.uk> wrote in message news:1166790950.351244.67040(a)42g2000cwt.googlegroups.com... > > Alex Flinsch wrote: >> On Thu, 21 Dec 2006 18:58:39 -0600, P. Raulerson wrote: >> >> > Wow -that's a slightly different animal than what I took you to originally >> > mean. Each run is essentially brand new file, huh? >> > >> > The simple answer is to define the dataset as variable with the largest >> > possible record size set as the Max, then just use standard variable >> > records >> > in COBOL. >> > >> > That's a non-trivial challenge. >> > >> > >> >> 2 ways to go about it I can think of before more coffee -- >> >> The first is to set the record size in the program to the maximum, and the >> record type to fixed. Then have a conversion step before executing the >> program which uses a utility to convert the file to the lrecl used in the >> program >> >> The other is to set the record size in the program to the maximum and use >> a record type of undefined. > > > 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. > |