To recap:
My postingi of NOv. 3, 1993 described a situation where continuous
backup and entries in the online log file were not accurate when
compared to the logical log backup tape.

Bryan K. suggested we check the size specification for
our logical log backup drive.  That specification has a
block size of 1024 with a maximum of 5000000 Kbytes on the
tape.  The tape is theoretically rated to hold 25gig.

In addition I looked at two other tapes which carried  a
greater number of logs than the one I described at length in my
original posting.  Using tblog again, each of those tapes contained
in excess of twice the amount of tblog output as the original tape.  

Tblog is not an absolute measure, however:
 - each test was run with the same switch for verbosity
 - the amount of data per log written by tblog from the tapes
was consistent throughout. The estimate is pretty rough and
based on greps and file sizes, but each log generated VERY
roughly 340,000 bytes of tblog output.  We specify 1 meg.
logical logs which are unbuffered.

It seems very unlikely that we have run our log backup tape
to end of device.  We also are running what is supposed to be
a pretty good quality of 8mm tape.

I think that says we have some other problem.

Thanks to Bryan, but we need something else here.

I did not mention it in my original posting, but I have
reported this to Informix and there is an open case.  
--
*********************************************************
Con Woodall                     * "You can do anything
Colorado State University       * with a computer, but
Veterinary Teaching Hospital    * you might not want to."
Fort Collins, CO  80523         * --Larry Whatshisname
303-491-1244,  FAX 303-491-4414 * or Lauri Whatshername

*********************************************************

I have a customer who is trying to create a form for a table which has
48 1-character fields. This is using Perform, but I have this feeling
that the same problem may exist in 4GL forms also. Since it doesn't
seem to be case sensitive, letters "a" thru "z" only cover 26 fields.
Even if digits work (we haven't tried it), this only covers 36 fields.
We haven't tried launching into other characters such as punctuation,
in hopes of a better solution (that won't require trial and error to
avoid syntax problems). Does anyone know a way to specify this many
fields of 1-character?

I recall having seen this discussion in the past, but I am drawing
a complete blank now that we hit the issue ourselves. Can someone
remind me of a way to handle this?
--

CARS Information Systems Corp.          
Cincinnati, OH                          Standard Disclaimers Apply

: I have a customer who is trying to create a form for a table which has
: 48 1-character fields. This is using Perform, but I have this feeling
: that the same problem may exist in 4GL forms also. Since it doesn't
: seem to be case sensitive, letters "a" thru "z" only cover 26 fields.
: Even if digits work (we haven't tried it), this only covers 36 fields.
: We haven't tried launching into other characters such as punctuation,
: in hopes of a better solution (that won't require trial and error to
: avoid syntax problems). Does anyone know a way to specify this many
: fields of 1-character?

Brian,

sorry I don't know a way to specify so many 1-char fields, but isn't it
possible to make the fields 2_char in the form specification and then
only allow 1-char entries in them (via upscol/include)?

I know this is not an elegant solution, especially if you use the
default or any other field delimiters or have the fields appear in
reverse or color. But it should certainly work.

Regards, Richard
--
+----------------------------+-------------------------------------------+

| EDV-Gruppe Anaesthesie     | Tel     : +49-89-7095-3421                |
| Klinikum Grosshadern       | FAX     : +49-89-7095-8886                |
| 81366 Munich, Germany      |                                           |
+----------------------------+-------------------------------------------+