RC(-3) in a REXX exec in a batch run stream
William Gannon
It's been a little quiet lately so I thought I would liven it up a
little ....
I just wrote a REXX exec, called MOVEDATA, that I would like to run in a
batch job. The exec uses the DB2 command processor (DSN) command. I
used the JCL below to run the exec but I get en error accessing the DSN
command and I am unable to proceed past this point. My exec works
perfectly when invoked from within TSO, but when run in batch using the
following JCL it stops at the address tso "DSN SYSTEM(DSNP)" statement.
Partial output :
173 *-* "execio" lines "diskw sysin (finis"
>>> "execio 8 diskw sysin (finis"
174 *-* /*
175 *-* queue "RUN PROGRAM(DSNTEP2) PLAN(DSNTEP"verrel")",
||".RUNLIB.LOAD')"
177 *-* queue "END"
178 *-* /* Calling DSN command Processor, Running SQL in'
fsid
179 *-* address tso "DSN SYSTEM("fsid")"
>>> "DSN SYSTEM(DSNP)"
+++ RC(-3) +++
294 *-* error:
295 *-* say '** Error on line:' sigl 'rc=' rc
** Error on line: 179 rc= -3
296 *-* exit
IKJ56712I INVALID KEYWORD, PLAN(DSNTEP41)
READY
END
The JCL used:
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//MOVEDATA EXEC PGM=IKJEFT01,DYNAMNBR=20,REGION=2M,
// PARM='EXEC ''GANNON.ISPF.C(BATENVR)'''
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
EX 'GANNON.ISPF.REXX(MOVEDATA)' 'FSID(DSNP) TSID(DSNT) MNTH'
//*
And the proc used to set up the batch environment in PARM of JCL
(GANNON.ISPF.C(BATENVR))
PROC 0 /* ALLOCATE ISPF/PDF FILES */
CONTROL MSG ASIS /* DKM - MODIFIED FOR PBSB BY WBG 1999 */
PROF MSGID
FREE ALL
LISTDSI 'SYS1.NUCLEUS' NODIRECTORY
ALLOC F(SYSPROC) SHR DA('ICQ.ICQCCLIB','SYS1.SBLSCLI0',ISPF.REXX)
ALLOC F(ISPPLIB) SHR DA('ICQ.ICQPLIB','SYS2.PBCPLIB')
ALLOC F(ISPMLIB) SHR DA('ICQ.ICQMLIB','SYS2.PBCMLIB')
ALLOC F(ISPSLIB) SHR DA('ICQ.ICQSLIB','SYS2.PBCSLIB')
ALLOC F(ISPTLIB) SHR DA('ICQ.ICQTABLS',ISPF.T)
ALLOC F(ISPPROF) SHR DA(ISPF421.ISPPROF)
ALLOC F(STEPLIB) SHR DA('DSN#T.RUNLIB.LOAD','DSN#T.DSNEXIT',
'DSN#T.DSNLOAD','ISP.SISPLOAD', 'ISP.SISPLPA')
EXIT CODE(&MAXCC)
I added the STEPLIB portion to give the batch program addressability to
the DSN command (in DSNLOAD) because I thought that might be the problem
- but alas it wasn't.
Any Ideas on what a "RC(-3)" is or where I can look it up at ? This is
the part I have always disliked when creating an exec, the debugging /
searching 20 manuals for the right environment / options / things....
Well I am at a wits end today, maybe tomorrow things will be clearer -
Step away from the chalufas ;-)
If you have any insight or recommendations, or if there are any other
DB2 persons out there running execs against DB2 in a batch mode and have
proper JCL, could you please share them :-)
TIA
Bill G.
Conlin, Ron
your CLIST....
Hope this helps.
Ronald L. Conlin
Jackson National Life Insurance Company
Technology Department - Systems Programmer
voice: 517.367.3931
fax: 517.394.0986
email: ron.c...@jnli.com
Seibert, Dave
Just a guess.
It appears that since the Run command is complaining about the Plan
parameter, you're getting the TSO command Run.
here's the beginning of the help infor for RUN (FUNCTION -
THE RUN COMMAND COMPILES,LOADS AND EXECUTES A SOURCE PROGRAM.)
...
I think if you try pinpointing the reason it's finding the wrong Run
command.
Looks like your Steplib is coded correctly.
Insure that your steplib allocate is not failing.
Why the mix of JCL, Clist & Rexx?
Good luck.
David Seibert
Compuware Corporation File-AID product planner
Dave_S...@compuware.com
Robert Lawrence
HTH
Bob Lawrence
DBA
BOSCOV'S Dept Stores
Metz, Seymour
does not add it to the search list. He needs to either do it in his JCL or
to use the TSOLIB command.
Shmuel (Seymour J.) Metz
William Gannon
Thank you all for your responses (especially Mr. Conlin and Mr. Metz) - I
added a steplib to the batch JCL to point to the DB2 modules and everything is
working fine !
Have a Great weekend everyone ! :-)
Bill G.
Wilco Boschman
Your REXX complained about the DB2 RUN command. The parameter PLAN was
probably ok, but the next parameter, RUNLIB was not. It should be like:
RUN PROGRAM(«the program») PLAN(«the plan») RUNLIB(«the runlib
library»)
When you say you added the DB2 modules to the steplib or joblib, you
probably meant that you added the runlib library to the job/steplib. That
made it unnecessary to add the RUNLIB parameter to the RUN command.
William Gannon <wga...@INET-SERVICES.PALMBEACH.K12.FL.US> schreef in
berichtnieuws 3819F156...@email.palmbeach.k12.fl.us...
Gumbo
do something similar.
I need to remove the screen crap they have set up for DB2 at my site.
Currently we have to go through 4 separate screens to get to the screen
which edits the SQL to be run. I am hoping to reduce that to just the screen
to edit the SQL and possibly one to run it.
William Gannon
Process:
- The STEPLIB has only DSNEXIT and DSNLOAD
- The exec was changed to remove the RUNLIB
= the exec failed on the DSN command - rc8 (looking correct so far ..)
- The STEPLIB changed to add to the RUNLIB dataset to DSNEXIT and DSNLOAD
- The exec was changed to remove the RUNLIB on the DSN call line
= the exec failed on the DSN command - rc8
So, no I guess the approach isn't correct .. sorry ... but thanks for the
attempt anyway :-)
Bill G.
Wilco Boschman wrote:
> Hi William,
>
> Your REXX complained about the DB2 RUN command. The parameter PLAN was
> probably ok, but the next parameter, RUNLIB was not. It should be like:
> RUN PROGRAM(+the program;) PLAN(+the plan;) RUNLIB(+the runlib
N Benson
(William Gannon) wrote:
>Hi List !
>
>It's been a little quiet lately so I thought I would liven it up a
>little ....
<Snip>
Nice to see that someone else gets these helpful messages. I had a similar
problem trying to run SDF2 in batch. Normally running ISPF in any environment
doesn't require a STEPLIB at all - as long as the LNKLST and LPALST are set up
correctly. The site at which I am working recently introduced new versions of
everything included some new load libraries. Consequently these were omitted
from the LNKLST/LPALST. STEPLIBing to all the ISPF load libraries may cure your
problem. While debugging the SDF problem I only got -3 RCs but pulling the SDF2
rexx apart I found the only 10 dynamic allocations were being made, this
happened well before the -3 RCs. Even though these libraries had been missed
from the required list - there appeared to be no detriment to TSO itself !
Hope this helps .. let us know the outcome..
Nigel Benson
Wilco Boschman
As fas as I know, you don't need the DSNEXIT. You need the DSNLOAD because
the RUN command is in this dataset. The DSNTEPx (in our shop, DSNTEP2)
program is in the RUNLIB. What we do is add the DSNLOAD to the STEPLIB
(dynamically) and specify the RUNLIB in the RUN-command. I use this approach
all the time and it works fine. In REXX it looks like this:
"%STEPL 'DB2.DSNLOAD'" /* allocates DSNLOAD to the STEPLIB */
Ś
push 'END'
push 'RUN PROGRAM(DSNTEP2) PLAN(DSNTEP2) RUNLIB(DB2.<ssid>.RUNLIB.LOAD)'
address 'TSO' "DSN SYSTEM(<ssid>)"
before calling the DSN command the SQL should be in SYSIN, and the SYSPRINT
file should be allocated to capture the output. I allocate these file to a
VIO dataset.
maybe this is of some more help....
Wilco