Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 04/03/2006 at 09:07 PM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said: >However, this still leaves me confused over IBM's constant reference >to blocking and reblocking of load modules. Does this make the >authors as stupid as me? The authors regard the csect as the

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 04/02/2006 at 02:31 PM, Gerhard Postpischil <[EMAIL PROTECTED]> said: >RLD, CESD, IDR, etc. are all control records - you're just haggling >over the price Then how do you distinguish CTL from the others? -- Shmuel (Seymour J.) Metz, SysProg and JOAT IS

Re: 3380-3390 Conversion - DISAPPOINTMENT

Ron and Jenny Hawkins wrote: However, this still leaves me confused over IBM's constant reference to blocking and reblocking of load modules. Does this make the authors as stupid as me? Only in being confused by the language - when they refer to "blocking" of load modules, they are referring t

Re: 3380-3390 Conversion - DISAPPOINTMENT

Gerhard/Shmuel, Where ever the reference I had to Text records splitting on instruction boundaries is, I can no longer find. This may be another senior moment! References I've found all reference CSECT boundaries as a point to terminate text records. So I consider myself better educated. However

Re: 3380-3390 Conversion - DISAPPOINTMENT

Shmuel Metz (Seymour J.) wrote: There is one record type limited to 256 bytes, and that's the control record; There are others, e.g., RLD. RLD, CESD, IDR, etc. are all control records - you're just haggling over the price Gerhard Postpischil Bradford, VT ---

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 04/01/2006 at 04:22 PM, Gerhard Postpischil <[EMAIL PROTECTED]> said: >There is one record type limited to 256 bytes, and >that's the control record; There are others, e.g., RLD. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 04/01/2006 at 04:45 PM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said: >To follow your way of thinking there is only one text record which is >simply, broken up into pieces on Blocksize and track boundaries, >ignoring the instruction records within the block. That d

Re: 3380-3390 Conversion - DISAPPOINTMENT

Ron and Jenny Hawkins wrote: Seymour, To follow your way of thinking there is only one text record which is simply, broken up into pieces on Blocksize and track boundaries, ignoring the instruction records within the block. The reality is that the linkage editor and Copymod are processing Instru

Re: 3380-3390 Conversion - DISAPPOINTMENT

change the performance of fetch, or the size of a loadlib. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Shmuel Metz (Seymour J.) > Sent: Wednesday, 29 March 2006 10:11 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: 33

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 03/29/2006 at 12:35 AM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said: >No I'm not. Then where do you get the idea that the number 256 has anything to do with text record sizes? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: 3380-3390 Conversion - DISAPPOINTMENT

>With that many TXT records, I don't understand why one would use other than 1/2 trk blocking (27998 for "3390")? You missed a point (or two). The block is undefined. The block size is the maximum size a txt record can be. TXT records can be longer than 'regular' records. With today's DASD price

Re: 3380-3390 Conversion - DISAPPOINTMENT

ck and less than the maximum. But you would eliminate an I/O now and then, and *every* I/O counts. My 0.02USD -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Talman Sent: Tuesday, March 28, 2006 10:47 AM To: IBM-MAIN@BAMA.UA.EDU Su

Re: 3380-3390 Conversion - DISAPPOINTMENT

Since this thread will not die, I would like to comment about the various opinions on blksize of loadlibs. Our large production loadlibs (>10,000 trks used) contain mostly Cobol modules that support various combinations of DB2 IMS CICS MQ. The module sizes vary downward from X'35' - about

Re: 3380-3390 Conversion - DISAPPOINTMENT

No I'm not. > > No, because text records are *not* limited to 256 bytes. You're > confusing them with other records, e.g., Control, RLD. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 03/28/2006 at 01:57 AM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said: >The text blocks appear as a continuous byte stream, but this is the >unformatted representation of the text records, where each record is >machine instruction. I'm not sure what you're trying to

Re: 3380-3390 Conversion - DISAPPOINTMENT

Adam, I certainly wouldn't be leading a crusade to reblock load libraries to save space either. In most shops they make up a very small percentage of the total space. I'm more interested in good practices when creating a loadlib. I have always reblocked active load libraries, with some quantifiab

Re: 3380-3390 Conversion - DISAPPOINTMENT

