Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Could not execute ALLOC and FREE in REXX

473 views
Skip to first unread message

Jeff Wang

unread,
Feb 5, 2004, 2:37:53 PM2/5/04
to
Hi all,

Can someone helps me out. I've been struggling with this for almost a
week and still have no clue what's wrong.

Basically I want to write a DB2 stored procedure for OS/390 in REXX.
In this procedure it reads a dataset and return the first line of the
dataset. I met two problems:

Problem 1:
WLM environment does not start automatically when the DB2 stored
procedure is called.

Problem 2:
TSO Commands, such as ALLOCATE and FREE cannot be executed in the REXX
stored procedure, but TSO REXX commands can (like EXECIO, TE, TS).

My story is listed below:

REXX Procedure - JEFF.PDS.REXX(RXREAD1):

ARG fileName
say ADDRESS();
"ALLOC FI(FILEDD) DA('"fileName"') SHR REUSE"
"EXECIO 1 DISKR FILEDD (STEM lines."
fileTxt = lines.1
"EXECIO 0 DISKR FILEDD (FINIS"
"FREE FI(FILEDD)"
EXIT fileTxt


Command used to create the DB2 stored procedure JEFF.RXREAD1:

CREATE PROCEDURE RXREAD1(
IN FILENAME CHAR(44),
OUT FILETXT VARCHAR(256))
LANGUAGE REXX
EXTERNAL NAME RXREAD1
NO COLLID
NO SQL
ASUTIME NO LIMIT
RUN OPTIONS 'TRAP(ON)'
WLM ENVIRONMENT WLMENV1
PARAMETER STYLE GENERAL
SECURITY DB2
DYNAMIC RESULT SET 1
COMMIT ON RETURN NO;

Definition of WLM application environment WLMENV1:

Appl Environment Name . . WLMENV1
Description . . . . . . . Stored Procedures
Subsystem type . . . . . DB2
Procedure name . . . . . DSN1WLM1
Start parameters . . . . DB2SSN=&IWMSSNM,NUMTCB=2,APPLENV='WLMENV
1'
Limit on starting server address spaces for a subsystem instance:
No limit


I got a time-out error when I issued a CALL from the client program
(DB2 Client Command Center):
CALL RXREAD1("JEFF.TEST", ?)

It hangs there until return a time-out error message:

------------------------------ Command Entered
------------------------
CALL RXREAD1("JEFF.TEST", ?)
-----------------------------------------------------------------------
SQL0471N Invocation of routine "JEFF .RXREAD1 " failed
due to reason "00E79002". SQLSTATE=55023

So I read some manuals and wrote a WLM-environment start-up script and
put in the PROCLIB:
ADCD.ZOSV1R2.PROCLIB(DSN1WLM1)
//*************************************************************
//* JCL PROCEDURE FOR THE STARTUP OF THE
//* DB2 STORED PROCEDURES ADDRESS SPACE
//* RGN -- THE MVS REGION SIZE FOR THE ADDRESS SPACE.
//* DB2SSN -- THE DB2 SUBSYSTEM NAME.
//* NUMTCB -- THE NUMBER OF TCBS USED TO
//* PROCESS END USER REQUESTS.
//*
//*************************************************************
//DSN1WLM1 PROC RGN=24M,DB2SSN=DSN1,NUMTCB=8,APPLENV=
//IEFPROC EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,
// PARM='&DB2SSN,&NUMTCB,&APPLENV.'
//STEPLIB DD DISP=SHR,DSN=DSN710.RUNLIB.LOAD
// DD DISP=SHR,DSN=CEE.SCEERUN
// DD DISP=SHR,DSN=DSN710.SDSNLOAD
//SYSEXEC DD DSN=JEFF.PDS.REXX,DISP=SHR
//SYSTSPRT DD SYSOUT=*


