Fwd: iSeries marketing request at Common Lug Luncheon (fwd)

--
--
[ Picked text/plain from multipart/alternative ]
"jt"

You have a special talent for babbling. Is there anyway to keep it NET or off
the   internet  You continue to bombard these lists with long note and
shallow content.

Sit back and enjoy whatever is exciting in Columbus OH

When was the last time you went to COMMON?
Are you going this time?

From: "jt" <jt@ee.net>
To: <midrange-l@midrange.com>
Subject: RE: CA client code location (was RE: Oh where has my disk space
gone?
Reply-To: midrange-l@midrange.com
Date: Sun, 18 Nov 2001 09:01:26 -0500

Tom,

Thanks.

I seriously question one statement you wrote "NT servers are pretty common
in the same network and necessary skills aren't hard to come by."  I
actually agree, completely, with what you've said, and this is obviously one
of the prime selling points of NT.  I think it's a question of how you
define "necessary skills".  One of the, maybe subtle, points I've been
writing about (or maybe around...;-) is that NT hasn't existed long enough
for those poor sods to have accumulated anything close to the kind of wisdom
that I see here on this list daily.

Plenty of technical folks in the NT world.  I don't think that suffices.
The strength of 400 people, or a fair number of them, is that rare
combination of people skills, technical skills and business skills.  I
shouldn't imply that acquiring these skills takes a lifetime.  But I've
worked with plenty of 400 folks who were extremely technical, but to a
degree, ineffective.  Great code is just fluff, IMHO, if it doesn't produce
a competitive advantage for the employer/client.  Great code is just fluff,
if it doesn't effectively solve a business problem.  (I'm thinking of a
follow-up to your insights on the SPLF thread, as an example.)

I /have/ noticed that this combination of people, technical and business
skills seems to be fairly common amongst people on this list here, and it
appears most of these people have 10, 15, 20 and even more, years of
experience.  I think there are a number of things working against this in
the NT world, but primary is that these folks (from my POV) frequently don't
appear to have made it all the way "around the block", so to speak.

One thing the 400 and NT have in common is being used in smaller companies.
I think folks who've worked in smaller shops and/or management have, by
necessity, learned to wear many hats.


I see the technical points you made below.  You wrote "I'm not sure how many
CA client PTFs are ever included in cume packages any more."  I was working
on the assumption they *all* were.  Not so...?

jt

> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [<A 
>HREF="mailto:midrange-l-admin@midrange.com%5DOn">mailto:midrange-l-admin@midrange.com]On</A>
> Behalf Of thomas@inorbit.com
> Sent: Sunday, November 18, 2001 12:52 AM
> To: midrange-l@midrange.com
> Subject: CA client code location (was RE: Oh where has my disk space
> gone? )
>
>
> jt:
>
> On Sat, 17 November 2001, "jt" wrote:
>
> > Is there disadvantages to centralizing CA updates on the 400?
> (Other than
> > cost of DASD.)
>
> Uh... I suppose. The obvious advantage is that it's "centralized"
> -- single point and style of management, standard centralization
> advantages. Very handy when the AS/400 is your only server. I'm
> just not sure how many people care anymore; NT servers are pretty
> common in the same network and necessary skills aren't hard to
> come by. And the argument can easily be made that because it is
> client code, it should be 'centralized' along with other PC
> clients and applications -- on a PC server.
>
> Besides simple space, I've personally never been happy to share
> my I/O adapter for code updates, especially dozens or hundreds of
> 20-60MB downloads; it's enough of a bottleneck at times without
> adding more.
>
> I'd be glad to hear others' experiences with how best to handle
> it. Once I've figured out which LPPs can be removed, I've had no problems.
>
> In any case, after thinking about it (you know, in that
> split-second between hitting <Send> and seeing the confirmation),
> I'm not sure how many CA client PTFs are ever included in cume
> packages any more. Might not even have been a good example.
>
> Tom Liotta
>
> >
> > > -----Original Message-----
> > >
> > > On Thu, 15 November 2001, rob@dekko.com wrote:
> > >
> > > > Hey, you wouldn't be fixing anything if you didn't know it was
> > > broke would
> > > > you?  Perhaps you ARE using it?
> > >
> > > Not necessarily. The various Client Access client LPPs are an
> > > example. Many iSeries and AS/400 systems have these installed on
> > > the server but don't need them there because the clients are
> > > installed from CD or from another, usually NT, server in the
> > > network as are the service packs. But because they are installed
> > > on the iSeries/AS400, cume PTFs apply fixes that often have no
> > > useful point. (Note that this is separate from fixes to the
> > > server-side code, the host servers, etc.) Not only space but time
> > > as well is wasted.
>
> --
> Tom Liotta
> The PowerTech Group, Inc.
> 19426 68th Avenue South
> Kent, WA 98032
> Phone  253-872-7788
> Fax  253-872-7904
> <A HREF="http://www.400security.com/">http://www.400Security.com</A>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list





--
From: "jt" <jt@ee.net>
To: <midrange-l@midrange.com>
Subject: RE: iSeries marketing request at Common Lug Luncheon (fwd)
Importance: Normal
In-Reply-To: <Pine.SV4.3.96.1011118090548.29440G-100000@saltmine.radix.net>
Sender: midrange-l-admin@midrange.com
Precedence: bulk
Reply-To: midrange-l@midrange.com
Date: Sun, 18 Nov 2001 09:37:32 -0500

Don,

Thanks for the question, and hope you don't mind my "cutting in" in Brad.

>From the thing I just posted.

"===> IMV, the iNation is just an organized way of going about stuff like
this.  It's a mindset for implementing these kinds of ideas.  It's a vehicle
for ***IBM paying back the Community for it's support***."

So what I'm saying is that IMV (in my opinion, or IOW according to my view
of the situation) customers can market more effectively than IBM can.  It's
a question of which is more effective.  IMV, word of mouth is more effective
than a big marketing budget.

The advantage to the iSeries Community for doing this marketing for IBM is
twofold.

1) The entire iCommunity "boat" will float higher if the "ocean" gets
larger.
2) IBM might (emphasis on ***might***) be willing to fund the iNation with a
bigger budget.

BTW, do you think this thread belongs over on the iSN-Citizens list?  I'll
cross-post this there, and will reply wherever.

jt




> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Don
> Sent: Sunday, November 18, 2001 9:08 AM
> To: midrange-l@midrange.com
> Subject: iSeries marketing request at Common Lug Luncheon (fwd)
>
>
>
>
> Brad,
>
> And once again you'ld be doing what IBM should be doing....MARKETING THE
> iSERIES....
>
> So, tell me why should I be doing, FOR IBM, what they're to ashamed to do
> for themselves?
>
> -------
>
>
>
> On Sun, 18 Nov 2001, Brad Jensen wrote:
>
> >
> > ----- Original Message -----
> > From: "jt" <jt@ee.net>
> > To: <midrange-l@midrange.com>
> > Sent: Wednesday, November 14, 2001 11:30 PM
> > Subject: RE: [Interlug] Re: iSeries marketing request at Common
> > Lug Luncheon (fwd)
> >
> >
> > > This is a succinct summary of my as-yet unwritten part 3 of
> > yesterdays
> > > posts:
> >
> >
> > The best way to advertise the ISeries is for all of you to tell
> > all of your customers and the friends you meet at trade
> > associations that you are using ISeries and love it. Stick it in
> > your email tag line with a link back to IBM.
> >
> > My server can beat up your server
> >
> > etc.
> >
> >
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.