View previous topic :: View next topic
|
Author |
Message |
WilliamDownie
New User
Joined: 01 Jul 2020 Posts: 21 Location: UK
|
|
|
|
I've got a REXX / ISPF panel where I list PDS members and from there I can select a member to browse or edit. If I edit a member which is currently being edited I get the following Dialog Error, and the dialog then exits which is a bit messy.
Code: |
ISPF Dialog Error
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. *
* * |
To edit I use the following:
Code: |
Address ISPEXEC "EDIT DATASET('"MEM"')"
|
How can I either trap this error or better still check whether the member is being edited before I attempt to edit it ? Is there something like SYSDSN that can be used ? I've look into using QUERYENQ but this seems a bit of a hammer to crack a nut. I don't need to know who is currently editing the member. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
just tested, if a dataset is in use You will get a return code of 14
but You could have found that also using the model statement
Code: |
If rc ^= 0 Then /* Return codes */
Do /* 4 - Data not saved */
End /* 12 - LOCK specified */
Else /* 14 - Member or sequential */
/* data set in use */
/* 16 - No members in library */
/* 18 - VSAM processing unavailable */
/* 20 - Severe error */
|
even if a few times the model statement returns wrong information
it still a very useful source of information
just open an empty member and type MODEL in the command line |
|
Back to top |
|
|
WilliamDownie
New User
Joined: 01 Jul 2020 Posts: 21 Location: UK
|
|
|
|
Thanks Enrico, I didn't know about "ISPEXEC CONTROL ERRORS". I've added:
Code: |
Address ISPEXEC "CONTROL ERRORS RETURN" |
and I get RC of 14 if the member is in use. Exactly what I was looking for. |
|
Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011 Posts: 199 Location: UK
|
|
|
|
Is there any reason why you couldn't use SYSDSN as you suggested in your first post? That should return UNAVAILABLE DATASET if the dataset is in use. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
becuse it would be a waste of time...
it is a good practice to allways check the return codes
and the return code from the edit should be checked anyway
You might want to know for example if the dataset was changed or not |
|
Back to top |
|
|
WilliamDownie
New User
Joined: 01 Jul 2020 Posts: 21 Location: UK
|
|
|
|
David , Initially I did look into using SYSDSN. I found SYSDSN returns one of the following:
Quote: |
OK
MEMBER SPECIFIED, BUT DATASET IS NOT PARTITIONED
MEMBER NOT FOUND
DATASET NOT FOUND
ERROR PROCESSING REQUESTED DATASET
PROTECTED DATASET
VOLUME NOT ON SYSTEM
UNAVAILABLE DATASET
INVALID DATASET NAME, data-set-name:
MISSING DATASET NAME |
There isn't a check for dataset being edited. I tried using SYSDSN on a dataset being edited and it returned 'OK'. |
|
Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015 Posts: 734 Location: Denmark
|
|
|
|
re "check whether the member is being edited before I attempt to edit it"
You can check the enqueue major = SPFEDIT and minor = left(datasetname,44) left(memberna,e,8)
There are ways to do that - MXI or SDSF comes to mind, but at the end of the day then EDIT and check for rc>0 is probably the fastest. The advantage of using ENQ is that you can see which job is editing the member. |
|
Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015 Posts: 734 Location: Denmark
|
|
|
|
Correction:
major = SPFEDIT
minor = left(datasetname,44) || left(membername,8) |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
enrico-sorichetti wrote: |
just tested, if a dataset is in use You will get a return code of 14
but You could have found that also using the model statement
Code: |
If rc ^= 0 Then /* Return codes */
Do /* 4 - Data not saved */
End /* 12 - LOCK specified */
Else /* 14 - Member or sequential */
/* data set in use */
/* 16 - No members in library */
/* 18 - VSAM processing unavailable */
/* 20 - Severe error */
|
even if a few times the model statement returns wrong information
it still a very useful source of information
just open an empty member and type MODEL in the command line |
Yes! The MODEL command is one of the hidden gems in ISPF. So few seem to know about it. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
Quote: |
The MODEL command is one of the hidden gems in ISPF. So few seem to know about it |
but it clobbers the edit screen
better be sure of using an empty member, |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
hit the back button twice |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
enrico-sorichetti wrote: |
Quote: |
The MODEL command is one of the hidden gems in ISPF. So few seem to know about it |
but it clobbers the edit screen
better be sure of using an empty member, |
The RESET command gets rid of the Note lines, leaving just the sample syntax and return codes. I find MODEL especially helpful on the rare occasions that I create a dialog application using COBOL. |
|
Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015 Posts: 1337 Location: Bamberg, Germany
|
|
|
|
There are a couple of SHARE foils presenting what ISPF has to offer. Always worth reading. |
|
Back to top |
|
|
|