The time out problem still existed.
Then I wrote another JCL to start the WLM address space manually:
JEFF.PDS.REXX(JEFFCHEK)
//JEFFCHEK JOB (999,POK),'SAVE TIME',NOTIFY=&SYSUID.,
// CLASS=A,MSGCLASS=T,REGION=5000K,
//* TYPRUN=SCAN,
// MSGLEVEL=(1,1)
// EXEC DSN1WLM1,DB2SSN=DSN1,NUMTCB=8,APPLENV=WLMENV1
/*
//


I submited job JEFFCHEK and called the procedure again:

CALL RXREAD1("JEFF.TEST", ?)
------------------------------ Command Entered
------------------------
CALL RXREAD1("JEFF.LUCIDRDR", ?)
-----------------------------------------------------------------------
FILETXT: LINES.1
"RXREAD1" RETURN_STATUS: "0"


It returned something, but not the first line of the dataset. I
checked the output of SYSTSPRT of job JEFFCHEK, it has:
TSO
3 *-* "ALLOC FI(FILEDD) DA('"fileName"') SHR REUSE"
+++ RC(-3) +++
IRX0555E The input or output file FILEDD is not allocated. It cannot
be opened for I/O.
IRX0670E EXECIO error while trying to GET or PUT a record.
7 *-* "FREE FI(FILEDD)"
+++ RC(-3) +++

Based on my understanding, it means the host commands: ALLOC and FREE
could not be executed.

Can somebody tell me what's wrong? Any comments are welcome.

Thanks!

Jeff Wang
Afshar Consulting Group

Larry Kahm

unread,
Feb 5, 2004, 7:10:15 PM2/5/04
to
Hey Jeff,

Add the phrase ADDRESS TSO to your ALLOC and FREE statements - because they are, after all, TSO
commands.

Hope that helps!

Larry

"Jeff Wang" <jeffwa...@yahoo.com> wrote in message
news:9930a8e7.04020...@posting.google.com...

David Bond

unread,
Feb 5, 2004, 10:24:20 PM2/5/04
to
"Jeff Wang" <jeffwa...@yahoo.com> wrote in message
news:9930a8e7.04020...@posting.google.com...
> Problem 2:
> TSO Commands, such as ALLOCATE and FREE cannot be executed in the REXX
> stored procedure, but TSO REXX commands can (like EXECIO, TE, TS).

The TSO commands (like ALLOC) are only usable in a TSO address space.
If you are running on z/OS 1.4, you can use BPXWDYN.
See "Using REXX and z/OS UNIX Systems Services" SA22-7806-03.
Otherwise, you will need to write your own external function to perform
the SVC 99. There is probably one on the CBT. http://www.cbttape.org/

David Bond - Tachyon Software LLC - http://www.tachyonsoft.com


Jeff Wang

unread,
Feb 6, 2004, 4:43:47 PM2/6/04
to
Thanks Larry!

I added the phrase ADDRESS TSO in front of the ALLOC and FREE
statements, the return code was still -3.

Jeff

"Larry Kahm" <lkahm@nospam_bellatlantic.net> wrote in message news:<HXAUb.17999$KV5....@nwrdny01.gnilink.net>...

Jeff Wang

unread,
Feb 6, 2004, 4:53:59 PM2/6/04
to
Hi David,

I used "say ADDRESS()" to print the running address space of the REXX
script and it returned "TSO". Did it mean the REXX procedure was
actually running in a TSO address space? If yes, why wouldn't it
execute ALLOCATE?
I will check BPXWDYN out.

Thank you very much for your help.
Jeff

"David Bond" <db...@tachyonsoft.com> wrote in message news:<ENDUb.13256$F23....@newsread2.news.pas.earthlink.net>...

David Bond

unread,
Feb 6, 2004, 5:32:21 PM2/6/04
to
Hi Jeff,

Look at the results from PARSE SOURCE to determine if you are running
under TSO or not. I do not believe that DB2 stored procedures or functions
run in a TSO environment so ALLOC, FREE or all other TSO command
processors will not work.

David Bond - Tachyon Software LLC - http://www.tachyonsoft.com

"Jeff Wang" <jeffwa...@yahoo.com> wrote in message
news:9930a8e7.04020...@posting.google.com...

Jeff Wang

unread,
Feb 9, 2004, 10:09:58 AM2/9/04
to
Hi David,

I add the code below to the script:
PARSE SOURCE sysname .
say sysname
It displays "TSO". Does it mean the procedure is running under TSO?
I tried BPXWDYN and it worked. But I still want to get the TSO
commands working if at all possible. I need to use some other TSO
commands like LISTCAT, LISTDS in the REXX procedure.

Thank you for your help!
Jeff


"David Bond" <db...@tachyonsoft.com> wrote in message news:<VBUUb.14083$F23....@newsread2.news.pas.earthlink.net>...

Jeff Wang

unread,
Feb 9, 2004, 11:31:29 AM2/9/04
to
Hi David,

I tried PARSE SOURCE again in the REXX procedure:
PARSE SOURCE sysname
say sysname
It displays:
TSO SUBROUTINE RXREAD1 SYSEXEC ? RXREAD1 TSO TSO/E ?

Thank you!
Jeff

"David Bond" <db...@tachyonsoft.com> wrote in message news:<VBUUb.14083$F23....@newsread2.news.pas.earthlink.net>...

David Bond

unread,
Feb 11, 2004, 9:40:51 PM2/11/04
to
Hi Jeff,

PARSE SOURCE always returns "TSO" as the first token on MVS.
The 8th token should return "TSO/E", "MVS", "ISPF" or some other value.
I don't know of any way to get LISTDS or other TSO commands to
run in a DB2 WLM address space - short of executing IKJEFT01.
For LISTCAT you could allocate SYSIN and SYSPRINT, start IDCAMS
and then parse the SYSPRINT file.

David Bond - Tachyon Software LLC

"Jeff Wang" <jeffwa...@yahoo.com> wrote ...

0 new messages