joseph@elbereth.rutgers.edu (Seymour Joseph) (01/12/90)
Hi again folks. I recently converted from using a First Class Peripherals Sider 10MB hard disk on my Apple IIGS to using Apple's SCSI board (rev C) and a Hyperdrive FX/20 external 20 MB SCSI drive. My system is a 2.25MB Rom 01 Apple IIGS. Since the changeover, my Apple IIGS has been a little flakey. I am running System 5.0.2 as provided on the Claris update disks for AppleWorks GS v 1.1. I had been running system 5.0 on my Sider for months without any such problems. I ran the ROM self test, and the Claris RAM test application and both report that my system is fine. Last night, I was working on an AWGS database and had repeated problems with the program corrupting data. I would add some records to my database and then scroll back over them and to my suprise some of the fields had "????????!?!?!?!?!?!?@?@?@?@?@?@?" and other similar garbage in them. I saved the database under a new name (thank god) and tried reloading it. All I got were 79 records with ERROR in almost every field. I called Claris tech support today. I spoke with Ellen who made an alarming statement: "Yes, we are having problems reported with some SCSI drives. There are bugs in the current versions of the GS/OS SCSI manager that can cause data corruption. We feel that it's not our problem, it's Apple's They are working on a fix but we don't know when it will be available." She wasn't sure if my problem stemmed from that or not, but WOW that is a frightening statement. Can anyone from Apple comment on the stability and integrity of the System 5.0.2 SCSI drivers and SCSI Manager? Can anyone from Claris give me more insight as to what might be going on with my database? I built it with version 1.0v2 and converted it with the converter application you provided with the 1.1 version. I have been left feeling that I simply cannot trust my Apple IIGS as a small business tool. I am afraid that I will lose my database and other files at any time and would like some kind of assurance that either Ellen is wrong, or that something is being done about it PRONTO. Thank you for you assistance. Seymour Joseph joseph@elbereth.rutgers.edu
shatara@memit.enet.dec.com (Chris Shatara) (01/12/90)
In article <Jan.11.19.47.00.1990.8429@elbereth.rutgers.edu>, joseph@elbereth.rutgers.edu (Seymour Joseph) writes... > > >I called Claris tech support today. I spoke with Ellen who made an >alarming statement: > >"Yes, we are having problems reported with some SCSI drives. There >are bugs in the current versions of the GS/OS SCSI manager that can >cause data corruption. We feel that it's not our problem, it's >Apple's They are working on a fix but we don't know when it will be >available." > I had similar problems. What I found was that I could copy AWGS using prosel and got a good copy and all worked fine. When I used the installer or finder, strange things would happen. I sent a set of disks to Dave Lyons at DTS with AWGS on them copied with PROSEL and Finder. The following represents the response I got from Dave this morning. This may help. I've had NO problems with AWGS since I copied it onto the hard disk with Prosel, and I've been using the all the modules quite hard. ----------------------- note from Dave Lyons ---------------------- From: MEMIT::DECWRL::"dlyons@apple.com" 12-JAN-1990 01:03:04.67 To: shatara@memit.enet.dec.com CC: Subj: damaged AppleWorks GS copies Chris, Thanks for your help in tracking down the problem with damaged copied files under GS/OS. It turns out there is a bug in the SCSI.Manager (in 5.0.2 and 5.0) that can show up in the following situation: a large write (but not a read) is being performed on more than 64K of data at a time, and the data includes one entire 64K bank plus some data in the next -and- previous banks. The bug will be fixed at our next opportunity; for now users can use the 4.0 SCSI.DRIVER for copying large files (or, of course, use any utility that does not seem affected by the bug). (Note that it's -not- a Finder bug...the APW Duplicate command can also create a bad copy, for example.) I haven't investigated why ProSel isn't affected; it may simply not read data in large enough chunks to get bitten. --Dave (dlyons@apple.com) ---------------------------- end of message ------------------------ ============================================================================= | Chris Shatara | Internet: shatara@memit.enet.dec.com | | Opinions expressed are | DEC Easynet: memit::shatara | | mine and mine only! | UUCP: ...!decwrl!memit!shatara | =============================================================================
wombat@claris.com (Scott Lindsey) (01/13/90)
In article <Jan.11.19.47.00.1990.8429@elbereth.rutgers.edu> joseph@elbereth.rutgers.edu (Seymour Joseph) writes: > Last night, I was working on an AWGS database and had repeated > problems with the program corrupting data. I would add some records > to my database and then scroll back over them and to my suprise some > of the fields had "????????!?!?!?!?!?!?@?@?@?@?@?@?" and other > similar garbage in them. I saved the database under a new name (thank > god) and tried reloading it. All I got were 79 records with ERROR in > almost every field. > I called Claris tech support today. I spoke with Ellen who made an > alarming statement: > "Yes, we are having problems reported with some SCSI drives. There > are bugs in the current versions of the GS/OS SCSI manager that can > cause data corruption. We feel that it's not our problem, it's > Apple's They are working on a fix but we don't know when it will be > available." > She wasn't sure if my problem stemmed from that or not, but WOW that > is a frightening statement. > Can anyone from Apple comment on the stability and integrity of the > System 5.0.2 SCSI drivers and SCSI Manager? > Can anyone from Claris give me more insight as to what might be going > on with my database? I built it with version 1.0v2 and converted it > with the converter application you provided with the 1.1 version. As Dave said in the mail forwarded by Chris, there is a SCSI bug. I've yet to hear of it affecting anyone except those with 3rd party hard drives. (Just got mail from Dave saying that Apple doesn't know of any reason that it shouldn't affect Apple hard drives, though). Since the bug occurs when a WRITE occurs for data in 3 contiguous banks, I doubt that the SCSI bug is at fault (No promises though). Generally, what's been seen is corruption of the program when copying it resulting in an almost unusable copy on your hard drive. Standard questions: can you repeat the problem with that database? If it's corrupt to start with, all bets are off. If the problem is repeatable, does it happen if the program is run off of floppy? Was this the first time you'd used this database since a) converting it b) changing hard drives. We pounded on AWGS long enough that it's pretty solid and there's no straightforward answers to what bugs are left in there (c'mon, there's no such thing as an 800K program with *no* bugs! Especially not one coded in assembly.) Scott Lindsey | I dig iguana in their outer space duds Claris Corp. | saying, "Aren't you glad we only eat bugs?" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or Dead.
kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) (01/13/90)
In article <1232@mountn.dec.com> shatara@memit.enet.dec.com (Chris Shatara) writes: >In article <Jan.11.19.47.00.1990.8429@elbereth.rutgers.edu>, joseph@elbereth.rutgers.edu (Seymour Joseph) writes... >>"Yes, we are having problems reported with some SCSI drives. There >>are bugs in the current versions of the GS/OS SCSI manager that can >>cause data corruption. We feel that it's not our problem, it's >>Apple's They are working on a fix but we don't know when it will be >>available." > >----------------------- note from Dave Lyons ---------------------- > >Thanks for your help in tracking down the problem with damaged copied files >under GS/OS. It turns out there is a bug in the SCSI.Manager (in 5.0.2 and >5.0) that can show up in the following situation: a large write (but not >a read) is being performed on more than 64K of data at a time, and the data >includes one entire 64K bank plus some data in the next -and- previous >banks. > >The bug will be fixed at our next opportunity; for now users can use the >4.0 SCSI.DRIVER for copying large files (or, of course, use any utility >that does not seem affected by the bug). > What's this--use System Disk 4.0's driver? I always thought system 5 felt very flaky. Jus the way the orange bar moves in the Finder when copying files should leave you to believe sys 5.0 is flaky... :-) Seriously, I have felt for a while that the basic features of GS/OS seemed flaky under system disk 5.0--from install to copying files. Not only did the icons change, but many other things that felt like "home" changed, making me feel that doing ordinary things under GS/OS was no longer quite right. In fact, some software that demands Sys software v5.0 doesn't work under 1 drive...though everything indicates that it should (this software should pop to mind to a few readers here). I feel that it is the new system which is messing up...An inexplicable feeling for sure. GS/OS 1.0 (on sys disk 4.0) seemed solid, in fact I still use it as my default secondary operating system (I boot into ProDOS 8 always, and keep GSOS as a file in my root directory to boot from as a secondary). Sys disk 5.0 doesn't give me such an easy time booting (sometimes it does, usually it doesn't). Other than the obvious Quickdraw routines and forked files extensions, what else has changed in v5.0.2? Why does the Finder, when copying files, not seem to increment to copy bar properly? Why does the SCSI driver there seem to have this new bug in it? What exactly has happened to Apple's high standard of quality control? [I ask anyone to name an actual *BUG* in Applesoft, other than the ONERR cannot-have-another-statement-on-the-same-line quirk? Applesoft is amazingly stable for v1.0...in fact, Apple users have come to expect that from Apple, so anything less, (ie., other-computerish) seems a let down. I'm just trying to put my gripes in perspective...on an IBM compatible, I'm happy if the disk drive doesn't munch my disks, let alone read them in correctly. :-)] Kent Dickey [This post also comes from a recent purchaser (but not yet recipient) of a 65 Meg SCSI hard drive, who doesn't want to hear about the latest system software bug in SCSI drive software.....] kadickey@phoenix.Princeton.EDU
paulh@nuchat.UUCP (Paul Hutmacher) (01/13/90)
In article <1232@mountn.dec.com> shatara@memit.enet.dec.com (Chris Shatara) writes: >The following represents the response I got from Dave this morning. >----------------------- note from Dave Lyons ---------------------- > >It turns out there is a bug in the SCSI.Manager (in 5.0.2 and >5.0) that can show up in the following situation: a large write (but not >a read) is being performed on more than 64K of data at a time, and the data >includes one entire 64K bank plus some data in the next -and- previous >banks. >---------------------------- end of message ------------------------ So if I read this correctly there's a problem with the SCSI.Manager under System Disk 5.0.2 and I need to avoid it. Since I use a CMS SCSI card as well as a CMS hard drive doesn't my system bypass Apple's SCSI drivers and managers, etc? If I remember correctly gs/os creates a driver on the fly for non-Apple SCSI devices. At least I hope so! -- Paul Hutmacher uunet!nuchat!paulh
wombat@claris.com (Scott Lindsey) (01/16/90)
In article <18390@nuchat.UUCP> paulh@nuchat.UUCP (Paul Hutmacher) writes: > So if I read this correctly there's a problem with the SCSI.Manager under > System Disk 5.0.2 and I need to avoid it. Since I use a CMS SCSI card as > well as a CMS hard drive doesn't my system bypass Apple's SCSI drivers and > managers, etc? > If I remember correctly gs/os creates a driver on the fly for non-Apple > SCSI devices. At least I hope so! Sort of. The CMS SCSI card doesn't look like a SCSI to GS/OS, so it generates a driver... unless you've upgraded to the new CMS ROMs. Since it's not going through the SCSI manager, you don't run into the bug. Most of the GS programmers here at Claris have CMS's so we never ran into the bug firsthand. --and in article <12882@phoenix.Princeton.EDU> kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) writes: > ... GS/OS 1.0 (on sys disk 4.0) ... Actually, System 4.0 contained GS/OS 2.0, the first shipping version. System 5.0.x contains GS/OS 3.x. > [other stuff praising 4.0 in comparison to 5.0] I'll let someone from Apple tackle the issues of Apple's standards & bugs... however, from a developer's standpoint, System 5.0 blows 4.0 out of the water: Much is belittled by the statement "Other than the obvious Quickdraw routines and forked files extensions..." Many bugs in 4.0 were eliminated and many speed enhancements were introduced. With the introduction of ExpressLoad, application boot times can be dramatically cut. Resources are much more than just a file storage type; they add a new level of programability to the machine. Maybe from a user standpoint 5.0 doesn't give you much, but when developers take advantage of its capabilities, you get a whole lot more. Scott Lindsey | I dig iguana in their outer space duds Claris Corp. | saying, "Aren't you glad we only eat bugs?" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or Dead.