uniData error: GMK file is too big to open.

[frosty]

Getting this error on any attempt to access a uniData file:

GMK file is too big to open.

LIST ONLY <filename> or LIST.INDEX <filename> etc.

give the error immediately.

In this case, google is not my friend. =':^<

Anybody know what this error means?

And how to fix it?

[James Schram]

My assumtion is that it is a static not a dynamic hashed table. What OS are you on AIX, Windows HPUX...

[Anthony Youngman]

On 04/12/13 18:09, frosty wrote:
> Getting this error on any attempt to access a uniData file:

> *GMK file is too big to open.*

>
> LIST ONLY <filename> or LIST.INDEX <filename> etc.
> give the error immediately.
>

> In this case, google is _not_ my friend. =':^<

>
> Anybody know what this error means?

How big is it? Total guess, is it 2Gb?

>
> And how to fix it?
>

If it's 2Gb you probably have a corrupt file ... I don't know UD, but I
think files by default are limited to 2Gb (you need 64-bit mode for
anything bigger), and going over this limit is a "boom!" moment :-(

The UD equivalent of fixfile will probably fix it, but lose data in the
process :-( You probably need to fix it, then create a new 64-bit file
and copy across.

If it was UV this would definitely be the case, and I think UD is similar.

Cheers,
Wol

[frosty]

Sorry, uniData 7.3 on RHEL.

Not sure if it's static or dynamic; GUIDE fails with "GMK file is too bit to open."

[frosty]

When I cd to the directory, ls -al shows this:

 1073741824 dat001

  301432832 dat002

    6022702 gmekey

  268474368 idx001

   93618176 over001

Nothing approaching 2GB there.

Is the file named gmekey the GMK file?

[stope19]

I wonder if it's a shared memory size issue..

[Bob Wyatt]

Your ulimit file size is limiting you to 1GB file sizes…

So you may not need 2GB, but you need more than 1…

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[frosty]

ulimit command returns unlimited.

[Bob Wyatt]

UniData at some point did exactly as it was supposed to… dat001 became 1GB, and it created dat002.

The udtconfig file has a setting (MAX_FLENGTH) that defines when a second dat file is created; you must have this set to the default (1GB). The maximum this can be is (2GB – 16KB).

The presence of the gmekey fle would indicate that this is a sequential dynamic file.

 

I would expect that somewhere, the ulimit is being changed from your seemingly unlimited value today.

Of more benefit is a ulimit –a, as I don’t think I’ve read anything about the Linux release or the UniData version in play.

And it isn’t necessarily important to tell me the output when run outside of UniData, such as an administrative user that doesn’t use UniData.

 

Log in as a user that would typically read or write the file in question, and grab the ulimit –a as that user from within UniData. Check the login paragraph or PROC – does it reset ulimit?

 

Otherwise, I’m out of suggestions.

[frosty]

Thanks, that was all helpful. To answer your questions:

UniData == 7.3

Red Hat == Enterprise Linux Server release 6.5 (Santiago)

Here's ulimit command from uniData command line:

!ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 256725

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 10240

cpu time               (seconds, -t) unlimited

max user processes              (-u) 1024

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

LOGIN paragraph does a bunch of UDT.OPTIONS, a BASICTYPE

and an ECLTYPE but no ulimit.

[Bob Wyatt]

I don’t know if what I provided has changed between 6.1 and 7.3…

 

None the less, it may be time to call Rocket…