Comments interspersed.
And that's ISPF's fault how?
Of course it's not ISPF's *fault*. My point is that it could do better at
meeting our needs.
Have you tried reference lists? You could have a separate
list for each application area, if you want.
Yep. REFLIST is not the easiest thing to use. It is better than nothing,
but not by much. (IMHO anyway).
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!)]
Yes, I am *extremely* currrent, and an obsessive reader of ISPF manuals.
One of my favourite hobbies is annoying my colleagues by pointing out new
features. Believe it or not (but, being in the training business there's
not much that would surprise you I guess) many programmers still don't know
about edit HILITE.
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_
That only shows you which data sets contain the string. You still have to
scan the PDS to find out which member(s) has(ve) the hit. I want it all: I
want to perform a SRCHFOR from within a member list, and see the members
with hits in a nested member list where I can browse, edit or whatever I
need to do. Yeah, I know that is asking a lot. :-)
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.
Of course. And I have used them. But, each one represents a little bit of
unnecessary productivity drain. Over the course of a year that adds up.
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"?
I have hundreds of different DB2 tables that I need to look at. I use SPUFI
all the time, but keeping track of table names on "scraps of paper" is yet
another productivity drain.
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.
Sorry, there was a typo in that part (I forgot to take out the "not", as a
programmer I know how devastating that can be). What I meant to say was:
"Am I 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)."
Remember this is an opinion, not a statement of fact. ISPF *can* be better.
(Remember I started on this tirade when another poster characterized ISPF as
"was a very powerful tool in its day." implying that its day is past. I
strongly disagree with that characterization, but I do maintain that
improvements are possible and needed.)
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.
I hear you. I am an independed consultant. My current client has SimpList,
but the next one may not, so I know I'm going to have to deal with vanilla
ISPF again. I am not looking forward to it.
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...
----------------------------------------------------------------------
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
