From: abbad on
Hi guys,

I have a problem to read a SEG-Y file (a file format used in
geophysics to store and process seismic data). The SEG-Y format
consists of three blocks separated by an IBG (InterBlock Gap). The
first block is written in EBCDIC on 3200 bytes and is followed after an
IBG by a 400-byte binary block. After a third IBG, there is another
binary block.

My questions are:

1) How to convert the EBCDIC code to real (through binary if necessary)
? I found that the ascii character from 0 to 20 corresponding to the
EBCDIC code don't exist in Windows and correspond to "blanck spaces".
2) How to jump the IGB gap when reading such a file?.
3) I wrote subroutines for binary to integer/real conversion and
vice-versa. are there any simple functions to do that for the special
formats of binary code (complement to "1" or not, on 4 or 8 bytes for
instance).
4) Do these functions depend on a specific Fortran compiler. If yes,
which one, running under windows, offers the best environement to
process EBCDIC and binary codes?.

thanks in advance and hope I get information from your past
experience with Fortran90.

From: Michel Olagnon on
abbad(a)ntnu.no wrote:
> Hi guys,
>
> I have a problem to read a SEG-Y file (a file format used in
> geophysics to store and process seismic data). The SEG-Y format
> consists of three blocks separated by an IBG (InterBlock Gap). The
> first block is written in EBCDIC on 3200 bytes and is followed after an
> IBG by a 400-byte binary block. After a third IBG, there is another
> binary block.
>
> My questions are:
>
> 1) How to convert the EBCDIC code to real (through binary if necessary)
> ? I found that the ascii character from 0 to 20 corresponding to the
> EBCDIC code don't exist in Windows and correspond to "blanck spaces".

Convert EBCDIC to ASCII, and read using internal READ.

> 2) How to jump the IGB gap when reading such a file?.

IGBs only exist on tapes. I doubt that you still use those
1600 bpi or 6250 bpi magnetic tapes we had when I was young.
Use a Stream I/O routine if your system provides one, a C routine
otherwise, to read in the 2 headers and the data

> 3) I wrote subroutines for binary to integer/real conversion and
> vice-versa. are there any simple functions to do that for the special
> formats of binary code (complement to "1" or not, on 4 or 8 bytes for
> instance).
> 4) Do these functions depend on a specific Fortran compiler. If yes,
> which one, running under windows, offers the best environement to
> process EBCDIC and binary codes?.
>

I guess that endianness may be a problem, otherwise you may also
need to do something non standard if your file is in Format #1,
binary IBM.

I wrote a SEG-Y import program long ago, I can provide it, but it
uses some C subroutines I also wrote, and the comments are in French.

From: glen herrmannsfeldt on
Michel Olagnon <molagnon(a)ifremer-a-oter.fr> wrote:

> IGBs only exist on tapes. I doubt that you still use those
> 1600 bpi or 6250 bpi magnetic tapes we had when I was young.

Inter Block Gaps exist on disks, also. They are more important
on disks, allowing rewriting one block without overwriting the
beginning of the next one. The size depends on the speed tolerance
of the drive, among other things. Most disks now store data in
512 byte blocks with gaps in between. IBM used to make disk drives
that would write blocks of arbitrary size, just like tapes. I believe
now they emulate that using fixed block disks.

-- glen
From: Michel Olagnon on
glen herrmannsfeldt wrote:
> Michel Olagnon <molagnon(a)ifremer-a-oter.fr> wrote:
>
>
>>IGBs only exist on tapes. I doubt that you still use those
>>1600 bpi or 6250 bpi magnetic tapes we had when I was young.
>
>
> Inter Block Gaps exist on disks, also. They are more important
> on disks, allowing rewriting one block without overwriting the
> beginning of the next one. The size depends on the speed tolerance
> of the drive, among other things. Most disks now store data in
> 512 byte blocks with gaps in between. IBM used to make disk drives
> that would write blocks of arbitrary size, just like tapes. I believe
> now they emulate that using fixed block disks.
>
> -- glen

I agree. I meant that IBGs on disks have no influence on the way
one should access the data in a disk file with a Fortran program,
whereas they *must* be handled by the Fortran program when reading
a tape.

From: glen herrmannsfeldt on
Michel Olagnon wrote:

(snip)

> I agree. I meant that IBGs on disks have no influence on the way
> one should access the data in a disk file with a Fortran program,
> whereas they *must* be handled by the Fortran program when reading
> a tape.

In that case, the disks IBM uses for systems like MVS have blocks
and IBGs just like tapes. VMS is a little different, but it has a
file system with a block structure, unlike the unix stream of bytes
file system.

-- glen