|
Hi Andy,
We have got this to work here. I don't know the IBM side enough
though to tell you exactly what maps to what, but here is our connect
info:
/type=sqlnk/config=(test$source:ltec_configs.dat,all_mvs)/net=tcp
in ltec_configs.dat we have the following:
all_mvs:
/applic=Test1
/transport=TCP
/node=MVS9000.LKQ.XXX.COM
/port_number=2000
/service=MVSDB2
/user=TCPIP
/pass=CANTSAYHERE
/db_user=vida2
/db_password=dontaskdonttell
/TABLES=
(
DBI1L806.*,
DBI1L806.ALL_DTPS/dbkey_mode=(BYTE,WORD),
DBI1L806.ALL_DTPS_2/dbkey_mode=read_only, #ALL COLUMNS HAVE 1 NULL VALUE
DBI1L806.CANDIDATES/dbkey_mode=(LAST_NAME,FIRST_NAME,MIDDLE_INITIAL),
DBI1L806.COLLEGES/dbkey_mode=(COLLEGE_CODE),
DBI1L806.CURRENT_INFO/dbkey_mode=(SSTART,LAST_NAME),
DBI1L806.CURRENT_JOB/dbkey_mode=(JOB_START,LAST_NAME),
DBI1L806.CURRENT_SALARY/dbkey_mode=(EMPLOYEE_ID),
DBI1L806.DEGREES/dbkey_mode=(EMPLOYEE_ID,DEGREE,DEGREE_FIELD),
DBI1L806.DEPARTMENTS/dbkey_mode=(DEPARTMENT_CODE),
DBI1L806.EMPLOYEES/dbkey_mode=(EMPLOYEE_ID),
DBI1L806.J/dbkey_mode=(JNUM),
DBI1L806.JOBS/dbkey_mode=(JOB_CODE),
DBI1L806.JOB_HISTORY/dbkey_mode=(EMPLOYEE_ID,JOB_START),
DBI1L806.P/dbkey_mode=(PNUM),
DBI1L806.RESUMES/dbkey_mode=read_only, # NO DATA, NOT INTERESTING
DBI1L806.S/dbkey_mode=(SNUM),
DBI1L806.SALARY_HISTORY/dbkey_mode=(EMPLOYEE_ID,SALARY_START),
DBI1L806.SCALED_DTPS/dbkey_mode=read_only, # LACKS GOOD CANDIDATES
DBI1L806.SHORT_TEXT/dbkey_mode=read_only, # NOT INTERESTING
DBI1L806.SPJ/dbkey_mode=(SNUM,PNUM,JNUM),
DBI1L806.WORK_STATUS/dbkey_mode=(STATUS_CODE)
)
|
| Hi Dan,
this is a real good example. Much better as in the docu! BUT!!
Same error....
What I can not use from your example is:
/db_user=
/db_password=
That's why I use:
/DB_LOGON_1=
/DB_LOGON_2=
even when I have to double the username PW....
They swaer, that there is no DB_USER/PW in there DB2 implementation.
/applic= ????
This is interesting? What is this? What happens if you leave that out?
I still get :
-LDRV-E-NO_TABLES, No tables found in database
-LDRV-E-BAD_META_QUERY, An error occurred executing a metadata query:
Stored Procedure
-LDRV-E-STRING_TRUNCATE, A string was truncated during conversion
Which part of the SW is responsible for that?
I'm quite ure that I'm on the DB I want to be.... but there I'm stuck..
Thanks
Andy
|
| hi Andy,
i'm not sure if i have any answers for you, but i have a little more
information that may be helpful - and i have some questions for you.
the /db_logon_1 and /db_logon_2 attach qualifiers are supposed to be a
'generic' way of supplying the 2 pieces of information that the SQLogon
call to SequeLink require. for db2, you can use /db_user and
/db_password, which will map to the appropriate parameters to SQLogon.
they are the user anme and password to logon to db2, if they are
required. the /user and /password are used to log on to the mvs system
if required.
you are obviously able to log on and get to db2, so you are specifying
a correct set of qualifiers.
the /applic qualifier is used as a 'connection name' on the SQConnect
call to SequeLink; it is optional. it should work the same way with or
without it.
my question is: what version of the SequeLink db2 server are you
running? the reason i'm asking is that we have seen a similar error
(STRING_TRUNCATE) when we attach to a SequeLink Server for Informix
Version 3 (that is SequeLink server v3, not Informix v3)
the problem we saw is that the server was returning the
string-truncated indicator for columns in the metadata query, even
though the data was not in fact truncated. i have reported the problem
to Intersolv tech support, but i'm not sure whether they were entirely
convinced that the problem was theirs. the only was around it that i
could find was for us to turn off checking for string truncation; this
would mean that no legitimate string truncations would be detected
(in user data as well as in metadata).
all of this is sort of moot if you do not have SequeLink server v3, but
a useful thing might be for you to turn on sqlnk_logging and send us
the output. on vms, you need to define a logical SQLNK$LOGGING set to
TRUE in order to enable SequeLink logging.
i hope all this helps,
linda kipnes
|
| >i'm not sure if i have any answers for you, but i have a little more
>information that may be helpful - and i have some questions for you.
I'm very happy for any help!
>the /db_logon_1 and /db_logon_2 attach qualifiers are supposed to be a
>'generic' way of supplying the 2 pieces of information that the SQLogon
>call to SequeLink require. for db2, you can use /db_user and
>/db_password, which will map to the appropriate parameters to SQLogon.
>they are the user anme and password to logon to db2, if they are
>required. the /user and /password are used to log on to the mvs system
>if required.
Yes. /db_user and /db_password works instead of /db_logon_1 and
/db_logon_2 but I still have to say /user and /password (same username
and PW as in the other parameter)
>you are obviously able to log on and get to db2, so you are specifying
>a correct set of qualifiers.
Yes. (It took a while, there were certain MVS problems as well....;-)
>the /applic qualifier is used as a 'connection name' on the SQConnect
>call to SequeLink; it is optional. it should work the same way with or
>without it.
Ok.
>my question is: what version of the SequeLink db2 server are you
>running? the reason i'm asking is that we have seen a similar error
>(STRING_TRUNCATE) when we attach to a SequeLink Server for Informix
>Version 3 (that is SequeLink server v3, not Informix v3)
>the problem we saw is that the server was returning the
>string-truncated indicator for columns in the metadata query, even
>though the data was not in fact truncated. i have reported the problem
>to Intersolv tech support, but i'm not sure whether they were entirely
>convinced that the problem was theirs. the only was around it that i
>could find was for us to turn off checking for string truncation; this
>would mean that no legitimate string truncations would be detected
>(in user data as well as in metadata).
On the MVS there is Sequelink 2.5-3 installed.
>all of this is sort of moot if you do not have SequeLink server v3, but
Same problem on V3 as in the versin before?
>a useful thing might be for you to turn on sqlnk_logging and send us
>the output. on vms, you need to define a logical SQLNK$LOGGING set to
>TRUE in order to enable SequeLink logging.
I'd love to. But I get no additional output...
I tried SQLNK$LOGGING and SEQLNK$LOGGING but no results...
I search the EXE files, no reference to anything like "logging"
I get the error while reading any metadatainfo about a table. This info
is in EBCDIC. As EBCDIC is not as standartised as ASCII might the
"conversion error" be a EBCDIC/ASCII conversion problem?
Andy
i hope all this helps,
linda kipnes
|