Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Steve Comstock]

Bob Shannon wrote:

In the "golden days" (just 5 or 6 years ago,
even), many companies built in training time
as part of each IT employee's performance plan.



That may be true, but IMO training budgets never recovered from cutbacks
in the early 1990ss.

Bob Shannon


Well, yes, that's absolutely true.

In the early 90's US West had a training organization
in Bellevue, WA for IT of 30-40 people, plus training
work in Salt Lake, Omaha, Denver; by the end of the
decade there were three schedulers; then it was all
outsourced.

Kind regards,

-Steve Comstock

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Bob Shannon]

>In the "golden days" (just 5 or 6 years ago,
>even), many companies built in training time
>as part of each IT employee's performance plan.

That may be true, but IMO training budgets never recovered from cutbacks
in the early 1990ss.

Bob Shannon

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Steve Comstock]

Tom Marchant wrote:

Does anyone know when 3.4 was first introduced?

How about when the Workplace (3.11) was introduced?

There's a lack of credibility when people talk about 3.4 as an example
of using new features.

As to panels that pop up to tell me about new features, I find them
to be rather annoying.  If they tell only about the changes since the
last release, they are of little value.  How many of us migrate to
every new release?  If they go back to far, there is too much
repetition.  The time for me to effectively learn new features is not
when I begin using the tool for a particular purpose.  I need to
explore the tool when I have a little more free time.  Maybe
it's just me



The reality is, most people seldom take the time
(or have the time, given the results of many
iterations of downsizing, layoffs, outsourcing
resulting in skeleton staffs carrying rather
full loads).

In the "golden days" (just 5 or 6 years ago,
even), many companies built in training time
as part of each IT employee's performance plan.

Now it's pretty much catch as catch can, and
it better be on your own time and dime.

I'd like to see some kind of balance between
the extremes, but I'm just goin' with the
reality flow these days.

-Steve Comstock




On Thu, 18 May 2006 16:12:56 +, Dave Salt <[EMAIL PROTECTED]> wrote:



In <[EMAIL PROTECTED]>, on 05/15/2006
  at 08:49 PM, Dave Salt <[EMAIL PROTECTED]> said:



My experience is that 90% of programmers use the upgraded ISPF/PDF
interface  almost immediately after the new option is added to their
ISPF menu. The other 10% eventually come around, just as they
eventually came around to using ISPF option 3.4. Human nature is
such that if a tool is not only far more powerful than whatever they
were using before, but is also far easier to use, inertia is quickly
overcome.



From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>
That's not my experience; I've seen all too many programmers ignoring
useful ISPF enhancements for many releases. In some cases they will
try them once they see[1] me using them, but in other cases they won't
because it's not what they're used to.



I think that's the key; the user has to 'see' the new 


command/feature/option


in order to use it. For example, along comes a new release of ISPF with a
wonderful new command that can be used in edit called 'COMPARE'. However,
where does the user have to go to know this new command is available? Most
users don't read tutorials or new versions of the ISPF manuals. So, unless
they get training (Steve: your comments go here...) 


thanks. didn't see this until it was in this reply.
you must be using the listserv instead of the mail list
(is that the way it works? I always get a little muddled
about that).

Anyway, for ISPF we have:



ISPF Update - 2 days; a fast path for
  features update;
details:
http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a634descrpt.htm




Advanced ISPF - 1 day; features that
   are not normally
   covered elsewhere
details:
http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a635descrpt.htm




[snip]

Kind regards,

-Steve Comstock

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Tom Marchant]

Does anyone know when 3.4 was first introduced?

How about when the Workplace (3.11) was introduced?

There's a lack of credibility when people talk about 3.4 as an example
of using new features.

As to panels that pop up to tell me about new features, I find them
to be rather annoying.  If they tell only about the changes since the
last release, they are of little value.  How many of us migrate to
every new release?  If they go back to far, there is too much
repetition.  The time for me to effectively learn new features is not
when I begin using the tool for a particular purpose.  I need to
explore the tool when I have a little more free time.  Maybe
it's just me

On Thu, 18 May 2006 16:12:56 +, Dave Salt <[EMAIL PROTECTED]> wrote:

