Hello everybody
I´ve an IDS 7.31 UC5 on SCO OpenServer 5.0.5 and i need export or onunload a database greather than 2 gb and i can´t.
I try the command split but dosent work. I try this
$ onunload -t archivo.out -b 32 -s 1000000 dbname | split -b 100k
or
$ split -b 100k < onunload -t archivo.out -b 32 -s 1000000 dbname
and nothing
If i do onunload without split it´s ok
Any help?

Thanks for your time

Susana

I don't understand .... "If i do onunload without split it´s ok"
If you execute:
$ onunload -t archivo.out -b 32 -s 1000000 dbname

works ?

if your answer is YES , the problem are the split , not the onunload...

so anyway... if you have this problem you can try solve using FIFO files (mkfifo command)...
BUT , so far I know , the SPLIT don't work with PIPES (fifo files or pipe just like your example).

I presume that when you say:
> If i do onunload without split it&#180;s ok
you mean the command starts without a nutty error but still fails when the output file reaches 2GB. Otherwise, why would you be posting.

What I see is that you are misunderstanding the pipe "|" usage in the shell. So let's clarify what's happening with your command:
> onunload -t archivo.out -b 32 -s 1000000 dbname | split -b 100k

This splits the STDOUT of the onunload process. There is no reason to believe it's going to split the file [that you specified with -t]. SO let's take that split out of the command line; onunload does not produce much stdout output unless it gets a gadzillion errors. (Actually, thouse would probably go to stderr so the split is utterly meaningless here.)

Now, let's address the reason you want to split: Repeating my guess from above, I'd say you are getting an error when the file reaches a certain size, like 2GB. Two possible causes; both may be true.

1. Your target file system has not been configured for "large files". As your Unix admin to fix this silliness.

2. You are using a version of IDS earlier than 9.4; none of the commands therein are "large file safe". You can't just quickly upgrade to >= 9.4, much as you should.

Either way, you must somehow split the "tape" file.
Quickest solution I know of:

1. Create a named pipe file (mkpipe or mkfifo, depending on your OS), say /tmp/yutz

2. Start a process reading from the pipe, like cat, piping its output to the split command so the command would be something like:
cat /tmp/yutz | split -b 1024m -a3 - onunload.dat

3. Now start the onunload process:
onunload -t /tmp/yutz -b 32 -s 2097120

With such a large "tape" size, it should not prompt for another tape volume unless your database is over 2TB. In the meantime, your SPLIT command is setting up files of size 1GB each, named onunload.dat.aaa, onunload.dat.aab, etc.

If your database is over 2TB, you need some way to automate the handling of prompts and switching of output files; the split command would no longer be relevant there. That is beyond the scope of this lesson. :-)

Good luck!

-- Rasputin Paskudniak

Hello Rasputin, thanks for your reply.
I need unload a database that produce files greather 2 gb and the sco openserver 5.0.5 doesn&#180;t permit and do it on tape is very slow.
I&#180;ll try your suggestion.
Very thanks again

Susana

Susana,
I already have a similar situation here with HP-UX 11 and ids 7.31 .
To workaround I use 2 solutions:
- piped file (FIFO)
- NFS mount at other server.
Was shared a disk on Linux Suse 9 and at HP-UX mounted and generated the files with more than 40GB...

Hello Cesar, once i&#180;d try with an NFS on Windows but didn&#180;t work, the file reaches a 2gb. Now i do it with piped file but is very slow.
I&#180;ll try with Linux and i hope it works becose i need recreate a table to reclaim space (it has a blob column)
Thanks

Hello Cesar, i shared a disk in linux debian and mounted from sco openserver 5.0.5 and got the error 27 file to large. Any sugestion?

Thanks
Susana

Hi Susana,
Well, I don't experience this on my environment, works for me.
What file system is you using in Linux machine?
What the output of command "ulimit" ?
My suggestion, to identify where is the problem, on linux machine, locally , create or copy a file with size greater 2GB and see if the problem aren't in the linux machine.

In the SCO machine, I don't have big experience and I don't have any more suggestion .... sorry...

Use PIPE and gzip.