|
|
View previous topic :: :: View next topic
|
| Author |
Message |
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 665
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.
Thanks. |
|
| Back to top |
|
 |
|
|
Pedro
Senior Member
Joined: 01 Sep 2006
Posts: 2042
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. |
|
| Back to top |
|
|
enrico-sorichetti
Global Moderator
Joined: 14 Mar 2007
Posts: 10272
Location: italy
|
|
|
|
did You remember to use
Address ISPEXEC "CONTROL ERRORS RETURN"
probably not
a 14 return code is returned for ...
member or sequential dataset in use
IMHO checking ahead is a waste of time ...
You would have to check anyhow the EDIT return code for the WHAT IF |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 665
Location: Pennsylvania
|
|
|
|
Pedro,
Thanks for that information. I tried it out and it will give me the information I need.
Enrico,
I did not remember to use that command. In fact I forgot about it altogether.
I used it and did get the return code = 14.
I have been on the fence on checking ahead of time or not.
I think I need to check first because if any of my datasets (3 or 4) are enqueued, I do not want to update any of them. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6967
Location: porcelain throne
|
|
|
|
| Quote: |
| I do not want to update any of them |
in use, i agree, but why if enqueued?
is this a timing issue? if so, why not run the exec after hours.
what i see is that during the time (second, millisecond) that I check
not enqueued, but a millisecond later a user wants to use the pds?
if you are updating, are you not trying for an exclusive on the pds?
that would prevent you from 'overwriting' a user,
but if these are production libraries, you could inhibit a production run.
i have always been of the opinion, that if I have to update a prod lib,
i schedule my exclusive with ops and then run it with their cooperation. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 665
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.
Thank you all for your help here. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6967
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.
just a suggestion. |
|
| Back to top |
|
|
|
|