>>In <[EMAIL PROTECTED]>, on 05/15/2006
>>at 08:49 PM, Dave Salt <[EMAIL PROTECTED]> said:
>>
>> >My experience is that 90% of programmers use the upgraded ISPF/PDF
>> >interface  almost immediately after the new option is added to their
>> >ISPF menu. The other 10% eventually come around, just as they
>> >eventually came around to using ISPF option 3.4. Human nature is
>> >such that if a tool is not only far more powerful than whatever they
>> >were using before, but is also far easier to use, inertia is quickly
>> >overcome.
>
>>From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>
>>That's not my experience; I've seen all too many programmers ignoring
>>useful ISPF enhancements for many releases. In some cases they will
>>try them once they see[1] me using them, but in other cases they won't
>>because it's not what they're used to.
>>
>
>I think that's the key; the user has to 'see' the new 
command/feature/option
>in order to use it. For example, along comes a new release of ISPF with a
>wonderful new command that can be used in edit called 'COMPARE'. However,
>where does the user have to go to know this new command is available? Most
>users don't read tutorials or new versions of the ISPF manuals. So, unless
>they get training (Steve: your comments go here...) or they see someone 
else
>use the command or they see the command 'advertised' somewhere on one of 
the
>panels they go to, the new command is simply ignored. However, if you add a
>new option to an ISPF menu (e.g. just as 3.4 was once added), curiosity 
will
>eventually get the better of most people, and eventually they'll go in and
>take a look.
>
>Most ISPF panels work on the premise that people will read the manuals or 
go
>into tutorials or pull down the drop down menus. In my experience, just 
like
>yours, this isn't the case. Options and commands have to be clearly visible
>or at least presented, otherwise most people will never know they exist.
>Some people think it's impossible to display every command or option on a
>panel, because each panel has limited space. However, where there's a will
>there's usually a way. For example, using the edit COMPARE command I just
>mentioned, it would obviously be impractical to permanently list the 
command
>at the top of the edit panel. So, in a situation like this, an alternative
>might be to do something like this:
>
>1) When someone goes into an edit session under a new ISPF release for the
>very first time, a message could be displayed saying "The following new
>commands are available...".
>
>2) When someone goes into ISPF option 3.12 for the very first time, a
>message could be displayed saying "Did you know you can compare 2 files 
from
>within an edit session? Here's how..."
>
>These suggestions are not 'bullet proof' and there will always be people 
who
>ignore messages and just don't want to learn. But for the majority of
>people, I think if you SHOW them something is available and they think it
>might be useful, they will want to try it.
>

--
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

Re: Cost of tools

[Ed Gould]

On May 18, 2006, at 9:31 AM, Steve Comstock wrote:


--- 
SNIP

Well, and my own private agony: no managers will
pay for ISPF training (which is one of the places
I discuss SDSF, (E)JES, IOF, etc.): "our people
already know it."

Right.

Kind regards,

-Steve Comstock
 
SNIP--


Steve,

Can you counter that training is a productivity tool?
Seems like you can catch some with old its also an investment and a  
moral builder.


Ed

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Thomas Berg]

==  Don Leahy  ==  wrote2006-05-18 20:00:


I agree that sometimes you have to hit people over the head to get their
attention, but once they see the benefit of the new tool it isn't that
difficult to convince them to use it, *if* it is easy to use.   If a 
product is beneficial but difficult (such as most debugging tools) then 
awareness of the product is not enough, training is required. 


Very true.

Thomas Berg


--

__

Mundus Vult Decipi
__

 They that can give up essential liberty to obtain a little temporary safety 
deserve neither liberty nor safety.
 - Benjamin Franklin

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Don Leahy]

- Original Message - 
From: "Dave Salt" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, May 18, 2006 12:12 PM
Subject: Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)



>In <[EMAIL PROTECTED]>, on 05/15/2006

   at 08:49 PM, Dave Salt <[EMAIL PROTECTED]> said:

>My experience is that 90% of programmers use the upgraded ISPF/PDF
>interface  almost immediately after the new option is added to their
>ISPF menu. The other 10% eventually come around, just as they
>eventually came around to using ISPF option 3.4. Human nature is
>such that if a tool is not only far more powerful than whatever they
>were using before, but is also far easier to use, inertia is quickly
>overcome.



From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>
That's not my experience; I've seen all too many programmers ignoring
useful ISPF enhancements for many releases. In some cases they will
try them once they see[1] me using them, but in other cases they won't
because it's not what they're used to.



I think that's the key; the user has to 'see' the new
command/feature/option in order to use it.



When we installed SimpList in our shop, the local sysprog didn't want to
change the local ISPF menu to include it as an option.  An email
announcement was made regarding its availability, but it didn't have much
impact because most people had no idea what the product was and weren't
interested in finding out on their own.  Most of them probably deleted the
email right after they read it..

I'd stuck my neck out to convince Management to buy the product (they are
more interested in gettting rid of mainframe software licences than
acquiring any new ones) and I didn't want it to fail through inertia.  To
remedy this,  I circulated a series of emails containing 'tips of the week'
describing some of the product's most useful features and how easy it was to
use them.   Within a month, over 80% of the programmers were using it
regularly; within two months everyone was using except for one die-hard
user, who came around a few months later.

