|
Is there a winNT conversion from win95 available?...ie..to save a scratch install? "Genyphyr Novak" <novakg@ssax.com> on 23022000 15:01:30 Please respond to BPCS-L@midrange.com To: BPCS-L@midrange.com cc: (bcc: Anthony Jackson/North/CSI) Subject: Re: PC's Locking up when in BPCS Hi Dean, The main issue we have at SSA, is that some customers get the 'hang' and the lockup confused when calling in to HelpLine and frankly, since the causes (and resolutions therefore) are different, we consider this to be fairly important and not 'splitting hairs' ! Whether you have to get rid of duplicate records in a server file or apply a server BMR to prevent a program from looping (causing a BPCS PC application hang waiting for the server program) or apply the latest OPS Runtime Service Pack because you are getting true lockups is a real issue for the end-user and HelpLine. The OPS Runtime Service Pack is not going to resolve your application looping issue, so that is why it is important to us that we know the difference up front when analyzing the problem - we want to send you the right fix! This is why we ask everyone to ask your end-users who are complaining about a given PC 'hang' or 'freeze' problem to be as specific and detailed as possible when calling the problem in to us. Your other notes about the superiority of NT's operating system are very true, and it is true that our product is not the only one suffering this fate (I personally switched to using an NT workstation at work, and I do not use BPCS except to do testing here and there on fixes I write - I had my old Windoze 95 box lock-up when running simple 'Microserf' office applications and other non-BPCS applications, which forced me to re-boot sometimes several times in one day - I am much happier on NT because I have seen the 'blue screen of death' about 1 time in the year I have had the box). All the same, we are committed to resolving this problem for the Win95 platform - it just is taking a long time to debug and fix due to the nature of the problem and the lack of trails it leaves when it occurs. Here is a snippet of information from one of our runtime developers that goes into the technical details of why the OS on NT is a better design than WIN95 in general at handling programming errors, and what is happening 'under the covers' on NT when the true 'lockups' occur: "For the edification of the thread members, I thought I would add a short explaination of why it's much more difficult to lock up the NT OS than the Win 98/95. Windows/NT is a true protected mode, entirely 32-bit preemptive multitasking operating system. (ala AS/400 or UNIX). Win 98/95 is merely an operating environment with a display subsystem based on Win 3.1 so it can still run Win 3.1 programs. I could go on forever about the differences but as an example, what's one of the important factors that makes a difference in the BPCS case ? In NT, you get your own entire process space, including it's own hooks into the Windows display subsystem as well as other operating system services. So if a process hangs or otherwise looses its integrity, the operating system acts essentially the same as an AS/400, protecting the rest of the system from the unique process and in deleting the process as well as any resources attached. Win 95/98 has a 16-bit nonreentrant display subsystem. In fact, when any process is using the display system, a semaphore is set which literally blocks every other task currently running which also utilizes the display subsystem. (As a bit of trivia, remember the original Intel Pro II's that were optimized for 32-bit performance ...... They didn't perform on Win/95 machines because of the constant thunking to 16-bit mode). Some might think that this might be extremely inefficient, in fact, crippling. Imagine having this screaming race car of a 450 MHz PC that is constantly slamming on the brakes. This could be why Linux screams on a box compared to Win 95/98. I have also heard of people in the financial industry who say that old war horse OS/2 screams compared to Win 95/98 but you can be the judge. So let's say your program gets into that display code, sets the block every task semaphore and than does something illegal as far as the OS is concerned (unbeknownst to the programmer who programmed it, obviously). Voila .... what do you have is ..... PC Lockup. I have also had other PC programmers show me just some normal programming bugs such as illegal memory writes or stack overflows that will create PC Lockup in Win 95/98 because of shared operating environment problems. These are just a few examples. The runtime code on the BPCS client is very complex and has numerous places where we have already found and fixed these sorts of issues, obviously some still remain to be discovered. If I was in a work environment without need for 16-bit emulation or games, I would seriously consider Win/NT. " Thanks Genyphyr Novak SSA -----Original Message----- From: DAsmussen@aol.com <DAsmussen@aol.com> To: BPCS-L@midrange.com <BPCS-L@midrange.com> Date: Tuesday, February 22, 2000 11:54 PM Subject: Re: PC's Locking up when in BPCS >Genyphyr, > >In a message dated 2/22/00 11:04:16 AM Eastern Standard Time, novakg@ssax.com >writes: > >> The reason NT is better has nothing to do with the Task Manager allowing you >> to kill the BPCS job. NT simply does not lock up in BPCS. Please read prior >> threads defining what a 'lock up' is versus what is a simple application >> 'hang' on the PC. I still have found no reports of a real 'lock up' on the >> NT platform. If you had a true lock up, the task manager would not even be >> available because the keyboard does not respond. The PC lock up as >described >> on BMR43360 is non-application related, whereas a hang can always be traced >> to some sort of application problem, usually on the server job. ><<snip>> > >Well, let's not split hairs over what a lockup is. I have the whole history >of Micro$oft operating systems on various machines at the office (two of >which are so old I can't even _GIVE_ them away!) and, after DOS, NT is the >most stable because it allows you an out instead of giving a hard freeze >where even the keyboard won't work -- at least most of the time. I did not >intend to imply that the task manager was the reason that NT worked better, >merely that it was available. > >BPCS is _FAR_ from the only software that runs better on NT than it does on >the 95/98 suite. NT (like OS/2 before it) seems to do a better job of >isolating tasks from each other, so that memory "leaks" are less >catastrophic. Lotus SmartSuite, Visio, and ABC Flowcharter also run better >under NT that they did under Windows 3.11 or 95/98. Pretty good company to >be sharing a problem with. NT also seems to handle devices and their drivers >better than the lesser forms of Windows, which is odd given that NT drivers >are harder to come by and 95/98 are often called upon to support a more >diverse hardware configuration sampling in the home arena than does NT, which >is used primarily for businesses with more consistent hardware configurations. > >While not technically a lockup, a non-respondent application is still a >failed application, even if you can recover from it. Contrary to your >statement that most lockups are caused by server errors, my current client >(full C/S, 6.1.00, latest patches) hangs several times daily and, with the >exception of some poor code in ORD701B that's not checking SQLSTS and causing >a couple of the lockups with a decimal data error, the server is not at fault >over 90% of the time. > >My client had a long conversation with Helpline over this today, and you guys >are doing a fantastic (albeit late) job of trying to resolve this issue >through the "OPS Runtime Service Pack" initiative. Perhaps my original >explanation of why NT works better was technically inaccurate. But just >because the system doesn't lock doesn't mean it's not the _SAME_ problem. NT >just isn't so picky... > >Regards! > >Dean Asmussen >Enterprise Systems Consulting, Inc. >Fuquay-Varina, NC USA >E-mail: DAsmussen@aol.com > >"Jimi Hendrix was the first rocker on the Internet. His modem was a purple >Hayes." -- Anonymous >+--- >| This is the BPCS Users Mailing List! >| To submit a new message, send your mail to BPCS-L@midrange.com. >| To subscribe to this list send email to BPCS-L-SUB@midrange.com. >| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. >| Questions should be directed to the list owner: dasmussen@aol.com >+--- > +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +--- Tony Jackson. BPCS Support. DCS Industry Solutions Caledonia House, Office : +44 (0) 113 204 3300 Email : ANTHONY_JACKSON@dcsgroup.co.uk Lawnswood Business Park, Facsimile : +44 (0) 113 204 3333 Web Site :www.dcsgroup.co.uk Redvers Close, Mobile: +44 (0) 7712 086679 Leeds, LS16 6QY United Kingdom. ********************************************************************** The information contained in this electronic mail message is confidential. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If the reader of this message is not the intended recipient, you are hereby notified that any use, copying, dissemination or disclosure of this information is strictly prohibited. ********************************************************************** +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +---
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.