View previous topic :: View next topic
|
Author |
Message |
Prasun De
New User
Joined: 17 Jan 2008 Posts: 28 Location: Kolkata, INDIA
|
|
|
|
Hi,
I have gone through the available threads on this topic. The code that is working for others is not working for me. Obviously I'm missing something.
Any help in figuring out what, would really be helpful.
I am using the below code
Code: |
/*REXX*/
TRACE A
"ALLOCATE DATASET ('xxxxxxxxxxxxxxx') F(LOADDP) SHR"
"ALLOCATE DATASET ('x1',",
"'x2',",
"'x3',",
"'x4',",
"'x5',",
"'x6',",
"'x7') F(PROGLIB) SHR"
PARM='yyyy'
DROPBUF
QUEUE "RUN PROGRAM(pgm1) PARM('"PARM"') PLAN(testplan) LIB(PROGLIB)"
QUEUE "END"
"DSN SYSTEM(zzzz)"
"FREE FI(LOADDP PROGLIB)"
DROPBUF
EXIT
|
When I'm running this I'm getting the below trace
Code: |
3 *-* "ALLOCATE DATASET ('xxxx') F(LOADDP) SHR"
>>> "ALLOCATE DATASET ('xxxx') F(LOADDP) SHR"
4 *-* "ALLOCATE DATASET ('x1',",
"'x2',",
"'x3',", "'
x4',", "'x5',", "'x6',", "'x7') F(PROGLIB) SHR"
>>> "ALLOCATE DATASET ('x1', 'x2', 'x3', 'x4', 'x5', 'x6', 'x7') F(PROGLIB) SHR"
11 *-* PARM='yyyy'
12 *-* DROPBUF
>>> "DROPBUF"
13 *-* QUEUE "RUN PROGRAM(pgm1) PARM('"PARM"') PLAN(testplan) LIB(PROGLI
B)"
14 *-* QUEUE "END"
15 *-* "DSN SYSTEM(zzzz)"
>>> "DSN SYSTEM(zzzz)"
DATASET NOT IN USE
16 *-* "FREE FI(LOADDP PROGLIB)"
>>> "FREE FI(LOADDP PROGLIB)"
17 *-* DROPBUF
>>> "DROPBUF"
18 *-* EXIT
***
|
The message "DATASET NOT IN USE" seems to be the problem. But I don't know why it is happening.
Please Note : I have masked all the actual dataset, plan, program and DB2 SSID names. |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
|
|
|
|
Check the data sets in your search order. It seems like you have some local program called 'DSN'. |
|
Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006 Posts: 1353 Location: Israel
|
|
|
|
Funny, I always thought that the LIB parameter must specify a DSN, not a DD...
When I tried something similar to your code, I got message IKJ56228I and a return code of 8:
Code: |
IKJ56228I DATA SET PROGLIB.LOAD NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED
+++ RC(8) +++ |
(and that's because I have TSO PROF NOPREFIX, otherwise same message but for dataset myprefix.PROGLIB.LOAD) |
|
Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006 Posts: 1353 Location: Israel
|
|
|
|
Also, try TSO PROF MSGID before running your program.
If it is a system message, it will have an id (like IKJ56228I).
There will be no change if it is a message issued from one of your programs. |
|
Back to top |
|
|
Prasun De
New User
Joined: 17 Jan 2008 Posts: 28 Location: Kolkata, INDIA
|
|
|
|
Thanks guys for your feedback..
Marso wrote: |
Also, try TSO PROF MSGID before running your program.
If it is a system message, it will have an id (like IKJ56228I).
There will be no change if it is a message issued from one of your programs. |
I tried this.. no change..
Pedro wrote: |
Check the data sets in your search order. It seems like you have some local program called 'DSN'. |
You are right...
I looked at the SYSPROC and SYSEXEC libraries but found no DSN command.
But I found a DSN module in SYSTEM Linklist libraries, which say's whether a perticuler dataset is in use by which job or userID.
That explains why my code was not working.
Now, how to avoid it searching the system linklist.
I tried putting the ALTLIB command in the CLIST to specify executing the DSN command from '*.SDSNLOAD' library.
But that too did not work. I guess because the system linklists are getting searched before anything.
Is there an way out without contacting the my site system programmer. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
Please note that ALTLIB affects the SYSPROC and SYSEXEC concatenations, not the STEPLIB concatenation containing load modules. If you are running outside of ISPF, you can use the TSOLIB command to alter STEPLIB. If not, there are several third-party products that will do this; ask your support workgroups if your system has one installed. |
|
Back to top |
|
|
Prasun De
New User
Joined: 17 Jan 2008 Posts: 28 Location: Kolkata, INDIA
|
|
|
|
Akatsukami wrote: |
Please note that ALTLIB affects the SYSPROC and SYSEXEC concatenations, not the STEPLIB concatenation containing load modules. If you are running outside of ISPF, you can use the TSOLIB command to alter STEPLIB. If not, there are several third-party products that will do this; ask your support workgroups if your system has one installed. |
Thanks...
But I need my rexx to run under ISPF as I would need ISPF panels..
Talked to one of the support guy, was not aware of any such third party softwate that can do the tsolib function under ISPF..
I guess the only way I'm seeing is to request system programmer to remove/rename that dsn local command from link list.
or I have to re-write all the cobol db2 code in rexx itself..to avoid that bumpy road of changing the old system, which no body has ever complained on.. |
|
Back to top |
|
|
Prasun De
New User
Joined: 17 Jan 2008 Posts: 28 Location: Kolkata, INDIA
|
|
|
|
Marso wrote: |
Funny, I always thought that the LIB parameter must specify a DSN, not a DD...
When I tried something similar to your code, I got message IKJ56228I and a return code of 8:
Code: |
IKJ56228I DATA SET PROGLIB.LOAD NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED
+++ RC(8) +++ |
(and that's because I have TSO PROF NOPREFIX, otherwise same message but for dataset myprefix.PROGLIB.LOAD) |
Guess what guys I found that DSN is just an alias of DSNECP00. (may be only for our system)
So I used DSNECP00 instead of DSN which solved my problem of local DSN program. Then I understood the error you talked about in the above quote.
So I have removed the allocation and specified the loadlib directly... and it worked... WOW... Thanks guys...
My code now looks like below..
Code: |
/*REXX*/
"ALLOCATE DATASET ('xxxx') F(LOADDP) SHR"
PARM='zzzz'
DROPBUF
DSN1='prefix.project.loadlib'
QUEUE "RUN PROGRAM(pgm1) PARM('"PARM"') PLAN(testplan) LIB('"DSN1"')"
QUEUE "END"
"DSNECP00 SYSTEM(SSID)"
"FREE FI(LOADDP)"
DROPBUF
EXIT
|
|
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
|
|
|
|
You did not say the origin of your DSN program... it could be a local tool. It is somehow mis-named. It seems inappropriate for your system programmers to allow such a name. I think the best solution is for that module to be renamed.
I think we have success in calling DB2 locally by using LIBDEF to ISPLLIB from our clist. The search order is ISPLLIB before the system linklist libraries. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
The LIBDEF to ISPLLIB approach also works in our shop. We need to do it that way because we have more than one DB2 subsystem in our development environment. |
|
Back to top |
|
|
Prasun De
New User
Joined: 17 Jan 2008 Posts: 28 Location: Kolkata, INDIA
|
|
|
|
Pedro wrote: |
You did not say the origin of your DSN program... it could be a local tool. It is somehow mis-named. It seems inappropriate for your system programmers to allow such a name. I think the best solution is for that module to be renamed.
I think we have success in calling DB2 locally by using LIBDEF to ISPLLIB from our clist. The search order is ISPLLIB before the system linklist libraries. |
Yes.. it is a local tool.. talked to the system programmer.. could not be renamed as it is used widely in other tools... Anyway, I got a command DSTEPLIB which adds the SDSNLOAD to the linklist dynamically to resolev the conflict.
tried the LIBDEF as well, it changed the search order and picked up the DSN program but it abended saying DSNCEP10 module not found.. but it is present in the library I added to ISPLLIB using LIBDEF. |
|
Back to top |
|
|
|