I agree that sometimes you have to hit people over the head to get their
attention, but once they see the benefit of the new tool it isn't that
difficult to convince them to use it, *if* it is easy to use.   If a product
is beneficial but difficult (such as most debugging tools) then awareness of
the product is not enough, training is required.  IMO anyway.

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Dave Salt]

In <[EMAIL PROTECTED]>, on 05/15/2006
   at 08:49 PM, Dave Salt <[EMAIL PROTECTED]> said:

>My experience is that 90% of programmers use the upgraded ISPF/PDF
>interface  almost immediately after the new option is added to their
>ISPF menu. The other 10% eventually come around, just as they
>eventually came around to using ISPF option 3.4. Human nature is
>such that if a tool is not only far more powerful than whatever they
>were using before, but is also far easier to use, inertia is quickly
>overcome.



From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>
That's not my experience; I've seen all too many programmers ignoring
useful ISPF enhancements for many releases. In some cases they will
try them once they see[1] me using them, but in other cases they won't
because it's not what they're used to.



I think that's the key; the user has to 'see' the new command/feature/option 
in order to use it. For example, along comes a new release of ISPF with a 
wonderful new command that can be used in edit called 'COMPARE'. However, 
where does the user have to go to know this new command is available? Most 
users don't read tutorials or new versions of the ISPF manuals. So, unless 
they get training (Steve: your comments go here...) or they see someone else 
use the command or they see the command 'advertised' somewhere on one of the 
panels they go to, the new command is simply ignored. However, if you add a 
new option to an ISPF menu (e.g. just as 3.4 was once added), curiosity will 
eventually get the better of most people, and eventually they'll go in and 
take a look.


Most ISPF panels work on the premise that people will read the manuals or go 
into tutorials or pull down the drop down menus. In my experience, just like 
yours, this isn't the case. Options and commands have to be clearly visible 
or at least presented, otherwise most people will never know they exist. 
Some people think it's impossible to display every command or option on a 
panel, because each panel has limited space. However, where there's a will 
there's usually a way. For example, using the edit COMPARE command I just 
mentioned, it would obviously be impractical to permanently list the command 
at the top of the edit panel. So, in a situation like this, an alternative 
might be to do something like this:


1) When someone goes into an edit session under a new ISPF release for the 
very first time, a message could be displayed saying "The following new 
commands are available...".


2) When someone goes into ISPF option 3.12 for the very first time, a 
message could be displayed saying "Did you know you can compare 2 files from 
within an edit session? Here's how..."


These suggestions are not 'bullet proof' and there will always be people who 
ignore messages and just don't want to learn. But for the majority of 
people, I think if you SHOW them something is available and they think it 
might be useful, they will want to try it.


Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

--
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

Re: Cost of tools

[Steve Comstock]

Paul Gilmartin wrote:

In a recent note, "Shmuel Metz (Seymour J.)" said:



Date: Thu, 18 May 2006 09:09:37 -0300

That's not my experience; I've seen all too many programmers ignoring
useful ISPF enhancements for many releases. In some cases they will
try them once they see ... me using them, but in other cases they won't
because it's not what they're used to.



Likewise, I'm astonished at how many SDSF users persist in using
PREFIX instead of OWNER (shades of TSO OUTPUT!  I stopped prefixing
my job names with my TSO ID as soon as I learned of OWNER),
H instead of ST, and 'S' instead of '?'.  And somewhat less
astonished at how many aren't even aware of these alternatives.

-- gil


Well, and my own private agony: no managers will
pay for ISPF training (which is one of the places
I discuss SDSF, (E)JES, IOF, etc.): "our people
already know it."

Right.

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.
http://www.trainersfriend.com

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Paul Gilmartin]

In a recent note, "Shmuel Metz (Seymour J.)" said:

> Date: Thu, 18 May 2006 09:09:37 -0300
> 
> That's not my experience; I've seen all too many programmers ignoring
> useful ISPF enhancements for many releases. In some cases they will
> try them once they see ... me using them, but in other cases they won't
> because it's not what they're used to.
> 
Likewise, I'm astonished at how many SDSF users persist in using
PREFIX instead of OWNER (shades of TSO OUTPUT!  I stopped prefixing
my job names with my TSO ID as soon as I learned of OWNER),
H instead of ST, and 'S' instead of '?'.  And somewhat less
astonished at how many aren't even aware of these alternatives.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/15/2006
   at 08:49 PM, Dave Salt <[EMAIL PROTECTED]> said:

>My experience is that 90% of programmers use the upgraded ISPF/PDF
>interface  almost immediately after the new option is added to their
>ISPF menu. The  other 10% eventually come around, just as they
>eventually came around to  using ISPF option 3.4. Human nature is
>such that if a tool is not only far  more powerful than whatever they
>were using before, but is also far easier  to use, inertia is quickly
>overcome.

