Redirect SELECT results to a file

**Dave Hughes** · Jul 8 '08, 09:25 PM

Re: Redirect SELECT results to a file

MeBuggyYouJane wrote:

This should be simple, and the docs say so, but no...
>
1) I have an .hta file (VBScript), with a call to windoze shell
2) the shell call is to db2cmd, input from a file
3) the command file has a db2 SELECT <blah command
>
If I insert foo.txt in the db2cmd command line, the
commands, result set, and messages go to foo.txt. That's sort
of OK, except that running EXPORT, i can concoct the command
with a file for output, and the result goes there. The client
wants both the SELECT and EXPORT to work the same: result
set in a file.

A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):

EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).

In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.

So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...

The docs say that I can insert -r foo.txt in either the
db2cmd command line or the db2 command line, and get the
result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
but db2 errors with "unable to access file".

-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).

I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.

I don't think it should be so difficult.

That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.

[1]

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.l

uw.admin.cmd.do c/doc/r0002036.html

Cheers,

Dave.

**MeBuggyYouJane** · Jul 9 '08, 12:25 AM

Re: Redirect SELECT results to a file

Dave Hughes wrote:

MeBuggyYouJane wrote:
>

>This should be simple, and the docs say so, but no...
>>
>1) I have an .hta file (VBScript), with a call to windoze shell
>2) the shell call is to db2cmd, input from a file
>3) the command file has a db2 SELECT <blah command
>>
>If I insert foo.txt in the db2cmd command line, the
>commands, result set, and messages go to foo.txt. That's sort
>of OK, except that running EXPORT, i can concoct the command
>with a file for output, and the result goes there. The client
>wants both the SELECT and EXPORT to work the same: result
>set in a file.

>
A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):
>
EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).
>
In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.
>
So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...
>

>The docs say that I can insert -r foo.txt in either the
>db2cmd command line or the db2 command line, and get the
>result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
>but db2 errors with "unable to access file".

>
-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).
>
I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.
>

>I don't think it should be so difficult.

>
That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.
>
[1]

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.l

uw.admin.cmd.do c/doc/r0002036.html
>
>
Cheers,
>
Dave.

Yes, they're different. The client just doesn't want/need the commands
and messages. Makes sense. And the error code flashed by before I
caught it: DB21005E. But that just translates to can't use the file.

No Google Groups or usenet in cubeland, so it'll have to be on the
morrow. I did find an APAR for that code, but not quite the same symptom.

thanks.

**MeBuggyYouJane** · Jul 10 '08, 12:35 AM

Re: Redirect SELECT results to a file

MeBuggyYouJane wrote:

Dave Hughes wrote:

>MeBuggyYouJa ne wrote:
>>

>>This should be simple, and the docs say so, but no...
>>>
>>1) I have an .hta file (VBScript), with a call to windoze shell
>>2) the shell call is to db2cmd, input from a file
>>3) the command file has a db2 SELECT <blah command
>>>
>>If I insert foo.txt in the db2cmd command line, the
>>commands, result set, and messages go to foo.txt. That's sort
>>of OK, except that running EXPORT, i can concoct the command
>>with a file for output, and the result goes there. The client
>>wants both the SELECT and EXPORT to work the same: result
>>set in a file.

>>
>A quick word of caution regarding this: EXPORT's output is
>fundamentall y different (in purpose) to the captured output of a SELECT
>statement executed by the CLP (e.g. via -r or a stdout redirection):
>>
>EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
>data unambiguously in specifically structured formats (IXF, delimited,
>fixed width).
>>
>In contrast, the CLP's output is meant for human consumption - /not/
>for data transfer. Hence the CLP takes certain liberties in its output.
>Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
>represented by a "-" (which can't be distinguished from a CHAR column
>containing a "-"), dates are formatted into the client's locale, etc.
>etc.
>>
>So - nothing wrong with wanting them to work similarly, but I'd be very
>wary of somebody wanting to use them for the same purpose. Anyway...
>>

>>The docs say that I can insert -r foo.txt in either the
>>db2cmd command line or the db2 command line, and get the
>>result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
>>but db2 errors with "unable to access file".

>>
>-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
>Windows to provide the necessary environment for db2. The only options
>it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
>Windows sessions and it seemed to work fine (no mysterious access
>errors).
>>
>I've no idea why DB2 would say it can't access the file when it's been
>created successfully, unless the file already existed and the user
>executing the CLP doesn't have the necessary privileges to overwrite
>the file.
>>

>>I don't think it should be so difficult.

>>
>That's because it's not ;-). I suspect there may be a problem with the
>command line you're using, or the way you're invoking the CLP. Can you
>post the /exact/ command line you're using, along with the output? If
>you're launching the CLP from an application the code for launching the
>CLP would be good too.
>>
>[1]
>http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
>uw.admin.cmd.d oc/doc/r0002036.html
>>
>>
>Cheers,
>>
>Dave.

>
Yes, they're different. The client just doesn't want/need the commands
and messages. Makes sense. And the error code flashed by before I
caught it: DB21005E. But that just translates to can't use the file.
>
No Google Groups or usenet in cubeland, so it'll have to be on the
morrow. I did find an APAR for that code, but not quite the same symptom.
>
thanks.

Turns out to be from either WshShell or windoze itself. I was able to
get the syntax to work from db2cmd directly. Didn't, and can't, see why
it should be different from the shell. But from the shell it will only
write to a directory local file. Better than nothing. oh well.

thanks.

**Lennart** · Jul 10 '08, 07:35 AM

Re: Redirect SELECT results to a file

