Don Leahy wrote:
> Of course, there are always wish list items, but why do you
say ISPF out of the bag isn't very productive?
Kind regards,
-Steve Comstock
Where do I begin? :-)
First off, I don't want to come off sounding harsh; I have been happily
using ISPF for over 25 years. And, I realize that life before ISPF
(which was before my time, thank goodness!) was a lot more difficult.
(I have seen TSO Edit....not a pretty sight... though I am sure that
some of the more venerable members of this list remember it fondly)
However, ISPF forces you to remember a *lot* of data set names. To the
system programmers on this list that may not be a big deal, (everything
that matters starts with SYS1.* right?) but I work in applications
support where every one of the systems I work with tends to have unique
naming conventions. Yeah, you can blame that on lax standards, but the
point is it that you have to cope with it regardless.
I used to cope with it by keeping scraps of paper scattered around my
desk, or on my cubicle walls, each one with a list of important data set
names for "easy" reference. And when I lost the scrap of paper, I was
forced to grope my way to the right answer by doing catalog searches
using 3.4 or LISTCAT.
And that's ISPF's fault how?
Have you tried reference lists? You could have a separate
list for each application area, if you want.
Navigation is another issue. If I had a dollar for every time I told a
newbie "No, you have to go to 3.1 to do that" I could have retired 5
years ago. This becomes second nature after a while, but is there no
standard member list on which you can do everything? What's a newbie to
think? (...that ISPF "sucks" perhaps?)
Hmm. You could use the Workplace (ISPF option 11; or have you
not kept yourself current?) [BTW, I have a class for keeping
current / getting up to date on ISPF features (What a surprise!)]
Lack of integration is another biggie. I spend a lot of time performing
impact analysis for application changes. A big part of my job involves
searching for variable names or other strings of information stored
within our source libraries. To do this I have to split my screen, go
to 3.14 and perform a search. SRCHFOR does a good job of searching, but
returns the results in a report. There's nothing *wrong* with that, but
it is much less productive than seeing the search results expressed in a
member list from which you can then select members for Browsing or Editing.
How about going to DSLIST with list of dsnames to search; then
issuing
SRCHFOR _stuff_
Will put you in View of a report for each library of the members
that contain the string _stuff_; a couple of editor commands and
a Create and you can have your list of members.
There's other approaches you could take, too.
And that's just data sets. ISPF doesn't give you any way to manage,
say, DB2 tables, TSO commands or other non-data set objects. (Option
6, which keeps a list of the last 10 TSO commands executed doesn't
constitute "managing" in my opinion. I want a list that is under my
full control). Am I not being unfair by demanding this? No, because
that's what today's progammer has to deal with, and ISPF isn't giving
him enough help. (IMHO anyway).
Well, you can do a lot of your DB2 work in SPUFI; I'm not sure what
you want to "manage" about commands; save favorites as REXX execs
and invoke them from the command line? Easily done. How do you
want to "manage" "non-data-set objects"? Or what "non-data-set-objects"?
Regarding the last parts of your paragraph:
What is it you are "demanding" exactly? (What is the referrant of
"this"?) Are you demanding it? Who are you demanding too? What does
it mean to be "unfair" by "demanding" "this"? Have you talked to
the ISPF developers? Informed them of your demands (or even just
talked about what you'd like to see, nice and comfortable and
friendly like?) And what is the "that" that today's programmer
has to deal with? What _exactly_ is it you want? As I said in
my question, there are always wish list items, but the developers
can't read minds.
And yes, I know each one of these complaints probably has a historical
or technical justification of some sort, and some have workarounds.
However, that is not the point I am trying to make.
If z/OS is to continue to thrive, its interactive user interface is
going to have to be perceived as accessible and productive.
No quarrel there.
This is why I have become an enthusiastic user of SimpList, a
productivity tool marketed by Mackinney. It's extremely inexpensive
(ie, so it's not just a "wish list" item) and addresses all of the
concerns I expressed above.
Well, good for you and good for them.
I have to pretty much stick with vanilla IBM products because
when I go and teach I'm never sure what mix of third-party
products I'll find in any given shop. And I can fly around
a keyboard with ISPF pretty well, using five or six named
split screens (out of a possible 32), and features like
retp, cmd, and so on.
Not that I feel strongly about this issue. :-)
Right. You've found your answers and you're happy, it sounds
like. . . . Unless there are some features in Simplist...
Kind regards,
--
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
-- to be included in our opt-in list of announcements of
-- new courses and other products and services from The
-- Trainer's Friend, send an email to [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
