|
View previous topic :: View next topic
|
| Author |
Message |
sureshahead
New User
Joined: 07 Feb 2008
Posts: 2
Location: Bangalore/Chennai
|
|
|
|
Hi All,
I ran the REXX Code thru TSO EXEC & the code ran fine giving the desired results.
After the REXX was run I was to submit some JCL which actually uses
the datasets used in the REXX code.
When the JCL got submitted I found the following message in JESMSGLG :
FOLLOWING RESERVED DATA SET NAMES UNAVAILABLE TO XXXXM091
DSN = XXXXX.XXXX.XXX0004.XYZ XXXM091 RC = 04
JOB XXXM091 WAITING FOR DATA SETS
So when I gave in TSO ISRDDN ---> then enq, I found all the datasets used in the REXX with exclusive lock & the job name pointing to my user-id.
But when I try to open the datsets in Edit mode, am able to edit them but the JCL job is unable to access the same & so are the access using diff user id's.
I would like to present some of the function which I have coded in REXX to use the datsets :
| Code: |
COPYDS: PROCEDURE
ARG SRC_DSNAME DES_DSNAME LOGS LOG REASON
"ALLOC DSN('"DES_DSNAME"') LIKE('"SRC_DSNAME"')"
"ALLOC FI(SYSUT1) DA('"SRC_DSNAME"') SHR REU"
"ALLOC FI(SYSUT2) DA('"DES_DSNAME"') SHR REU"
"ALLOC FI(SYSPRINT) SYSOUT REU"
"ALLOC FI(SYSIN) DUMMY REU"
"IEBGENER"
SAY 'COPY RETURN CODE = 'RC
"FREE FI(SYSUT1 SYSUT2 SYSIN SYSPRINT)"
IF REASON='REVERT INFO' THEN
LOGDATA='REVERT INFO : COPIED 'SRC_DSNAME || ' TO ' || DES_DSNAME
ELSE LOGDATA='COPIED ' || SRC_DSNAME || ' TO ' || DES_DSNAME
IF LOG=YES THEN CALL APPEND LOGS LOGDATA
RETURN
|
| Code: |
SEARCHDS: PROCEDURE
ARG SRC_DSNAME,POSITION,VAL1,VAL2
/*TRAPOUT=OUTTRAP('LINE.')*/
"ALLOC F(IN) DA('"SRC_DSNAME"') SHR"
IF RC¬=0 THEN CALL DSERRQUIT SRC_DSNAME 'ALLOCATE'
"EXECIO * DISKR IN (STEM DATA. FINIS"
"FREE F(IN)"
DO INC=2 TO (DATA.0)-1
VAL=SUBSTR(DATA.INC,POSITION,1)
IF VAL=VAL1 & VAL2='' THEN RETURN 1
ELSE IF VAL=VAL1 | VAL=VAL2 THEN RETURN 1
END
RETURN 0
|
| Code: |
REPLACEHEADER: PROCEDURE
ARG SRC_DSNAME DES_DSNAME LOGS LOG
/*TRAPOUT=OUTTRAP('LINE.')*/
"ALLOC F(IN) DA('"SRC_DSNAME"') SHR"
IF RC¬=0 THEN CALL DSERRQUIT SRC_DSNAME 'ALLOCATE'
/*TRAPOUT=OUTTRAP('LINE.')*/
"ALLOC F(OUT) DA('"DES_DSNAME"') OLD"
IF RC¬=0 THEN CALL DSERRQUIT DES_DSNAME 'ALLOCATE'
"EXECIO" 1 "DISKR IN" 1
PARSE PULL HEADER1
"EXECIO" 1 "DISKRU OUT" 1
PARSE PULL HEADER2
"EXECIO 0 DISKR IN (FINIS"
"FREE F(IN)"
HEADER2=HEADER1
PUSH HEADER2
"EXECIO 1 DISKW OUT"
"EXECIO 0 DISKW OUT (FINIS" /*COPY USING STEM*/
"FREE F(OUT)"
LOGDATA='REPLACED HEADER OF ' || DES_DSNAME || ' WITH HEADER FROM ',
|| SRC_DSNAME
IF LOG='YES' THEN CALL APPEND LOGS LOGDATA
RETURN
|
Please verify the above functions & let me know whether my access to datasets & deallocation of memory allocated for the datasets are right.
If everything is proper then pls let me know what might be the reason for exclusive lock on DS using my User-id. |
|
| Back to top |
|
 |
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
There is nothing I can think of within REXX that would allow it to place an exclusive enqueue lock on a dataset, especially since REXX has no dealings with datasets. Dataset allocations, de-allocations, etc. are handled by other external processes. So, I'd forget about it being a REXX issue and look elsewhere. It looks like you're using the TSO command "ALLOCATE" to handle some of your dataset allocations. Nothing appears out of place there, except that most users code the REUSE parameter on an ALLOCATE.
One way I know of to lock a dataset is to use DISP=OLD allocation and then not FREE it. Another is the process of editing a dataset with ISPF EDIT, or using an ISPF Service to issue an exclusive lock. I don't see either in your code samples.
At this point, I'd ask that you turn on a TRACE, run your code, and then post the entire results of the TRACE output. |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
Hi Superk,
I too have come across the same exact situation, where i used basic ALLOC and DISKR and DISKWR and FREE commands only.
strange though 
It would be helpful if there is a logical reasoning for this.
Thanks, |
|
| Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
| I think if it did happen, I'd stop at that point and list all of the dataset allocations for my TSO session. I'd at least want to know the DD name that was the culprit. For debugging purposes, I'd try to use different DD names for the same dataset allocation. |
|
| Back to top |
|
|
sureshahead
New User
Joined: 07 Feb 2008
Posts: 2
Location: Bangalore/Chennai
|
|
|
|
The culprit code exists in the procedure that I created to copy the datasets.
I.E : Previously I did not have a DD name associated with the newly created dataset(DES_DSNAME) & thus I did not free the memory occupied by the same after copy of data is done. Now I just corrected the code as mentioned below & got the problem resolved.
COPYDS: PROCEDURE
ARG SRC_DSNAME DES_DSNAME LOGS LOG REASON
"ALLOC FI(DESDS1) DSN('"DES_DSNAME"') LIKE('"SRC_DSNAME"') NEW"
.
.
.
.
"IEBGENER"
SAY 'COPY RETURN CODE = 'RC
"FREE FI(DESDS1 SYSUT1 SYSUT2 SYSIN SYSPRINT)"
.
.
.
RETURN
Thanks Superk for your advice & thru Trace I got clue where the mistake was & also after running the code I went & checked the TSO ISRDDN & found only the datasets accessed through this proc to have got the exclusive lock & tried my hands to fix the same & it worked.
Any comments welcome...!!!  |
|
| Back to top |
|
|
|
|