That's not my experience; I've seen all too many programmers ignoring
useful ISPF enhancements for many releases. In some cases they will
try them once they see[1] me using them, but in other cases they won't
because it's not what they're used to.

[1] In fact, quietly exploiting features seems to be far more
effective in promulgating their use than trying to talk people
into trying them.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Cost of tools

[Staller, Allan]

Dave,

You've been spending too much time reading Dilbert 



YOU: I'd like permission to buy a new software tool that upgrades the
ISPF/PDF interface.

BOSS: How much does it cost?

YOU: $5,000.

BOSS: What's wrong with the interface we have now?

YOU: It's slow, cumbersome, difficult to learn and use, and very
unproductive.

BOSS: But it works though, right? I'm sorry, but if what we've got works
then we don't need to spend money to buy something extra.

YOU: But with 100 developers using it, it would save our company more
than a million dollars a year. Isn't it worth spending $5,000 to save a
million?

BOSS: Maybe so, but the budget is tight right now. Where would we get
$5,000 from?

YOU: We're planning to hire 500 new people for the call center, and each
of them will have a PC on their desk. If we don't buy them a mouse, it
will save more than $5,000.

BOSS: But a mouse is critical; you can't use a PC without a mouse!

YOU: Actually, you can. It's hard, and it takes some training, but it
can be done.

BOSS: But wouldn't productivity go down?

YOU: Yes, I'm afraid it would.

BOSS: Well that's no good. If each call takes longer to deal with than
it needs to, it will end up costing us money, not saving money.

YOU: Wow, you're smart. You're saying that spending a little bit of
extra money to improve productivity saves even more money in the long
run!

BOSS: Yes, exactly. That's why I'm the boss.

YOU: Wow, I see what you mean. So, would it make sense to spend $5,000
to upgrade the ISPF interface and save the company a million dollars a
year?

BOSS: Of course it would. And $5,000 is so low I can spend it without
even having to go further up the chain to get approval.

YOU: Wow boss, thanks. You're the best!



--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Paul Gilmartin]

In a recent note, Edward Jaffe said:

> Date: Tue, 16 May 2006 07:57:06 -0700
> 
> Bruce Hewson wrote:
> > I continue to be astonished/annoyed/aggravated etc by how many
> > sysprogs/developers/operators insist on using basic Mod-2 (24x80) format
> > 3270 emulator screens.
> 
> Amen to that, Bro!
> 
> Funny story. During last month's beta testing of an upcoming software
> release, it was discovered (by a participating early tester at a *large*
> government installation) that the software no longer worked _at all_
> with a 24x80 screen. Nobody here ever noticed!
> 
You've stumbled on the other side of the coin.  ISVs must be
careful that no such productivity enhancement, optional, ISV,
CVT, whatever contaminates your testing environment, and do
our validation testing in an environment having only the
minimum published System Requirements (in addition to testing
for compatibility with enhancements plausibly encountered in
the customer environment).  If we specify model 2 as a minimum
requirement, we must test exhaustively on a model 2.

BTW, what had you specified as a requirement for terminals?
If you don't specify at least 3278-2, the customer has a
right to expect support for linemode TSO.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Edward Jaffe]

Bruce Hewson wrote:
I continue to be astonished/annoyed/aggravated etc by how many 
sysprogs/developers/operators insist on using basic Mod-2 (24x80) format 
3270 emulator screens.
  


Amen to that, Bro!

Funny story. During last month's beta testing of an upcoming software 
release, it was discovered (by a participating early tester at a *large* 
government installation) that the software no longer worked _at all_ 
with a 24x80 screen. Nobody here ever noticed!



When logging on natively to TSO/E (not going through our Session 
Manager), I use 51x80 primary size and 62x132 alternate size.
When logging on via our Session Manager, I use 62x80 primary size and 
62x132 alternate size.

In both cases, I set the ISPF Screen Format to "1. Data"


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Tom Marchant]

This sales pitch is getting annoying.  Additional comments below.

On Tue, 16 May 2006 00:00:11 +, Dave Salt <[EMAIL PROTECTED]> wrote:

>>From: Charles Mills <[EMAIL PROTECTED]>
>>
>>The real, total cost includes:
>>
>>- Management time to evaluate, negotiate, and purchase
>
>Evaluation is usually left to be done by the people in the trenches.

Not anywhere I ever worked.
>
>>- Sysprog time to install, secure, configure, etc.
>
>Anyone can install the ISPF/PDF interface upgrade,

That depends.  Does he have a panel library that he can update?

>It doesn't take a sysprog to install it. In any case, it takes
>less than an hour to install.