Seymour, The text blocks appear as a continuous byte stream, but this is the unformatted representation of the text records, where each record is machine instruction. It's probably a case of semantics and/or context as to whether text in an object is a block of machine instructions, or a record u

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 03/24/2006 at 11:27 AM, Gerhard Adam <[EMAIL PROTECTED]> said: >Single CSECT load modules are almost never large enough to use the >maximum (32760) since that would require 8 base registers, No it wouldn't. You're making un warranted assumptions about what is in the

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 03/25/2006 at 01:16 PM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]> said: >But you can have any number of CCWs, each transferring 65,535 bytes >and using data chaining, to make a much larger block than 64K. As long as your channel is fast enough to avoid

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 03/25/2006 at 10:41 AM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said: >The Text records may be 256 bytes, but they are blocked, and the >Blocksize of the "text" block will be up to the blksize of the >loadlib. WTF? Everything *but* text records is 256 bytes, and no

Re: 3380-3390 Conversion - DISAPPOINTMENT

In <[EMAIL PROTECTED]>, on 03/24/2006 at 08:13 PM, John Eells <[EMAIL PROTECTED]> said: >There are three kinds of blocks: Fixed, Variable, and Undefined. I realize that it doesn't get much[1] use, but there is a fourth type of block. Is it restricted to tape? [1] Actually, I wouldn't guaranty

Re: Contract Programmers (Was: 3380-3390 Conversion)

In <[EMAIL PROTECTED]>, on 03/22/2006 at 07:49 AM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said: >In my current job heading up R&D here, I have had mostly bad >experiences with contract programmers. I think many people adopt a >different attitude about a project when they know they won't be >ar

Re: 3380-3390 Conversion - DISAPPOINTMENT

Thanks Eric for taking the time to explain and provide me samples of your jcls. I will look them over and should I have any questions could I kindly impose upon your good offices? As you can see it is Saturday night and I am working. Such is the life as we have ALL have done. P.S. I thi

Re: 3380-3390 Conversion - DISAPPOINTMENT

In a message dated 3/24/2006 7:13:27 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Excellent basic primer on records and blocks. A few comments for the more advanced user: >each physical record on tape and DASD ... >... >The hardware limit is established by the Count fields in b

Re: 3380-3390 Conversion - DISAPPOINTMENT

Ron: You are correct that the library will typically use less space, however ... This is very much dependent on the size of the CSECTS within it. I don't have a problem with the assertion that 32760 results in larger TXT blocks being written, but unless you have a library that has such la

Re: 3380-3390 Conversion - DISAPPOINTMENT

Adam, Yes there are a few RLD, ESC, etc records and they are LE 256 bytes. However this does not affect the blocking of the text blocks. If, after writing a few small records a track has space remaining for a text block up to the Max block size then it will use the max block size. If the remain

Re: 3380-3390 Conversion - DISAPPOINTMENT

John, what a great post! thorough, well-organized, mostly easy to understand. You should consider getting a version added to the Using Data Sets manual, or at least published as a TechNote. A point you might want to add: For PDSs there is an additional track utilization issue and that is the

Re: 3380-3390 Conversion - DISAPPOINTMENT

>The Text records may be 256 bytes, but they are blocked, and the Blocksize of the "text" block will be up to the blksize of the loadlib. >Two verifications: >1) Browse any medium size load module in you load libraries and page right. Browse reads the modules as a recfm=u file, and you will see te

Re: 3380-3390 Conversion - DISAPPOINTMENT

Gerhard, The Text records may be 256 bytes, but they are blocked, and the Blocksize of the "text" block will be up to the blksize of the loadlib. Two verifications: 1) Browse any medium size load module in you load libraries and page right. Browse reads the modules as a recfm=u file, and you will

Re: 3380-3390 Conversion - DISAPPOINTMENT

** Very long post warning * I thought I'd posted this before, but didn't see it in the archives. This was originally written as a post to IBM's internal software packaging forum on the topic of block sizes to recommend for different system software data sets.

Re: 3380-3390 Conversion - DISAPPOINTMENT

On Mar 24, 2006, at 3:57 PM, Steve Arnett wrote: Ed Gould wrote: On M John, Had not heard about that parm before. I looked it up and it was as clear as mud... (ok dark bear). It is obviously Friday! How much clearer is a light bear? Enough to see a face on the other side of the mug:

Re: 3380-3390 Conversion - DISAPPOINTMENT

On Mar 24, 2006, at 12:00 AM, Ted MacNEIL wrote: except for SAS SAS went to strictly PS files with V6 (I think) and relative record/ block access. The issue from BDAM files disappeared in the conversion from 3380 to 3390, except for space. Then they dropped support for BDAM in V8. - -teD