On Jul 10, 2:33 am, MeBuggyYouJane <gnuo...@rcn.co mwrote:

MeBuggyYouJane wrote:

Dave Hughes wrote:

MeBuggyYouJane wrote:

>

>This should be simple, and the docs say so, but no...

>

>1) I have an .hta file (VBScript), with a call to windoze shell
>2) the shell call is to db2cmd, input from a file
>3) the command file has a db2 SELECT <blah command

>

>If I insert foo.txt in the db2cmd command line, the
>commands, result set, and messages go to foo.txt. That's sort
>of OK, except that running EXPORT, i can concoct the command
>with a file for output, and the result goes there. The client
>wants both the SELECT and EXPORT to work the same: result
>set in a file.

>

A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):

>

EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).

>

In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.

>

So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...

>

>The docs say that I can insert -r foo.txt in either the
>db2cmd command line or the db2 command line, and get the
>result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
>but db2 errors with "unable to access file".

>

-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).

>

I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.

>

>I don't think it should be so difficult.

>

That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.

>

[1]
>http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
uw.admin.cmd.do c/doc/r0002036.html

>

Cheers,

>

Dave.

>

Yes, they're different. The client just doesn't want/need the commands
and messages. Makes sense. And the error code flashed by before I
caught it: DB21005E. But that just translates to can't use the file.

>

No Google Groups or usenet in cubeland, so it'll have to be on the
morrow. I did find an APAR for that code, but not quite the same symptom.

>

thanks.

>
Turns out to be from either WshShell or windoze itself. I was able to
get the syntax to work from db2cmd directly. Didn't, and can't, see why
it should be different from the shell. But from the shell it will only
write to a directory local file. Better than nothing. oh well.
>

Just a thought, did you use an absolute or relative path? Also, is it
a local disk, or is it mounted somehow?

/Lennart

**MeBuggyYouJane** · Jul 12 '08, 12:25 AM

Re: Redirect SELECT results to a file

Lennart wrote:

On Jul 10, 2:33 am, MeBuggyYouJane <gnuo...@rcn.co mwrote:

>MeBuggyYouJa ne wrote:

>>Dave Hughes wrote:
>>>MeBuggyYouJa ne wrote:
>>>>This should be simple, and the docs say so, but no...
>>>>1) I have an .hta file (VBScript), with a call to windoze shell
>>>>2) the shell call is to db2cmd, input from a file
>>>>3) the command file has a db2 SELECT <blah command
>>>>If I insert foo.txt in the db2cmd command line, the
>>>>commands, result set, and messages go to foo.txt. That's sort
>>>>of OK, except that running EXPORT, i can concoct the command
>>>>with a file for output, and the result goes there. The client
>>>>wants both the SELECT and EXPORT to work the same: result
>>>>set in a file.
>>>A quick word of caution regarding this: EXPORT's output is
>>>fundamentall y different (in purpose) to the captured output of a SELECT
>>>statement executed by the CLP (e.g. via -r or a stdout redirection):
>>>EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
>>>data unambiguously in specifically structured formats (IXF, delimited,
>>>fixed width).
>>>In contrast, the CLP's output is meant for human consumption - /not/
>>>for data transfer. Hence the CLP takes certain liberties in its output.
>>>Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
>>>represente d by a "-" (which can't be distinguished from a CHAR column
>>>containing a "-"), dates are formatted into the client's locale, etc.
>>>etc.
>>>So - nothing wrong with wanting them to work similarly, but I'd be very
>>>wary of somebody wanting to use them for the same purpose. Anyway...
>>>>The docs say that I can insert -r foo.txt in either the
>>>>db2cmd command line or the db2 command line, and get the
>>>>result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
>>>>but db2 errors with "unable to access file".
>>>-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
>>>Windows to provide the necessary environment for db2. The only options
>>>it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
>>>Windows sessions and it seemed to work fine (no mysterious access
>>>errors).
>>>I've no idea why DB2 would say it can't access the file when it's been
>>>created successfully, unless the file already existed and the user
>>>executing the CLP doesn't have the necessary privileges to overwrite
>>>the file.
>>>>I don't think it should be so difficult.
>>>That's because it's not ;-). I suspect there may be a problem with the
>>>command line you're using, or the way you're invoking the CLP. Can you
>>>post the /exact/ command line you're using, along with the output? If
>>>you're launching the CLP from an application the code for launching the
>>>CLP would be good too.
>>>[1]
>>>http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
>>>uw.admin.cmd .doc/doc/r0002036.html
>>>Cheers,
>>>Dave.
>>Yes, they're different. The client just doesn't want/need the commands
>>and messages. Makes sense. And the error code flashed by before I
>>caught it: DB21005E. But that just translates to can't use the file.
>>No Google Groups or usenet in cubeland, so it'll have to be on the
>>morrow. I did find an APAR for that code, but not quite the same symptom.
>>thanks.

>Turns out to be from either WshShell or windoze itself. I was able to
>get the syntax to work from db2cmd directly. Didn't, and can't, see why
>it should be different from the shell. But from the shell it will only
>write to a directory local file. Better than nothing. oh well.
>>

>
Just a thought, did you use an absolute or relative path? Also, is it
a local disk, or is it mounted somehow?
>
>
/Lennart
>

All local. It's clear that there is some pathological interaction among
DB2/windoze/WshShell. If nothing else, the users and permissions
differ between the local directory and non-local directory file. The
local has DB2ADMNS and DB2USERS defined.

For now, they'll have to live with getting the SELECT listing in the
..hta file's directory.

thanks.

Redirect SELECT results to a file

Redirect SELECT results to a file

Comment

Comment

Comment

Comment

Comment