Joined: 01 Dec 2006 Posts: 714 Location: Pennsylvania
Hi,
I am working an a Rexx exec, and I am trying to edit a PDS Member using the command ISPEXEC Edit with an Edit Macro.
The command is shown in the error below.
The problem is if the member is in use, it fails horribly, see here:
Code:
ISPF Dialog Error Member in use
Command ===>
******************************************************************************
* ISRE093 *
* *
* Member in use *
* Member is being updated by you or another user. Enter HELP for a list of *
* users using the data set. *
* *
* *
* *
* *
* *
* Current dialog statement: *
* EDIT DATASET(MAILBOX.PHEAA.TEST.DS94024.DATA(RULES)) MACRO(RULMAC1) *
* *
* Enter HELP command for further information regarding this error. *
* Press ENTER key to terminate the dialog. *
* *
* *
* *
* *
******************************************************************************
I realize this is always a possibility so I would like to do either of these possibilities:
1) Check ahead of time if the member is available. I can do this for a sequential file, but I can not figure out how to for a PDS member.
2) Fail more gracefully, meaning, trap the error, and report back the member is in use. I can return nicely to the calling program.
I have tried SIGNAL ON ERROR and FAILURE, but it has not effect.
I have tried x=msg('off'), but it has no effect.
I would great appreciate ideas on how to check ahead of time if the member is available (most preferred), or capture the error so that ISPF does not end on this error.
Joined: 01 Sep 2006 Posts: 2115 Location: Silicon Valley
ISPF Planning and Customization manual has an appendix for 'member name enqueue' that describes the enqueue:
Quote:
rname
the data set name, length of 44, padded with blanks, followed by
the member name, length of 8, padded with blanks
With the QNAME being SPFEDIT.
And ISPF Services Guide describes the QUERYENQ service, which will tell you who is using the data set and whether exclusive use or shared, based on the QNAME and RNAME parameters.
Joined: 01 Dec 2006 Posts: 714 Location: Pennsylvania
I am using the terms enqueue and inuse interchangeably (right or wrong).
This is for an automation project.
The user sets up data in a given (TSO) application.
Based on that setup 3 or 4 other files (one is a pds member) need updates.
The user will invoke the update from the Panel and the Rexx will make the updates. This improves their productivity and accuracy.
I want to be sure all the other files are available for update before I perform any updates.
I can not enqueue the entire pds as there are 1000s of other members there not related to this project.
Ideally this member should be in its own sequential file, but that is out of scope of this project.
I used the information Pedro provided to check if all of my resources are available. I will take the risk that these resources will not become unavailable in the short (very short) time it will take to perform the updates using small edit macros.
I am using a new (to me) technique I found on this forum to pass data to the edit macro from the Rexx. Create a NEWSTACK, Queue however many lines of data, then invoke edit with the macro. The macro can then pull the data from the stack. I think I like it better than using the Shared pool, or with input parms. We will see.
Joined: 20 Oct 2006 Posts: 6970 Location: porcelain throne
an alternative approach that I have used when I attempted to write batch applications that mimic CICS is:
i would define a small, 1 record file that I would only allocate during the application. any other application would have its own file.
pseudo code:
Code:
i = 0
do until RC = 0
alloc [b]this_apps_ds[/b] as I/O and old.
i = i + 1
if i > 1000 then
do
say contact dave at telno: 555-good-luck
exit
end
end
normal process of script.
free [b]this_apps_ds[/b]
exit
end pseudo code
this insured that I was able to complete the edits, once started.
and yes if one of the edit macros fell over, you will start getting
'dave,i am calling because.....'
but at least you will have stopped any processing immediately after the first failure.
and the user that had the first macro failure will have to free the this_apps_ds
he possibly did not call, because he did not realize that there was a problem,
unless of course he tries again for some other data,
but then he will call, because he, due to not freeing the ds will also have alloc problems.