Re: 3380-3390 Conversion - DISAPPOINTMENT

>except for SAS SAS went to strictly PS files with V6 (I think) and relative record/block access. The issue from BDAM files disappeared in the conversion from 3380 to 3390, except for space. Then they dropped support for BDAM in V8. - -teD I’m an enthusiastic proselytiser of the universal pan

Re: 3380-3390 Conversion - DISAPPOINTMENT

Ed Gould wrote: On M John, Had not heard about that parm before. I looked it up and it was as clear as mud... (ok dark bear). It is obviously Friday! How much clearer is a light bear? -- For IBM-MAIN subscribe / signoff

Re: 3380-3390 Conversion - DISAPPOINTMENT

On Mar 24, 2006, at 8:23 AM, John Eells wrote: SNIP--- Also, to avoid RC4s from COPYMOD that would make a duly diligent sysprog from looking at (and up) messages that don't matter, always use PARM=SPCLCMOD with COPYMOD. John, Had not heard about that

Re: 3380-3390 Conversion - DISAPPOINTMENT

Willie, I'll try to answer all of your questions. I'll do this one from the listserve web site, as it doesn't time out like my Roadrunner Email account does when I take a little too long to reply. I found some of my old JCL, so I'll cut and paste that for the catalog moves. 1. I think all of th

Re: 3380-3390 Conversion - DISAPPOINTMENT

>Yes, but While IBM has been preaching 32760 for loadlibs and system- >determined blocksizes for other libraries, it has also been churning out some Program Directories that have not been rewritten for decades, with BLKSIZE= >6144 for loadlibs, 3200 for LRECL=80 datasets, etc. And some peop

Re: 3380-3390 Conversion - DISAPPOINTMENT

On Fri, 24 Mar 2006 09:23:12 -0500, John Eells <[EMAIL PROTECTED]> wrote: >... >> IBM has been recommending BLKSIZE=32760 for load libraries for at least >> a decade. > > >Absolutely true for system software load libraries. ... Yes, but While IBM has been preaching 32760 for loadlibs and

Re: 3380-3390 Conversion - DISAPPOINTMENT

>There are many ways to produce a single CSECT of only one module that uses >only one base register at any one time. It begs the question, since the issue isn't whether it can be done, but whether it would be considered a typical size for a load module. Adam ---

Re: 3380-3390 Conversion - DISAPPOINTMENT

In a message dated 3/24/2006 1:29:56 P.M. Central Standard Time, [EMAIL PROTECTED] writes: >Single CSECT load modules are almost never large enough to use the maximum >(32760) since that would require 8 base registers, so the only load modules >that would produce TXT large enough to take

Re: 3380-3390 Conversion - DISAPPOINTMENT

I don't understand your comment. COPYMOD has always adjusted the size of text blocks to optimally fill the track, so in actual fact 32760 for load libraries will sell less DASD, not more. I don't understand the issue. Load libraries have an undefined record format precisely because the major

Re: 3380-3390 Conversion - DISAPPOINTMENT

eekend. Eric Bielefeld Sr. Systems Programmer P&H Mining Equipment 414-671-7849 Milwaukee, Wisconsin - Original Message - From: willie bunter Date: Thursday, March 23, 2006 7:13 pm Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT To: IBM-MAIN@BAMA.UA.EDU > Hi, > > I was th

Re: 3380-3390 Conversion - DISAPPOINTMENT

Ed, I don't understand your comment. COPYMOD has always adjusted the size of text blocks to optimally fill the track, so in actual fact 32760 for load libraries will sell less DASD, not more. Ron > >> > Sell that DASD? > -- F

Re: (fwd) RE: Contractor vs. employee was RE: 3380-3390 Conversion

In addition to the 'Contractor vs. employee' split there is also the 'professional vs "company man"' comparison Do I do what is best for the people who cut my check, could be a widget maker or a consultant body shop. example: An Enron person going to any length to make his firm look good Do I do

Re: 3380-3390 Conversion - DISAPPOINTMENT

Bielefeld Sr. Systems Programmer P&H Mining Equipment 414-671-7849 Milwaukee, Wisconsin - Original Message - From: willie bunter <[EMAIL PROTECTED]> Date: Thursday, March 23, 2006 7:13 pm Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT To: IBM-MAIN@BAMA.UA.EDU > Hi, >