Not likely, but I'll grant that you might have an easy to install
interface.  Maybe I'm a little slow, but 
>
>>- Training time. Takes no training? Really? Not even a memo to announce 
its
>>availability?
>
>No training, really. No need to announce availability; just stick an option
>on the ISPF menu.

So I install your product and I'm instantly using it like a pro?
Does that mean that I won't need to bother using your help either?

>But if you want to send a memo to announce it, I guess you
>should add about 10 minutes to the overall cost.

Hmmm...  I've already spent over ten minutes on your product and I don't 
know enough to write the memo.
>
>>- Help desk time (particularly if you scrimped on the training - some
>>people
>>can screw up anything)
>
>Help desk people absolutely love it. The phone rings, and the the help desk
>answers:
>HD:  "Hello, this is the help desk."
>Caller: "Hi, I've run out of space in my data set. What do I do?"
>HD: "Select the data set using function 'I' (Information), then overtype 
any
>attributes you want to change".
>Caller: "Great; thanks!"

I have a PDS that's compressed and full with 16 extents and
I can fix it by overtyping something on an information panel?
Not likely without some authorized code unless you're going to
allocate a new data set and copy, and that's of limited value.

>>- Cost of future maintenance
>
>$5,000 annually. No additional fees when upgrading to bigger/faster
>mainframes.
>
>>- Management time to negotiate future upgrades, etc.
>
>See above.

So you say.  I looked for Ts & Cs on the web site but couldn't find them.

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Tom Marchant]

3.4?  I abandoned 3.4 nearly ten years ago.
Now I use the ISPF workplace instead.

Tom Marchant

On Mon, 15 May 2006 20:49:15 +, Dave Salt <[EMAIL PROTECTED]> wrote:

>>Bruce A. Black wrote:
>>IMHO, its not so simple.  You are assuming that by installing such a tool,
>>it would automatically and enthusiastically be used by all or most of 
those
>>programmers.  Personally I find that inertia is a major factor.
>
>My experience is that 90% of programmers use the upgraded ISPF/PDF 
interface
>almost immediately after the new option is added to their ISPF menu. The
>other 10% eventually come around, just as they eventually came around to
>using ISPF option 3.4.

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Bruce Hewson]

I really dont care what people say, you can lead a horse to water etc.

I continue to be astonished/annoyed/aggravated etc by how many 
sysprogs/developers/operators insist on using basic Mod-2 (24x80) format 
3270 emulator screens.

It's not as if they havent been shown how to improve there work environment.

:-(


best wishes

Bruce Hewson

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Dave Salt]

From: Charles Mills <[EMAIL PROTECTED]>
As someone who has been on the vendor side of this one, let me say that
"$5000" is only a small part of the cost, and if you do your cost
justification based on that, then any perceptive manager is going to give
you a thumbs down.

The real, total cost includes:

- Management time to evaluate, negotiate, and purchase


Evaluation is usually left to be done by the people in the trenches. While 
programmers are using it to get their regular day to day tasks done, they're 
being more productive. So, the cost to the company is none. Instead, the 
company is actually saving time and money while the free trial evaluation is 
being conducted.



- Sysprog time to install, secure, configure, etc.


Anyone can install the ISPF/PDF interface upgrade, even a junior application 
developer with no authority to update anything but their own personal 
libraries. It doesn't take a sysprog to install it. In any case, it takes 
less than an hour to install.



- Training time. Takes no training? Really? Not even a memo to announce its
availability?


No training, really. No need to announce availability; just stick an option 
on the ISPF menu. But if you want to send a memo to announce it, I guess you 
should add about 10 minutes to the overall cost.


- Help desk time (particularly if you scrimped on the training - some 
people

can screw up anything)


Help desk people absolutely love it. The phone rings, and the the help desk 
answers:

HD:  "Hello, this is the help desk."
Caller: "Hi, I've run out of space in my data set. What do I do?"
HD: "Select the data set using function 'I' (Information), then overtype any 
attributes you want to change".

Caller: "Great; thanks!"

HD: "Hello, this is the help desk".
Caller: "I accidentally deleted/corrupted a data set. What do I do?"
HD: "Select the dataset using function 'H' (HSM) and select the backup you 
want to recover from the displayed list."

Caller: "Great; thanks!"


- Cost of future maintenance


$5,000 annually. No additional fees when upgrading to bigger/faster 
mainframes.



- Management time to negotiate future upgrades, etc.


See above.


- Risk that you raise future maintenance charges, upgrade charges, etc.


Built into the contract; no risk.


- Risk that the product causes conflicts/problems with a critical system
(yeah, you know it won't, but that pointy-headed boss sees that as a
salesman promise)


None.


