1)
Parse SOURCE . . . . . . . env .
If env = 'ISPF' then Is_ISPF = 'Y'
2)
If sysvar(sysispf) = 'NOT ACTIVE' then Is_ISPF = 'N'
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
SYSVAR is a TSO extension. An exec using SYSVAR that is not running in a
TSO environment will fail.
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Ryerse, Robin
Sent: 28. heinäkuuta 2008 21:19
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Parse Source (8) vs sysispf?
In a word, the answer is "no".
SYSVAR is a TSO extension. An exec using SYSVAR that is not running in a
TSO environment will fail.
----------------------------------------------------------------------
/* REXX */
address = address()
parse source . . alias . . . . env .
'SUBCOM ATTACH'; attach = \rc; rc = 16
'SUBCOM ATTCHMVS'; attchmvs = \rc; rc = 16
'SUBCOM ATTCHPGM'; attchpgm = \rc; rc = 16
'SUBCOM CONSOLE'; console = \rc; rc = 16
'SUBCOM CPICOMM'; cpicomm = \rc; rc = 16
'SUBCOM ISPEXEC'; ispexec = \rc; rc = 16
'SUBCOM ISREDIT'; isredit = \rc; rc = 16
'SUBCOM LINK'; link = \rc; rc = 16
'SUBCOM LINKMVS'; linkmvs = \rc; rc = 16
'SUBCOM LINKPGM'; linkpgm = \rc; rc = 16
'SUBCOM LU62'; lu62 = \rc; rc = 16
'SUBCOM MVS'; mvs = \rc; rc = 16
'SUBCOM TSO'; tso = \rc; rc = 16
'SUBCOM DSNREXX'; dsnrexx = \rc; rc = 16
'SUBCOM SYSCALL'; syscall = \rc; rc = 16
call varlist
"SUBCOM ISPEXEC"
queries the existence of a specified host command environment.
or
"SUBCOM TSO"
"SUBCOM MVS"
etc.
David
------------------( Forwarded letter 1 follows )---------------------
Date: Mon, 28 Jul 2008 19:59:41 +0200
Reply-To: TSO.REXX.Discussion.List[TSO-REXX]@VM.MARIST.EDU.INET
Sender: TSO.REXX.Discussion.List[TSO-REXX]@VM.MARIST.EDU.INET
From: lindy.m...@SSF.SAS.COM.INET
Subject: Parse Source (8) vs sysispf?
To: TSO-...@VM.MARIST.EDU.INET
X-HDT-HopCount: 1
Does anyone know if these two methods for an exec to know if it is in an
ISPF environment are equivalent?
1)
Parse SOURCE . . . . . . . env .
If env = 'ISPF' then Is_ISPF = 'Y'
2)
If sysvar(sysispf) = 'NOT ACTIVE' then Is_ISPF = 'N'
----------------------------------------------------------------------
Rather better, I think, is
If env = 'ISPF' then Is_ISPF = 1
Then, later in your code, you can have
if is_ispf then
do
whatever
end
When I really want to use Y and N, then I start my program with
parse upper value 'y n' with char_y char_n .
(and yes, that is a dot at the end - to swallow any trailing spaces)
If env = 'ISPF' then Is_ISPF = char_y
...
if Is_ISPF = char_y then ...
This has the advantage that when I need a y to sometimes mean yes and sometimes yellow,
instead of searching for 'Y' and then deciding which one this Y means, I can search for if_y or
colour_y as the case might be.
Hope, at least, this gives you some food for thought.
James Campbell
> Date: Mon, 28 Jul 2008 19:59:41 +0200
> From: Lindy Mayfield <lindy.m...@SSF.SAS.COM>
> Subject: Parse Source (8) vs sysispf?
>
Is_ISPF = env = 'ISPF'
Which sets Is_ISPF if env=ISPF and 0 if env<>ISPF
Ken MacKenzie
PRAMERICA SYSTEMS IRELAND LIMITED
is a private company limited by shares,
incorporated and registered in the Republic of Ireland
with registered number 319900 and registered office at:
6th Floor,
South Bank House,
Barrow Street,
Dublin 4,
Ireland.
James Campbell
<jacampbell@ACSLI
NK.NET.AU> To
TSO-...@VM.MARIST.EDU
Sent by: TSO REXX cc
Discussion List
<TSO-...@VM.MARI Subject
ST.EDU> Re: [TSO-REXX] Parse Source (8) vs
sysispf?
Tue 07/29/2008
01:30 PM
Please respond to
TSO REXX
Discussion List
<TSO-...@VM.MARI
ST.EDU>
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Ken MacKenzie
Sent: 29. heinäkuuta 2008 15:53
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Parse Source (8) vs sysispf?
Or, to make it more succinct:
Is_ISPF = env = 'ISPF'
Which sets Is_ISPF if env=ISPF and 0 if env<>ISPF
----------------------------------------------------------------------
I actually had a little typo, corrected sentence below:
Which sets Is_ISPF to 1 if env=ISPF and 0 if env<>ISPF
So, in later processing you can just say:
If Is_ISPF Then
do this
Else
do that
Ken MacKenzie
PRAMERICA SYSTEMS IRELAND LIMITED
is a private company limited by shares,
incorporated and registered in the Republic of Ireland
with registered number 319900 and registered office at:
6th Floor,
South Bank House,
Barrow Street,
Dublin 4,
Ireland.
Lindy Mayfield
<lindy.mayfield@S
SF.SAS.COM> To
TSO-...@VM.MARIST.EDU
Sent by: TSO REXX cc
Discussion List
<TSO-...@VM.MARI Subject
ST.EDU> Re: [TSO-REXX] Parse Source (8) vs
sysispf?
Tue 07/29/2008
02:01 PM
Please respond to
TSO REXX
Discussion List
<TSO-...@VM.MARI
ST.EDU>
Is_ISPF=(env='ISPF')
The parentheses don't change the REXX syntax at all; they just make the
statement's meaning a little more obvious to those who come after me.
(You can code spaces around the '='; es macht nichts to me.)
---
Bob Bridges, rhb...@attglobal.net
cell 336 382-7313
/* The will to win is not nearly as important as the will to prepare to
win. -R.M. Knight */
-----Original Message-----
From: Ken MacKenzie
Sent: Tuesday, July 29, 2008 08:53
Or, to make it more succinct:
Is_ISPF = env = 'ISPF'
----------------------------------------------------------------------
If someone can help I would be veras I am completely stumped by this
one...
I am using REXX to display an ISPF panel and if a certain condition is
true, I then issue a command to display a table. This should just pop up
another panel and allow me to then scroll up/down and select an entry on
the panel. However, this TBDISPL does not show any panel, it just
immediately gives me RC=8 (as if I had displayed the screen and then
pressed a PFkey). Notjhing I do seems to make any difference and I am
considering tearing out what little hair I have....
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
-----------------------------------------
________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.
HTH,
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
> Date: Thu, 31 Jul 2008 17:13:42 +0100
> From: GWar...@DTCC.COM
> Subject: ISPF TBDISPL problem
> To: TSO-...@VM.MARIST.EDU
_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Grant Ward Able
Sent: 31. heinäkuuta 2008 19:14
To: TSO-...@VM.MARIST.EDU
Subject: [TSO-REXX] ISPF TBDISPL problem
I know this is a not entirely suited to this list, but hey, I am using it
in REXX!
If someone can help I would be veras I am completely stumped by this
one...
I am using REXX to display an ISPF panel and if a certain condition is
true, I then issue a command to display a table. This should just pop up
another panel and allow me to then scroll up/down and select an entry on
the panel. However, this TBDISPL does not show any panel, it just
immediately gives me RC=8 (as if I had displayed the screen and then
pressed a PFkey). Notjhing I do seems to make any difference and I am
considering tearing out what little hair I have....
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
----------------------------------------------------------------------
Ken MacKenzie
PRAMERICA SYSTEMS IRELAND LIMITED
is a private company limited by shares,
incorporated and registered in the Republic of Ireland
with registered number 319900 and registered office at:
6th Floor,
South Bank House,
Barrow Street,
Dublin 4,
Ireland.
Grant Ward Able
<GWardable@DTCC.C
OM> To
TSO-...@VM.MARIST.EDU
Sent by: TSO REXX cc
Discussion List
<TSO-...@VM.MARI Subject
ST.EDU> [TSO-REXX] ISPF TBDISPL problem
Thu 07/31/2008
05:13 PM
Please respond to
TSO REXX
Discussion List
<TSO-...@VM.MARI
ST.EDU>
I would suggest:
address ispexec "CONTROL DISPLAY SAVE"
address ispexec "VGET (ZVERB )"
say ">"zverb"<"
zverb = ""
address ispexec "VPUT (ZVERB )"
.........
address ispexec "TBDISPL...........
blah-de-blah-de-blah
address ispexec "CONTROL DISPLAY RESTORE"
The VGET and say are only for you to see if that is the problem.
The CONTROL DISPLAYs are what IBM recommend for nested panels. I'm not sure
what they do( and I don't want to know:) ) but if they are not there IBM
moan if you report a problem.
Cheers
Martin
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Grant Ward Able
Sent: 31 July 2008 17:14
To: TSO-...@VM.MARIST.EDU
Subject: [TSO-REXX] ISPF TBDISPL problem
I have tried many combinations of the CONTROL service.
If I use the "DISPLAY PANEL(panelx)" on it's own - no problem. If I use
the "TBDISPL table PANEL(panely)" on it's own - no problem, it works.
I have tried setting ZVERB to "" - it gives RC(0), but makes no
difference!
Here is the trace data of the portion of the EXEC that is giving me
trouble. Hopefully someone will see a problem that I dont.....
1167 *-* parse arg type
>>> ""
1168 *-* if type = ''
***
>>> "1"
*-* then
*-* do
1169 *-* do
1170 *-* ISPEXEC 'VERASE (A,S,QM,PN,DESC,T,ID,U,E) PROFILE'
>>> "ISPEXEC VERASE (A,S,QM,PN,DESC,T,ID,U,E) PROFILE"
1171 *-* retc = 0
>>> "0"
1172 *-* do while retc < 8
>>> "1"
1173 *-* csrf = 'A'
>>> "A"
1174 *-* disqp0:
*-* ISPEXEC 'DISPLAY PANEL(MQMQPROC) CURSOR('csrf')'
>>> "ISPEXEC DISPLAY PANEL(MQMQPROC) CURSOR(A)"
***
>>> now the panel is displayed. I enter some data, position the cursor and
press PF4 <<<
+++ RC(8) +++
1175 *-* retc = RC
>>> "8"
1176 *-* if ((ZPFKEY = 'PF03') | (ZPFKEY = 'PF15'))
>>> "0"
1178 *-* if wordpos(S,'T Q U P') = 0
>>> "0"
1187 *-* ISPEXEC 'VGET (A,S,QM,PN,DESC,T,ID,U,E,CNAME) PROFILE'
>>> "ISPEXEC VGET (A,S,QM,PN,DESC,T,ID,U,E,CNAME) PROFILE"
1188 *-* if ((ZPFKEY = 'PF04') & (CNAME = 'QM'))
>>> "1"
*-* then
1189 *-* do
1190 *-* select
1191 *-* when s = 'T'
>>> "1"
*-* then
1192 *-* do
1193 *-* ispexec 'TBOPEN MQDEFTQM NOWRITE'
>>> "ISPEXEC TBOPEN MQDEFTQM NOWRITE"
1194 *-* ispexec 'ADDPOP'
>>> "ISPEXEC ADDPOP"
1195 *-* zverb = ''
***
>>> ""
1196 *-* ispexec 'VPUT (ZVERB)'
>>> "ISPEXEC VPUT (ZVERB)"
1197 *-* ispexec 'TBDISPL MQDEFTQM PANEL(MQMQQMGR)'
>>> "ISPEXEC TBDISPL MQDEFTQM PANEL(MQMQQMGR)"
+++ RC(8) +++
1198 *-* ispexec 'REMPOP'
>>> "ISPEXEC REMPOP"
1199 *-* end
1219 *-* end
Normally, isn't it like this?
/* Create temp table */
"TBCREATE tabname (field1 field2 field3) NOWRITE"
/* Set table data variables */
Field1='a';field2='b';field3='c'
/* Add row to table (table already open) */
"TBADD tabname"
/* Move to first row */
"TBTOP tabname"
/* Display */
"TBDISPL tabname PANEL(tabpanel)"
/* Process ... */
"TBEND tabname"
Lindy
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Grant Ward Able
Sent: 1. elokuuta 2008 11:46
To: TSO-...@VM.MARIST.EDU
Did you try Ken's advice and view the contents of ZERRLM?
Here are some things I'd try to debug this:
** 1.
The Dialog Test facility is good for chasing down problems like this.
Option 4 within Dialog Test allows you to
1 Display row 3 Modify row 5 Display structure
2 Delete row 4 Add row 6 Display status
Try it and see if it enlightens you.
I have worked at a couple places where dialog test was hidden. (I think
there might have been fascist wannabees running the joint).
It should be on your main menu. Option 7.
**2.
Note that the notes in the MODEL TBDISPL skeleton say this about RC=8
---------------------------------------------------
8 - The end or return command was
entered. If crp at top, no
lines modified
- Panel was generated from tags
and the EXIT command was
entered
---------------------------------------------------
I notice your output shows an rc=8 after you press F4 from the previous
panel.
I wonder if that's carrying forward to your TBDISPL.
**3.
Try testing your TBDISPL logic in a member by itself.
Dave
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Grant Ward Able
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
Lindy Mayfield <lindy.m...@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
01/08/2008 12:10
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
"Seibert, Dave" <Dave.S...@COMPUWARE.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
01/08/2008 12:42
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Re: [TSO-REXX] ISPF TBDISPL problem
Why do you press F4? Can you confirm the value assigned to F4?
Dave
Hi Grant,
Dave
----------------------------------------------------------------------
In general it's usually a very bad idea for ISPF dialogs to be concerned with function keys. They should only be concerned with WHAT was entered, and not HOW it was entered. For example, whether someone manually enters 'END' on a command line or presses F3 should make absolutely no difference to the dialog. Even if a user changes their keys around so that F3 = HELP and F1 = END, they should be able to type END on the command line or press F1, and again it should make no difference to the dialog.
This doesn't mean you can't assist users by giving them 'special' function keys. For example, if a dialog has a command called 'DOIT' that users need to enter a lot, the 'DOIT' command could be assigned to a function key (e.g. F4). That way, the user could simply press F4 instead of having to keep manually entering 'DOIT' over and over again. But again, the dialog would never need to check if F4 was pressed; instead, it would only check if 'DOIT' was entered. Whether the user manually entered 'DOIT' on the command line or whether they pressed F4 would be of absolutely no concern to the dialog.
In the long run you'll be much better off if you remove all logic that checks which function key was pressed, and instead just focus on which commands were entered.
HTH,
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
> Date: Fri, 1 Aug 2008 09:46:20 +0100
> From: GWar...@DTCC.COM
> Subject: Re: ISPF TBDISPL problem
> To: TSO-...@VM.MARIST.EDU
>
________________________________
_________________________________________________________________
Find hidden words, unscramble celebrity names, or try the ultimate crossword puzzle with Live Search Games. Play now!
http://g.msn.ca/ca55/212
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
"Seibert, Dave" <Dave.S...@COMPUWARE.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
01/08/2008 12:52
Dave
Hi Grant,
Dave
-----------------------------------------
________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.
----------------------------------------------------------------------
That we see the RC=8 after you press F4 makes me question that you have
no value assigned.
Do you mean that it isn't assigned anything by your dialog? If yes,
then my guess is that F4 then gets the default value of "RETURN"
And if that's the case, I believe that is your problem.
Dave
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Grant Ward Able
Sent: Friday, August 01, 2008 11:31 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: ISPF TBDISPL problem
There is no value assigned to it. It is just used as an indicator that
the user wants to select from a list. The EXEC 'sees' that PF04 has been
pressed & acts accordingly...
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
----------------------------------------------------------------------
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Don Leahy
Sent: 1. elokuuta 2008 19:34
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] ISPF TBDISPL problem
Check your PFK definitions (i.e. issue the KEYS command on your
panel). Are you sure that it's not set to RETURN? If it is then that
explains the problem.
----------------------------------------------------------------------
Yes, and that's exactly what should happen. When F3 (END) is pressed, ISPF returns to the previous panel. When F4 (RETURN) is pressed, ISPF returns to the previous application. F4 means 'Goodbye, I'm done'. ISPF has always acted this way. The only surprise would be if another panel *was* displayed!
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
> Date: Fri, 1 Aug 2008 21:24:35 +0200
> From: lindy.m...@SSF.SAS.COM
> Subject: Re: ISPF TBDISPL problem
> To: TSO-...@VM.MARIST.EDU
_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207
Do forever
"Display Panel(mypanel)"
Say ZPFKEY /* says literally ZPFKEY */
Say RC /* RC=8 for PF3 and PF4, RC=0 for enter */
If RC>4 then leave
Select
When ZCMD = 'Something' /* Process command line. */
Then Call Disp_Table /* or could process ENTER = RC(0) */
Otherwise NOP
End
ZCMD = ""
End
I can trap PF3 and PF4 and Enter. But if I exit on a PF4 I go back to
the primary menu. And if I exit on a PF3 I go back to the panel where
it was called.
Oh, ok, ahh, now I see what you are saying. If I don't exit on a PF4
but try to TBDISPL, then I get an RC(8) from that. Right. The thought
of doing that was so foreign to me that I couldn't imagine it.
And if he DOES want to use PF4 (can't imagine why) then, as you helped
me, there needs to be a dynamic dummy area so that normal PF4 processing
isn't done.
Close?
Lindy7
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Dave Salt
Sent: 1. elokuuta 2008 22:34
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] ISPF TBDISPL problem
> From: lindy.m...@SSF.SAS.COM
> He gets the RC(8) immediately after the TBDISPL with no panel coming
up at all, right?
Yes, and that's exactly what should happen. When F3 (END) is pressed,
ISPF returns to the previous panel. When F4 (RETURN) is pressed, ISPF
returns to the previous application. F4 means 'Goodbye, I'm done'. ISPF
has always acted this way. The only surprise would be if another panel
*was* displayed!
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
----------------------------------------------------------------------
Do Forever
"Display Panel (MyPanel)"
Select
When Rc = 8 Then
Leave
When Rc > Then
Call ISPF_ERROR_TRAP
OtherWise
Call Process_Screen
End
End
Mickey
-------------- Original message ----------------------
From: Lindy Mayfield <lindy.m...@SSF.SAS.COM>
> I think using Rexx and ISPF services is one of the best development
> environments I've worked with.
>
> Almost everything I do is based on this very simple model of Rexx code:
>
> Do Forever
> Call Get_Data
> "Display Panel(mypanel)"
> If RC > 4 then Leave
> /* Process ZCMD, data, etc */
> End
> /* Cleanup */
> /* Exit or Return */
>
> ISPF is very flexible, but there are some things it just doesn't want to
> do because they go against the standard.
>
> I believe everyone is saying that the OP needs to maybe rethink a bit
> how he wants to handle the way the panel to table-list-panel works.
>
> Just from looking at the code where you want to "Position the Cursor and
> press F4" perhaps you could position the cursor and press ENTER?
>
> Here is a small utility that I got somewhere on the net (sorry, don't
> remember the author, it isn't in the comments). You push data onto the
> stack, call it, and it displays a nice listbox of values to choose from.
> It's very nice and I use it in some of my applications. It may give
> ideas about another way to do what you want.
>
> Here is the Rexx code and panel.
> http://lilliana.eu/downloads/listbox.rexx.txt
> http://lilliana.eu/downloads/listbox.panel.txt
>
> Rgds,
> Lindy
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
> Of Dave Salt
> Sent: 2. elokuuta 2008 0:42
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: [TSO-REXX] ISPF TBDISPL problem
>
>
> The above is okay, except there is no need to check ZPFKEY. It doesn't
> matter which function key a user pressed (if any); it's totally
> irrelevant. The only thing a dialog needs to care about is what return
> code was set by the display. If it's zero (meaning the user pressed
> ENTER), then process whatever was entered on the panel (if anything). If
> it's not zero, then quit.
Well, if the RC is non-zero, it may be more than just the user pressing enter. I trap errors and display a screen with the service, return code, and the line of code the error occurred on.
Mickey
If the return code from a panel display is not zero it means the user wants to exit or something went wrong (e.g. the panel wasn't found). Either way, non-zero means quit. I usually do something like this:
exit_code = 0
do while exit_code = 0
"DISPLAY PANEL(MYPANEL)"
select
when rc = 0 then call PROCESS_INPUT
when rc = 8 then exit_code = 8
otherwise do
exit_code = 16
"SETMSG MSG("zerrmsg")"
end
end
end
EXIT exit_code
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
_________________________________________________________________
I think you could make it clearer that much of what you say in that
message is your opinion about what is good design.
If someone wants to design a dialog which requires you to press F4 to
invoke a certain function, that is the design.
You and I may disagree with that design and say it provides challenges
for usabililty and consistency with the way many other dialogs work, but
that is merely our opinion. Sure, it's based on decades of experience.
But it is my opinion that you shouldn't imply it is technically wrong
and say that checking function keys is irrelevant.
If one's panel has a keylist assigning a literal to F4 (or does the
equivalent the old way) and the instructions on his panel say PRESS F4
to ...
then checking function keys is completely relevant.
There is no technological reason not to do that. The reasons not to, in
my opinion, are based on design and social notions, not technical
reasons.
Grant didn't ask for design advice, but debugging assistance. I'm not
saying it's wrong to offer design advice, but I suggest making it
clearer between what is opinion and what is the root of his problem.
It appears to me that Grant's problem is that his program not handling
F4 correctly.
Dave
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Dave Salt
Sent: Friday, August 01, 2008 5:42 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: ISPF TBDISPL problem
> From: lindy.m...@SSF.SAS.COM
> I'm a tad confused. If I do this, which is sort of a standard for my
things:
>
> Do forever
> "Display Panel(mypanel)"
> Say ZPFKEY /* says literally ZPFKEY */ Say RC /* RC=8 for PF3 and PF4,
> RC=0 for enter */ If RC>4 then leave Select When ZCMD = 'Something' /*
> Process command line. */ Then Call Disp_Table /* or could process
> ENTER = RC(0) */ Otherwise NOP End ZCMD = ""
> End
The above is okay, except there is no need to check ZPFKEY. It doesn't
matter which function key a user pressed (if any); it's totally
irrelevant. The only thing a dialog needs to care about is what return
code was set by the display. If it's zero (meaning the user pressed
ENTER), then process whatever was entered on the panel (if anything). If
it's not zero, then quit.
> I can trap PF3 and PF4 and Enter. But if I exit on a PF4 I go back to
> the primary menu. And if I exit on a PF3 I go back to the panel where
> it was called.
Just to be clear, there is no need to 'trap' which function key was
pressed. The return code tells you everything you need to know. RC=0
means continue, RC=8 means quit. On rare occassions you might want to
know what was entered to cause the return code to be set to 8, but
that's the exception and not the rule so I don't want to muddy the
waters by getting into that. But even then, the only thing that matters
is *what* was entered and not *how* it was entered, so there still isn't
any need to check which function key was pressed.
In most situations when the return code is 8, all the dialog has to do
is exit. It really doesn't matter whether the user pressed END or RETURN
or =3.4 (etc), as ISPF takes care of the details. For example, if the
user pressed END then ISPF returns the user to the previous panel. If
they pressed RETURN then ISPF returns them to the previous menu. If they
entered '=3.4' then ISPF takes them to option 3.4, and so on. So, the
dialog usually doesn't have to concern itself with why the return code
is 8; all it has to do is exit.
> Oh, ok, ahh, now I see what you are saying. If I don't exit on a PF4
> but try to TBDISPL, then I get an RC(8) from that. Right. The thought
> of doing that was so foreign to me that I couldn't imagine it.
I think it would be better to simply not mention function keys. They're
irrelevant.
> And if he DOES want to use PF4 (can't imagine why) then, as you helped
> me, there needs to be a dynamic dummy area so that normal PF4
> processing isn't done. Close?
Not exactly. First of all, we have to clarify the meaning of "wanting to
use PF4". A dialog could assign a command to PF4 (e.g. 'DOIT'), but the
dialog would *never* need to check if PF4 was pressed. Instead, after
displaying a panel, the dialog would simply check the return code. If
it's 8, this means exit. If it's zero, this means check what was entered
on the panel (if anything) and process it. For example, if the 'DOIT'
command was entered, then call the DOIT routine. It doesn't matter *how*
the DOIT command was entered; the user could have manually typed DOIT on
the command line, or they could have pressed a function key (e.g. F4)
that DOIT was assigned to, or they could have pressed F12 to retrieve
the DOIT command, or they could have set F1 to DOIT, or they could have
pressed a point-and-shoot field that sets ZCMD = DOIT, or they could
have used their super powers to will the command to be set to DOIT . All
of this is totally irrelevant to the dialog, because it couldn't care
less *how* the command was entered. The only thing it cares about is
*what* was entered.
As for creating a dummy dynamic area, that was a special situation to
allow scroll commands (e.g. UP, DOWN, LEFT and RIGHT) to be passed
through to a dialog. This allows the dialog to respond to scroll
commands. Whether the dialog scrolls or does something else is up to the
dialog, but again the dialog is responding to *commands* that were
entered, and is *not* responding to which function key was pressed.
To keep this simple, I would summarize it like this:
1) ISPF dialogs should never care which function key was pressed.
2) If the return code from a panel display is 8, this means exit. If
it's zero, this means process whatever was entered on the panel (if
anything).
HTH,
Dave Salt
I don't think a clear answer has been given yet on how to code Rexx (oh
and that ispeff-whatchamacallit stuff) in order to get F4 to act like
the OP wanted it to.
I have some ideas but I'd have to test it first before committing myself
to writing it down.
Lindy
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Seibert, Dave
Sent: 4. elokuuta 2008 13:43
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] ISPF TBDISPL problem
Hello Dave,
Dave
----------------------------------------------------------------------
Many thanks to all posters!
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
Lindy Mayfield <lindy.m...@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
04/08/2008 11:48
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Lindy
Hello Dave,
Dave
-----------------------------------------
________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.
----------------------------------------------------------------------
PF2 may be a more logical choice, but PF4 should be good too. Now I
want to know how to get the PF key pressed with ZPFKEY. It didn't work
for me.
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Grant Ward Able
Sent: 4. elokuuta 2008 13:55
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] ISPF TBDISPL problem
People - I am not just lurking, I hear all that has been said & agree
that
I may be treading on decades of best practice toes. It's just that I was
asked to create a panel where the csr can be positioned & a PFKEY
pressed
to get a list of acceptable values (just like a PROMPT in the IBM MQ
panels). I will be looking at all the advice given and attempting to
make
some changes to my code ASAP.
Many thanks to all posters!
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
----------------------------------------------------------------------
Retrieving the PFKEY requires setting a variable in the Panel and then
checking the variable in the program.
I haven't done it in years.
But here's an example:
In the panel:
)PROC
&PFK = .PFKEY
& in the rexx:
Say &PFK
Dave
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Lindy Mayfield
Sent: Monday, August 04, 2008 8:00 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: ISPF TBDISPL problem
Say PFK
Dave
&ZPFKEY = .PFKEY
and in my EXEC I just use ZPFKEY:
ISPEXEC 'DISPLAY PANEL(MQMQPROC) CURSOR('csrf')'
if ((ZPFKEY = 'PF03') | (ZPFKEY = 'PF15')) then return
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
Lindy Mayfield <lindy.m...@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
04/08/2008 13:00
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
-----------------------------------------
________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.
----------------------------------------------------------------------
But I thought there had to be a dummy dynamic area to make it work, but
as Dave said, it only works for a few keys. In my test PF7 PF8 PF10
PF11.
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Grant Ward Able
Sent: 4. elokuuta 2008 13:55
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] ISPF TBDISPL problem
People - I am not just lurking, I hear all that has been said & agree
that
I may be treading on decades of best practice toes. It's just that I was
asked to create a panel where the csr can be positioned & a PFKEY
pressed
to get a list of acceptable values (just like a PROMPT in the IBM MQ
panels). I will be looking at all the advice given and attempting to
make
some changes to my code ASAP.
Many thanks to all posters!
----------------------------------------------------------------------
VGET (ZPF04)
zpf04_save = zpf04 /* save PF4 */
zpf04 = 'mycom'
'VPUT (ZPF04)'
..
'DISPLAY PANEL(...)'
..
if ZCMD = 'mycom'
then do
/* the PF4 action */
end
..
zpf04 = zpf04_save /* restore PF4 */
'VPUT (ZPF04)'
Albert
VERLAGSGRUPPE WELTBILD GMBH
Sitz der Gesellschaft: Augsburg
Handelsregister Augsburg HRB 6035
Ust-ID-Nr: DE 127501299
Geschäftsführung:
Carel Halff (Vorsitzender), Dr. Klaus Driever, Werner Ortner, Herbert Zoch
Vorsitzender des Aufsichtsrates:
Dr. Klaus Donaubauer
In my reply to the OP, I suggested it's a bad idea to check which function key is pressed. In my reply to Lindy, I suggested his code didn't need to check which function key is pressed. In Lindys case, it's irrelevant. Nevertheless, I'm sorry if my opinion came across too strongly; part of that might be because I'm currently on vacation and trying to write emails as quickly as possible while my family is nagging me to "get going" (even as they are doing at this very moment!).
> If one's panel has a keylist assigning a literal to F4 (or does the
> equivalent the old way) and the instructions on his panel say PRESS F4
> to ...
> then checking function keys is completely relevant.
I'm afraid I have to disagree. If a command has been assigned to F4 (e.g. 'DOIT') and the panel says to press F4, the logic should still only check which command was entered. In my opinion, it's the command that was entered that's important, and not how the user chose to enter it.
> Grant didn't ask for design advice, but debugging assistance. I'm not
> saying it's wrong to offer design advice, but I suggest making it
> clearer between what is opinion and what is the root of his problem.
I agree. In my original post to Grant, I tried to offer debugging advice; i.e. that the cause of the problem was that F4 was being pressed, and F4 means 'RETURN'. I then went on to offer design advice; i.e. that it's generally not a good idea to check which function key was pressed (I'm pretty sure that's how I phrased it). Anyway, I got to go; my family is getting impatient!
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207
Your family is right.
Go enjoy them and your vacation.
Dave
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Dave Salt
Sent: Monday, August 04, 2008 10:45 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: ISPF TBDISPL problem
I wish I'd had more time earlier to explain why I think ISPF dialogs shouldn't check which function key was pressed. I've got a bit more time now, so in case you're curious I'll try to explain my reasoning.
From an ISPF perspective, function keys are there for the convenience of the user. For example, it's much easier for a user to press F3 than it is to keep manually typing 'END'. However, it's important to note that it's the 'END' command that causes a panel to exit, and not the fact that F3 was pressed. As I'm sure you know, if the commands associated with F1 (HELP) and F3 (END) were switched around, then pressing F3 would display help; it would not END from a panel. This is because it's the command (and not the function key) that determines what action gets performed.
SDSF sets F5 to a default value of 'IFIND', but a user can change F5 to execute some other command, and could use a different function key (e.g. F12) to execute the IFIND command. Or, they might choose to not have a function key set to IFIND, and instead might manually enter IFIND. In other words, it's completely up to the user as to how commands are executed.
Now imagine if an ISPF dialog *forced* users to press certain function keys. For example, users could *only* execute IFIND by pressing F5. Many users would find this to be extremely poor design, not only because it's so restrictive but also because it runs completely contrary to the way every other panel in ISPF is designed to work.
When someone creates a home-grown ISPF panel that requires certain function keys to be pressed, I'm sure they're doing it with the very best of intentions. In other words, they're trying to make things 'easier' for the user by allowing them to press certain keys instead of having to enter certain commands. But ultimately this does more harm than good. For example, imagine if a user has set F4 to execute 'TSO TIME' on every panel they go into. How impressed do you think they would be if they want into a panel that refused to let them use F4 to execute 'TSO TIME'?
There are several ways to make it easy for users to perform different actions, without 'forcing' them to have to press particular keys. If you're looking for ideas I'd be happy to suggest some. Meanwhile, I hope this explanation regarding my view on function keys has been of some use to you.
Regards,
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
_________________________________________________________________
If you like crossword puzzles, then you'll love Flexicon, a game which combines four overlapping crossword puzzles into one!
http://g.msn.ca/ca55/208
>My Solution:
>
>VGET (ZPF04)
>zpf04_save = zpf04 /* save PF4 */
>zpf04 = 'mycom'
>'VPUT (ZPF04)'
>..
>'DISPLAY PANEL(...)'
>..
>if ZCMD = 'mycom'
>then do
> /* the PF4 action */
>end
>..
>zpf04 = zpf04_save /* restore PF4 */
>'VPUT (ZPF04)'
I suggest that setting the new value of PF4 should happen immediately before
DISPLAY, and resetting to its original value should happen immediately after
DISPLAY.
Yes, this means that you will set and reset PF4 many times, but it avoids the
problem of PF4 having a bizarre value in case of ABEND or timeout.
(change Arabic number to Roman numeral to email)
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
Dave Salt <ds...@HOTMAIL.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
05/08/2008 05:29
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Re: [TSO-REXX] ISPF TBDISPL problem
Grant,
Regards,
Dave Salt
-----------------------------------------
________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.
----------------------------------------------------------------------