MVSFORUMS.com

[jim haire]

Has anyone ever ran into a scenario where they were doing ISPF table processing in a REXX program and the ISPF table dataset was still open after the program completed?

It seems as if all my table processing completed correctly and the TBCLOSE statement closed the table, but when I try to go to 3.4 and delete the dataset, it says the dataset is open.

I've tried a number of things in my code...
EXECIO with a FINIS, deallocate the file, freeing the dataset. Nothing seems to work. Only way I can delete the dataset is to logoff TSO and log back in.

Any ideas how I can programatically close the dataset?

[semigeezer]

I don;t know why it is open, but I think if you do a tbopen of another table (even one that doesn't exist and trap the error), it gets cleaned up. That's a memory from 10 years ago though.
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.

[jim haire]

That didn't work. I did a "TBOPEN DUMMY NOWRITE" immediately after I did a TBSAVE. It was the last thing I did upon exiting the program. I wasn't able to delete the dataset because it was still open.

[expat]

1) How is the file allocated within your REXX.
2) What have you done to find out "who" has the file open.
_________________
If it's true that we are here to help others,
then what exactly are the others here for ?

[semigeezer]

I think this is what I was thinking of Jim

http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.f54mc00/ispzmc6019.htm
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.

[jim haire]

I really thought you had the answer when I went to the link. However, I didn't issue a table service with a LIBRARY parameter. (Maybe that's what I'm doing wrong?)

Here are the steps I am doing in order:
1. Check to see if table dataset already exists.
2. If not, do a PDS allocation using TSO ALLOC. I immediately free the
dataset after creating it.
3. The next thing I do is:
"LIBDEF ISPTABL DATASET ID('"TABLE_DATASET"')".
TABLE_DATASET is built using my userid and a literal string.
4. I next check to see if there is a member within the PDS called
TSQUEUE.
5. If there is a member there I issue a "TBOPEN TSQUEUE WRITE".
6. If there isn't a member with that name, I issue a
"TBCREATE TSQUEUE NAMES(TXTSTRG) WRITE" .
7. After step 5 or 6 is performed, I do a
"TBSTATS TSQUEUE ROWCURR(NUMROWS)" to set up a variable
where the number of rows on the table is to be stored.
8. I issue a "TBBOTTOM TSQUEUE NOREAD" to position myself at the
botom of the table.
9. I then set the value TXTSTRG to some value and execute a
"TBADD TSQUEUE". This gets repeated until I have no more values
to add.
10. At this point I issue a "TBSAVE TSQUEUE", to make the values
permanent.
11. I tried the "TBOPEN JUNK LIBRARY(DDJUNK)" you suggested at this
point, but it didn't make a difference.

Hopefully this gives an explanation of how I'm allocating my files and the
logic I'm executing.

I am the only one accessing this dataset. I am the only one who could have it open.

[expat]

Mmmmmmmmmm, I'm sure I've had this myself many moons ago.

I usually use the STACK parameter with LIBDEFS, and at the end of my REXX will issue a null LIBDEF

[CZerfas]

What I tink is missing in your sequence of actions is a cleanup of the libdef allocations as could be
"LIBDEF ISPTABL"
without further parameters. This should get rid of your starting LIBDEF allocation.

Probably this helps.
Christian

[jim haire]

Thanks for all your patience.

I am very new to ISPF tables and am finding them very confusing. It appears that the "LIBDEF ISPTABL" did clean up my allocations and did allow me to delete my ISPF table dataset after I had written values to it.

But I am confused by something else. I wrote three values to my ISPF table. I can look at the member within my PDS and I can see the values. I even wrote another program, opening the PDS with a DDNAME of ISPTLIB and viewing the three values I put on the table.

However, I then delete my PDS, the entire dataset set including the member containing the three values. I then choose three different values to put on the table. Table gets recreated, re-allocated, etc. When I use my program to view the values I have written to the tables it now shows the original 3 plus the new 3 values!

I would have thought that deleting the dataset would have rid me of those inital 3 values. What am I not understanding?

[expat]

I believe that ISPF may well maintain a copy of the table in storage.

Again, with experience and good tutoring, when finishing loading a table I always tend to use TBCLOSE rather than TBSAVE, and then open the table afresh.

From the manual

[semigeezer]

Sorry Jim, I can't really help there. I stay away from tables questions because I almost always get the answer wrong. In this case, it may be that the variables are coming from the profile somewhere but I don't use tables (because I can't figure them out either, and dynamic areas aren't too hard for display) so -- that answer is probably wrong :
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.

[jim haire]

Sorry I didn't get back sooner. I had some real work that needed to get done.

I tried substituting the TBCLOSE for the TBSAVE, but it didn't get rid of the variables when I did the delete. The description Expat provided did seem as if this should resolve the problem, but it didn't.

I can probably do a TBERASE to remove the variables from the tables. It just seems odd that I set up a dataset/member to hold these variables, delete the entire dataset, and the variables are still there when I
re-create the table.

It's good to hear that I'm not the only one who hasn't figured out ISPF table logic, Semigeezer. Seemed like it would be easy, but results haven't proven out to be.

I tried googling on this topic, but there's not much available.