Subject: RISKS DIGEST 12.38 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 20 September 1991 Volume 12 : Issue 38 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Midwest Stock Exchange Reaps Millions Due to Accounting Glitch (Jeff Helgesen) Newark NJ high school computer problem (Martin A. Leisner) Technology and the oldest profession (Henry Cox) YATO (Yet Another Telco Outage) (Richard Johnson) AT&T switch trouble (Fernando Pereira) English Supermarket Checkout Failure (Maddock) Samurai Hackers' Cunning Employer Screening Process (Marco Barbarisi) Re: Fly-by-wire without leaving the ground (A. Padgett Peterson) MSAFP, utilities, and all that (Mark Fulk) Computer monitoring of pill bottles (Jennifer Heymont) Documentation and lack thereof (Stanley (S.T.H.) Chow) Just the wrong number (Jerry Leichter) Reliability and Redundancy (Bill Murray) CPSR Annual Meeting (Eric Roberts) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Fri, 20 Sep 91 14:54:15 cdt From: jmh@guinevere.pubserv.com (Jeff Helgesen) Subject: Midwest Stock Exchange Reaps Millions Due to Accounting Glitch The Chicago Tribune reports that leaders of the Midwest Stock Exchange had discovered a 13-year-old accounting glitch which enabled a subsidiary to wrongfully reap millions of dollars in interest payments which should have gone to broker-dealers. While the exact amount of money recieved by the subsidiary due to the error was not disclosed, the chairman of the exchange said that he estimated that over the last twelve months, the firm received around 1.8 million dollars. The accounting error, due partly to human error and partly the fault of computers[sic], apparently dates back to about 1978. At that time, the exchange and two of its subsidiaries, Midwest Clearing Corp. and Midwest Securities Trust Co., altered the way certain broker-dealer transactions were handled. Clearing Corp. instituted a change, largely computerized, ordering broker-dealers to wire money to it for the sale of securities before the securities were received by Securities Trust Company. By depositing these funds in short-term, government-backed securities, sometimes overnight but also for longer periods, Clearing Corp. generated for itself interest payments which should have gone to the broker-dealers. This is referred to as "playing the float". When the clearing system is working properly, the securities and proceeds are transmitted through the system simultaneously, thus eliminating such a float. The Midwest Stock Exchange insists that they are taking the situation very seriously, and plan to pay the money back. Some exchange members are concerned that the money used for the refund will come in the form of higher exchange rates, putting the exchange at a serious competetive disadvantage. [Summary from Chicago Tribune Business Section, 9-20-91, "Exchange: Unit profited from 13-year glitch"] ------------------------------ Date: Fri, 20 Sep 1991 11:55:41 PDT Sender: Martin_A._Leisner.Henr801C@xerox.com Subject: Newark high school computer problem >From the New York Times, Wednesday 18Sep91, page B2: "Computer Glitch Sends Newark School Into Chaos" by Joseph F. Sullivan The article starts off: Newark, Sept. 17 -- When Central High School's 1000 students and 90 teachers showed up for the start of the school year on Sept. 5, many found themselves in a computer-generated game that was part musical chairs and part hide-and-seek. About half of the students had no schedules for classes or had schedules with holes in them. Some classrooms had no teachers, while others had four teachers instead of one. Many students spent much of last week in the school auditorium conferring with guidance conunselers who were trying to correct the scores of mistakes in their classroom assignments. The article then goes on to talk about absenteeism and the other problems this caused. marty leisner.henr801c@xerox.com UUCP:uunet!xerox.com!leisner.henr801c ------------------------------ Date: Thu, 19 Sep 91 09:37:25 EDT From: cox@cadence.com (Henry Cox) Subject: Technology and the oldest profession This morning, the Boston Globe had an article about a $3 million prostitution ring which had been running out of a Boston suburb, which was broken in a series of raids yesterday. The computer relevant (or irrelevant, as the case may be) portion of the story was that the group kept a database of their 4000-odd customers and had used call forwarding/etc. to be able to move headquarters from place to place quickly and easily. The story was unclear on what the police intend to do with the customer list, most of whom are apparently fairly well off. [Similar stories have been recorded in the RISKS annals before -- e.g., SoftwEngNotes 11 5, 12 1, 14 1. (See RISK-7.72, 8 Nov 88, Computers in the oldest profession (Dave Horsfall). PGN) ------------------------------ Date: Fri, 20 Sep 91 9:19:19 PDT From: richard@oresoft.com (Richard Johnson) Subject: YATO (Yet Another Telco Outage) According to KINK radio in Portland, Oregon, this morning, most of the suburbs south and east of Portland were without telphone usage for about six hours because someone cut a fiber-optic cable. More importantly, the towns of Milwaukie and Lake Oswego (just south of Portland, upstream on the Willamette river) were without 911 coverage for over three hours. Richard Johnson richard@oresoft.com richard@agora.rain.com ------------------------------ Date: Thu, 19 Sep 91 14:51:13 EDT From: pereira@klee.research.att.com (Fernando Pereira) Subject: AT&T switch trouble According to the AP, the union for the technicians in charge of monitoring the AT&T switch that shut down this Wednesday causing major disruptions to air traffic control (RISKS-12.36) claimed that they were not on duty because they were attending a class to learn about a new alarm system for the problem that caused the shutdown. ------------------------------ Date: Wed, 18 Sep 91 10:41 GMT From: "Maddock :-)" Subject: English Supermarket Checkout Failure The English 'Daily Telegraph' (Sept 18) reports on the failure of 32 computer operated checkout tills in the Sainsbury supermarket in Aylesford, Kent. 'Shoppers ... were invited to suggest a fair price for the goods in their trolleys when the scanners which which read the bar codes refused to work. The breakdown happened only 10 days after the opening of the new store ... The store was then closed for the rest of the day.' Sainsbury's described the failure as 'extremely rare' and said 'when a total failure occurs we ask the customer to suggest a price'. The chain said that 'this allows customers already shopping to complete their purchases'. ------------------------------ Date: Wed, 18 Sep 91 13:59:07 CDT From: Barbarisi Subject: Samurai Hackers' Cunning Employer Screening Process I'm sure many of you have seen the recent issue of Rolling Stone magazine, with the article entitled "Samurai Hackers". It discusses the hiring of young computer enthusiasts by law firms, ad agencies, and the like, for the purpose of prying into the electronic data of subordinates and coworkers. Basically, individuals and firms recruit "hackers" from BBSs and pay them thousands of dollars to do little more than break passwords and riffle through files. Appropriately, the young hackers call these people "Stupids". Of course, the young hackers should really be called "crackers", but I really don't want to start another semantics war. Both the crakcers and their employers have unsettling views on privacy: Data stored electronically is considered public information, regardless of the locks (passwords) enabled by the keeper. The really cunning aspect of the article is one little paragraph in which the samurai explain how they screen potential employers over a BBS. Claiming the need to "authenticate" potential employers and differentiate them from the Feds, the crackers will not deal until they get the person's social security or credit card numbers! Though not mentioned in the article, it seems reasonable to assume that this "authentication" process includes requests for other information such as birthdate, childrens' names, home phone number, car tag, etc. All of this occurs remotely over a BBS system. I'll leave it as an exercise for the reader to figure out what is wrong with this picture. Marco C. Barbarisi - NCSC Panama City, FL - marco@email.ncsc.navy.mil ------------------------------ Date: Wed, 18 Sep 91 17:10:51 -0400 From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: Re: Fly-by-wire without leaving the ground From: fmsrl7!art-sy!chap@sharkey.cc.umich.edu >James Higgins, THE DETROIT NEWS, 15 September, page 1C: ... Clemson engineers >... have patented a new automobile camshaft/throttle control system they say >can boost fuel economy by 20 percent in a gasoline engine. Over what ? A '74 Toronado, or a Honda Civic HF ? >A camshaft controls the action of the valves that let mixed fuel and air into >an engine and allow burned gases to escape. Usually it's set up so that the >valves will open or close according to just one setting. That setting is a >compromise, not...optimal...for all engine speeds. ... In the Clemson system, >the camshaft consists of two shafts, one of which rotates inside the other. An >infinite variety of valve settings is possible, theoretically allowing optimal >valve action in every situation. Both Bruce Crower (1973) and the Cadillac 8-6-4 (1978) tried similar but less complex solutions. Neither was satisfactory. >But here's the nub--his >system also includes a computer-controlled device that electronically allows >the camshaft to act as the car's throttle--a revolutionary idea. >The Clemson system substitutes [for] the mechanical connection...a computer >control--a "fly by wire" device like those...on advanced aircraft. The Knight sleeve-valve engine had some similar characteristics back in the 20's as I recall. The idea has promise but a MAP (Manifold Absolute Pressure) following throttle plate would have the same charactoristics without the drawbacks. So does any cruise control. See below. > When the engine doesn't have to labor against a partially closed throttle, >significant fuel economy gains are possible, Nelson says. This is wrong. An engine doesn't "labor" against a partially closed throttle any more than a vaccuum cleaner "labors" against a blocked inlet - the power requirement goes down, not up as the MAP decreases since less air volume is being moved/compressed. When you remove the combustion aspects, a gasoline engine is often modeled as an air pump with maximum capacity at WOT (wide open throttle) and minimum load with a closed throttle. One point not mentioned is that such a scheme would also require direct cylinder fuel injection, also like a Diesel & considerably more expensive than the port or throttle body injection currently used on "conventional" gasoline engines since the very short intake duration and low manifold & port gas velocities at cruise woud preclude other methods. This is not to mention the lack of any manifold vaccuum source for accessories or emissions devices (why passenger Diesels have little vaccuum pumps mounted on them). Of course this is souluble with a bit of engineeering but the question remains whether any advantage is gained that is not available with a "fly-by'wire" throttle plate alone. It would be interesting to see how this device would match up with a good cruise control on a modern engine. This is not to say that the variable camshaft duration (haven't seen the device, but would expect the delta to be in duration not lift since a) is much simple to impliment, and b) would allow tailoring not only of the effective flow, but also the advance/retard charactoristics that could spread effective scavaging/ram effects over a broader range than with a fixed cam) doesn't sound theoretically feasible, just that there are easier ways to go about it and I have to wonder if it might be more suited to racing than the road. Really digging now but didn't Mercedes experinent with variable durations on the 300SLR's desmodromic (sp?) valve gear in the early fifties ? In short, the idea has promise but, at least for the moment, I would have to put it in the same category as the D.A.F. "DAFODIL" with the constant velocity transmission of a few years ago - the same idea approached from the opposite side. Padgett ------------------------------ Date: Wed, 18 Sep 91 11:42:42 EDT From: fulk@cs.rochester.edu Subject: MSAFP, utilities, and all that I must regret having created something of a monster. My original point was simply this: the advocates of the MSAFP assigned different utilities to the various possible outcomes than I did. However, their advocacy literature did not address this possibility. On questioning, one MSAFP advocate (a geneticist at Strong Memorial Hospital) admitted that the rate of spontaneous abortions had relatively little impact on consideration of the MSAFP. It was clear from our conversation that the MSAFP advocates (the geneticist was one) were concerned with the social good of reducing defective births, whereas I was also concerned with the grief and self-recrimination that would surely follow an accidental abortion. Although it is tempting to respond at length to Mr. Grodberg, I will limit myself to three points: I did this calculation in 1987, it was done with the numbers supplied to me by the ADVOCATES of MSAFP screening, and I possessed and used some relevant facts that Mr. Grodberg lacked. In particular, I regarded anencephalic births as having only about double the (negative) utility of spontaneous abortions, whereas spina bifida was given a much lower (worse) utility. This because anencephalic infants do not survive, whereas infants with s.b. do and require surgery; at least a few years ago they were generally paralyzed from about the waist down. Almost all s.b. victims also suffer hydrocephaly (maybe it's all, I forget); and the shunts used to treat hydrocephaly frequently break down. I'd provide you with precise numbers if I could find my notes. Unfortunately, they are buried under about a foot of papers on my table here. After all, it has been nearly four years now. Mark Fulk ------------------------------ Date: Wed, 18 Sep 91 13:47:47 -0400 From: fulk@cs.rochester.edu Subject: Re: MSAFP, utilities, and all that If people would stipulate three points: (1) The parties affected by a choice do not usually share a common assignment of utilities to outcomes (if they can be said to have utilities at all; see Kahneman and Tversky). (2) Point 1 is rarely acknowledged by published risk-benefit analyses. (Emphasize rarely; some studies may, but the studies that I've read haven't.) (3) Points 1 and 3 are of interest to RISKS readers, and should be born in mind whenever discussing risks of any sort. then I would have succeeded, and I don't really give a damn what people think of the MSAFP. In fact, my position would be that people OUGHT TO make their own evaluations of the MSAFP. The same point can be made in several different ways. For example, government tends to equate all deaths, or at least to equate years of life lost; people in general, however, have strong preferences about the NATURE of their deaths. Mark ------------------------------ Date: Wed, 18 Sep 91 13:57:05 -0400 From: jleah@ATHENA.MIT.EDU Subject: Computer monitoring of pill bottles There seems to me to be one very obvious problem with the so-called "Smart Pill Bottles," which is that there does not need to be any correspondence whatsoever between the number of times that a patient opens a pill bottle and the number of times that they actually *take* the medication. Two scenarios, both of which are common to people who take medication regularly, come readily to mind: a) patient opens the pill bottle to see how many are left and whether or not they need to refill their prescription. This would result in more openings than pills taken, and the doctor might well think that the patient was taking the appropriate number when in reality they are not. This would probably be in the noise, since it doesn't happen that often. b) much more common is a patient who opens the bottle, transfers some to another bottle, which he keeps in a different place, takes on a trip with him, etc. This would result in a number of bottle opens that was drastically less than the number of pills taken, causing the doctor misattribute effects the effects of too low a dosage to incomplete ingestion of medication. Now granted, in both of these scenarios, all that is necessary to avoid the problem is for the patient to know what is going on and make sure to keep track of things like this. However, presumably if they were on the ball enough to do that, they wouldn't need something like this in the first place! Jennifer Heymont [There are many problems with the original approach... But the fundamental problem is another example of looking for a high-tech solution to a low-tech problem... PGN] ------------------------------ Date: 19 Sep 91 13:02:00 EDT From: Stanley (S.T.H.) Chow Subject: Documentation and lack thereof In a recent issue of "Vectors", published by Hughes Aircraft, there is an article entitled "So, you can't replcae it then make it better". The article talks about the amazing feats the Hughes achived in winning the MTSP (Microelectronics Technology Support Program). The whole MTSP seems to be a response to the problem of not being able to obtain obsolete components for military systems. This is itself of some interest due to the military going from leading edge to the trailing edge. Of more interest to RISKS readers, contractors to the MTSP had to solve three problems: - "Reverse engineer an obsolete intergreated circuit". - "Given technical data on a circuit board, reverse engineer the circuit board". (There is no statment of how much technical data) - develope replacements for above, using silicon compilers and generic gate arrays. Given the well-known mountains of paper that the Pentagon requires for any hardware, and the many mil-spec's for documenting and testing any and everything, it is quite a surprise to me that anyone should need to reverse engineer anything. To make explicit the RISKS: Even excellent documentation is usesless, Unless you can find it again. Stanley Chow (613) 763-2831 BNR PO Box 3511 Stn C, Ottawa, Ontario, Canada K1Y 4H7 BitNet: schow@BNR.CA schow%BNR.CA.bitnet@relay.cs.net ..!uunet!bnrgate!bcarh185!schow ------------------------------ Date: Thu, 19 Sep 91 22:33:47 EDT From: Jerry Leichter Subject: Just the wrong number Sanford Sherizen's recent posting about the Tandem crash due to the date/time have "just the wrong value" reminds me of two other such incidents that I know of. Curiously, in both cases the POTENTIAL for the problem was spotted in the code, but as far as I know in neither case was it ever triggered. Case 1: So you think that's a good password? When I was an undergraduate at Princeton, a group of friends and I, ahem, made full use of some of the more arcane and undesireable aspects of OS/360. Now, OS/360 had no provision for passwords on accounts - it was, after all, a batch/card system. However, the local system support people decided that passwords were needed. They needed to retrofit a password scheme into an existing system. To store the password, they re-used 3 bytes in the existing user data file (they had previously contained the user's initials). A submitted deck could, anywhere at all within it, contain a $PASSWORD card with the correct password. (The recommendation was that carry with you a $PASSWORD card, pre-punched with your password, but with the printing turned off. The card would not appear in your output, and without the printing it couldn't be "accidentally" read without a deliberate effort. Given the technology, not a bad system.) Since many old decks existed, and there was a large group of existing users, it was decided that the password feature would be optional: Initially, you had no password. If you had no password, you didn't need a $PASSWORD card; if fact, if you provided one, your job was rejected. Once you had set a pass- word, you had to provide it. Now, there is no free bit to indicate "has set a password", so instead the chosen field was re-used: If it was three 0 bytes, the system assumed you had no password. In that case, it didn't even check the password provided on a $PASSWORD card - it immediately rejected the job. Three bytes does not a good password make. It's not that there are too few combinations - in an environment where the only way to try a password is to submit a deck of cards, 2^24 of them is plenty. However, people want some- thing they can remember. So the system allowed passwords of, as I recall, up to 16 bytes. The 16 bytes were run through an encryption algorithm (the designers apparently thought it was a one-way encryption - it wasn't, as we proved by inverting it) and then compressed down to three bytes. There are many perfectly valid passwords which, after running through this algorithm, produce an encrypted, compressed password of three zero bytes. The password setting code didn't check for this; it simply stored the cal- culated value. Set one of those passwords, and you were locked out of your account until you thought to run a deck with no $PASSWORD file in it at all. Case 2: A spacey kind of Saturday. A number of years ago, I worked on a system that supported all of DEC's manu- facturing plants. The system was written in BASIC PLUS on RSTS/E - sounds bizarre, but it worked out quite well. (This experience also left me per- manently skeptical of all claims that any new language/OS/whatever is a panacea. Most programmers, and probably all academics, would look down their noses at the environment we had - but we built and maintained a large, successful system, running quite reliably 24 hours a day, tying together multiple CPU's - in 1974, when networking was virtually unheard of.) The standard RSTS representation for the date was a two-byte number represen- ting an offset from some base day, I forget when. BASIC PLUS had some very nice file management calls, but they worked with strings, not numbers. No problem: There was a set of what amounted to type coercions that would take, say, a date and treat it as a two character string. One day. I did a little calculation and realized that we were quite close to an interesting anniversary: The day that the date, interpreted as a string, came out to two spaces. The date happened to fall on a Saturday. Some string operations in BASIC PLUS truncate trailing spaces - the obvious string comparison operation is one. I could imagine many potential failures in programs that suddenly found that the current date was the null string. So I was looking forward to an interesting Monday morning of panicked calls from, literally, all over the world. I must say that I was glad that none came in! -- Jerry ------------------------------ Date: Fri, 20 Sep 91 15:34 EDT From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Reliability and Redundancy (Re: PGN, RISKS-12.36) >Here we have another example of creative redundancy and supposedly >conservative design (hardware reliability, fault tolerance, extra capacity, >alternative routing, standby power, etc.) still not being good enough to >prevent massive outages. This should not come as a surprise to anyone. There is an upper bound to the degree of reliability that can be built into a system by redundancy. At some point, one introduces so much complexity, so many components, and so many connections that these begin to cause failures that would not have occured in their absence. I do not intend to suggest that there is an upper bound to reliability; while I suspect that there is, I do not pretend to know. Only that there is clearly an upper bound to the reliability that can be achieved by redundancy. I have more hope for what can be achieved by integration and simplification. William Hugh Murray, New Canaan, Connecticut ------------------------------ Date: Thu, 19 Sep 91 14:09:33 PDT From: eroberts@Eeyore.Stanford.EDU Subject: CPSR Annual Meeting 1991 Annual Meeting of Computer Professionals for Social Responsibility October 12 and 13 Massachusetts Institute of Technology Cambridge, MA Auditorium 34-101 Celebrating Ten Years of CPSR Computer Professionals for Social Responsibility, the nation's only public interest organization of computing professionals, will hold its 1991 Annual Meeting on October 12 and 13 in Cambridge, Massachusetts. The CPSR Annual Meeting is a national gathering that gives computer professionals from all over the country a chance to meet and to discuss the important and interesting issues facing the profession and the public. The meeting is open to everyone who has an interest in computers, communication, the future of our high-tech society, and our role as citizens in the development of policy. This year's meeting will focus on current developments in information technology and the impact they will have on our ways of communicating and distributing information. The Bush administration has proposed a $2 billion program of investment in new computer networking technologies, which have the potential of transforming the future of international communication. There are many pressing policy issues raised by the proposal: Who will control the new network? Who will have access to its resources? What are the provisions for privacy, security, and equity? The sessions on Saturday, October 12, will include several distinguished speakers addressing these and other pressing public-interest issues surrounding electronic communication and the emerging "information age." It will provide an opportunity to think together about the problems, and through CPSR to pass the resulting assessments along to the media, to policymakers, and the other participants in the democratic process. Admission to the CPSR Annual Meeting is $20 for members, $25 for non-members, and $10 for students and low-income attendees. We welcome additional contributions to support our work. Contributions to CPSR are tax-deductible. For more information and registration materials, contact CPSR at (415) 322-3778 or by electronic mail at cpsr@csli.stanford.edu. PROGRAM Saturday, October 12 8 a.m. to 9 a.m. Registration and Continental Breakfast 9 a.m. to 9:15 a.m. Welcome from the CPSR Board 9:15 a.m. to 10:45 a.m. "The Past, Present, and Future of Government Policy in the Information Age" John Shattuck, Vice President, Government, Community and Public Affairs, Harvard University. Research Associate in the Science, Technology, and Public Policy Program at the John F. Kennedy School of Government, Harvard University. Former Washington director of the American Civil Liberties Union, and former vice-chair of Amnesty International. 10:45 a.m. to 11 a.m. Break 11 a.m. to 12:30 p.m. "The Personal and the Political in Electronic Communication" Judith Perrolle, Associate Professor of Sociology, Northeastern University. Research Associate at the Harvard School of Public Health. Author of the book, _Computers and Social Change_. 12:30 p.m. to 2 p.m. Lunch (not included in the conference) 2 p.m. to 3:30 p.m. "Educational Equity and the International Economy in the Information Age" Herb Gintis, Professor of Economics, the University of Massachusetts at Amherst. Co-author of the books _Inequality_ (with Christopher Jencks and others), _Schooling in Capitalist America_ (with Samuel Bowles), and _Democracy and Capitalism_ (with Samuel Bowles). 3:30 p.m. to 4 p.m. Break 4 p.m. to 6 p.m. Parallel presentations on public interest programs involving information technology. o An overview of CPSR's programs and operations, intended for new members and those who would like to become more active in the organization, presented by members of the CPSR Board of Directors. o Mass OnLine, a project of the Boston Computer Society, presented by Tracy Licklider, president, Boston Computer Society. o Community Bytes, a project of the MIT Community Fellows Program, presented by Laxmi Ramasubramanian, research associate, Community Fellows Program. o The Electronic Frontier Foundation, to be presented by a representative of EFF. o The CPSR Computing and Civil Liberties Project, presented by Marc Rotenberg, National Program Director, Computer Professionals for Social Responsibility. Sunday, October 13 8 a.m. to 9 a.m. Continental breakfast 9 a.m to 10 a.m. Reports from CPSR leadership 10 a.m. to 10:30 a.m. Break 10:30 a.m. to 12:30 a.m. Chapter organizing workshop 12:30 p.m. to 2 p.m. Lunch 2 p.m. to 3 p.m. General CPSR business meeting 3 p.m. to 4:30 p.m. Parallel workshop sessions on CPSR projects 4:30 p.m. to 5 p.m. Wrap-up and evaluation ------------------------------ End of RISKS-FORUM Digest 12.38 ************************