- Other undefined risks (a BIG deal in big corporations - nobody ever got
fired for NOT buying your product)


Compared to the risk of not using a product that dramatically increases 
productivity, while your competitors do use it? None.



I'm not putting down your product. I'm just telling anyone cost-justifying
it to their management to be sure to include ALL the costs.


I understand, and I'm not putting down your comments. If a company is buying 
a product that costs half a million bucks, they should seriously do all the 
things you've suggested and of course the cost of doing that needs to be 
taken into consideration. But installing a product that takes less than an 
hour to install, can be tried for free, and can be purchased for money that 
some companies keep in their petty cash drawer, shouldn't raise the cost by 
any tangible amount.



Frankly, you might consider raising your prices! As the above cost to the
customer may well exceed $100,000, it's a shame the authors/IP owners are
only getting 5% of that!


$5,000 is an introductory price, and it will go up. But customers who get it 
at the introductory price won't be expected to pay the higher price when it 
eventually goes up. Note that I use the word 'price' and not 'cost'; the 
product is designed to save hundreds of thousands or even millions of 
dollars a year, so it doesn't really 'cost' anything.


Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Charles Mills]

As someone who has been on the vendor side of this one, let me say that
"$5000" is only a small part of the cost, and if you do your cost
justification based on that, then any perceptive manager is going to give
you a thumbs down.

The real, total cost includes:

- Management time to evaluate, negotiate, and purchase
- Sysprog time to install, secure, configure, etc.
- Training time. Takes no training? Really? Not even a memo to announce its
availability?
- Help desk time (particularly if you scrimped on the training - some people
can screw up anything)
- Cost of future maintenance
- Management time to negotiate future upgrades, etc.
- Risk that you raise future maintenance charges, upgrade charges, etc.
- Risk that the product causes conflicts/problems with a critical system
(yeah, you know it won't, but that pointy-headed boss sees that as a
salesman promise)
- Other undefined risks (a BIG deal in big corporations - nobody ever got
fired for NOT buying your product)

I'm not putting down your product. I'm just telling anyone cost-justifying
it to their management to be sure to include ALL the costs.

Frankly, you might consider raising your prices! As the above cost to the
customer may well exceed $100,000, it's a shame the authors/IP owners are
only getting 5% of that!

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Dave Salt
Sent: Monday, May 15, 2006 1:49 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)


>Bruce A. Black wrote:
>IMHO, its not so simple.  You are assuming that by installing such a tool, 
>it would automatically and enthusiastically be used by all or most of those

>programmers.  Personally I find that inertia is a major factor.

My experience is that 90% of programmers use the upgraded ISPF/PDF interface

almost immediately after the new option is added to their ISPF menu. The 
other 10% eventually come around, just as they eventually came around to 
using ISPF option 3.4. Human nature is such that if a tool is not only far 
more powerful than whatever they were using before, but is also far easier 
to use, inertia is quickly overcome.

To cite examples from two ends of the spectrum, there is one shop with 1,000

programmers and all 1,000 programmers use the upgraded ISPF/PDF interface. 
There is another shop with 20 programmers and all 20 programmers use the 
upgraded interface. Given that usage is strictly voluntary and no-one at 
either site went on any training courses whatsoever, this is a pretty 
remarkable achievement.

--
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

Re: Cost of tools

[Steve Comstock]

Dave Salt wrote:
[snip]
I sympathize, I really do. I've encountered management like that before, 
and unfortunately they seem to be becoming more and more commonplace. In 
my experience, you have to sit them down and talk to them very gently to 
make them understand how buying something can actually save money. For 
example, a conversation might go like this:



[snip]

Wow. Your conversations go better than mine!

Me: I'd like to save your people months of
reading, trial and error, and hard work
to learn some skills they need now,
giving them some actual hands-on experience
in (topic_x) on your own system!

Prospect: go away.


hmmm.


Kind regards,

-Steve Comstock

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Shane]

Dave is a bit evangelical - nothing wrong with that I guess as, like the
rest of us, he has to eat.
I'm a little in agreement with John; seems it's getting harder to get
the bucks spent (initially). As I've said before, sometimes I wonder how
ISVs survive at all - especially the smaller/newer ones.

For myself, I stay handy with the minimal "standard set" of utilities I
need to do my job. I go into a reasonable number of different sites, and
sometimes for only a short while. Expecting them to have my favourite
tool(s) is generally a forlorn hope.
Even getting access to something handy can be a problem sometimes - like
the cbt site, or Marks handy REXX.
Sometimes you just have to work with what you have. Nothing new there.

Shane ...

--
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

Re: Cost of tools

[Dave Salt]

From: "McKown, John" <[EMAIL PROTECTED]>
Around here if it
cannot be shown to actually save "hard" dollars, it is unlikely to be
"bought into" by management.



