SPF functions
Howard Brazee
want cursor and scrolling control. My guess is these functions don't
apply within the ISPF. Checking through IBM's manuals, I can't find key
words such as SysCurPos. Is there a library of functions useable from
within SPF edit sessions? If so, where's the documentation on how to
access it?
Doug Nadel
I don't think they exist in a 3270 environment. ISPF does provide a
fairly rich edit macro environment though. Or if you are just looking
for cursor control, have a look at your emulator package for a macro
facility there. I use Tom Brennen's Vista package for Windows and
have macros set up for everything from generating web pages from
screens to cycling through commonly used data set names, to making
network connections and filling in forms. It is VERY fast, very small
(720KB download) and very inexpensive ($30). It also fully supports
extended data streams, upload/download (IND$FILE) and other 3270
things I never needed. It's available at
http://home.earthlink.net/~tombrennan/index.html
Doug Nadel
----------------------------------------
ISPF and OS/390 Tools & Toys page:
http://somebody.home.mindspring.com/
Howard Brazee
then return to my original position within the editor.
Let's say I am editing a PDS member, looking at columns 101-172, and I press
an FKey designed to count each occurrence of the word CALL in that listing.
(or count all words, or change spelling, or whatever). My cursor is on line
10 column 30 of this window, which happens to be line 222 of the PDS
member. I want to do my command and then return to line 10 column 30
(really line 232 column 131), when my REXX program is done with its command.
I would love to see a REXX program which did an SPF command such as C X Y
ALL, and then returned me to the exact same view of my data as before, so I
can continue typing. Even better, would be to put back in my old find
command in the find buffer so that I could press F5 to continue my old
search.
Maybe a Windows macro is the way to do (Obviously it wouldn't be able to find
my Find buffer, but I don't know whether Rexx can do that easily). But a
REXX command will work even if I dial in from another computer (which I do).
Dan Dirkse
What you want can be easily done with an edit macro. It would be something like
this (working without a net):
/* Rexx */
Address ISREDIT "MACRO (PARM)"
/* Save user state which includes the find string */
Address ISREDIT "(USTATE) = USER_STATE"
/* Save cursor location */
Address ISREDIT "(CSRLINE,CSRCOL) = CURSOR"
/* Perform the command */
Address ISREDIT parm
/* Restore user_state and set cursor back */
Address ISREDIT "USER_STATE = (USTATE)"
Address ISREDIT "CURSOR = (CSRLINE,CSRCOL"
Exit
If this macro is named DOIT, then issue DOIT C X Y ALL and you should get your
desired result. This assumes that the parm you send is a valid command since it
is not doing anything to capture errors, etc.
Hope this helps,
Dan Dirkse
Iuvo Technologies, Inc.
Howard Brazee
Thanks!
I've been going over our REXX libraries looking at some similar code, discovering
that the recent ISPF commands ZOOM and SHOWPROC are actually REXX programs.
(I guess I could change SHOWPROC to look for
// JCLLIB ORDER=(UMS.D44201.PROC,UMS.STG1TEST.PROC)
command in my JCL and act accordingly )
Howard Brazee
Dan Dirkse wrote:
> Howard:
> What you want can be easily done with an edit macro. It would be something like
> this (working without a net):
>
> /* Rexx */
> Address ISREDIT "MACRO (PARM)"
> /* Save user state which includes the find string */
> Address ISREDIT "(USTATE) = USER_STATE"
> /* Save cursor location */
> Address ISREDIT "(CSRLINE,CSRCOL) = CURSOR"
> /* Perform the command */
> Address ISREDIT parm
> /* Restore user_state and set cursor back */
> Address ISREDIT "USER_STATE = (USTATE)"
> Address ISREDIT "CURSOR = (CSRLINE,CSRCOL"
> Exit
>
> If this macro is named DOIT, then issue DOIT C X Y ALL and you should get your
> desired result. This assumes that the parm you send is a valid command since it
> is not doing anything to capture errors, etc.
That worked, once I added a right parenthesis.
Next question:
I tested this out by using it to call a macro which did the following:
"c p'========' MR12483 73 80 nx"
This worked as long as NUMS was off. If NUMS is STANDARD, I got the following
errors:
Command in error . : c p'========' MR12483 73 80 nx
Invalid column range
The CHANGE column range attempts a search beyond the last data column.
If NUMS is COBOL, I got the following errors:
Command in error . : c p'========' MR12483 73 80 nx
Invalid left boundary
79 (left bound) + 8 (string size) greater than 80 (LRECL).
Error message ID . : ISRE258
Since it is an ISPF editor command which I am running (passed from REXX), I would
have guessed it would work just as if I had typed it in from the editor, but
instead, it works differently depending on how I have NUMS set up.
How do I program for this difference? I tried typing "NUMS OFF" in my REXX, but it
didn't understand. I'm not sure that would be the best solution anyway.
Dan Dirkse
Unfortunately you have found a very frustrating 'feecher' of Edit Macros. Macros can
only see 'data' -- no sequence numbers. You should be able to numbers off with
Address ISREDIT "NUM OFF" but you may also need an
Address ISREDIT "UNNUM" (again working without a net).
It should be the same commands that you would use to turn numbering off from an edit
session.
Hope this helps,
Dan Dirkse
Iuvo Technologies, Inc.
Howard Brazee
Dan Dirkse wrote:
> Howard:
> Unfortunately you have found a very frustrating 'feecher' of Edit Macros. Macros can
> only see 'data' -- no sequence numbers. You should be able to numbers off with
> Address ISREDIT "NUM OFF" but you may also need an
> Address ISREDIT "UNNUM" (again working without a net).
> It should be the same commands that you would use to turn numbering off from an edit
> session.
If it is the same as from within ISPF, then UNNUM isn't what I need. I modified
ADDRESS ISPEXEC; /* these are copied from other programs */
ADDRESS ISPREDIT; /* I really don't know what they do */
to:
ADDRESS ISPEXEC;
Address ISREDIT "NUM OFF"
and got a page including:
Command in error . : NUM OFF
Command not executed
An ISREDIT MACRO statement must precede any executable statements.
and another screen with:
ISPS102
Invalid service name
'MACRO' is not a recognized dialog service name.
Then I was knocked right out of PDF.
So, I guess I'll have to take an hour trying to find the correct syntax and functions,
poring through the slowest and most user unfriendly Web pages in the universe, the IBM
Bookmanager.
I called my progam using F4 set to doit modid 'mr12483', hoping to get NUMS back to
wherever I started (COBOL or OFF):
D44201.REXX.LIB(DOIT) - 01.02 Columns 00001 00072
d ===> Scroll ===> CSR
***************************** Top of Data ******************************
/**********************************************************************/
/* */
/* This Rexx macro saves the screen and cursor position, passes */
/* on a REXX macro command then returns the original settings */
/* */
/**********************************************************************/
Address ISREDIT "MACRO (PARM)"
/* Save user state which includes the find string */
Address ISREDIT "(USTATE) = USER_STATE"
/* Save cursor location */
Address ISREDIT "(CSRLINE,CSRCOL) = CURSOR"
/* Perform the command */
Address ISREDIT parm
/* Restore user_state and set cursor back */
Address ISREDIT "USER_STATE = (USTATE)"
Address ISREDIT "CURSOR = (CSRLINE,CSRCOL)"
Exit
Howard Brazee
Dan Dirkse wrote:
> Howard:
> Unfortunately you have found a very frustrating 'feecher' of Edit Macros. Macros can
> only see 'data' -- no sequence numbers. You should be able to numbers off with
> Address ISREDIT "NUM OFF" but you may also need an
> Address ISREDIT "UNNUM" (again working without a net).
> It should be the same commands that you would use to turn numbering off from an edit
> session.
Bookmanager has to be the slowest web pages out there - and the most worthless. I wanted
to gain an understanding of ISREDIT, as my REXX experience (OS/2 only) and my REXX book
aren't IBM Mainframe based.
To show you what happens after drilling down through their very slow web pages, I get a
page such as this:
2.5.6 The ISPEXEC and ISREDIT Host Command Environments
The ISPEXEC and ISREDIT host command environments are available only to REXX execs that
run in ISPF. Use the environments to invoke ISPF commands and services, and ISPF edit
macros.
When you invoke a REXX exec from ISPF, the default initial host command environment is
TSO.
You can use the ADDRESS instruction to use an ISPF service. For example, to use the ISPF
SELECT service, use the following instruction:
ADDRESS ISPEXEC 'SELECT service'
The ISREDIT environment lets you issue ISPF edit macros. To use ISREDIT, you must be in
an
edit session.
Note that the value that can be set in the REXX special variable RC for the ISPEXEC and
ISREDIT environments is a signed 24-bit number in the range -8,388,608 to +8,388,607.
This page may be meaningful to people who don't need to use this page, but it is
meaningless to anybody who doesn't already understand ISREDIT.
Howard Brazee
> Howard:
> Unfortunately you have found a very frustrating 'feecher' of Edit Macros. Macros can
> only see 'data' -- no sequence numbers. You should be able to numbers off with
> Address ISREDIT "NUM OFF" but you may also need an
> Address ISREDIT "UNNUM" (again working without a net).
> It should be the same commands that you would use to turn numbering off from an edit
> session.
I found that I can put this command within my DOIT program (see thread), but not in the
program called by:
Address ISREDIT parm
That decreases the value of having a DOIT program.
Playing with the ISREDIT command, I am somewhat confused. Sometimes I can simply have a
SPF command in quotes, the same way I would do in OS/2. Other times I seem to need to
put the command after an Address ISREDIT prefix. Is there any rule here which I should
follow?
Do you have a list of the different "Address" commands which I should be aware of?
Doug Nadel
>To show you what happens after drilling down through their very slow web pages, I get a
>page such as this:
>
>
>2.5.6 The ISPEXEC and ISREDIT Host Command Environments
[snip]
>
>This page may be meaningful to people who don't need to use this page, but it is
>meaningless to anybody who doesn't already understand ISREDIT.
Not sure I understand. There is a whole book dedicated to edit and
edit macros. Your best bet is to look at some edit macro examples
(there are many of them on the web) and glean the basics there. Then
go to the book and look up specific commands. Basically, edit macros
let you enter any primary command from a program, with restrictions in
some cases and extensions in others.
Other than regular edit commands you'd use every day, you need to be
aware that edit macros can get and set variables through a common
syntax:
set: Address isredit '(var1,var2) = EDITCOMMAND'
use: Address isredit 'EDITCOMMAND = (var1)'
eg: Address isredit '(capsval) = CAPS'
Address isredit 'CAPS = (capsval)'
Basically variables are in parentheses.
(The exception is "LINE (N) = ..." won't always work, but there is
always an exception, isn't there?)
Doug Nadel
<howard...@cusys.edu> wrote:
>
>
>Dan Dirkse wrote:
>
>> Howard:
>> Unfortunately you have found a very frustrating 'feecher' of Edit Macros. Macros can
>> only see 'data' -- no sequence numbers. You should be able to numbers off with
>> Address ISREDIT "NUM OFF" but you may also need an
>> Address ISREDIT "UNNUM" (again working without a net).
>> It should be the same commands that you would use to turn numbering off from an edit
>> session.
>
Jeremy C B Nicoll
Howard Brazee <howard...@cusys.edu> wrote:
> Dan Dirkse wrote:
> > Howard: Unfortunately you have found a very frustrating 'feecher' of
> > Edit Macros. Macros can only see 'data' -- no sequence numbers. You
> > should be able to numbers off with Address ISREDIT "NUM OFF" but you
> > may also need an Address ISREDIT "UNNUM" (again working without a
> > net). It should be the same commands that you would use to turn
> > numbering off from an edit session.
a) I don't think anyone should write edit macros until they understand
the ispf editor well; half of your problems are that you don't appear
to understand all the ins and outs of numbering modes. It's not a
macro issue, this.
b) Once you understand what the editor lets you do, you'll find that
macro commands can be used to query the state of the edit environment
as well as alter it. So for example, to find out the line number of
the last line of a file you can do (in a rexx edit macro):
"(lastnum) = linenum .zlast"
This sets the ispf variable linenum to that line number. I imagine
(though as I'm posting from home I can't check this) that the status
of line numbering etc can be extracted eg as:
"(numstata) = number" (or something)
This then means that if line number states bother your macro you are
able to extract relevant values and use your logic (and your under-
standing of the editor) to issue appropriate commands.
--
Jeremy C B Nicoll - my opinions are my own.
Howard Brazee
> In article <38B3F34D...@cusys.edu>,
> Howard Brazee <howard...@cusys.edu> wrote:
>
> > Dan Dirkse wrote:
>
> > > Howard: Unfortunately you have found a very frustrating 'feecher' of
> > > Edit Macros. Macros can only see 'data' -- no sequence numbers. You
> > > should be able to numbers off with Address ISREDIT "NUM OFF" but you
> > > may also need an Address ISREDIT "UNNUM" (again working without a
> > > net). It should be the same commands that you would use to turn
> > > numbering off from an edit session.
>
> a) I don't think anyone should write edit macros until they understand
> the ispf editor well; half of your problems are that you don't appear
> to understand all the ins and outs of numbering modes. It's not a
> macro issue, this.
I understand the ISPF editor well (at least, I have never worked with anybody
who knew all the commands easily from within the ISPF as well as I do). What
I don't understand is macros. The reply is from someone who understands
macros - who wasn't sure about which numbering mode command to use. That's
fine, his expertise in macros is what I asked for. He already knew what I
discovered, that the following work differently:
ISPF Command line commands:
NUM COBOL
C p'========' 34567890 73 80
vs
NUM COBOL
Call REXX program which has the command
"C p'========' 34567890 73 80"
If I replace those two NUM COBOL commands with NUM OFF commands, the two
situations work the same.
I have a shell REXX program which saves off the current user state and cursor
position then does an:
Address ISREDIT parm
before restoring the current user state and cursor position.
If I have my
Address ISREDIT "NUM OFF"
in the calling program, it works fine, but in the called program I am getting
errors. (An ISREDIT MACRO statement must precede any executable
statements.), which knocks me right out of PDF.
Also, I don't understand why sometimes I need an "Address ISREDIT" command,
and other times, I can just enter my ISPF command line command from within
Rexx.
Dan Dirkse
Please send me your execs offline and I will look at them.
Dan Dirkse
Iuvo Technologies, Inc.
Jeremy C B Nicoll
Howard Brazee <howard...@cusys.edu> wrote:
> I understand the ISPF editor well (at least, I have never worked with
> anybody who knew all the commands easily from within the ISPF as well
> as I do). What I don't understand is macros. The reply is from
> someone who understands macros - who wasn't sure about which numbering
> mode command to use. That's fine, his expertise in macros is what I
> asked for. He already knew what I discovered, that the following work
> differently:
> ISPF Command line commands:
> NUM COBOL
> C p'========' 34567890 73 80
> vs
> NUM COBOL
> Call REXX program which has the command
If your rexx is named, say "MYMAC" then I hope what you mean is you typed
MYMAC in the command line; if you typed TSO MYMAC then I don't think it
would work.
> "C p'========' 34567890 73 80"
I don't see why these should be different (and unfortunately I no longer
have the first few posts on this topic) provided you're comparing like
with like, but your following text here suggests you might not be:
> If I replace those two NUM COBOL commands with NUM OFF commands, the two
> situations work the same.
> I have a shell REXX program which saves off the current user state and
> cursor position then does an: Address ISREDIT parm before restoring the
> current user state and cursor position.
> If I have my Address ISREDIT "NUM OFF" in the calling program, it works
> fine, but in the called program I am getting errors. (An ISREDIT MACRO
> statement must precede any executable statements.), which knocks me
> right out of PDF.
> Also, I don't understand why sometimes I need an "Address ISREDIT"
> command, and other times, I can just enter my ISPF command line command
> from within Rexx.
The macro that you invoke by entering its name in the editor command line
gets control with its rexx addressing mode set to TSO. I normally start
rexx macros as follows:
/*REXX
this macro does whatever it does
*/
address ispexec ; "control errors return" ; "control display refresh"
address isredit ; "macro"
What this does first is ask rexx to direct host commands to ispf. The
next two commands are ispf services commands saying: if a service that is
invoked fails return control to the rexx exec rather than displaying the
standard ispf error panel, and: force a full-screen redraw at the next
opportunity (that's in case I do any non-full-screen say statements after
which the screen might not get redrawn properly).
Then I ask rexx to redirect host commands to the editor environment. The
first such command is "macro" which must be seen before ispf edit is
willing to accept that future commands are coming from this macro. From
then on in the edit macro any editor commands are those statements that
are not rexx ones (ie normal host commands), in practice anything wrapped
up in quotes, eg:
"num on"
"caps on"
"recovery off"
"(lastlin) = linenum .zlast"
All of these commands are documented in the edit macro manual. Although
most commands of the form "attribute value" eg "num on" are the same as
the command-line equivalents, they are not all the same (some edit macro
formats are more versatile). Also the commands that query the state of
things in edit do not have command-line equivalents.
Normally when I get to the end of my macro I have code like:
"builtin save"
if rc Ž== 0 then do
/* whatever I want to do if saving the changed file didn't work
end
"builtin cancel"
At this stage the default addressing environment in the rexx exec is
still that of the editor, ie if you did a: say address() you'd see the
value "ISREDIT".
The reason I preface "save" and "cancel" by "builtin" is that that
prevents any user's own macros named "save" or "cancel" from being run.
I find it better to do a save and test the result of that prior to doing
a cancel (which WILL work), rather than doing an END and then not being
in control if the implicit save fails (eg for Sx37 abends).
After the "builtin cancel" I normally just the rexx exec's exit statement
however in some case I will then revert to address ispexec prior to using
ispf services to VPUT values I wish saved in the session profile.
If a macro also displays panels, menus etc - for example to get
processing options from the user - then you need to invoke those ispf
services with 'address ispexec' active and you'd then need to understand
rexx and its address environments rather better.
Prior to rexx when macros were mostly written in clist every macro
command had to be written as: ISREDIT something just as ispf service
calls were normally written as: ISPEXEC whatever. People who don't
understand how rexx works frequently do the same sort of thing when they
write a rexx exec edit macro, eg:
address isredit "command one"
address isredit "command two"
address isredit "command three"
This sort of thing should be written (and is much more efficient) as:
address isredit
"command one"
"command two"
"command three"
num on"which are not always
Doug Nadel
<howard...@cusys.edu> wrote:
>Also, I don't understand why sometimes I need an "Address ISREDIT" command,
>and other times, I can just enter my ISPF command line command from within
>Rexx.
Hi Howard, Sorry I haven't read the whole thread, so excuse me if I
answer the wrong question (in a hurry at the moment)...
The ISREDIT MACRO statement is required to be the 1st statement of any
edit macro. I think the confusion here comes from the fact that in
ISREDIT newcmd
newcmd is considered a new edit macro. So you can't just start with
other edit commands. Basically, if another program is called from
within an edit macro, that called program is a considered a new macro.
(The method of calling sets up an new environment (I use the term
loosely) that does not have characteristics that the MACRO statement
sets up).
Keep plugging away at it. It's worth it once you get the basics down.
Doug Nadel
----------------------------------------
ISPF & OS/390 Tools & Toys page:
http://www.mindspring.com/~somebody/
Howard Brazee
Jeremy C B Nicoll wrote:
> > ISPF Command line commands:
> > NUM COBOL
> > C p'========' 34567890 73 80
>
> > vs
>
> > NUM COBOL
> > Call REXX program which has the command
>
> If your rexx is named, say "MYMAC" then I hope what you mean is you typed
> MYMAC in the command line; if you typed TSO MYMAC then I don't think it
> would work.
>
> > "C p'========' 34567890 73 80"
>
> I don't see why these should be different (and unfortunately I no longer
> have the first few posts on this topic) provided you're comparing like
> with like, but your following text here suggests you might not be:
I first had REXX in my CLIST library with TSO EXEC, until I discovered the
REXX library would allow me a shorter command (I have my FKEY set to run the
command).
Apparently REXX gets confused by line numbers, looking at the screen instead
of the data.
> The macro that you invoke by entering its name in the editor command line
> gets control with its rexx addressing mode set to TSO. I normally start
> rexx macros as follows:
Thanks for the guidelines, I saved them and they make sense to me.
Peter Heberer
I got a similar problem lately and found the following solution:
a) The UNNUM command also switches OFF number mode, if it's currently on.
b) UNNUM removes the numbers of the current number mode.
That means, if you currently have "NUM STD", UNNUM will remove them, but NOT
cobol numbers that might ALSO be in the file.
To understand, try the following commands by hand:
NUM COB
NUM STD (now your have both numbers in cols 1-6 and 73-80.
NUM COB
UNNUM (now the cobol numbers are gone)
NUM STD
UNNUM (now the standard numbers are gone).
I found a command to retrieve the current number mode (sorry, not at hand,
no mainframe at home).
So in the macro, I first retrieved the current number mode (stored in two
variables,
ON/OFF and STD/COBOL/DATA or whatever), then I switched to NUM STD and
did an UNNUM command.
After the execution of the intended commands, I restored the user's initial
number mode
using the "inverse" form of the command I can't yet remember, and that did
it.
I can look up the exact command tomorrow at work if you need it.
Regards,
Peter
"Howard Brazee" <howard...@cusys.edu> schrieb im Newsbeitrag
news:38B3F2A7...@cusys.edu...
>
>
> Dan Dirkse wrote:
>
> > Howard:
> > Unfortunately you have found a very frustrating 'feecher' of Edit
Macros. Macros can
> > only see 'data' -- no sequence numbers. You should be able to numbers
off with
> > Address ISREDIT "NUM OFF" but you may also need an
> > Address ISREDIT "UNNUM" (again working without a net).
> > It should be the same commands that you would use to turn numbering off
from an edit
> > session.
>
Howard Brazee
Peter Heberer wrote:
> Howard,
>
> I got a similar problem lately and found the following solution:
>
> a) The UNNUM command also switches OFF number mode, if it's currently on.
>
> b) UNNUM removes the numbers of the current number mode.
> That means, if you currently have "NUM STD", UNNUM will remove them, but NOT
> cobol numbers that might ALSO be in the file.
> To understand, try the following commands by hand:
> NUM COB
> NUM STD (now your have both numbers in cols 1-6 and 73-80.
> NUM COB
> UNNUM (now the cobol numbers are gone)
> NUM STD
> UNNUM (now the standard numbers are gone).
I often do this as the easiest way to put blanks in columns 73-80. In this
case, I will simply want to set NUMS OFF while REXX does its column oriented
command, and then restore NUMS to whatever state it was originally in when that
macro is finished.
> I found a command to retrieve the current number mode (sorry, not at hand,
> no mainframe at home).
>
> So in the macro, I first retrieved the current number mode (stored in two
> variables,
> ON/OFF and STD/COBOL/DATA or whatever), then I switched to NUM STD and
> did an UNNUM command.
>
> After the execution of the intended commands, I restored the user's initial
> number mode
> using the "inverse" form of the command I can't yet remember, and that did
> it.
>
> I can look up the exact command tomorrow at work if you need it.
>
> Regards,
> Peter
I'm not sure what "(USTATE) = USER_STATE" includes. I suspect I will need to
save off and restore the NUM current state. At lunch, I went to a computer book
store and found 3 books on REXX, but alas none of them had anything about using
REXX in a TSO/ISPF environment.