ISPF Command Tables
JB Moore
If the command table that you are trying to make changes to is ISPCMDS and you are running under ISPF Version 4, this might be an opportune time to look into adding a "SITECMDS" command table.
You need only declare that you will be using a site command table by adding a constant in ISRCONFG. This will forever eliminate problems with atempting to modify the IBM-supplied ISPCMDS which no longer needs to be "customized" to add site-specific ISPF commands.
That's why IBM provided the "SITECMDS" feature to the ISPF environment. Right Doug?
Jim Moore
Imbriale, Donald , Exchange
modify the IBM-supplied command table, but it does not address the problem
of updating the table when it is open by others.
Don Imbriale
If the command table that you are trying to make changes to is
ISPCMDS and you are running under ISPF Version 4, this might be an opportune
time to look into adding a "SITECMDS" command table.
You need only declare that you will be using a site command table by
adding a constant in ISRCONFG. This will forever eliminate problems with
atempting to modify the IBM-supplied ISPCMDS which no longer needs to be
"customized" to add site-specific ISPF commands.
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
JB Moore
Of course, you are right. The original post did not mention exactly which command table was being modified either. All my post was meant to communicate was the capability of using a SITE-specific command table.
I am working right now at a V4 ISPF site where someone went in and tediuosly re-applied all their site-specific customization (MVS Quickref's QW and QWSDSF among others) to the baseline ISPCMDS table.
The post that mentioned using a bogus newappl of "xxxx" (or whatever) using a renamed copy of the real table is the best way to actually "permanently" modify a heavily accessed ISPF command table.
Jim Moore
ISPF discussion list <ISP...@listserv.nd.edu> wrote:
> The use of SITECMDS (or whatever name you use) will eliminate the need tomodify the IBM-supplied command table, but it does not address the problem
Doug Nadel
On Thu, 2 Mar 2000 16:11:34 -0500, you wrote:
>
>The use of SITECMDS (or whatever name you use) will eliminate the need to
>modify the IBM-supplied command table, but it does not address the problem
>of updating the table when it is open by others.
I'm not sure of what is needed here. If you want to have the changes
reflected immediately to users who are already running, I don't see a
good way since the cmd table is only read at initialization time (or
when your only logical screen abends and restarts). If, however, you
just need to get around some SPFEDIT ENQ, you can use a standard
utility (iebgener/iebcopy,etc) to copy the updated version into a
shared library.
I know that many people use table services to update command tables
temporarily. You might be able to write a small exec that would read
the new version and update the command table in storage but that would
require the user to run it. If you wanted to get fancy, you could
probably modify the primary panel to run it each time that panel is
displayed. Then users would see the new version by returning to the
primary panel or just splitting the screen. IBM (aka Marv Knight)
doesn't recommend the open command table updating technique, but I'm
not aware of the particular reason. Many people have had success with
it. Just be sure to put the aliases before the other entries. You
can see the CMD2DTL command at my page for some rexx code that sorts
the table that way.
Doug Nadel
----------------------------------------
ISPF and OS/390 Tools & Toys page:
http://somebody.home.mindspring.com/
Gray, Alastair
USERCMDS command table as well. So that all those out of date copies of
ISPCMDS that people have added to their ISPPROFs in order to add some handy
new commands can be removed as well.
Alastair Gray
System Type
> -----Original Message-----
> From: JB Moore [SMTP:conl...@IX.NETCOM.COM]
> Sent: Thursday, March 02, 2000 9:33 PM
> To: ISP...@listserv.nd.edu
> Subject: ISPF Command Tables
<snip>
> If the command table that you are trying to make changes to is ISPCMDS and
> you are running under ISPF Version 4, this might be an opportune time to
> look into adding a "SITECMDS" command table.
>
> You need only declare that you will be using a site command table by
> adding a constant in ISRCONFG.
<snip>
Bob Richards
> IBM (aka Marv Knight) doesn't recommend the open command table
> updating technique
Marv (and Doug),
Is there a reason we should not be doing this?
I am using SITECMDS in my own ISPTLIB, which is concatenated ahead of
the default one. I have a little CLIST/Panel that enables me to
IEBGENER SITECMDS to NEWCMDS and then edit NEWCMDS, make my
modifications and then prompts me if I want to copy it back as
SITECMDS. To see my changes, I exit and reenter ISPF. Voila..new
entries!
What problems can this process cause?
=====
Bob Richards, OS/390 Consultant Internet: richa...@yahoo.com
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
JB Moore
No, you are doing things OK. What Doug meant is the "on-the-fly", in-memory
modification of any ISPF command table. One of the problems that can occur
when doing this is excessive ZCT row additions. Years ago, I used to modify
ISPCMDS in memory (it is always open, anywhere in ISPF). Unless you put some
code in to determine if the command that you are trying to add is already in
the table, you might discover that such a command table modify dialog is
repeatedly adding the same row, over and over.
Plus, as Doug mentioned, something must execute the dialog that does the
in-memory command table modifications.
Jim Moore
Steve Werth
command table. It can be modified to also update a user command table.
Obviously, you'll want to make appropriate changes for your shop. The data
set that is being LIBDEFed would normally be one that's already allocated to
ISPTLIB, but it wouldn't have to be.
Steve Werth
OS/390 Systems Programmer
PKS Computer Services, LLC - System Services
402-963-8905 (voice)
402-496-8676 (fax)
Steven...@pksis.level3.com
/*=============================== Rexx ===============================*/
Address ISPEXEC
"CONTROL ERRORS RETURN"
If Not_in_split_screen() Then
If User_table_updated() Then
"TBOPEN PKSCMDS NOWRITE SHARE"
Else
NOP
Else
Do
zedsmsg = ''
zedlmsg = 'User command tables cannot be updated while in split',
'screen mode'
"SETMSG MSG(ISRZ001)"
End
Exit
User_table_updated: Procedure
"TBEND PKSCMDS"
"LIBDEF ISPTABL DATASET ID('SYS1.PKS.SISPTENU') STACK"
"SELECT PGM(ISPUCM) PARM(PKS)"
crc = rc
"LIBDEF ISPTABL"
Return (crc <= 8)
Not_in_split_screen: Procedure
"VGET ZSPLIT SHARED"
Return (zsplit = 'NO')
Frank Clarke
>
>If the command table that you are trying to make changes to is ISPCMDS...
At the risk of saying something politically incorrect, I've found the
protocol for those additional tables to be far too klunky. I have,
for many years now, used a routine (ADDCMDS) which takes a spare
command table (xxxCMDS) and splices it to the in-storage copy (not a
DASD copy) of ISPCMDS. Such changes take place immediately and affect
only --my-- copy of ISPCMDS and only for as long as I stay inside ISPF
and avoid a dialog error.
I can bop over to 3.9 and upgrade my TMPCMDS table, then immediately
add those changes by re-running ADDCMDS.
Yes, I have to re-run ADDCMDS every time I start ISPF. Yes, I have to
re-run ADDCMDS every time I get a dialog crash. Cheap enough.