I sympathize, I really do. I've encountered management like that before, and 
unfortunately they seem to be becoming more and more commonplace. In my 
experience, you have to sit them down and talk to them very gently to make 
them understand how buying something can actually save money. For example, a 
conversation might go like this:


YOU: I'd like permission to buy a new software tool that upgrades the 
ISPF/PDF interface.


BOSS: How much does it cost?

YOU: $5,000.

BOSS: What's wrong with the interface we have now?

YOU: It's slow, cumbersome, difficult to learn and use, and very 
unproductive.


BOSS: But it works though, right? I'm sorry, but if what we've got works 
then we don't need to spend money to buy something extra.


YOU: But with 100 developers using it, it would save our company more than a 
million dollars a year. Isn't it worth spending $5,000 to save a million?


BOSS: Maybe so, but the budget is tight right now. Where would we get $5,000 
from?


YOU: We're planning to hire 500 new people for the call center, and each of 
them will have a PC on their desk. If we don't buy them a mouse, it will 
save more than $5,000.


BOSS: But a mouse is critical; you can't use a PC without a mouse!

YOU: Actually, you can. It's hard, and it takes some training, but it can be 
done.


BOSS: But wouldn't productivity go down?

YOU: Yes, I'm afraid it would.

BOSS: Well that's no good. If each call takes longer to deal with than it 
needs to, it will end up costing us money, not saving money.


YOU: Wow, you're smart. You're saying that spending a little bit of extra 
money to improve productivity saves even more money in the long run!


BOSS: Yes, exactly. That's why I'm the boss.

YOU: Wow, I see what you mean. So, would it make sense to spend $5,000 to 
upgrade the ISPF interface and save the company a million dollars a year?


BOSS: Of course it would. And $5,000 is so low I can spend it without even 
having to go further up the chain to get approval.


YOU: Wow boss, thanks. You're the best!



Feel free to print this and use it when you go in to ask your boss for 
$5,000.   :-)



Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Salt
> Sent: Monday, May 15, 2006 3:49 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Cost of tools (was: Migrating from OPS/MVS to 
> AF/OPERATOR)
> 
> 



> competitiors, but they're 
> using far less effort to accomplish it. The value of a happy 
> and content 
> work-force is difficult to measure in a monetary sense, but 
> should not be 
> underestimated.
> 

I don't disagree with the above, personally. But around here if it
cannot be shown to actually save "hard" dollars, it is unlikely to be
"bought into" by management.

Example: Due to license upgrade fees, we replaced Compuware's Xpeditor
and AbendAid with CA's Intertest and Symdump. Hard dollar cost is down.
Programmer productivity is also down. The "hard dollars" trumped
productivity. The, now ex-, manager who made this decision basically
said that if the programmers wanted something other than the CA
products, they could either take a pay cut equivalent to the cost
difference or tell him who to fire to make up the cost difference.
Current management (big shake up soon after all this) may be more open.
Or not. I don't really know yet. 



> Dave Salt
> SimpList(tm) - The easiest, most powerful way to surf a mainframe!
> http://www.mackinney.com/products/SIM/simplist.htm



--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Dave Salt]

Bruce A. Black wrote:
IMHO, its not so simple.  You are assuming that by installing such a tool, 
it would automatically and enthusiastically be used by all or most of those 
programmers.  Personally I find that inertia is a major factor.


My experience is that 90% of programmers use the upgraded ISPF/PDF interface 
almost immediately after the new option is added to their ISPF menu. The 
other 10% eventually come around, just as they eventually came around to 
using ISPF option 3.4. Human nature is such that if a tool is not only far 
more powerful than whatever they were using before, but is also far easier 
to use, inertia is quickly overcome.


To cite examples from two ends of the spectrum, there is one shop with 1,000 
programmers and all 1,000 programmers use the upgraded ISPF/PDF interface. 
There is another shop with 20 programmers and all 20 programmers use the 
upgraded interface. Given that usage is strictly voluntary and no-one at 
either site went on any training courses whatsoever, this is a pretty 
remarkable achievement.


Big shop or small shop, it makes no difference. Within the first 10 minutes 
of using the new interface, programmers are far more productive than they 
ever were using the regular ISPF/PDF interface. As the tool is much easier 
to learn and use than regular ISPF, training costs go down, not up. By 
increasing productivity and reducing training costs, companies that use the 
upgraded ISPF/PDF interface are saving themselves a small fortune. Not only 
is their work-force far more productive than their competitiors, but they're 
using far less effort to accomplish it. The value of a happy and content 
work-force is difficult to measure in a monetary sense, but should not be 
underestimated.


The way I see it, there are 3 types of companies:

