|
-- -- [ 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
