| View previous topic :: View next topic |
| Author |
Message |
sumithar
Beginner
Joined: 22 Sep 2006
Posts: 84
Topics: 29
|
 Posted: Tue Apr 10, 2012 10:24 am Post subject: Diff between CALL and SELECT |
 |
|
What is the difference between these 2 approaches to invoking the search utility?
ADDRESS ISPEXEC "SELECT PGM(ISRSUPC) PARM(SRCHCMP,ANYC)"
"CALL *(ISRSUPC) 'SRCHCMP,ANYC'"
I'll candidly admit that I'm always cobbling things together and making it work since I don't often have the luxury of time to suss what exactly is going on!
FWIW, I couldn't the first technique to work, I got an RC28, but as I said, I found the other approach that took and am fated to remain in darkness about that RC28  |
|
| Back to top |
|
 |
papadi
Supermod
Joined: 20 Oct 2009
Posts: 594
Topics: 1
|
| Posted: Tue Apr 10, 2012 1:13 pm Post subject: |
|
|
Suggest you run a trace and post the output (just the part where the error is presented).
Did you research the rc28? Suggest you do so - i'm not familiar with an rc28.
_________________
All the best,
di |
|
| Back to top |
|
|
sumithar
Beginner
Joined: 22 Sep 2006
Posts: 84
Topics: 29
|
| Posted: Tue Apr 10, 2012 4:11 pm Post subject: |
|
|
Thanks for the followup.
Nothing much from trace. I have allocated the relevant datasets before the trace command.
9 *-* QUEUE "SRCHFOR '"STRING"'"
>>> "SRCHFOR 'WORKING'"
10 *-* "EXECIO" QUEUED() "DISKW SYSIN(FINIS"
>>> "EXECIO 1 DISKW SYSIN(FINIS"
12 *-* ADDRESS ISPEXEC "SELECT PGM(ISRSUPC) PARM('SRCHCMP,ANYC')"
>>> "SELECT PGM(ISRSUPC) PARM('SRCHCMP,ANYC')"
+++ RC(28) +++
I did some research in Google, but didn't find anything meaningful. I found a link for ISPF Services guide which talks about SELECT, maybe something will turn up there.
Since I've found an alternate working method, I really didn't want to try much more. |
|
| Back to top |
|
|
semigeezer
Supermod
Joined: 03 Jan 2003
Posts: 1014
Topics: 13
Location: Atlantis
|
| Posted: Tue Apr 10, 2012 10:29 pm Post subject: |
|
|
For this case, there is very little operational difference. The main differences are that SELECT PGM() loads the module and calls it within the same task as the ISPF screen is running (LINK macro). The CALL (from TSO) or the SELECT CMD() (from ISPF) start a new subtask (ATTACH macro). More importantly though SELECT (from ISPF) maintains an environment in which ISPF services are reliably available. CALL does not.
There is one very esoteric oddity in your example too... internally ISPF sets up the environment very slightly differently if the module name starts with ISR or ISP but I doubt ISRSUPC is sensitive to the differences. I think it sets up the length field of the command buffer slightly differently for ISR/ISP modules.
_________________
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. |
|
| Back to top |
|
|
sumithar
Beginner
Joined: 22 Sep 2006
Posts: 84
Topics: 29
|
| Posted: Fri Apr 13, 2012 3:21 pm Post subject: |
|
|
| semigeezer wrote: | For this case, there is very little operational difference. The main differences are that SELECT PGM() loads the module and calls it within the same task as the ISPF screen is running (LINK macro). The CALL (from TSO) or the SELECT CMD() (from ISPF) start a new subtask (ATTACH macro). More importantly though SELECT (from ISPF) maintains an environment in which ISPF services are reliably available. CALL does not.
There is one very esoteric oddity in your example too... internally ISPF sets up the environment very slightly differently if the module name starts with ISR or ISP but I doubt ISRSUPC is sensitive to the differences. I think it sets up the length field of the command buffer slightly differently for ISR/ISP modules. |
thanks for that detailed reply. I'm not sure I get it all but it sounds as if you are leaning towards using the ISP SELECT rather than the CALL but I can't seem to get the former to work. I looked in the ISPF services manual and I don't even see a return code 28 option with SELECT!
For all the work I've done with REXX in writing utilities these past so many years, I am yet to come to grips with the differences between TSO address space and ISPF services and MVS address spaces. I am always in a hurry to get it done and move on to my "real" job! |
|
| Back to top |
|
|
Mickeyd
Beginner
Joined: 02 Jan 2003
Posts: 27
Topics: 0
|
| Posted: Fri Apr 13, 2012 5:24 pm Post subject: |
|
|
This is what you select command should look like,
"SELECT PGM(ISRSUPC) PARM(SRCHCMP,ANYC,FINDALL)" |
|
| Back to top |
|
|
sumithar
Beginner
Joined: 22 Sep 2006
Posts: 84
Topics: 29
|
| Posted: Tue Apr 17, 2012 1:10 pm Post subject: |
|
|
| Mickeyd wrote: | This is what you select command should look like,
"SELECT PGM(ISRSUPC) PARM(SRCHCMP,ANYC,FINDALL)" |
I've tried with the parms inside apostrophes and without apostrophes. Result is same. |
|
| Back to top |
|
|
papadi
Supermod
Joined: 20 Oct 2009
Posts: 594
Topics: 1
|
| Posted: Tue Apr 17, 2012 2:58 pm Post subject: |
|
|
Is this part of a larger rexx exec?
Suggest you clone this exec and keep only the file allocations and the superc invocation. Then see what happens, and if it fails, run the trace again and post the trace and the cloned exec.
_________________
All the best,
di |
|
| Back to top |
|
|
sumithar
Beginner
Joined: 22 Sep 2006
Posts: 84
Topics: 29
|
| Posted: Wed Apr 18, 2012 7:51 am Post subject: |
|
|
| papadi wrote: | Is this part of a larger rexx exec?
Suggest you clone this exec and keep only the file allocations and the superc invocation. Then see what happens, and if it fails, run the trace again and post the trace and the cloned exec. |
No, I'm trying it out as just standalone...Here are the trace results. I found that in statement 9 if I had srchcmp in lowercase the result was RC 8, with uppercase it was RC 28
I tried variations like having the parms in apostrophes or not, and a comma separating the parms or not. Results are the same.
| Code: |
3 *-* "ALLOC F(outdd) NEW REU UNIT(VIO) SP(1,1) CYLINDERS"
>L> "ALLOC F(outdd) NEW REU UNIT(VIO) SP(1,1) CYLINDERS"
IRX0100I +++ Interactive trace. TRACE OFF to end debug, ENTER to continue. +++
4 *-* "ALLOC FI(NEWDD) DS('PROD.SOURCE(PROG500)') SHR REUSE"
>L> "ALLOC FI(NEWDD) DS('PROD.SOURCE(PROG500)') SHR REUSE"
5 *-* "ALLOC FI(SYSIN) DUMMY SHR REUSE"
>L> "ALLOC FI(SYSIN) DUMMY SHR REUSE"
6 *-* STRING = 'WORKING'
>L> "WORKING"
7 *-* QUEUE "SRCHFOR '"STRING"'"
>L> "SRCHFOR '"
>V> "WORKING"
>O> "SRCHFOR 'WORKING"
>L> "'"
>O> "SRCHFOR 'WORKING'"
8 *-* "EXECIO" QUEUED() "DISKW SYSIN(FINIS"
>L> "EXECIO"
>F> "1"
>O> "EXECIO 1"
>L> "DISKW SYSIN(FINIS"
>O> "EXECIO 1 DISKW SYSIN(FINIS"
9 *-* address ISPEXEC "SELECT PGM(ISRSUPC),PARM('SRCHCMP,ANYC')"
>L> "SELECT PGM(ISRSUPC),PARM('SRCHCMP,ANYC')"
+++ RC(28) +++
9 *-* address ISPEXEC "SELECT PGM(ISRSUPC),PARM('srchcmp,ANYC')"
>L> "SELECT PGM(ISRSUPC),PARM('srchcmp,ANYC')"
+++ RC(8) +++
|
|
|
| Back to top |
|
|
papadi
Supermod
Joined: 20 Oct 2009
Posts: 594
Topics: 1
|
| Posted: Wed Apr 18, 2012 2:23 pm Post subject: |
|
|
You might try OUTDD rather than outdd. . .
Why is SYSIN specified as "DUMMY"? I've never tried to ask superc to read a dummy file.
_________________
All the best,
di |
|
| Back to top |
|
|
sumithar
Beginner
Joined: 22 Sep 2006
Posts: 84
Topics: 29
|
| Posted: Thu Apr 19, 2012 8:04 am Post subject: |
|
|
Serves me right for copying and pasting blindly! I changed it to
"ALLOC F(sysin) NEW REU UNIT(VIO) RECFM(F B) LRECL(80)"
and it worked like a charm.
Thanks for pointing that out! |
|
| Back to top |
|
|
papadi
Supermod
Joined: 20 Oct 2009
Posts: 594
Topics: 1
|
| Posted: Thu Apr 19, 2012 10:21 am Post subject: |
|
|
Just found out that when superc is asked to compare "empty" files an rc28 is generated. The DUMMY would be "empty". . .
There is always a reason, sometimes it just hides for a while 
_________________
All the best,
di |
|
| Back to top |
|
|
sumithar
Beginner
Joined: 22 Sep 2006
Posts: 84
Topics: 29
|
| Posted: Sun Apr 22, 2012 5:59 pm Post subject: |
|
|
| papadi wrote: | Just found out that when superc is asked to compare "empty" files an rc28 is generated. The DUMMY would be "empty". . .
There is always a reason, sometimes it just hides for a while |
True dat! You are very helpful. |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