1) Those that can afford to pour money down the drain.
2) Those that believe that buying the absolute minimum saves money.
3) Those that understand the ultimate key to success is productivity, and 
that spending a little to save a lot is an absolute no-brainer.


Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm





By the same stroke, I was at a shop where programmers were forced to use 
the regular ISPF/PDF interface. Watching them work was excruciatingly 
painful. They had about 120 programmers, which (at a conservative estimate 
of $100,000 annual cost per programmer), would have cost the company at 
least TWELVE MILLION DOLLARS A YEAR! When you're talking about numbers as 
big as this, anything that can be done to improve productivity pays 
ENORMOUS dividends.


For five thousand dollars (i.e. about 0.04% of that amount, or 5% of the 
cost of hiring a single new programmer), they could have given their 
programmers a far more powerful interface. This would have taken less than 
an hour to do, and would have made all of their programmers roughly 10% 
more productive. Do the math.


Even for a shop with only 1 programmer, upgrading the ISPF/PDF interface 
should be a no-brainer. Yet there are many companies out there who still 
use the same basic interface their programmers were using in the 1980's. 
And this is only one example of how companies can same vast amounts of 
money. It's why I contend that NOT buying tools wastes far more money than 
is ever wasted by buying them.




--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Bruce Black]

By the same stroke, I was at a shop where programmers were forced to 
use the regular ISPF/PDF interface. Watching them work was 
excruciatingly painful. They had about 120 programmers, which (at a 
conservative estimate of $100,000 annual cost per programmer), would 
have cost the company at least TWELVE MILLION DOLLARS A YEAR! When 
you're talking about numbers as big as this, anything that can be done 
to improve productivity pays ENORMOUS dividends.


For five thousand dollars (i.e. about 0.04% of that amount, or 5% of 
the cost of hiring a single new programmer), they could have given 
their programmers a far more powerful interface. This would have taken 
less than an hour to do, and would have made all of their programmers 
roughly 10% more productive. Do the math.


Even for a shop with only 1 programmer, upgrading the ISPF/PDF 
interface should be a no-brainer. Yet there are many companies out 
there who still use the same basic interface their programmers were 
using in the 1980's. And this is only one example of how companies can 
same vast amounts of money. It's why I contend that NOT buying tools 
wastes far more money than is ever wasted by buying them. 
IMHO, its not so simple.  You are assuming that by installing such a 
tool, it would automatically and enthusiastically be used by all or most 
of those programmers.  Personally I find that inertia is a major factor. 

We are a relatively small development shop, so we don't spend on 
external software without a good reason.   We have a variety of tools to 
enhance our ISPF experience, some from CBT and other sources (e.g., the 
PDS command), some home-grown, but in my experience only a small 
percentage of our programmers make effective use of them.  Many can't be 
bothered to take the time to learn to use the tools and would rather 
"get on with the job" even if it means more work in the long run. 

Use of a new or enhanced environment often requires education, periodic 
re-education (to remind them of the functions they never took time to 
learn) and proselytizing by some cadre of proponents. 


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
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

Re: Cost of tools (was: Migrating from OPS/MVS to AF/OPERATOR)

[Dave Salt]

From: "Eric N. Bielefeld" <[EMAIL PROTECTED]>
I think that this is one of those areas where the real answer is it 
depends. Every shop is different.  I know at P&H we had a lot of software 
that was brought in, and then sat around unused.


By the same stroke, I was at a shop where programmers were forced to use the 
regular ISPF/PDF interface. Watching them work was excruciatingly painful. 
They had about 120 programmers, which (at a conservative estimate of 
$100,000 annual cost per programmer), would have cost the company at least 
TWELVE MILLION DOLLARS A YEAR! When you're talking about numbers as big as 
this, anything that can be done to improve productivity pays ENORMOUS 
dividends.


For five thousand dollars (i.e. about 0.04% of that amount, or 5% of the 
cost of hiring a single new programmer), they could have given their 
programmers a far more powerful interface. This would have taken less than 
an hour to do, and would have made all of their programmers roughly 10% more 
productive. Do the math.


Even for a shop with only 1 programmer, upgrading the ISPF/PDF interface 
should be a no-brainer. Yet there are many companies out there who still use 
the same basic interface their programmers were using in the 1980's. And 
this is only one example of how companies can same vast amounts of money. 
It's why I contend that NOT buying tools wastes far more money than is ever 
wasted by buying them.


Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm





I just wanted to point out that a lot of money is "wasted" on products 
that are

unnecessary, for a lot of reasons, and that sites need to stay on top of
what they are paying for.



While I don't disagree, I believe far more money is wasted by NOT buying 
products than will ever be wasted by buying them.


Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm




--
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