Re: REXX ISPF edit FIND failing
Shmuel Metz (Seymour J.) wrote: In 500f6f1d@bcs.org.uk, on 07/25/2012 at 04:59 AM, CM Poncelet ponce...@bcs.org.uk said: Yes I know that. ADDRESS ISREDIT, on its own, is sufficient to cause all commands that follow it to be interpreted as ISREDIT ones (without quotes The need, or lack of need, for quotes has nothing to do with whether you use a stand-alone ADDRESS statement. You need quotest around text that you want treated as a constant. You don't need quotes around an expression that will evaluate to the value you want. I know that too. But I do not normally use ADDRESS except for IPCS: it is just as easy, and quicker, to put strings in quotes. The two have nothing to do with each other. I did not say they had. I said it is just as easy, and quicker, to put strings in quotes. That is what I said, No, you said 'So I assume that ISPEXEC ... is calling ISPEXEC directly', and thast assumption is incorrect. You are right: I should have said is calling ISPEXEC indirectly. But I was thinking in terms of ISPEXEC itself being called by ISPEXEC ..., rather than whether the call was then direct or indirect. Thanks for noticing/correcting my lack of attention to detail. except that I use quotes instead of ADDRESS. They are unrelated to each other. All of these are equivalent[1]: ADDRESS ISREDIT F ALL ADDRESS ISREDIT F ALL ADDRESS ISREDIT F ALL F ALL Yes, I know that. But ISREDIT ... is quicker to type than ADDRESS ISREDIT ... et al. - and it is only the results that matter to me. So why should I spend 15 minutes typing ADDRESS when using quotes will take me only 10 minutes? The REXX code will execute in seconds either way. It is then typically executed only once - just to save time from making my changes, or doing whatever else, manually. So I have hundreds of these 'adhoc' REXX and Clist things (I name them @000/1/2/3 etc., as what they are called is irrelevant) and all I want is quick results, so I can carry on with other work afterwards. Yes, by IPCS call I mean expressions beginning with IPCS Then it's indirect. Sure: but so what? If I'm analyzing a dump, all I'm interested in is the results - not in whether my IPCS REXX is direct or indirect. If I use a hammer, I could not care less about which company made it and what color its handle is: all that matters to me is whether it hits nails. I am not referring to REXX invoking other environments - which requires either an ADDRESS (which I do not use) or quotes (which I do use). Quotes are irrelevant to the issue. Whether you need them has nothing to do with whether you use ADDRESS. Are you being serious, or just wasting my time with your platitudes? Is there anything else you think I need to know? If yes, could you please put all the things you think I need to know in a single list and send that to me so I can send it to the trash folder. Thanks. I do understand both. Your references to quotes suggest otherwise. [1] Assuming that F and ALL are uninitialized and you are not trapping NOVALUE Tut tut Is that it now? Ta ta -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
In 9251321842665626.wa.paulgboulderaim@listserv.ua.edu, on 07/24/2012 at 10:39 AM, Paul Gilmartin paulgboul...@aim.com said: And remembering that Rexx considers lower case characters special. Not quite, but the default value of an uninitialized variable is the upper case name. Do these have different semantics? No; ISREDIT will recognize the extraneous ISREDIT command and process the remainder of the string. However, these have the same semantics: Address ISREDIT foo Address ISREDIT foo If ISPF assumes that an ampersand in a command string has special meaning to the scripting language It doesn't. '(L) = LINE' ILine Is this yet another convention? Yes. Is it not sufficient? Not with current ISPF syntax. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
On Tue, 24 Jul 2012 08:39:35 -0400, Shmuel Metz (Seymour J.) wrote: Address ISREDIT does not in general require quotes either. The quotes are only needed because you want constants with special characters. And remembering that Rexx considers lower case characters special. Had you wanted, e.g., Address ISREDIT F NEXT then you wouldn't have needed quotes, assuming that you haven't assigned values to F or NEXT. And assuming you're not trapping references to undefined variables. By IPCS call and ISREDIT call do you mean expressions beginning with IPCS or ISREDIT? If so, it's indirect. OTOH, if you mean expressions recognized by IPCS or ISREDIT, then it's direct. Address ISREDIT ISREDIT foo/* indirect */ foo/* direct */ Do these have different semantics? No; there's a clash between the way ISPF works and your preconceptions about how it works. From an ISPF and CLIST perspective, REXX is just a consumer of strings; how it interprets those string is beyond the scope of the scripting language. If ISPF assumes that an ampersand in a command string has special meaning to the scripting language to the scripting language, and allows its behavior to be influenced by that (sometimes incorrect) assumption, ISPF is overstepping its proper scope. But I'm accustomed to accessing script variables (in Rexx) by coding their names in parentheses, e.g.: ILine = 42 '(L) = LINE' ILine Is this yet another convention? Is it not sufficient? Why do we need idiosyncratic treatment of ampersands also? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Shmuel Metz (Seymour J.) wrote: In 500e6b77.2090...@bcs.org.uk, on 07/24/2012 at 10:31 AM, CM Poncelet ponce...@bcs.org.uk said: OK. But I do not *have* to code ISPEXEC CONTROL ERRORS RETURN. The rest is mostly ISREDIT ... apart from pure REXX instructions which do not need quotes around them. Address ISREDIT does not in general require quotes either. The quotes are only needed because you want constants with special characters. Had you wanted, e.g., Address ISREDIT F NEXT then you wouldn't have needed quotes, assuming that you haven't assigned values to F or NEXT. Yes I know that. ADDRESS ISREDIT, on its own, is sufficient to cause all commands that follow it to be interpreted as ISREDIT ones (without quotes and without having to specify ADDRESS ISREDIT FIND NEXT etc. each time) - until another ADDRESS whatever is found. But I do not normally use ADDRESS except for IPCS: it is just as easy, and quicker, to put strings in quotes. So I put quotes around ISREDITs (when writing in REXX) and then pure REXX code without quotes. So I assume that ISPEXEC ... is calling ISPEXEC directly, but that ISREDIT ... is then calling ISREDIT likewise directly No; Address ISPEXEC is calling ISPECEC directly and Address ISREDIT ... is calling ISREDIT directly. A statement containing only an expression is evaluated and the result passed to the current environment. That is what I said, except that I use quotes instead of ADDRESS. But on the other hand, if REXX does an ADDRESS IPCS followed by an IPCS call - and then an ADDRESS ISREDIT followed by one or more ISREDIT calls - does that imply that IPCS is now calling ISREDIT, or is ISPEXEC still calling it? By IPCS call and ISREDIT call do you mean expressions beginning with IPCS or ISREDIT? If so, it's indirect. OTOH, if you mean expressions recognized by IPCS or ISREDIT, then it's direct. Address ISREDIT ISREDIT foo/* indirect */ foo/* direct */ Yes, by IPCS call I mean expressions beginning with IPCS (unless ADDRESS IPCS is coded beforehand, when the expressions that follow it are then interpreted as IPCS ones - i.e. as 'direct' IPCS). Etc. Meanwhile, REXX is a function-like sort of interpretative and simplified PL/I Don't confuse REXX syntax with the syntax of commands that REXX is passing to an environment. From a REXX perspective, what it is passing to TSO, ISPEXEC, ISREDIT or any other environment is an arbitrary character string. I mean pure REXX syntax is a function-like interpretative and simplified form of PL/I - e.g., from memory, X= D2C(X2D(VAR)) is what I would call pure REXX. I am not referring to REXX invoking other environments - which requires either an ADDRESS (which I do not use) or quotes (which I do use). But I have a feeling that this is 'barking up the wrong tree'. Panels are associated with ISPF dialogs which, in turn, rely on the 'old' standards (which include Clist as well as panels). Why do you believe that CLIST had any impact on the design of ISPF panels? That is not what I believe. I am pointing out that Clist and ISPF panels come from a same 'era' in which ampersands were used to denote variables - but without implying that one had a direct impact on the other. Two people can speak a same language without necessarily having any impact on each other - although it is more efficient to choose people who can speak the same language if they are to interact with each other. So I guess there is a clash between the 'old' way of prefixing variables with 's and the 'new' way of declaring them without 's. No; there's a clash between the way ISPF works and your preconceptions about how it works. From an ISPF and CLIST perspective, REXX is just a consumer of strings; how it interprets those string is beyond the scope of the scripting language. I have no preconceptions about how ISPF works. I do not dispute that REXX is just a consumer of strings. But from a CPU's perspective - ISPF, Clist and REXX are just 'producers of strings' (of machine code, ultimately), and how they build their strings or in what sequence they are then 'presented' is irrelevant. The CPU executes whatever is in its instruction cache. How the CPU interprets this machine code is beyond the scope of even the machine code itself, because the CPU is 'hard-wired' to 'interpret' microcode. Hence the machine code can be described as the 'old way' and Clist as the 'new way', or Clist as the 'old way' and REXX as the 'new way', or REXX as the 'old way' and mobile phone apps (whatever they are) as the 'new way' etc. ad nauseam. But at the 'atomic level', it is the microcode that makes things work. but because they use different 'building blocks' that don't fit together. Actually, REXX and ISPF fit together quite well, but you have to understand both. I do understand both. I mean different 'building blocks' not fitting
SV: REXX ISPF edit FIND failing
Maybe this posting is superfluous, but I feel there is an underlying misunderstanding regarding this problem with ampersands. At least this ongoing discussion hints at that. 1. REXX does *nothing* special with ampersands (it treats it as any other character - in data it is.). 2. ISPF as such has the ampersand as a variable identifying character. And does, when it's appropriate, evaluate/substitute it. 3. CLIST *also* have the ampersand as variable char. And does *its* variable substitution work. 4. You need to be aware of this - nothing more. 5. Personally I avoid using ampersands in edit commands such as FIND. It simplifies the life. 6. If You must I suggest an initial change like (e g) C '' '§' all and an ending C '§' '' all. (And of course using the § in place of .) 7. An alternative to the variants of editing/searching a PDS member as ISPF Edit and EXECIO the member is this: ISREDIT (LAST) = .ZL r.0 = last Do i = 1 To r.0 ISREDIT '(R) = LINE' i r.i = r End - Then You can work with the stem r.. And if needed, do a EX ALL + DEL ALL X + inserting the lines with e g LINE_AFTER etc. Regards, Thomas Berg ___ Thomas Berg Specialist AM/SMS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] För CM Poncelet Skickat: den 22 juli 2012 14:50 Till: IBM-MAIN@LISTSERV.UA.EDU Ämne: Re: REXX ISPF edit FIND failing Paul Gilmartin wrote: On Fri, 20 Jul 2012 07:31:09 +0100, CM Poncelet wrote: I did explain that ISREDIT follows Clist rules when processing 's, in my earlier posting, methinks grin: ... TSO Clist edit macros have been around long before REXX appeared (around 1989-90) and ISREDIT was meant to be called in Clist, not REXX.. So REXX has to follow the Clist rules when calling ISREDIT - e.g. to process data containing 's. Does this mean that if the same command string is issued to ISREDIT from CLIST and from Rexx the effect will be identical, or not? In most cases yes - unless there are ampersands in the string. In Clist, 3 's must be coded. But it seems like 2 's are enough in REXX (I have not checked what happens if 3 's are coded in REXX). I scarcely know CLIST. Is it even meaningful to discuss the command string issued from CLIST to ISREDIT? It is meaningful only when ISREDIT command strings issued from REXX do not produce the expected 'REXX-like' results. How old is the CALL interface from programming languages? I do not know, but either it or something like it was around for 'executing' Clist from PL/I in the 1980's. However, it is more efficient CPU-wise to call a load module from REXX/Clist (e.g. in a loop) and perform whatever needs to be done by REXX/Clist in the calling REXX/Clist code itself, rather than execute a load module first and have it then call REXX/Clist for whatever it needs. Same question as earlier: Do identical command strings issued to ISREDIT from CLIST and CALL have identical effect? I would expect the ISREDIT effects of REXX/Clist v. ISPLINK calls to be identical, because the command strings in the call are passed as data constants. How are ampersands treated in commands passed via CALL? If you are referring to ISPLINK, the ampersands would be passed together with all the other characters in the string. The assembler (or compiler) cannot interpret the meaning/purpose of the REXX/Clist strings to convert them into efficient machine code. So it assembles/compiles its own program code, which it recognizes, but leaves the REXX/Clist strings as they are and passes them as data in the call. As you imply Rexx is not CLIST. Might it not have been better if the Rexx interface had been specified as CALL-like rather than CLIST-like? Unless I misunderstand what you mean by 'CALL-like', REXX is calling ISREDIT - as the strings are enclosed in quotes (e.g. ISREDIT FIND whatever). It is ISREDIT, not the REXX interface, which interprets an ampersand-prefix as a variable (like Clist does). I suspect that this is because edit macros were originally written in Clist, before REXX appeared, and ISREDIT follows Clist rules because of that. There is nothing wrong with ISPF itself. That's a sweeping statement. Are you sure? I meant it within the context of using 'FIND' in ISPF itself, instead of via ISREDIT. If you copy/paste all the JCL PROC lines from the original post (e.g. into a member of a PDS) and then, from the command line, issue FIND FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)', ISPF's EDIT will then position its cursor on the first line that contains that string and also at the first character of that string; if you hit RFIND, it will find the next occurrence etc.; ditto for all the other FIND strings in the edit macro. If you then save that member and BROWSE it, and repeat
Re: REXX ISPF edit FIND failing
Paul Gilmartin wrote:
On Fri, 20 Jul 2012 07:31:09 +0100, CM Poncelet wrote:
I did explain that ISREDIT follows Clist rules when processing 's, in
my earlier posting, methinks grin:
...
TSO Clist edit macros have been around long before REXX appeared (around
1989-90) and ISREDIT was meant to be called in Clist, not REXX.. So REXX
has to follow the Clist rules when calling ISREDIT - e.g. to process
data containing 's.
Does this mean that if the same command string is issued to ISREDIT
from CLIST and from Rexx the effect will be identical, or not?
In most cases yes - unless there are ampersands in the string. In Clist,
3 's must be coded. But it seems like 2 's are enough in REXX (I have
not checked what happens if 3 's are coded in REXX).
I scarcely know CLIST. Is it even meaningful to discuss the command
string issued from CLIST to ISREDIT?
It is meaningful only when ISREDIT command strings issued from REXX do
not produce the expected 'REXX-like' results.
How old is the CALL interface from programming languages?
I do not know, but either it or something like it was around for
'executing' Clist from PL/I in the 1980's. However, it is more efficient
CPU-wise to call a load module from REXX/Clist (e.g. in a loop) and
perform whatever needs to be done by REXX/Clist in the calling
REXX/Clist code itself, rather than execute a load module first and have
it then call REXX/Clist for whatever it needs.
Same
question as earlier: Do identical command strings issued to ISREDIT
from CLIST and CALL have identical effect?
I would expect the ISREDIT effects of REXX/Clist v. ISPLINK calls to be
identical, because the command strings in the call are passed as data
constants.
How are ampersands
treated in commands passed via CALL?
If you are referring to ISPLINK, the ampersands would be passed together
with all the other characters in the string. The assembler (or compiler)
cannot interpret the meaning/purpose of the REXX/Clist strings to
convert them into efficient machine code. So it assembles/compiles its
own program code, which it recognizes, but leaves the REXX/Clist strings
as they are and passes them as data in the call.
As you imply Rexx is not
CLIST. Might it not have been better if the Rexx interface had been
specified as CALL-like rather than CLIST-like?
Unless I misunderstand what you mean by 'CALL-like', REXX is calling
ISREDIT - as the strings are enclosed in quotes (e.g. ISREDIT FIND
whatever). It is ISREDIT, not the REXX interface, which interprets an
ampersand-prefix as a variable (like Clist does). I suspect that this is
because edit macros were originally written in Clist, before REXX
appeared, and ISREDIT follows Clist rules because of that.
There is nothing wrong with ISPF itself.
That's a sweeping statement. Are you sure?
I meant it within the context of using 'FIND' in ISPF itself, instead of
via ISREDIT. If you copy/paste all the JCL PROC lines from the original
post (e.g. into a member of a PDS) and then, from the command line,
issue FIND FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)',
ISPF's EDIT will then position its cursor on the first line that
contains that string and also at the first character of that string; if
you hit RFIND, it will find the next occurrence etc.; ditto for all the
other FIND strings in the edit macro. If you then save that member and
BROWSE it, and repeat all the FINDs, ISPF's BROWSE will each time
position the cursor at the correct line and starting character of the
string. So ISPF is not itself causing the edit macro problems. If you
then write some REXX to ALLOCATE FI(IN) DA('whatever the DSN(member)
is') SHR KEEP, EXECIO * DISKR IN (STEM REC. FINIS), then loop
through a 'SAY REC.*' to display the lines read in - and save/execute
this REXX - all the lines will be displayed exactly as they are in the
PDS member and with their ampersands etc. So REXX is not causing the
edit macro problems either. Therefore ISREDIT is causing them.
Apart from that, there are lots of things wrong with ISPF (starting from
ESA onwards and getting worse); but that is way 'off topic'.
Cheers.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
On Sun, 22 Jul 2012 13:50:25 +0100, CM Poncelet wrote: Same question as earlier: Do identical command strings issued to ISREDIT from CLIST and CALL have identical effect? I would expect the ISREDIT effects of REXX/Clist v. ISPLINK calls to be identical, because the command strings in the call are passed as data constants. But if issuing identical commands issued from Rexx vis-a-vis CLIST produce different results, the result from ISPLINK must differ from at least one of them. I suppose I can consider myself blessed never to have encountered this problem, possibly because I have never attempted a FIND command containing an ampersand. I shall continue to strive to avoid doing so. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
On Fri, 20 Jul 2012 15:55:28 -0700, John Mattson wrote: Shmuel ! Its amazing how much you contribute without access to a z system. Hope my memory and research is that good when we go off zOS (we're being SAPonified). So, are you on a slippery slope? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
I did explain that ISREDIT follows Clist rules when processing 's, in
my earlier posting, methinks grin:
Original Message
Subject:Re: REXX ISPF edit FIND failing
Date: Thu, 19 Jul 2012 06:46:37 +0100
From: CM Poncelet ponce...@bcs.org.uk
Organization: L! Logic Integration
To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
References:
32716755.1342646266335.javamail.r...@mswamui-cedar.atl.sa.earthlink.net
of516764f6.4efe65dc-on88257a3f.0079fe91-88257a3f.007a2...@ea.epson.com
I think this has to do with ISREDIT following Clist rules for 's - even
when edit macros are written in REXX (no 'SYSSCAN = 0'.)
If rewritten in Clist it should work OK ... but 3 's should be coded
instead of 1 - e.g.
SET SYSSCAN = 0
ISREDIT FIND ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
etc.
SET SYSSCAN = 16
TSO Clist edit macros have been around long before REXX appeared (around
1989-90) and ISREDIT was meant to be called in Clist, not REXX.. So REXX
has to follow the Clist rules when calling ISREDIT - e.g. to process
data containing 's.
There is nothing wrong with ISPF itself.
Cheers, Chris Poncelet
John Mattson wrote:
There is a subtle and dangerous difference with ISREDIT FIND / CHANGE in
REXX.
Say you have a simple change command and forget to use rather than
/* REXX */
TRACE I
ADDRESS ISPEXEC
ISREDIT MACRO (MEM) NOPROCESS
CONTROL ERRORS RETURN
ISREDIT SCAN OFF
ISREDIT C ALL 'DISP=SHR,DSN=AAA' '@#$'
EXIT
And THIS is the file you wish to use it on...
// DD DISP=SHR,DSN=AAA.XXX
// DD DISP=SHR,DSN=BBB.YYY
// DD DISP=SHR,DSN=CCC.ZZZ
IF you use rather than here s what you get
// DD @#$AAA.XXX
// DD @#$BBB.YYY
// DD @#$CCC.ZZZ
If you use you get
// DD @#$.XXX
// DD DISP=SHR,DSN=BBB.YYY
// DD DISP=SHR,DSN=CCC.ZZZ
The moral of all this is: Do not assume ISREDIT commands will work
the same in REXX as in clists, or ISPF. I find this very annoying, how
about your folks?
From: Skip Robinson jo.skip.robin...@sce.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 02:26 PM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
I have found that the ISPF development folks are pretty responsive. This
problem is certainly worth an SR.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: John Mattson john_matt...@ea.epson.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:34 PM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
While I am at it...
WHY the Ampersand SYSTEM WORKS in the find,
but if you use PDQR rather than $PDQR it fails is just madness.
7 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
8 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
+++ RC(4) +++
From: John Mattson/Epson
To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:26 PM
Subject:Re: REXX ISPF edit FIND failing
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
In ofc799207c.54ac2d90-on88257a40.004f10aa-88257a40.004f4...@ea.epson.com, on 07/19/2012 at 07:25 AM, John Mattson john_matt...@ea.epson.com said: Shmuel ! A previous reply also suggested SCAN OFF. I tried it, Did you try it with your original FIND, or with the FIND that used picture? Please look at the example I sent before and try it yourself. Alas, I don't have access to a z system. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Shmuel ! Its amazing how much you contribute without access to a z system. Hope my memory and research is that good when we go off zOS (we're being SAPonified). I have to move on to other things but I have found the following: 1) It is indeed necessary to use the with the ISREDIT in REXX, whenever there is an in your string, and no matter whether it is a symbolic or not (could be just text). 2) When testing FIND, it is a good idea to VIEW your target data set so things will not get changed accidentially, and use CHANGE rather than FIND. Reason is you may be successfully FINDing something OTHER than what you think you are finding. Doing a change to some strange string makes it very clear just what you FOUND and CHANGEd. Much of my confusion was self-induced because the FIND commands appeared to be working, but they were only finding everything up to the single . Thanks for you, and everyone's help From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/20/2012 10:25 AM Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In ofddeba129.3add7da9-on88257a40.0050f760-88257a40.00514...@ea.epson.com, on 07/19/2012 at 07:47 AM, John Mattson john_matt...@ea.epson.com said: Shmuel ! I sent my original source, and it was REXX. It's ISPF that interprets the ampersamds, not REXX. Try turning on the ISPF trace and see if anything pops out. Having a few spare moments, I quickly converted the REXX to CLIST and all of the FIND's worked as a clist. What was the exact code? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
In 9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com, on 07/18/2012 at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said: Uh, I don't think so. You're thinking CLIST not REXX. I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable, which in this case is PDQR.', which does not refer to either CLIST or REXX variables. Try adding the statement: PDQR=A To set the ISPF variable PDQR from REXX he needs to dreop the ampersand: PDQR=A You will see in the trace that PDQR was not substituted. In what trace? The REXX trace is not relevant to substitutions performed by ISPF. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
On Thu, 19 Jul 2012 10:19:28 +0100, Rupert Reynolds wrote: There is no need to send edit commands via ISPEXEC anyway:-) What was the rationale for making the initial host command environment when an edit macro is entered TSO rather than the obvious ISREDIT? Was it merely that the ISPF developers were not well versed in Rexx lore when Rexx burst upon the TSO/E v.2 (whatever) scene? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Shmuel ! A previous reply also suggested SCAN OFF. I tried it, just tried it again, and it makes no difference. Please look at the example I sent before and try it yourself. From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/19/2012 05:26 AM Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In ofc169f9df.8de870ec-on88257a3f.006f4f36-88257a3f.00705...@ea.epson.com, on 07/18/2012 at 01:26 PM, John Mattson john_matt...@ea.epson.com said: Thanks to all, I now have something that works, sort of, but there is really something wrong with ISPF here. Not from what you have written. Try what Tom suggested[1] and add SCAN OFF to your macro. [1] Don't bother with the SCAN ON unless you need it later in the macro. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Shmuel ! I sent my original source, and it was REXX. Having a few spare moments, I quickly converted the REXX to CLIST and all of the FIND's worked as a clist. Oddly, they work with or withOUT SCAN OFF. Whether the problem belongs to ISPF, REXX, or both is not my problem. These commands should work as a REXX. I'll let IBM sort it out. From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/19/2012 07:17 AM Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In 9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com, on 07/18/2012 at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said: Uh, I don't think so. You're thinking CLIST not REXX. I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable, which in this case is PDQR.', which does not refer to either CLIST or REXX variables. Try adding the statement: PDQR=A To set the ISPF variable PDQR from REXX he needs to dreop the ampersand: PDQR=A You will see in the trace that PDQR was not substituted. In what trace? The REXX trace is not relevant to substitutions performed by ISPF. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
That's strange, they work fine as Rexx for me:
JCL: Note line 4
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
//* TEST LINE TO BE X ALL'ED AND NOT FOUND IN FIND ALLS
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Macro Source: Note the double ampersands as documented in the ISPF Edit
and Edit Macros manual.
/* REXX */
ISREDIT MACRO (MEM) NOPROCESS
trace i
CONTROL ERRORS RETURN
ISREDIT X ALL
ISREDIT SCAN OFF
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
Trace:
4 *-* CONTROL ERRORS RETURN
L CONTROL ERRORS RETURN
IKJ56500I COMMAND CONTROL NOT FOUND
+++ RC(-3) +++
5 *-* ISREDIT X ALL
L ISREDIT X ALL
6 *-* ISREDIT SCAN OFF
L ISREDIT SCAN OFF
7 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
8 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
9 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
10 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
11 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
12 *-* ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
L ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
13 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
14 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
JCL member now shows:
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
- - - - - - - - - - - - - - - - - - - 1 Line(s) not
Displayed
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: John Mattson john_matt...@ea.epson.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 10:49
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Shmuel ! I sent my original source, and it was REXX. Having a few spare
moments, I quickly converted the REXX to CLIST and all of the FIND's
worked as a clist. Oddly, they work with or withOUT SCAN OFF. Whether
the problem belongs to ISPF, REXX, or both is not my problem. These
commands should work as a REXX. I'll let IBM sort it out.
From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 07:17 AM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
In
9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com,
on 07/18/2012
at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said:
Uh, I don't think so.
You're thinking CLIST not REXX.
I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT
evaluates/substitutes any ISPF variable, which in this case is
PDQR.', which does not refer to either CLIST or REXX variables.
Try adding the statement: PDQR=A
To set the ISPF variable PDQR from REXX he needs to dreop the
ampersand:
PDQR=A
You will see in the trace that PDQR was not substituted.
In what trace? The REXX trace is not relevant to substitutions
performed by ISPF.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
And the grand prize goes to Tom Ambros
Yes, use DOUBLE AMPERSANDS in REXX and the FINDs work properly.
So simple when we finally see it. Many thanks to everyone.
From: Tom Ambros thomas_amb...@keybank.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 07:58 AM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
That's strange, they work fine as Rexx for me:
JCL: Note line 4
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
//* TEST LINE TO BE X ALL'ED AND NOT FOUND IN FIND ALLS
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Macro Source: Note the double ampersands as documented in the ISPF Edit
and Edit Macros manual.
/* REXX */
ISREDIT MACRO (MEM) NOPROCESS
trace i
CONTROL ERRORS RETURN
ISREDIT X ALL
ISREDIT SCAN OFF
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
Trace:
4 *-* CONTROL ERRORS RETURN
L CONTROL ERRORS RETURN
IKJ56500I COMMAND CONTROL NOT FOUND
+++ RC(-3) +++
5 *-* ISREDIT X ALL
L ISREDIT X ALL
6 *-* ISREDIT SCAN OFF
L ISREDIT SCAN OFF
7 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
8 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
9 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
10 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
11 *-* ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
L ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
12 *-* ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
L ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
13 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
14 *-* ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
L ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
JCL member now shows:
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
- - - - - - - - - - - - - - - - - - - 1 Line(s) not
Displayed
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: John Mattson john_matt...@ea.epson.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 10:49
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Shmuel ! I sent my original source, and it was REXX. Having a few spare
moments, I quickly converted the REXX to CLIST and all of the FIND's
worked as a clist. Oddly, they work with or withOUT SCAN OFF. Whether
the problem belongs to ISPF, REXX, or both is not my problem. These
commands should work as a REXX. I'll let IBM sort it out.
From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 07:17 AM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
In
9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com,
on 07/18/2012
at 10:37 AM, Hardee, Chuck chuck.har...@thermofisher.com said:
Uh, I don't think so.
You're thinking CLIST not REXX.
I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT
evaluates/substitutes any ISPF variable, which in this case is
PDQR.', which does not refer to either CLIST or REXX variables.
Try adding the statement: PDQR=A
To set the ISPF variable PDQR from REXX he needs to dreop the
ampersand:
PDQR=A
You will see in the trace that PDQR was not substituted.
In what trace? The REXX trace is not relevant to substitutions
performed by ISPF.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net
Re: REXX ISPF edit FIND failing
On Thu, 19 Jul 2012 09:12:54 -0700, John Mattson wrote: And the grand prize goes to Tom Ambros Yes, use DOUBLE AMPERSANDS in REXX and the FINDs work properly. So simple when we finally see it. Many thanks to everyone. So is the behavior of EDIT different when identical command strings are issued from Rexx vs. CLIST? Ugh! But might this be because the ISPF developers recognized that '' symbolics would be elaborated by CLIST but not by Rexx and made a misguided attempt to make the Rexx behavior superficially more CLIST-like by processing Rexx command strings in a front-end? Did they break an API to offset their misunderstanding of Rexx? What's the behavior when the macro is written in Assembler/ PL/I/C using the CALL interface? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Different in CLIST or Rexx? Not according to the documentation. From the Edit and Edit Macros doc: Section 3.3.80 SCAN--Set Command Scan Mode Examples To set a line whose number is in variable LNUM to: SYSDATE is a CLIST built-in function set scan mode off and issue the LINE command with SYSDATE as the CLIST function name. The CLIST processor strips off the first , but, because scan mode is off, the editor does not remove the second :; ISREDIT SCAN OFF ISREDIT LINE LNUM = SYSDATE is a CLIST built-in function ISREDIT SCAN ON Because the ISPEXEC call interface for REXX EXECs allows you to specify parameters as symbolic variables, a single scan always takes place before the syntax check of a statement. Therefore, the rule of using two ampersands () before variable names to avoid substitution of variable names also applies to REXX EXECs. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/19/2012 12:35 Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Thu, 19 Jul 2012 09:12:54 -0700, John Mattson wrote: And the grand prize goes to Tom Ambros Yes, use DOUBLE AMPERSANDS in REXX and the FINDs work properly. So simple when we finally see it. Many thanks to everyone. So is the behavior of EDIT different when identical command strings are issued from Rexx vs. CLIST? Ugh! But might this be because the ISPF developers recognized that '' symbolics would be elaborated by CLIST but not by Rexx and made a misguided attempt to make the Rexx behavior superficially more CLIST-like by processing Rexx command strings in a front-end? Did they break an API to offset their misunderstanding of Rexx? What's the behavior when the macro is written in Assembler/ PL/I/C using the CALL interface? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
There is a subtle and dangerous difference with ISREDIT FIND / CHANGE in
REXX.
Say you have a simple change command and forget to use rather than
/* REXX */
TRACE I
ADDRESS ISPEXEC
ISREDIT MACRO (MEM) NOPROCESS
CONTROL ERRORS RETURN
ISREDIT SCAN OFF
ISREDIT C ALL 'DISP=SHR,DSN=AAA' '@#$'
EXIT
And THIS is the file you wish to use it on...
// DD DISP=SHR,DSN=AAA.XXX
// DD DISP=SHR,DSN=BBB.YYY
// DD DISP=SHR,DSN=CCC.ZZZ
IF you use rather than here s what you get
// DD @#$AAA.XXX
// DD @#$BBB.YYY
// DD @#$CCC.ZZZ
If you use you get
// DD @#$.XXX
// DD DISP=SHR,DSN=BBB.YYY
// DD DISP=SHR,DSN=CCC.ZZZ
The moral of all this is: Do not assume ISREDIT commands will work
the same in REXX as in clists, or ISPF. I find this very annoying, how
about your folks?
From: Skip Robinson jo.skip.robin...@sce.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 02:26 PM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
I have found that the ISPF development folks are pretty responsive. This
problem is certainly worth an SR.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: John Mattson john_matt...@ea.epson.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:34 PM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
While I am at it...
WHY the Ampersand SYSTEM WORKS in the find,
but if you use PDQR rather than $PDQR it fails is just madness.
7 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
8 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
+++ RC(4) +++
From: John Mattson/Epson
To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:26 PM
Subject:Re: REXX ISPF edit FIND failing
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
REXX ISPF edit FIND failing
I have a little dataset which contains
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
I have a little REXX which I want to FIND these strings
/* REXX */
TRACE I
Address ISPEXEC
ISREDIT MACRO (MEM) NOPROCESS
CONTROL ERRORS RETURN
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
EXIT
The First Three FIND's work fine. Starting from the fourth find,
they all get RC=4, not found. Even tho I can clearly see that the strings
exist in the dataset. What in the whirled is going on here?? Is there
something special about two 's in a string? I have tried removing the
second from both the find and my dataset and the find still fails. I am
at wits end here.
I have also tried extracting the actual finds like: F ALL
'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'and executing them in TSO, and they all
work. What is special here. FYI, the final is in col 71
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
On Wed, 18 Jul 2012 11:58:48 -0500, Mark Zelden m...@mzelden.com wrote: Add FIRST to the end of the find or a TOP command in-between the find. Never mind... I didn't see the ALL in the find command. I usually put that at the end and missed it. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SV: REXX ISPF edit FIND failing
The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable, which
in this case is PDQR.
So:
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
is the same as
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
and is the same as
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
In the latter two cases (apparently) PDQR resolves into (empty) and
PDQR. also. (The dot . is used as an end-of-variable-name marker, IIRC.)
In e g this:
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
- resolves to: ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE('
wich is no to be found in the dataset.
Etc.
Regards,
Thomas Berg
___
Thomas Berg Specialist AM/SMS SWEDBANK AB (publ)
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
För John Mattson
Skickat: den 18 juli 2012 18:48
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: REXX ISPF edit FIND failing
I have a little dataset which contains
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
I have a little REXX which I want to FIND these strings
/* REXX */
TRACE I
Address ISPEXEC
ISREDIT MACRO (MEM) NOPROCESS
CONTROL ERRORS RETURN
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
EXIT
The First Three FIND's work fine. Starting from the fourth
find, they all get RC=4, not found. Even tho I can clearly see that the
strings exist in the dataset. What in the whirled is going on here?? Is
there something special about two 's in a string? I have tried
removing the second from both the find and my dataset and the find
still fails. I am at wits end here.
I have also tried extracting the actual finds like: F ALL
'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'and executing them in TSO, and they
all work. What is special here. FYI, the final is in col 71
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SV: REXX ISPF edit FIND failing
Is it possible that if you code PDQR as PDQR edit strips the first
ampersand and looks for the string the way you want? I have some code
which does something similar with SYSNAME variable in the started task
JCL. I change a string containing that variable during DR adjustments of
the VTAM proc.
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: Thomas Berg thomas.b...@swedbank.se
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 13:27
Subject:SV: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable,
which in this case is PDQR.
So:
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
is the same as
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
and is the same as
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
In the latter two cases (apparently) PDQR resolves into (empty) and
PDQR. also. (The dot . is used as an end-of-variable-name marker,
IIRC.)
In e g this:
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
- resolves to: ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE('
wich is no to be found in the dataset.
Etc.
Regards,
Thomas Berg
___
Thomas Berg Specialist AM/SMS SWEDBANK AB (publ)
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
För John Mattson
Skickat: den 18 juli 2012 18:48
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: REXX ISPF edit FIND failing
I have a little dataset which contains
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR(SYSTEM)
//SYSINDD DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)
I have a little REXX which I want to FIND these strings
/* REXX */
TRACE I
Address ISPEXEC
ISREDIT MACRO (MEM) NOPROCESS
CONTROL ERRORS RETURN
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(UCMIN)'
ISREDIT F ALL 'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'
EXIT
The First Three FIND's work fine. Starting from the fourth
find, they all get RC=4, not found. Even tho I can clearly see that the
strings exist in the dataset. What in the whirled is going on here?? Is
there something special about two 's in a string? I have tried
removing the second from both the find and my dataset and the find
still fails. I am at wits end here.
I have also tried extracting the actual finds like: F ALL
'DISP=SHR,DSN=PDQ.ALC.UNVLIB(MY)'and executing them in TSO, and they
all work. What is special here. FYI, the final is in col 71
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This communication may contain privileged and/or confidential information. It
is intended solely for the use of the addressee. If you are not the intended
recipient, you are strictly prohibited from disclosing, copying, distributing
or using any of this information. If you received this communication in error,
please contact the sender immediately and destroy the material in its entirety,
whether electronic or hard copy. This communication may contain nonpublic
personal information about consumers subject to the restrictions of the
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose
such information for any purpose other than to provide the services for which
you are receiving the information.
127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from
Key
send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in
the
SUBJECT line.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
While I am at it...
WHY the Ampersand SYSTEM WORKS in the find,
but if you use PDQR rather than $PDQR it fails is just madness.
7 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
8 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
+++ RC(4) +++
From: John Mattson/Epson
To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:26 PM
Subject:Re: REXX ISPF edit FIND failing
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
FYI. From ISPF You can see that Picture Strings are powerful
A picture string is a quoted string that is preceded or followed by the
letter P. It can contain blanks, alphabetic and numeric characters
which represent themselves, or any of the special characters listed
below, each of which represents a class of characters.
The special characters that can be used in a from picture string are:
= - any character . - invalid characters
@ - alphabetic characters - - non-numeric characters
# - numeric characters - lower case alphabetics
$ - special characters - upper case alphabetics
¬ - non-blank characters
The special characters that can be used in a to picture string are:
= - any character - lower case alphabetics
- upper case alphabetics
(continued on next page)
Lizette
-Original Message-
From: John Mattson john_matt...@ea.epson.com
Sent: Jul 18, 2012 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX ISPF edit FIND failing
While I am at it...
WHY the Ampersand SYSTEM WORKS in the find,
but if you use PDQR rather than $PDQR it fails is just madness.
7 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
8 *-* ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
L ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTEPDQR$(SYSTEM$'
+++ RC(4) +++
From: John Mattson/Epson
To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 01:26 PM
Subject:Re: REXX ISPF edit FIND failing
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
I am z/OS V1.12. I am using the F P'' ALL inside a member with your exact
data.
If I use
F ALL p'DISP=SHR=DSN=$PDQ$ALC$UNVLIB$$UCMIN$'
It works
If I use
F ALL p'DISP=SHR=DSN=$PDQ$ALC$UNVLIB$$UCMIN)'
It works. So not sure where the problem is. I will test later with an ISPF
macro. So native F ALL P'' works. Just need to check out the Macro side.
Lizette
Lizette
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
That's one of the very frustrating things about this problem.
Almost EVERY variation of these ISREDIT FIND's work just fine as the
'commands between the quotes' in TSO/ISPF.
So, why don't they work the same way in ISREDIT? Beats me, that's for
sure.
From: Lizette Koehler stars...@mindspring.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 02:18 PM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is
also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
I am z/OS V1.12. I am using the F P'' ALL inside a member with your
exact data.
If I use
F ALL p'DISP=SHR=DSN=$PDQ$ALC$UNVLIB$$UCMIN$'
It works
If I use
F ALL p'DISP=SHR=DSN=$PDQ$ALC$UNVLIB$$UCMIN)'
It works. So not sure where the problem is. I will test later with an
ISPF macro. So native F ALL P'' works. Just need to check out the
Macro side.
Lizette
Lizette
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX ISPF edit FIND failing
And I am on z/OS 1.13 and have the problem there so it's a current issue.
Charles (Chuck) Hardee
Senior Systems Engineer
Database Administration
Information Technology Services
Thermo Fisher Scientific
300 Industry Drive
Pittsburgh, PA 15275
Direct: 724-517-2633
FAX: 412-490-9230
chuck.har...@thermofisher.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Wednesday, July 18, 2012 5:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX ISPF edit FIND failing
Thanks to everyone! I have kept plugging at this and tried all your
suggestions.
Here is what I see so far.
1) There is no reason syntactically that this should not work
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.(SYSTEM)'
2) For some strange reality THIS works
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.'
and this does not.. as soon as you add the (
ISREDIT F FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTEPDQR.('
3) Lizette's P' processing can be made to work (but really should not be
necessary)
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM'
Works !!!
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM$'
Works
ISREDIT F ALL P'DISP=SHR,DSN=MSYS$UCMD$REMOTE$PDQR$(SYSTEM)'
Does NOT
Now, why ( causes the ISREDIT FIND to go nuts, but not the
ISREDIT FIND P' ' is quite beyond me.
And why ) causes ISREDIT FIND P' to go nuts, but NOT ( is also
Thanks to all, I now have something that works, sort of, but there is
really something wrong with ISPF here.
by the by, I am on zOS 1.11
I am z/OS V1.12. I am using the F P'' ALL inside a member with your exact
data.
If I use
F ALL p'DISP=SHR=DSN=$PDQ$ALC$UNVLIB$$UCMIN$'
It works
If I use
F ALL p'DISP=SHR=DSN=$PDQ$ALC$UNVLIB$$UCMIN)'
It works. So not sure where the problem is. I will test later with an ISPF
macro. So native F ALL P'' works. Just need to check out the Macro side.
Lizette
Lizette
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
