× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Using RISC as development, sending to CISC. Any problems forseen?
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Thu, 2 Jul 1998 11:01:07 -0500

Being the origniator of this post, I should point out that we are
converting from a 30S to a 50S.

Bradley V. Stone        
bvstone@taylorcorp.com
http://prairie.lakes.com/~bvstone/
"Closing my mouth before I scream.  No one can shake my self-esteem."
-YJM


> -----Original Message-----
> From: Bob Crothers [SMTP:bob@cstoneindy.com]
> Sent: Thursday, July 02, 1998 3:54 AM
> To:   'MIDRANGE-L@midrange.com'
> Subject:      RE: Using RISC as development, sending to CISC.  Any
> problems forseen?
> 
> Vernon,
> 
> You raise a good point that I should have brought out in my first 
> post:
> 
> >> So long as a shop can stay within the design parameters of a server
> 
> box<<
> 
> This is even more important with the server models than a normal 
> AS/400.
> 
> I think many have purchased server models without considering the 
> design parameters of the box.  A previous employer of mine purchased a
> 
> 50S for a production system (against my recommendations).  The machine
> 
> screamed for the first 6 months.  Then they went on a hiring binge and
> 
> went from 100 users to 200.  Interactive load went up (a lot).  CFINT1
> 
> kicked in.  Machine rolled over and died.
> 
> The moral of the story: Server models are for server type tasks (HTTP,
> 
> FTP, DNS, Client/Server apps, ODBC, etc)!. Or cheap compile engines. 
>  If you run significant interactive, stay away from them.
> 
> And forget server models if you are a Synon shop.  Probably other case
> 
> tools also.
> 
> And also be careful of the twinax limitations.
> 
> Bob
> 
> -----Original Message-----
> From: Vernon Hamberg [SMTP:hambergv@goldengate.net]
> Sent: Wednesday, July 01, 1998 3:38 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: Using RISC as development, sending to CISC.  Any
> problems 
> forseen?
> 
> At 08:20 AM 7/1/1998 -0000, you wrote:
> >Actually IMHO, One of the server models makes a great development 
> box.
> >
> >What happens most on a development box?  Compiles.  In batch.  Which
> >is where the server models scream.
> 
> -snip-
> 
> >We use a 40S for a development box and are very happy with it.
> >
> >Regards,
> >Bob Crothers
> >Cornerstone Communications, LLC
> >www.faxserver401.com
> >
> >
> >
> >-----Original Message-----
> >From:        Vernon Hamberg [SMTP:hambergv@goldengate.net]
> >Sent:        Tuesday, June 30, 1998 6:45 AM
> >To:  MIDRANGE-L@midrange.com
> >Cc:  bvstone@taylorcorp.com
> >Subject:     Re: Using RISC as development, sending to CISC.  Any 
> problems
> >forseen?
> 
> -snip-
> 
> >I _would_ question using a server box like the 50S. You could get 
> poor
> >interactive performance. Admittedly it's supposed to be better now,
> >but we
> >got bit verrry badly with a 50S. If you can keep your interactive CPU
> 
> >% <
> >10%, you'll probably be OK.
> 
> Server boxes _can_ definitely be a lower cost solution for 
> development.
> They _can_ also be an unmitigated disaster. It all depends. In our 
> case,
> under normal, orthodox operating conditions, our interactive load 
> simply
> rose too high, too often, for a server box to work in our environment.
> 
> I
> think they still have the 7-session twinax limit. They're not intended
> 
> to
> have much interactive at all, and preferably none.
> 
> So long as a shop can stay within the design parameters of a server 
> box,
> it'll be fine. It simply did not work for us, trying to run 10-15
> developers, help desk, etc., on a server box.
> 
> Cheers
> 
> Vernon Hamberg
> Systems Software Programmer
> Old Republic National Title Insurance Company
> 400 Second Avenue South
> Minneapolis, MN  55401-2499
> (612) 371-1111 x480
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: 
> david@midrange.com
> +---
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.