Re: 3380-3390 Conversion - DISAPPOINTMENT

Yes, but this conversion happended about 20 years ago. Some of the loadlibs were still blocked for 3330. Others were blocked to numbers that made no sense at all. production control had a lot of code to handle the different blksizes but still had periodic problems (one or two a year). . It was a

Re: 3380-3390 Conversion - DISAPPOINTMENT

In a message dated 3/24/2006 6:56:41 A.M. Central Standard Time, [EMAIL PROTECTED] writes: IBM has been recommending BLKSIZE=32760 for load libraries for at least a decade. >> Sell that DASD? -- For IBM-MAIN subscribe /

Re: 3380-3390 Conversion - DISAPPOINTMENT

Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Bell [ snip ] The single biggest issue I remember was blksize on loadlibs. After much discussion, we moved them manually with copymod to set new blksizes. IBM has been recommending BLKSIZE=3

Re: 3380-3390 Conversion - DISAPPOINTMENT

> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Mike Bell > > [ snip ] > > The single biggest issue I remember was blksize on loadlibs. > After much discussion, we moved them manually with copymod to > set new blksizes. IBM has been recommending BLKSIZE=32760 fo

Re: 3380-3390 Conversion - DISAPPOINTMENT

mailto:[EMAIL PROTECTED] On Behalf Of Stephen Mednick > Sent: Friday, 24 March 2006 12:55 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT > > Willie, > > As you've said that you have FDR, take a look at Section > 80.12 ti

Re: 3380-3390 Conversion - DISAPPOINTMENT

lto:[EMAIL PROTECTED] On Behalf Of willie bunter > Sent: Friday, 24 March 2006 12:35 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT > > Thanks Mike for the info. We have FDR. I presume it should > work just the same. > > Thanks for an

Re: 3380-3390 Conversion - DISAPPOINTMENT

he thread got hi-jacked and the discussion became one about > contractors and the antagonism towards them. I am very disappointed at the > lack of professionalism. > > Again, if someone out there has any tips or information regarding > 3380-3390 conversion please, please answer back. > >

Re: 3380-3390 Conversion - DISAPPOINTMENT

d at the > lack of professionalism. > > Again, if someone out there has any tips or information regarding > 3380-3390 conversion please, please answer back. > > I apologise for my diatribe but I am desperate for help and information. > > >

Re: 3380-3390 Conversion - DISAPPOINTMENT

tips or information regarding 3380-3390 conversion please, please answer back. I apologise for my diatribe but I am desperate for help and information. - New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates

Re: (fwd) RE: Contractor vs. employee was RE: 3380-3390 Conversion

>Having read Bob Shannon's comment about contractors breaking the watch, >have I been elevated to the lofty category of consultant because I >normally didn't break the programs or system? If it weren't for Bob's >great service to SHARE and to the field, I might really get annoyed. Sorry, but I

Re: (fwd) RE: Contractor vs. employee was RE: 3380-3390 Conversion

Clark wrote: >Having read Bob Shannon's comment about contractors breaking the >watch, have I been elevated to the lofty category of consultant >because I normally didn't break the programs or system? If it weren't >for Bob's great service to SHARE and to the field, I might really get >annoyed. H

(fwd) RE: Contractor vs. employee was RE: 3380-3390 Conversion

On 22 Mar 2006 09:09:38 -0800, in bit.listserv.ibm-main [EMAIL PROTECTED] (Greg Shirey) wrote: >Let's not forget the difference between contractor & consultant: >http://bama.ua.edu/cgi-bin/wa?A2=ind0006&L=ibm-main&D=0&I=1&P=240952 > >Greg Having read Bob Shannon's comment about contractors break

(fwd) RE: Contractor vs. employee was RE: 3380-3390 Conversion

On 22 Mar 2006 09:36:09 -0800, in bit.listserv.ibm-main [EMAIL PROTECTED] (Chase, John) wrote: >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of Clark Morris >> >> [ snip ] Basically I'm decent >> at borrowing the client's watch to tell them the time. > >And ya

Re: Contract Programmers (Was: 3380-3390 Conversion)

> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Ed Gould > > [ snip ] > > Unfortunately, there is no policing done, as I agree there > should be. > I also doubt it will never be done, either. There are various > reasons as to why as well. Once upon a time, acc

Re: Contractor vs. employee was RE: 3380-3390 Conversion

> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Clark Morris > > [ snip ] Basically I'm decent > at borrowing the client's watch to tell them the time. And ya gotta remember to keep the watch after you bill the client for half the national debt, too. :-D -

Re: Contract Programmers (Was: 3380-3390 Conversion)

On Mar 22, 2006, at 10:27 AM, Richards.Bob wrote: Ed, All of my comments were about contract sysprogs. While I understand the constraints contract programmers work under, I guess that I naively hoped that personal pride and professionalism would save the day. But if the reality (and perce

Re: Contractor vs. employee was RE: 3380-3390 Conversion

Let's not forget the difference between contractor & consultant: http://bama.ua.edu/cgi-bin/wa?A2=ind0006&L=ibm-main&D=0&I=1&P=240952 Greg -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Clark Morris Sent: Wednesday, March 22, 2006 10:55 AM

Re: 3380-3390 Conversion

uary 13th 2003. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Ed Gould > Sent: Wednesday, 22 March 2006 11:27 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: 3380-3390 Conversion > > On Mar 22, 2006, at 6:37 AM, Ro

Contractor vs. employee was RE: 3380-3390 Conversion

On 22 Mar 2006 07:07:52 -0800, in bit.listserv.ibm-main [EMAIL PROTECTED] (Richards.Bob) wrote: >Ron, > >I do not understand it here either. Until the recession in 2002, both Mark >Zelden and I were contractors. I believe our clients were more than satisfied >with our level of expertise and the

Re: Contract Programmers (Was: 3380-3390 Conversion)

PROTECTED] On Behalf Of Edward E. Jaffe Sent: Wednesday, March 22, 2006 10:50 AM To: IBM-MAIN@BAMA.UA.EDU Subject:Contract Programmers (Was: 3380-3390 Conversion) Richards.Bob wrote: > I suppose that some of the contractor resentment stems from the fact that the > local staff may

Contract Programmers (Was: 3380-3390 Conversion)

Richards.Bob wrote: I suppose that some of the contractor resentment stems from the fact that the local staff may or may not have had the necessary skills or time for the project at hand, and then some "hired gun" comes in making more money than the local staff. Nature takes its course and emo

Re: 3380-3390 Conversion

On Mar 22, 2006, at 6:37 AM, Ron and Jenny Hawkins wrote: Ed Well it's a good thing I am not a contractor then, or you may dislike me. I was just wondering who have more technical cred - a currently employed contractor a retired sysprog? Ron Ron. More or less retired. I am helping ou

Re: 3380-3390 Conversion

set is not really any superior to the locals own talents. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron and Jenny Hawkins Sent: Wednesday, March 22, 2006 9:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 3380-3390 Conve

Re: 3380-3390 Conversion

Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Richards.Bob > Sent: Wednesday, 22 March 2006 8:50 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: 3380-3390 Conversion > > Ron, > > While I understand the

Re: 3380-3390 Conversion

IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron and Jenny Hawkins Sent: Wednesday, March 22, 2006 7:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 3380-3390 Conversion Ed Well it's a good thing I am not a contractor then, or you may dislike me. I was just won

Re: 3380-3390 Conversion

PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: 3380-3390 Conversion > > > > > I disliked contractors for lots of reasons. The one that > > really gets my goat is "INSTANT copy". > > > > Ed > > > > > Huh???

Re: 3380-3390 Conversion

Ed Well it's a good thing I am not a contractor then, or you may dislike me. I was just wondering who have more technical cred - a currently employed contractor a retired sysprog? Ron > > I was going to say something like well.. it takes a contractor to say > something like that but I will let

Re: 3380-3390 Conversion

> I disliked contractors for lots of reasons. The one that > really gets my goat is "INSTANT copy". > > Ed > Huh??? -- snip -- Leave it alone Steve. Otherwise we'll just stir up the whole instant copy/flashcopy/remote copy thread again. John -

Re: 3380-3390 Conversion

> I disliked contractors for lots of reasons. The one that > really gets my goat is "INSTANT copy". > > Ed > Huh??? Stephen Mednick Computer Supervisory Services Sydney, Australia -- For IBM-MAIN subscribe / signoff / arc

Re: 3380-3390 Conversion

On Mar 21, 2006, at 7:22 PM, Ron and Jenny Hawkins wrote: Ed, --SNIP- If you don't have time for the luxury of research, why not hire a contractor from WIPRO to do it. It would cost less than having a outage wouldn't it? I was going to say something like wel