Just an observation.

It's been my bitter experience that no-one who creates IBM reel tapes from
mainframes has the slightest idea of how it was really created. They express
surprise that I should even have the audacity to ask the questions I ask,
and horror that I want the physical blocksize reduced to something under
32768 words, and maybe even an even numbers of bytes.per.record.

Tapescan helps, as does Suprtool, playing endlessly with Fcopy etc.

But I will say that it's a tribute to MPE and Surrounds that I have almost
always managed to make sense of the data after trial, error and
pleading.....

Regards

Neil


> -----Original Message-----
> From: Gilles Schipper [SMTP:[log in to unmask]]
> Sent: Thursday, July 08, 1999 4:32 AM
> To:   [log in to unmask]
> Subject:      Re: Need help with Fcopy
>
> FCOPY is probably getting the record size from the file label, so you
> probably want to ensure that your assumptions are correct.
>
> You can do this by getting your hands on a program like one called
> TAPESCAN, from the contributed library. This will read your tape and
> report
> all block lengths on it.
>
> The deblock option of the FCOPY command has nothing to do with the
> resulting output record length. It is simply used to partition an input
> block into several output writes, whose record size is influenced by
> several factors, none of which include the deblock option.
>
> The best way to control the output record size of your output file is to
> pre-build it, as follows:
>
> :build outfil;rec=-346,,f,ascii;disc=100000
>
> You would then omit the ;new option from your FCOPY command.
>
> This way, you do not rely on any fcopy and/or system defaults.
>
> Apart from that, your command looks fine. Once you determine the ACTUAL
> block size, you can use the deblock option to partition the block into
> records, as your example demonstrates.
>
> I believe the only flaw in your example - apart from relying on fcopy to
> establish record size - is the apparent mismatch between the actual block
> size of 5210 bytes(?) and the given one of 3450.
>
> At 09:09 PM 1999-07-07 -0400, Tim Manns wrote:
> >Hi All,
> >I am having some trouble reading in an IBM labeled tape and need some
> help.
> >The file length is 345 bytes, fixed, the blocking factor is 10 and the
> tape
> >label is "BACKUP".  The data is in EBCDIC format.  I realize that we need
> to
> >have a even record length so I increased it by 10 and reduced the
> blocking
> >factor to 1.  Then I did a deblock command in Fcopy but it keeps giving
> me
> >an output file with a record length of 5210 bytes.  Why would this be
> >happening?  Where does the 5210 come from?  Should it not be 345 bytes
> after
> >the deblock?
> >
> >Here is the exact command I used and the results thereof:
> >
> >:FILE T;DEV=TAPE;REC=-3450,1,U,ASCII;LABEL=BACKUP,IBM
> >:FCOPY FROM=*T;TO=OUTFIL;NEW;DEBLOCK=-345;EBCDICIN
> >HP31900A.05.02 FILE COPIER (C) HEWLETT-PACKARD CO. 1990
> >
> >*200*WARNING: FROMFILE RECSIZE IS 5210 BYTES, TOFILE RECSIZE IS 345
> BYTES.
> >CONTINUE OPERATION (Y OR N) ?N
> >0 RECORDS PROCESSED *** 0 ERRORS
> >
> >
> >END OF SUBSYSTEM
> >:
> >
> >Thanks for your help!!
> >Tim Manns
> >Overton's, Inc.
> >
> >
> --------------------------------------------------------------------------
> -
> Gilles Schipper
> GSA Inc.
> HP3000 & HP9000 System Administration Specialists
> 300 John Street, Box 87651   Thornhill, ON Canada L3T 7R4
> Voice: 905.889.3000     Fax: 905.889.3001
> Internet:  [log in to unmask]
> --------------------------------------------------------------------------
> -