2017-06-16 18:33:44 UTC
(Part of the reason I didn't already encounter it, probably, is that I don't usually write to a catalogued dataset; most of my routines use VIEWQ, which allocates a temporary dataset, writes the stack to that and then displays it in View. It's only rarely that I write to a real DSN.)
/* Side hike: If you're skeptical - up till now I would have said it's not possible to overwrite a dataset that's being edited - herewith some details:
I have a few REXX programs that generate TSS commands. In some cases rather than execute the TSS commands live, I EXECIOST them to My.Clist.Library(TCMDS), then immediately Edit TCMDS with the expectation that I will examine the results on the spot, possibly make changes, and then say "save;tso tcmds".
Just now I have an unusual situation: I see from the results of one such REXX routine a situation that I want to fix by running another. The second routine creates new TSS commands, writes them to TCMDS, issues the Edit service for TCMDS, gets back RC 14 (meaning it's in use) and abends with that message.
This has been happening occasionally for a week or two now, and I've been carelessly assuming that the second EXECIOST failed as well as the Edit. It isn't until today I discovered that the second program was doing the write successfully; it's only the second Edit that failed.
To test this, I entered an Edit session of TCMDS, then split the screen and ran one of the commands that writes to it. When that command failed ("In use"), I went back to the Edit session and issued the Restore command, which showed me the contents had been changed successfully. */
So I'd like some way of knowing ~before~ I try to write to My.Clist.Library(TCMDS) whether it's being edited, so I won't write over the contents accidentally. Any ideas? Here are some possibilities:
1) Allocate the output dataset with disp=OLD instead of SHR. Nope, it makes no difference; with TCMDS in an Edit session, that ALLOCATE statement still returns rc 0.
2) ISPEXEC LMINIT ENQ(EXCLU)/LMOPEN OPTION(OUTPUT)/LMMFIND MEMBER(TCMDS). I thought I was on to something there, but it turns out LMMFIND works only with OPTION(INPUT), although I don't see that in the documentation. With OPTION(INPUT), LMMFIND returns RC 0.
3) ISRDDN apparently can detect enqueue conditions, but how can I get ISRDDN to talk to a REXX? Maybe this way: Issue ISRDDN with the ENQ argument, after creating a private copy of the panel ISRDENQG that a) does a VGET to see whether it's being called by my routine and if so b) VPUTs the desired data and c) exits instead of displaying. I'd have to experiment quite a bit to get that to work.
4) Use the LM services to write the data, instead of EXECIO. I think that'll work; presumably the LM services can tell whether the member is already in use before writing. But I'm hoping for an easier way.
5) I could try editing ~before~ I do the write; but that's no good because assuming TCMDS is not in contention I'd end up in an Edit session and the REXX couldn't continue until I hit <Enter>.
6) Hey, this'd work: Write a NOP Edit macro, one whose only purpose is to exit the Edit session immediately. Then Edit the dataset with MACRO(NOP); if the Edit succeeds then there's no contention, and if the RC is 14 then there is. If no one here has a better idea, I'll try that.
You'd think there'd be a routine somewhere around that can detect such situations, but I'm not finding it so far.
***@gmail.com, cell 336 382-7313
/* We never fail God's tests; we just keep taking them until we pass. -attributed to Francis Frangipane */
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX