Article 68129 of news.groups: Newsgroups: news.groups Path: cs.utk.edu!gatech!howland.reston.ans.net!noc.near.net!das-news.harvard.edu!spdcc!merk!uvmark!jim From: jim@uvmark.uucp (Jim Todhunter) Subject: Re: RFD: comp.databases.pick Message-ID: <1993May06.213200.15724@uvmark.uucp> Date: Thu, 06 May 93 21:32:00 GMT References: <1s8la1$504@gazette.bcm.tmc.edu> Organization: VMARK Software, Inc. Lines: 33 In article <1s8la1$504@gazette.bcm.tmc.edu> rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller) writes: > >The real problem that I have is that PICK is not a database system. Please >find a more appropriate name. I could go with comp.os.pick but I think >something along the lines of comp.soft-sys.pick might be the most appropriate >name. While it is true that the older PICK environments were both O/S and database in one package, that model fell by the wayside long ago. Consider: + Prime INFORMATION, the first of database only PICK type systems, was an implementation of a large portion of the PICK database engine components to the PRIMOS operating system environment. + UniVerse, the first UNIX database to support PICK applications, was designed and built from scratch to be an O/S independent database environment that just happened to support PICK applications. Today, it is available on most UNIX platforms, and will shortly be available for NT. + PI/Open is essentially a UNIX port of Prime INFORMATION. + Unidata is a database available for both UNIX and VAX VMS. The open systems segment of the PICK marketplace is the fastest growing segment of the market. The environments which dominate this segment are definitely not operating systems; they are database management and application development environments. -- James W. Todhunter, Director, Research & Development jim%uvmark@merk.com VMark Software, Inc. 30 Speen Street Framingham, MA 01701-1800 USA Telphone: (508) 879-3311 Facsimile: (508) 879-3332 Article 68152 of news.groups: Path: cs.utk.edu!emory!gatech!howland.reston.ans.net!usc!cs.utexas.edu!uunet!nwnexus!osiris From: David Ruggiero Newsgroups: news.groups Subject: Re: RFD: comp.databases.pick Date: 7 May 1993 09:05:30 -0700 Organization: [none - why fight entropy?] Lines: 23 Sender: news@nwfocus.wa.com Message-ID: <1se1ca$mfh@nwfocus.wa.com> References: <1s6uvlINN97h@rodan.UU.NET> <1993May05.185937.38434@uvmark.uucp> Reply-To: osiris@halcyon.halcyon.com (David Ruggiero) NNTP-Posting-Host: nwfocus.wa.com Originator: osiris@halcyon.com todd@uvmark.uucp (Todd Cooper) writes: >I think this is great and a long time in coming (since pick is as old as unix) >For those who do not know, non-normal form databases differ for SQL in that >they can handle cells with more than one value and variable records. This >is what pick was based on, and some bigger SQL type database producers are >moving towards databases of this form. Microsoft in fact has coined a >term "postrelational" to refer to this. Todd's comments are very appropriate here; note that some of the niftier features of the database model used in Pick-like systems are now moving into the database mainstream (and acquiring high-priced academic names at the same time :). Score one for databases that model the real world, where you don't know in advance how many times something will happen (or how big it will be). Credit should also be given to Todd for first suggesting the comp.databases.* hierarchy as the most appropriate for this group - the consensus of the discussion so far seems to have agreed that this was the right choice. -- David Ruggiero (jdavid@halcyon.com) Seattle WA: Our slugs can beat up your slugs From dni Thu May 20 13:24:20 1993 Return-Path: Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA03776; Thu, 20 May 93 13:20:07 -0400 Errors-To: owner-grad@CS.UTK.EDU Received: from utkvx.dnet.utk.edu by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA03598; Thu, 20 May 93 13:17:22 -0400 Received: from utkvx.dnet.utk.edu by utkcs.dnet.utk.edu; Thu, 20 May 93 13:19:51 EDT Message-Id: <9305201719.AA03580@utkcs.dnet.utk.edu> Date: Thu, 20 May 93 13:19:51 EDT From: Ethel Wittenberg X-To: undergrad, grad-student, alumni X-Cc: wittenbe@UTKVX.UTCC.UTK.EDU Subject: position To: grad-list:; Status: R AREV PROGRAMMER WANTED: Immediate opening for experienced Advanced Revelation Programmer to provide, on customer site, AREV development and technical support assistance for large user group. 3 years' AREV programming experience desired, good communication skills needed. Send resume to Poplar Creek Solutions, Inc. Human Resources Department P O Box 958 Kingston TN 37763 Article 72 of comp.databases.pick: Path: cs.utk.edu!gatech!howland.reston.ans.net!noc.near.net!uunet!nwnexus!osiris From: David Ruggiero Newsgroups: comp.databases.pick Subject: Pick folklore (was: Re: What's a pick) Date: 15 Jul 1993 14:13:51 -0700 Organization: [none - why fight entropy?] Lines: 20 Sender: news@nwfocus.wa.com Message-ID: <224haf$c7k@nwfocus.wa.com> Reply-To: osiris@halcyon.com (David Ruggiero) NNTP-Posting-Host: nwfocus.wa.com Originator: osiris@chinook.halcyon.com brian@nothing.ucsd.edu (Brian Kantor) writes: >BTW, the Data/Basic language wasn't originially part of the Pick system. >Initially, it was programmed in 'proc' (like shell scripts) and assembler. >I remember an RPG, and other minor programming languages along the way >as well. The (somewhat apocryphal) story goes that Ken Sims, young bright Pick Systems programmer that he was, couldn't figure out a way to code a Star Trek game in assembler, so he asked around about other alternatives. Rod Burns (then a Microdata employee) gave him a copy of a 1960-vintage article about how to roll your own meta-compiler, and thus BASIC was born. Dick Pick's reported reaction was along the lines of "BASIC? Who needs it? We've got PROC and BATCH." :-) Many more stories could be told, but I've got no time right now. It's really good to see this group being used. -- David Ruggiero (jdavid@halcyon.com) Seattle WA: Our slugs can beat up your slugs Article 97 of comp.databases.pick: Path: cs.utk.edu!gatech!howland.reston.ans.net!noc.near.net!uunet!think.com!paperboy.osf.org!paperboy.osf.org!sjs From: sjs@sirius.osf.org (Steve Sears) Newsgroups: comp.databases.pick Subject: Re: Pick Internals Date: 20 Jul 93 11:38:03 Organization: Open Software Foundation Lines: 80 Message-ID: References: <22gksm$gcs@usenet.INS.CWRU.Edu> NNTP-Posting-Host: sirius.osf.org In-reply-to: am518@cleveland.Freenet.Edu's message of 20 Jul 1993 11:28:21 GMT Jeff> Does anyone have any articles/know of any books with Jeff> more information on how exactly Pick is implemented. I Jeff> have read a few articles about the history of Pick and Jeff> how it was all written using very simple assembly Jeff> instructions so that it could be easily ported. I would Jeff> like to see/know a little more about Pick as an OS. There isn't a lot of internals documentation around. I have heard that folks were afraid of getting sued by Pick Systems, and so no one was willing to publish. I don't necessarily believe it - the techinical community in Pick is relatively small and doesn't create a lot of demand for it. Having done a couple of monitors from scratch, I can tell you something about your other questions: First, understand some Pick architecture basics. The OS is really divided into two separate parts: Virtual, and the monitor. "Virtual" is the pageable part of the system and is written in Pick Assembler, typically called the ABS frames. The monitor is the hardware support part of the OS, and can be written in anything you want - most implementations use native assembler and the tools that Pick provides, but my monitors were mostly C with assembler support where it made sense (not much, but some). I will refer to "classic" pick as the monitor I originally got from Pick Systems, way back when. This was an R83 vintage which they don't even ship anymore, but I don't know if they changed much...Dick has some very strong opinions on certain things. The monitor/ABS relationship is still true. Jeff> How does Pick do CPU scheduling? What type of an alogrithm Jeff> does it use? Classic Pick did FIFO scheduling with all tasks on a central queue; a task typically represented a port, or a user ("task" is my word; internally they are called PIBs). Even sleeping tasks or those waiting on disk were on the same queue, which isn't really a bad thing as unrunable tasks tend to move to the end of the queue, and new ones are always at the front. Before Sequoia came along, there were not that many ports on a Pick machine and this was adaquate. Tim Holland found that a lot of stuff didn't scale real well (no suprise). There are others with large machines around now, or with different task paradigms. We changed the task = user early on and had several phantom processes in the system (similar to the spooler). Jeff> How does Pick handle memory protection? There isn't really a concept of memory in Pick: only disk. The "frame" is what you think of as a unit of storage and execution. Memory is just a special case of disk. Most implementations have no memory protection whatever. When we built a new monitor for the M88100 system we had, we did an implementation that checkerboarded memory; i.e. every other page in memory was invalid. This saved a lot of time checking on frame boundaries for various operations, as we just faulted when we got to the end of the frame and had a fault handler that knew what to do next. Implementing read/write protection type of frames is problematic for a number of reasons which I am not going to go into now. I did write protection on ABS frames for a while, but didn't ever ship it. How is file protection (and more generally the entire file subsystem) implemented? The file system is the heart of the Pick system. Read Ian Sandler's book for a good explanation. -Steve -- Steven J. Sears sjs@osf.org Open Software Foundation Research Institute "furthermore, the gap between theory and practice in practice is much larger than the gap between theory and practice in theory" Jun 9, 1993, Dr. Jeff Case in an item on the snmp mailing list. Article 1372 of comp.terminals: Newsgroups: comp.terminals Path: cs.utk.edu!gatech!rpi!usc!howland.reston.ans.net!pipex!sunic!trane.uninett.no!news.eunet.no!nuug!news.eunet.fi!funic!nphi.fi!amityaev From: amityaev@nphi.fi Subject: NEED terminals/WYSE/VT Message-ID: <1993Oct6.140457.1@nphi.fi> Lines: 14 Sender: usenet@nic.funet.fi Nntp-Posting-Host: nphi05.ktl.fi Organization: National Public Health Institute, Finland Date: 6 Oct 93 14:04:57 EET Lines: 14 My friends in Russia is interesting in second-hand 8-bits monitors - VT-100, VT-200, WYSE 120, WYSE 60. Preferably are WYSE, because it is possible to load cirrilics font. They work with PICK, so they are interesting in it. Please, contact with me E-mail: AMITYAEV@NPHI.FI (till 12th of October) ANCOR@RNICPM.MSK.SU or you can directly to get in touch with Serov S. in Moscow by fax: (095) 415-2973 Regards, Andrey Mityaev Article 371 of comp.databases.pick: Newsgroups: comp.databases.pick From: kch@edgtech.demon.co.uk (Keith Howell) Path: cs.utk.edu!emory!europa.eng.gtefsd.com!paladin.american.edu!darwin.sura.net!udel!news.sprintlink.net!demon!edgtech.demon.co.uk!kch Subject: File Upload Organization: EdgTech International Ltd X-Newsreader: TIN [version 1.2 PL2] Date: Tue, 30 Nov 1993 19:05:37 +0000 Message-ID: Sender: usenet@demon.co.uk Lines: 29 >---------------------------------------------------------------------------- >Date: Tue, 23 Nov 93 17:05:57 GMT >From: Harry Railing >Reply-To: harry@rail.demon.co.uk >To: uploads@demon.co.uk >Subject: PICK program -output to screen for pc capture > >in incomming jet-dump > >A quick and dirty programme to output a PICK item to screen without >value markers and line numbers for capturing on a pc and subsequent >import into a pc word processor. > >-- > >|_| _ _ _ < Internet : harry@rail.demon.co.uk >| | (_)_ | | |_| < CI$ : 100141,1632 > | < Snail : 90 Balham Grove, London SW12 8BE, UK >---------------------------------------------------------------------------- > >This file is now available from /pub/pick at ftp.demon.co.uk > -- ,---------------------------+----------------------------------------------. | Keith Howell | EdgTech International Ltd, 4/5 North Bar St, | | kch@edgtech.demon.co.uk | Banbury, OX16 0TB, United Kingdom. | | kch@cix.compulink.co.uk | Tel +44 (0)295 277088 Fax +44 (0)295 279179 | `---------------------------+----------------------------------------------' Article 388 of comp.databases.pick: Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!MathWorks.Com!transfer.stratus.com!knelson.habu From: Kevin_Nelson@vos.stratus.com (Kevin Nelson) Newsgroups: comp.databases.pick Subject: Re: Interfacing PICK financial data and Microsoft Excel (Library System) Date: Tue, 7 Dec 1993 07:28:00 -0800 Organization: Stratus Computer Inc, Marlboro MA Lines: 27 Distribution: world Message-ID: <9312070728.AA00053@knelson.habu> References: Reply-To: Kevin_Nelson@vos.stratus.com (Kevin Nelson) NNTP-Posting-Host: knelson.ca.stratus.com X-Newsreader: InterCon TCP/Connect II 1.2 I posted this yesterday, but I never saw it come across the net, so here it is again and I apologize if this is a repeat. A company called Eversoft Solutions Group, Inc. sells a product for the Macintosh called CrowFlite (as in the shortest distance between two points). It consists of an extension to Excel and a Pick host based server program. The Excel extension adds several new spreadsheet functions that access data from a Pick host. Simply recalculating the spreadsheet causes the data to be updated from the Pick host. It can also upload a spreadsheet onto the host in a Pick-compatible file. The company is working on a Windows version now and expects it to be available shortly. We have a customer that has used this product for a while and they love it. If you have any questions, please contact Eversoft directly at the address or phone number below, they are not on the net. Eversoft Solutions Group, Inc. P.O. Box 1327 Beaverton, OR 97075-1327 (503)239-3530 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kevin Nelson - Stratus Computer, Inc. Kevin_Nelson@vos.stratus.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Article 490 of comp.databases.pick: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!MathWorks.Com!transfer.stratus.com!knelson.habu From: Kevin_Nelson@vos.stratus.com (Kevin Nelson) Newsgroups: comp.databases.pick Subject: Re: Pick Arithmetic Part Two Date: Wed, 9 Feb 1994 12:40:56 -0800 Organization: Stratus Computer Inc, Marlboro MA Lines: 56 Distribution: world Message-ID: <9402091240.AA56534@knelson.habu> References: <760263884snz@hoxton.demon.co.uk> Reply-To: Kevin_Nelson@vos.stratus.com (Kevin Nelson) NNTP-Posting-Host: knelson.ca.stratus.com X-Newsreader: InterCon TCP/Connect II 1.2 In article <760263884snz@hoxton.demon.co.uk>, paul@hoxton.demon.co.uk (Paul Beardsell) writes: > > As a follow-up to "Pick Arithmetic" perhaps users of Pick-like systems > would like to test the following program and post the results to me or > here. The digest of the replies to this and to "Pick Arithmetic" will > be posted to comp.pick.databases. Thanks to those who have replied so > far. > > Needed is the name and version number of your Pick-like system and that > of the underlying operating system, if applicable. And, of course, the > output of: > Here are the results running Pick 4.1c on Stratus, VOS release 11.7.2. The results were the same on older releases as far back as I could check. :CT BP PRECISION PRECISION 001 * PRECISION test program from Paul Beardsell 002 PRECISION 2 003 X=11 004 Y=33 005 Z=0.33 006 A=X/Y 007 PRINT A 008 PRINT Z 009 IF A = Z THEN PRINT 'SAME' ELSE PRINT 'DIFFERENT' 010 X=999999999999.99 011 A=1234.03 012 Z=X+A-X 013 PRINT A 014 PRINT Z 015 IF A = Z THEN PRINT 'SAME' ELSE PRINT 'DIFFERENT' :BASIC BP PRECISION PRECISION **************** [241] Successful compile! 4 Frames used. :RUN BP PRECISION .33 .33 SAME 1234.03 1234.03 SAME ------------------------------------------------------------ Kevin_Nelson@vos.stratus.com Stratus Computer, Inc. ------------------------------------------------------------ Article 488 of comp.databases.pick: Newsgroups: comp.databases.pick From: paul@hoxton.demon.co.uk (Paul Beardsell) Path: cs.utk.edu!news.msfc.nasa.gov!sol.ctr.columbia.edu!howland.reston.ans.net!EU.net!uknet!demon!dis.demon.co.uk!hoxton.demon.co.uk!paul Subject: Re: Pick Arithmetic Distribution: world References: <1994Feb02.232843.12320@vmark.com> Organization: SAM Business Systems Limited Reply-To: paul@hoxton.demon.co.uk X-Newsreader: Simple NEWS 1.90 (ka9q DIS 1.21) Lines: 23 Date: Wed, 9 Feb 1994 07:09:43 +0000 Message-ID: <760263355snz@hoxton.demon.co.uk> Sender: usenet@demon.co.uk In article <1994Feb02.232843.12320@vmark.com> mark@vmark.com writes, inter alia: >Having INT() add 0.5 before doing the function, add one half of the current >precision value, or having a "smear" factor near the limits of the >underlying floating point precision are all options. None of these options >satify all of the user base. > >Mark >-- >+++++++++++++++++++++++++++++++++++++++++++++++++++++ >Mark A. Baldridge, (mark@vmark.com) >VMark Software, 30 Speen Street, Framingham, MA 01701 Yes. But you are not saying that it is impossible to satisfy all of the user base and that therefore no attempt will be made to do so. Or are you? -- Paul Beardsell SAM Business Systems Ltd ~~~~~~~~~~~~~~ 21 Finn House, Bevenden St, HOXTON, pbeardsell@cix.compulink.co.uk Hackney, London, N1-6BN, UK. paul@hoxton.demon.co.uk (+44 or 0)71 608-2391 Article 491 of comp.databases.pick: Newsgroups: comp.databases.pick Path: cs.utk.edu!ornl!fnnews.fnal.gov!uwm.edu!cs.utexas.edu!howland.reston.ans.net!pipex!mdis.co.uk!jpl From: jpl@gx2.mdis.co.uk (John Lambert) Subject: Re: Pick Arithmetic Part Two Organization: MDIS (McDonnell Information Systems) Ltd Date: Thu, 10 Feb 1994 04:56:44 GMT Message-ID: X-Newsreader: TIN [version 1.2 PL0] References: <760263884snz@hoxton.demon.co.uk> Sender: news@mdis.co.uk (News System Admin) Lines: 43 Paul Beardsell (paul@hoxton.demon.co.uk) wrote: : As a follow-up to "Pick Arithmetic" perhaps users of Pick-like systems : would like to test the following program and post the results to me or : here. The digest of the replies to this and to "Pick Arithmetic" will : be posted to comp.pick.databases. Thanks to those who have replied so : far. : Needed is the name and version number of your Pick-like system and that : of the underlying operating system, if applicable. And, of course, the : output of: : PRECISION 2 : X=11 : Y=33 : Z=0.33 : A=X/Y : PRINT A : PRINT Z : IF A = Z THEN PRINT 'SAME' ELSE PRINT 'DIFFERENT' : X=999999999999.99 : A=1234.03 : Z=X+A-X : PRINT A : PRINT Z : IF A = Z THEN PRINT 'SAME' ELSE PRINT 'DIFFERENT' The results for MDIS Reality were as follows, For Releases 7.3,7.2,7.1 and 7.0 0.33 0.33 same 1234.03 1234.03 same I would expect the same results on prior releases and on REALITYX because of the scaled arithmetic that is used in all versions of Reality. John Lambert MDIS Irvine,CA Article 498 of comp.databases.pick: Newsgroups: comp.databases.pick Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!uunet!psinntp!adpgate!rod From: rod@plaza.ds.adp.com (Rod Barnes) Subject: Re: Revelation ? Organization: ADP Dealer Services, Portland, OR Date: Wed, 16 Feb 1994 19:57:57 GMT Message-ID: <1994Feb16.195757.13201@plaza.ds.adp.com> X-Newsreader: TIN [version 1.1 PL6] References: Sender: usenet@plaza.ds.adp.com (Usenet News Admin) Lines: 14 justrob (justrob@netcom.com) wrote: > > Does anyone have the address for Revelation (PICK for pc's). I believe > the company is called Cosmos, Inc. Cosmos bought the original company called Revelation Technologies about six years ago. Here are the last numbers I had for RevTech. 'Hope these help. (206) 643-9898 for general (206) 746-1629 for tech support The company is (was?) in Bellevue, WA Article 499 of comp.databases.pick: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!netserv.unmc.edu!netserv.unmc.edu!not-for-mail From: cprice@netserv.unmc.edu (Chad Price x7936) Newsgroups: comp.databases.pick Subject: Re: Revelation ? Date: 17 Feb 1994 09:13:45 -0600 Organization: University of Nebraska Medical Center, Omaha, NE, USA Lines: 23 Message-ID: <2k01j9$l3i@netserv.unmc.edu> References: NNTP-Posting-Host: netserv.unmc.edu X-Newsreader: TIN [version 1.2 PL2] justrob (justrob@netcom.com) wrote: : Does anyone have the address for Revelation (PICK for pc's). I believe : the company is called Cosmos, Inc. They are now called Revelation Technologies, and are headquartered out of someplace on the east coast. Sales phone number is: 1-800-262-4747 The techies of the company are still in Washington State. The current releases are Advanced Revelation 3.1 for DOS and Open Insight 2.0 for Windoze. There was a 3.1 beta for OS/2 but developement was stopped on an essentially complete product due to "performance" problems, and a too-small perceived market. I use arev 3.1 and it's very good for development. OI 2.0 is something I have had no chance to really experiment with. It does however, read the 3.1 file system. chad price cprice@netserv.unmc.edu chad@windsurf.unmc.edu Article 503 of comp.databases.pick: Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!uunet!pipex!demon!cix.compulink.co.uk!jwatsona Newsgroups: comp.databases.pick From: jwatsona@cix.compulink.co.uk (John Watson) Subject: Addr/Phone Nbr for General Automation Reply-To: jwatsona@cix.compulink.co.uk Date: Fri, 18 Feb 1994 01:08:14 +0000 Message-ID: Sender: usenet@demon.co.uk Lines: 23 > Does anyone have the address and phone number for > General Automation ? Thanks in advance. >Brian Richardson >McDonnell Douglas Space Systems, Kennedy Space Center >email: richards@tardis.mdcorp.ksc.nasa.gov According to an ad in PickWorld it is: General Automation 1045 South East Street Anaheim, CA 92803 714-778-4800 800-854-0140 800-443-2332 (in California) Fax 714-778-5539 John Watson ============================================================================= jwatsona@cix.compulink.co.uk | Systems Manager spot@spuddy.uucp | NHS Supplies NE Division Sequoia OA/CItoh R91/Ultimate/Reality | Normanton, West Yorks, WF6 1TL Article 547 of comp.databases.pick: Path: cs.utk.edu!stc06r.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!cs.utexas.edu!usc!yeshua.marcam.com!zip.eecs.umich.edu!umn.edu!lynx.unm.edu!dns1.NMSU.Edu!rever!carrion From: carrion@acca.nmsu.edu (Carrion) Newsgroups: comp.databases.pick Subject: Re: Public Domain FTP sites for Pick Software? Date: 5 Mar 1994 03:46:18 GMT Organization: New Mexico State University Lines: 24 Message-ID: <2l8vaaINNbo6@dns1.NMSU.Edu> References: <1994Mar1.154657.10182@midway.uchicago.edu> NNTP-Posting-Host: rever.nmsu.edu X-Newsreader: TIN [version 1.2 PL2] John Watson (jwatsona@cix.compulink.co.uk) wrote: : > From: pynq@ellis.uchicago.edu (Jeremy Mathers) : > Subject: Public Domain FTP sites for Pick Software? : > : > Are there any? : > : There is /pub/pick directory on ftp.demon.co.uk but there's nothing in it : yet! I am waiting for Alan Glassman to upload the RED development system : - he will mail me when it is available. : John Watson : ========================================================================== : == : jwatsona@cix.compulink.co.uk | Systems Manager : spot@spuddy.uucp | NHS Supplies NE Division : Sequoia OA/CItoh R91/Ultimate/Reality | Normanton, West Yorks, WF6 1TL Pick systems told me that they are strongly considering hooking into Internet so people can easily contact them and get the patches. carrion Article 549 of comp.databases.pick: Newsgroups: comp.databases.pick From: kch@edgtech.demon.co.uk (Keith Howell) Path: cs.utk.edu!gatech!howland.reston.ans.net!pipex!uknet!demon!edgtech.demon.co.uk!kch Subject: Re: How do you use 'ls' in AP? References: Organization: EdgTech International Ltd X-Newsreader: TIN [version 1.2 PL2] Date: Sun, 6 Mar 1994 14:33:44 +0000 Message-ID: Sender: usenet@demon.co.uk Lines: 21 Mike Klecka (mikek@tsh.com) wrote: > We have the requirement to redirect output from an 'ls' > command into an Advance Pick data file. This processes > should be available through a PROC. The way to do this would be to use a small BASIC program. 001 open 'filename' to filename else stop 002 execute "!ls " capturing flist 003 write flist on filename, 'id' You can put 'tclread' or 'procread' at the start to get command line parameters etc. -- ,---------------------------+----------------------------------------------. | Keith Howell | EdgTech International Ltd, 4/5 North Bar St, | | kch@edgtech.demon.co.uk | Banbury, OX16 0TB, United Kingdom. | | kch@cix.compulink.co.uk | Tel +44 (0)295 277088 Fax +44 (0)295 279179 | `---------------------------+----------------------------------------------' Article 554 of comp.databases.pick: Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!library.ucla.edu!ihnp4.ucsd.edu!munnari.oz.au!yoyo.aarnet.edu.au!arnie.systems.sa.gov.au!state.systems.sa.gov.au!chdemgt Newsgroups: comp.databases.pick Subject: Re: Database and/or O/S Message-ID: <1994Mar7.125615.27627@state.systems.sa.gov.au> From: chdemgt@state.systems.sa.gov.au Date: 7 Mar 94 12:56:15 ACST References: <2l4221$4e5@golem.wcc.govt.nz> Organization: State Systems, South Australia Lines: 26 In article <2l4221$4e5@golem.wcc.govt.nz>, lee_c@ix.wcc.govt.nz (chris lee) writes: > I've just started a new job where they run a Pick database on a ADDS mini. > I'm having trouble figuring out whether Pick is a Database and/or and operating system? I mean is Pick a DBMS? If it is the operating system, what compilers are around for it? Is there a COBOL compiler for instance? Any help would be appreciated. In general (and on ADDS) it is an OS with a pervasive database-oriented approach and deeply embedded DBMS functionality. (How'm I going?) It existed in the market for many years as a stand-alone OS, but it is now well and truly agreed that it was totally trounced by unix. (sob) It is widely implemented on Unix systems as an application creating an OS-like environment (and living on a raw volume). People put in on Unix for its DBMS functionality. I.e. it walks like an OS and talks like a DBMS. (Getting better?) There is also a version called Advanced Pick for PC-DOS (AP/DOS). There is only one compiler, for an unusual form of structured BASIC, and it compiles into p-code. At first it seems a horror, but by the time the bits behind your ears have dried you realise that it is pretty hot stuff. You can do useful things in a fraction of the time you would take with COBOL. Regards, Mike (who can't see what he is doing. Damn this ... VAX and its ... mail editor.) talbot-wilson.michael@statemail.sa.gov.au (Michael Talbot-Wilson) Article 555 of comp.databases.pick: Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!sunic!EU.net!news.funet.fi!news.eunet.fi!news.spb.su!kaija!not-for-mail From: Alexey Fedotov Newsgroups: comp.databases.pick,comp.databases Subject: Re: Looking For Pick ODBC / IDAPI Driver Date: 7 Mar 1994 18:07:43 +0300 Organization: VISTA Ltd. (St-Petersburg) Lines: 19 Sender: news@owl.kaija.spb.su Distribution: world Message-ID: NNTP-Posting-Host: localhost X-Return-Path: vista!vista.spb.su!alex@kaija.spb.su Xref: cs.utk.edu comp.databases.pick:555 comp.databases:32424 Hello Gildas, In the PICK WORLD magazine September/October 1993 you can find article "ODBC opening windows for PICK" from Gordon Hamilton and advertisement of PICK ODBC driver from Liberty Software Corporation. Liberty Software Corporation, Canada - CompuServe 76020,3524 Liberty Software Corporation, Australia - CompuServe 100250,524 Best wishes, =================================================================== Alexei Fedotov Vista Software Ltd. St. Petersburg, Russia alex%vista.spb.su@ussr.eu.net Article 556 of comp.databases.pick: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!yeshua.marcam.com!charnel!olivea!news.bu.edu!kalena From: kalena@bu.edu (Karen R. Sabog) Newsgroups: comp.databases.pick Subject: BCS 4th Dimension SIG Meeting, March 10th, 7PM, MIT Date: 7 Mar 1994 19:43:05 GMT Organization: Boston University Office of Information Technology Lines: 124 Sender: kalena@itnet-dns.bu.edu. Message-ID: <2lg049$euo@news.bu.edu> NNTP-Posting-Host: pcsc-mac6.bu.edu X-Posted-From: InterNews 1.0@news.bu.edu. > Forwarded Message: From: kalena@it.bu.edu (Karen R. Sabog) Subject: BCS 4D SIG Mtg, Mar 10, 7PM, MIT To: 4d@isig.mit.edu (4D Internet Email Forum) [Courtesy of Peter Kussell, Director of BCS 4D SIG] [CORRECTIONS/CLARIFICATIONS courtesy of Peter Bogdonoff, ACI US, Inc. Boston Office] Boston Computer Society 4th Dimension Special Interest Group ============================================================ Next Meeting Date ----------------- Thursday, March 10th, 1994 6:30 PM Novices Meeting 7:00 PM Main Meeting MIT Building E51, Room 136 50 Wadsworth Street Cambridge, MA For more information, call Peter Kussell at 508/549-6466 (work) or 617/821-6324 (home). Agenda for March 10th, 7:00PM: ACI Developers Open House -------------------------------------------------------- Saloni Sarin, Head of Developer Services, and Dave Beckett, Marketing Engineer, will be our special guests from ACI US, Cupertino. Saloni will talk about ACI's multi-platform strategy and show off new product releases and upcoming products for 4th Dimension. Non-4Ders invited!!! [Correction: 1. It's DAN Beckett (not Dave Beckett) --Peter B.] ACI Announces 4D Universal Server! ---------------------------------- The latest issue of MacWeek (2/7/94) was a front-page issue for ACI, which detailed their plans for going multi-platform in the next year, including versions of 4D Server, 4D Client, 4D Compiler and 4D for Windows, Windows NT, Solaris, Chicago. They'll do this magic for 4D Server by taking core 4D Server code, tweaking it for the various platforms and then recompiling it. ACI is seeking to set itself apart from the pack (not the first time...) of other cross-platform database development systems by stressing the idea of "multi-platform" (good) vs. "cross-platform" (bad). The idea is that "cross-platform" assumes you carry over from some original operating system much information which is irrelevant or just plain wrong when working in another operating system. So there seems to be a very large-scale committment on ACI's part to map out a scalable future for clients and developers. 4th Dimension itself is still written in Object Pascal, so it seems Laurent R. is waiting for a cross-compiler from MetroWorks in order to bring the development system over to the PowerPC in native code. There are many tantalizing details in the article. We expect that the March 10th 4D Open House will be an opportunity to learn more about ACI's multi-platform strategy as well as see some new tools ACI has recently delivered or is about to deliver... This is definitely going to be an important, not-to-miss meeting... [Corrections/Clarifications 2. Re: "by taking core 4D Server code, tweaking it for the various platforms and then recompiling it" -- Not. 4D Universal is not a recompile. It's a revolutionary new architecture. We've been at work on it since 1990. 3. Re: "ACI is seeking to set itself apart from the pack...of other cross-platform database development systems by stressing the idea of "multi-platform" (good) vs. "cross-platform" (bad) -- For "multi-platform" please substitute "platform independence". There's a big difference. We'll explain what we mean in more detail. Come and hear about the VME (Virtual Machine Engine). 4. The PowerPC strategy will be discussed also. It is more like what you described as "multi-platform"; a tweak-and-recompile.] --Peter B.] February Meeting Highlights --------------------------- Peter Bogdanoff won a copy of Microsoft's FoxPro for the Mac... Jobs... Jobs... Jobs... ----------------------- Acumen, Inc. of Santa Fe, NM is looking for a full-time 4D Developer for a large new 4D project which they expect will also include Newton technology. Contact them at: Acumen, Inc. 803 Juniper Lane, Santa Fe, NM 87501, Compuserve: 72371,3356 or AL: D4630. Training... Training... Training... ----------------------------------- * ACI's March Training schedule in Boston is: 3/21-22 Intermediate; 3/23-24 Advanced; and 3/25 4D Server. Call them at 408/252-4444 x213 to register. * DMD Systems April dates are: 4/25-29 Call 303/989-8019. * Dimensions Magazine is published by Blackledge Publishing: 800/424-4855. Solid bimonthly 4D publication. April 14th Meeting ------------------ Thursday, April 14th, 1994 6:30 PM Novices Meeting 7:00 PM Main Meeting MIT Building E51, Room 136 50 Wadsworth Street Cambridge, MA Natural Intelligence will present a sneak preview of version 2 of Quick Code Pro! If you have an address change, call Tim Dalton, our membership chairman, at 508/777-6313. Our BBS using 1st Class Client is 617/864-3375. And, while you're at it, join the BCS! Call the BCS number at 617/252-0600 today! ====================================================================== Karen R. Sabog Internet: kalena@bu.edu Boston University Office of Information Technology Personal Computing Support Center HAWAII NO KA OI!!! ====================================================================== Article 557 of comp.databases.pick: Newsgroups: comp.databases.pick Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!library.ucla.edu!ihnp4.ucsd.edu!munnari.oz.au!newshost.anu.edu.au!sserve!ghm From: ghm@sserve.cc.adfa.oz.au (Geoff Miller) Subject: Re: Database and/or O/S Message-ID: <1994Mar7.231829.19047@sserve.cc.adfa.oz.au> Organization: Australian Defence Force Academy, Canberra, Australia References: <2l4221$4e5@golem.wcc.govt.nz> Date: Mon, 7 Mar 1994 23:18:29 GMT Lines: 21 ajm@hpwin064.uksr.hp.com (Andrew Monks ) writes: >On the system you are running on, Pick is both, the OS and the DBMS. The only >compiler is DATABASIC which comes as standard. On the 'unix' flavours of Pick, >the OS functions have been removed and your left with just the DBMS which >is better. I have to argue with this. On PI/Open (as far as I can see) most of the "OS" functions are still there, even if all they do is call the appropriate bit of Unix, and I suspect you could just about run the system from within PI/Open. >I think Pick is the best database around and the basic is so flexible you >can do almost anything you want to. No argument here, at least for the kind of applications I work with, which tend to be very much text-based. Perhaps if I were working a lot with numerical or coded data, the kind of things you get in survey work, I might prefer another product. Geoff Article 869 of comp.databases.pick: Newsgroups: comp.databases.pick Path: cs.utk.edu!gatech!howland.reston.ans.net!noc.near.net!das-news.harvard.edu!spdcc!merk!uvmark!mark From: mark@vmark.com (Mark Baldridge) Subject: Re: Day 10000 Problem Summary: Internal date = 10000 Message-ID: <1994May06.183245.62381@vmark.com> Sender: Mark A. Baldridge Date: Fri, 06 May 94 18:32:45 GMT Expires: May 18, 1995 References: <2q4g2n$hin@search01.news.aol.com> Organization: VMARK Software, Inc. Lines: 35 In article <2q4g2n$hin@search01.news.aol.com> dphochman@aol.com (DPHochman) writes: >For a paper to be presented to the 5th International PickLab Conference & >Exhibition in Sydney, I’m looking for information on the effects of the Pick >internal date reaching 10000 on May 18, 1995 and what you have done or are >planning to do. Two of the main problems are software that assume a four-digit >internal date (especially in item-ids) and dictionaries for date fields that >are left justified. > >Of particular interest is software provided by the various platform providers. ... >David P. Hochman >Multi-Value Products >dphochman@aol.com >CIS: 73352,42 > I wrote an article, "Date with Destiny: May 18, 1995" in SSELECT Magazine, September/October 1991. This article discusses the problems with left justified dates. It concentrates upon an application that expects the date to be 4 digits with a series of examples, showing how the problem may be corrected, and demonstrates how performance can be improved in the process. As a side note, in uniVerse, there is some protection from the two digit date problem. Depending upon the system year, ICONV("01/01/05","D2/") will return 2005, not 1905. It assumes some temporal proximity. Once the date is internal format, then it is not an issue. Mark -- +++++++++++++++++++++++++++++++++++++++++++++++++++++ Mark A. Baldridge, (mark@vmark.com) VMark Software, 30 Speen Street, Framingham, MA 01701 Article 1044 of comp.databases.pick: msuvx2.memphis.edu Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!ihnp4.ucsd.edu!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!aggedor.rmit.EDU.AU!otto!arthur Newsgroups: comp.databases.pick Subject: Re: freeware Pick Message-ID: From: arthur@otto.bf.rmit.oz.au (Arthur Adamopoulos) Date: 31 May 94 09:56:50 GMT References: <2rbhdm$1lg@news.cerf.net> <2rekeb$6qj@news.cerf.net> <2rf8nq$9s6@panix2.panix.com> <769475963snz@hoxton.demon.co.uk> <2rmdtc$98q@werple.apana.org.au> <769653529snz@hoxton.demon.co.uk> Organization: Royal Melbourne Institute of Technology, Melbourne, Australia. NNTP-Posting-Host: otto.bf.rmit.edu.au Lines: 39 paul@hoxton.demon.co.uk (Paul Beardsell) writes: >You don't understand: You can't give Pick away. At least not to >teaching institutions that will introduce it to students. Why >would they take it? Alright there is some odd university in Australia >somewhere that uses it a lot but at almost any other institution >it is regarded as simply a curiosity. Now please don't flame me, >or if you do then start a new thread! I'm simply saying that Pick >as it is will not inspire take up by a new user community. It must >offer features that are now regarded as essential. I named some of >them above. Yep... we do exist and we do teach with Pick. Mind you, it's used in the Business Faculty only... the Computer Science mob think it's a curiosity, as stated. Actually, we _do_ have all flavours of Pick running on our unix boxes, and all have been kindly donated by the relevant companies: Advanced Pick, UniVerse, Unidata. They must think there's some merit to having kids learn with Pick. I do agree with the above point that simply writing another Pick will not get you anywhere..... ...... Now, if you took Pick, added neat things like inheritance, proper transactions etc. etc..... and called it Object Oriented... ... hey presto, everyone is all ears. It's an interesting point that the CEO of Unidata is the author of a book on 'Object Oriented Databases' (Won Kim). Anything Unidata haven't told us yet ? (at least that's what the sleeve of my book says). ----------------------------------------------------------------------- Arthur Adamopoulos ACSnet: arthur@otto.bf.rmit.oz Business Computing Internet: arthur@otto.rmit.edu.au RMIT 411 Swanston st. Tel: +61 03 660 2849 Melbourne 3000 ICBM: 37 48 S / 147 58 E ----------------------------------------------------------------------- Article 1301 of comp.databases.pick: Path: cs.utk.edu!gatech!howland.reston.ans.net!agate!ihnp4.ucsd.edu!munnari.oz.au!yarrina.connect.com.au!werple.apana.org.au!news From: dave@werple.apana.org.au (David Rose) Newsgroups: comp.databases.pick Subject: Re: Limits of uniVerse debugger? Date: 27 Jun 1994 17:39:31 +1000 Organization: werple public-access unix, Melbourne Lines: 46 Message-ID: <2ulvnj$6ut@werple.apana.org.au> References: NNTP-Posting-Host: werple.apana.org.au Keywords: infoBASIC debugger uniVerse bug d.rogers@irl.cri.nz (Don Rogers) writes: >I have found that the debugger sometimes gets out of step with the line it is >displaying. It appears to be associated with long lines. I have some print >statements which are about 400 characters long. The debugger then executes the >statement two statements ahead of the one it is pointing to. >Has anyone else noticed this? Is it an undocumented feature? >I'm using uniVerse Command Language 6.3 I cannot comment on uniVerse but I can talk of Pick BASIC and there may be some similarity. The COMPILER drops a opcode (x'01') for each EOL it locates during compilation, when the debugger is called it searches for and counts these opcodes to locate the current line number, to do this it must know the length of each opcode and it's operands to ensure a operand is not considered an EOL opcode (e.g. if the debugger sees 0c010001 then it knows that an x'0c' is actually 3 bytes long so the first x'01' is not considered an EOL, but the second is an EOL). Now if the debuggers notion of an opcode/operand is incorrect then it may cound an operand as a EOL opcode which would create a line number descrepancy. Now, I have no idea how vmark does this, but if they employ a similar method then the line discrepancy could be becuase of an unrecognised-by-the-debugger opcode. >Donald Rogers >Computer Services >Industrial Research Ltd Email: D.Rogers@irl.cri.nz >PO BOX 31-310 Phone: +64-4-569-0444 4682 >Lower Hutt FAX : +64-4-569-0067 >New Zealand regards, dave. ------------------------------------------------------------------------------- | _ _ | | | | o o | David Rose, | .--_|\ | | ! | Fly By Night Programming, | / \ | | '''=``` | Australia. | \_.--.*/ | | ~ | | v | ------------------------------------------------------------------------------- Most people I know think that I am crazy (.. Billy Thorpe circa 1973) Especially the "application programmers" on comp.databases.pick (me circa 1994) Article 1474 of comp.databases.pick: Path: cs.utk.edu!gatech!swrinde!ihnp4.ucsd.edu!news.cerf.net!mdcsc!hve From: hve@mdcsc (Henry Eggers) Newsgroups: comp.databases.pick Subject: Re: Bozo Filters Date: 12 Jul 1994 01:16:39 GMT Organization: McDonnell Information Systems (MDIS) Lines: 84 Message-ID: <2vsqtn$qt4@news.cerf.net> References: <2vheuu$m0t@news.cerf.net> <1994Jul8.225943.11055@plaza.ds.adp.com> Reply-To: heggers@ca.mdis.com NNTP-Posting-Host: mdcsc.ca.mdis.com X-Newsreader: TIN [version 1.2 PL0] Jim Idle (jimi@plaza.ds.adp.com) wrote: : Henry Eggers (hve@mdcsc) wrote: : : Jim Todhunter (jim@vmark.com) wrote: : : : In article <1994Jul5.234814.11443@plaza.ds.adp.com> jimi@plaza.ds.adp.com (Jim Idle) writes: : : : >Any compiler written using yacc and lex.... : : : Perhaps we should write yacc and lex for Pick?! We've been working on the basis that we'd have one available 'in the environment' in due time. It seems to be there. [Interpolating from related discussions.....] :: :: Because there wasn't a 'match space' capability in the BNF. :This is of course the specific reason for that bug. More generally of course :things of this ilk turn up less when you have a nice tool set with which to :build your compiler. :: In this case, the 'tool set' with which to build the BNF is the set of primatives available from the meta. Somebody(s) got lazy for about a decade on the addition of this rather simple tool. : : ..., would say that it should be :punishable by reverting to ED :-) Which reminds me. Is there a UNIX/DOS freeware version of ED around out there anywhere? I've got cousin-of-Runoff, but I still need a decent editor to get my productivity up. :-) :: : : :: : : [In general, 'statement names' may be used as variables, since they] :: : However: :: Yes. But ABS() is a _function_, not a statement. For a rather long :: time, DIM ABS (10) worked. :Yes. I guess I was trying to say that allowing some keywords as identifiers but :disallowing others (even though they are functions) is probably worse than :allowing all keywords as functions. What is even worse though is: : : ABS = 7 ;* Works (on Reality, anyway) : DIM ABS(7) ;* Does not :: Before we get too carried away with reserved-word purity, let me observe that in the beginning there were just a few statements and functions, and that over the years, they have multiplied. Since 'things' are not added by #include , or through user-defined functions, the only path of development for the language has been the addition of statements and 'intrinsic functions' (which means that you get 'em whether you want 'em or not), it was necessary to have preexisting programs still compile as new functions and statements were added. Since all 'meaningful' terms were already in use in the preverbial 8 million programs, that meant that the only way out was this now-clearly-impure behavior. Two counter examples: from 2.4 to R77 the LN(x) function was added. Unfortunately, all prior programs included the statement DIM LN(66), where LN(1) throught 66 were lines 1 throught 66 of the page (Heading wasn't there yet, didn't work, still doesn't work, et cetera). Every output routine in the planet failed. For i = 1 to 66; print ln(i); next J did not output what was expected. Second, there once was a time, long, long ago, far, far away, where some good soul decided that, as a 'handle' for communications, the term REFNO would be used -- as a reserved word. Unfortunately, _all_ the programs in the world seem to have been there first.... : :I really meant that with a yacc source it is a few extra lines along the lines of : if ($6 != $2) : { : warn : } Yup. That's all there is to it. But documentation, 'conversion programs', bug reports.... Bletch. : : ... Writing stuff :like this in Pick Assembler is a lot more difficult than in C. Really? The assembler has a problem with 'global data'; once that is recognized and attended to, I'm not at all sure that it is either more difficult, or that the result is more obscure. What the assembler machine does is sprint up and down strings using pointers (greviously mis-named 'registers' by IBM in a fit of hardware ethnocentrism), and it does it rather more facilly than C. So much for being 'reconstructed'. -- Henry V. Eggers | Opinions are heggers@ca.mdis.com | solely mine. Article 1467 of comp.databases.pick: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!news.cerf.net!nic.cerf.net!rothj From: rothj@nic.cerf.net (Jack Roth) Newsgroups: comp.databases.pick Subject: Re: Freeware Date: 11 Jul 1994 19:28:31 GMT Organization: CERFnet Dial n' CERF Customer Lines: 31 Message-ID: <2vs6gv$kqk@news.cerf.net> References: <2vq9e9$kdk@search01.news.aol.com> NNTP-Posting-Host: nic.cerf.net PICK Systems is willing to be a ftp site for PICK freeware. Our address is ftp.picksys.com Use ftp to place incoming files into the /pub/to.freeware directory, that evening the files will be moved to the /pub/freeware directory for others to use. When I get our system supported by an archie site, these files will be listed. If we start getting many files we may need to break the directory into subdirectories, based upon release or utility function. If you want to use this resource, start dropping off files. If you have comments or suggestions send mail to freeware@picksys.com. Files sent to freeware@picksys.com will be cheerfully ignored. Questions about software contained in the freeware directory will be answered to the best of my ability. (I know nothing.... :-). Please no copyrighted material. Pick Systems has sole authority to determine what will be kept at this site. We will not change the contents of the files, but we may delete files. There is a disclaimer in the /pub/freeware directory, please include it in anything you place at this site. Thanks and I'm looking forward to helping get a ftp site going. jack@picksys.com Article 1497 of comp.databases.pick: Path: cs.utk.edu!gatech!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nntp-server.caltech.edu!news.cerf.net!nic.cerf.net!rothj From: rothj@nic.cerf.net (Jack Roth) Newsgroups: comp.databases.pick Subject: Pick Freeware FTP Site Date: 13 Jul 1994 17:31:37 GMT Organization: CERFnet Dial n' CERF Customer Lines: 12 Message-ID: <3018dp$ins@news.cerf.net> NNTP-Posting-Host: nic.cerf.net At Jay La Bonte's request there is now a way to place software in /pub/freeware by mail as well as by ftp. To get information on using this ftp site, send email to: info-freeware@picksys.com The scripts to administrate the freeware was put together in a couple of hours, so the process will change with time. If you have suggestions or comments, please mail me at jack@picksys.com. I hope you find the site useful. Article 1495 of comp.databases.pick: Path: cs.utk.edu!gatech!swrinde!news.dell.com!tadpole.com!uunet!newstf01.cr1.aol.com!search01.news.aol.com!not-for-mail From: accutrac@aol.com (AccuTrac) Newsgroups: comp.databases.pick Subject: FREEWARE/SHAREWARE Date: 13 Jul 1994 12:27:07 -0400 Organization: America Online, Inc. (1-800-827-6364) Lines: 35 Sender: news@search01.news.aol.com Message-ID: <3014kr$ehj@search01.news.aol.com> NNTP-Posting-Host: search01.news.aol.com OK everyone, Thanks to Jack Roth at 'picksys.com' for setting up a location to deposit Freeware/shareware software for the pick community. The directory is '/pub/freeware' to submit a file to the freeware directory, please direct them to /pub/to.freeware The files currently available are as follows: TELEDISK.ZIP - This is a great DOS program that I think may become our standard for PICK data transfer. The program will convert any disk, (Yes, PICK T-dump's, Account-Save's even File-Save) 5-1/4 or 3-1/2 to a DOS data file. GENR83.EXE - Is a self exploding zip file. It will create an DOS Based installation disk for a PICK R83 Version 3.1 System. GENAPD.EXE - Is a self exploding zip file. It will create a DOS Based installation disk for a PICK AP/DOS Ver 5.2 System GENESIS.ZIP - This file contains both GENR83.EXE and GENAPD.EXE GENESIS.TD0 - This is an Account-Save created using TELEDISK. When Processed by TELEDISK it will re-create and account-save 5-1/4 floppy for the GENESIS R83 VERSION 3.1 Pick System. Once the floppy has been re-created, you may run and Account-restore. (Please Note I Just sent an update to this file because to original was missing a file. The Updated version should be available on 7-14-94) If anyone has any questions or needs assistance please feel free to E-mail me. Jay La Bonte AccuTrac Corporation Article 1497 of comp.databases.pick: Path: cs.utk.edu!gatech!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nntp-server.caltech.edu!news.cerf.net!nic.cerf.net!rothj From: rothj@nic.cerf.net (Jack Roth) Newsgroups: comp.databases.pick Subject: Pick Freeware FTP Site Date: 13 Jul 1994 17:31:37 GMT Organization: CERFnet Dial n' CERF Customer Lines: 12 Message-ID: <3018dp$ins@news.cerf.net> NNTP-Posting-Host: nic.cerf.net At Jay La Bonte's request there is now a way to place software in /pub/freeware by mail as well as by ftp. To get information on using this ftp site, send email to: info-freeware@picksys.com The scripts to administrate the freeware was put together in a couple of hours, so the process will change with time. If you have suggestions or comments, please mail me at jack@picksys.com. I hope you find the site useful. Article 1640 of comp.databases.pick: Path: cs.utk.edu!emory!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!isclient.merit.edu!msuinfo!harbinger.cc.monash.edu.au!yarrina.connect.com.au!werple.apana.org.au!news From: dave@werple.apana.org.au (David Rose) Newsgroups: comp.databases.pick Subject: Re: Bozo Filters Date: 22 Jul 1994 20:39:06 +1000 Organization: werple public-access unix, Melbourne Lines: 207 Message-ID: <30o7ka$enq@werple.apana.org.au> References: <304ch9$k5n@werple.apana.org.au> <1994Jul18.215437.27961@plaza.ds.adp.com> NNTP-Posting-Host: werple.apana.org.au jimi@plaza.ds.adp.com (Jim Idle) writes: >David Rose (dave@werple.apana.org.au) wrote: >: hve@mdcsc (Henry Eggers) writes: >: >: >Jim Idle (jimi@plaza.ds.adp.com) wrote: >: >: Henry Eggers (hve@mdcsc) wrote: >: >: : : Jim Idle (jimi@plaza.ds.adp.com) wrote: >: >: >[settled issues deleted] >: >: ... system like Unix won't crash if you illegally write to memory! >: >: >Without wanting to belabor the point, writing viable 'virtual code' >: >isn't that hard, either. But, again, there are more tools in UNIX >: >to make the world safe. (Very seldom do the 'traditionally defined' >: >machines 'crash' in my experience. flz is a lot like 'dumping core', >: >which is well within the daily capability of the Unix machines I use. >: >PCs just get the three finger salute. Appalling.) >It is not the Unix machines that core dump it is the programs you are using. >Also FLZ does not give you a lot of information. For instance it cannot tell you >exactly what path you took to get there or whther it has inadvertantly corrupt >half your POVF table. FLZ and related errors happen on a daily basis on far too >many machines for my liking. Hopefully, most are 'mostly' harmless. But once your >PICK system is slightly corrupt, it might as well have stopped altogether. You >can't fix a GFE and this affects the whole system. I guess it is important to know if we are discussing an unexpected, random abort or we are discussing a program that fails during testing. If the is the former then a good support specialist can 'poke' around the PCB, ABS and system tables and get a feel for whether the POVF table is hosed or just a single frame. The return stack can tell you where you came from. But I do agree, aborts are too common and my experience has shown the MOST COMMON cause is hardware failure and the second most common is users not noticing nasty messages (often caused by the first cause) and allowing the system to slowly screw itself. But given the choice of a GFE and a unix system that will not boot becuase fsck can't 'fix' the file system, I want GFEs. I CAN FIX GFES ! It is just a matter of how much time you can give me to fix them, and even then I may not be able to recover all of the data. I have MANY TIMES, recovered enough of the important parts of a system to be able to get a file-save off and then start restoring and SEL-RESTORing to rebuild a trashed system. Now, if we are talking about a system under development, I don't need a lot of information from the system debugger, I know why I am in a given piece of code and it doesn't take long to figure out what went wrong. Hopefully, I fix it before I ship the code to a customer site. >The point is that it is quite easy for a Pick assembler programmer to bring down >the whole machine with a bit of errant code and that this presents problems for >concurrent development by many programmers. I would have to delibeartely try and >panic a Unix kernel and certianly could not easily overwrite other peoples >workspace. I think one of the 'bad' things about unix is that it is too easy to have 'many' programmers working on the system at once (this is the SYSTEM, not some application). My experience at ultimate was that more than about 5 programmers working on virtual was too many, this is not beacuse of the development environment, but more becuase there seems to be a limit to the number of fingers you want touching any system before you start to loose consistancy in the interfaces and the quality. Think back, unix was developed by 3 or 4 people. Once it moved out into the outside world commands like 'find', 'cpio' and 'dd' where born, and they have a completely different user interface than 'ls', 'ps', 'grep', etc >: I am on henry's side. I have written Pick assembler and C (on both unix and >There weren't any sides originally! Do you propose some :-) Pistols at dawn and >all that! back to back they faced each other, drew their swords and shot each other ! >: MSDOS). And it is no harder to write assembler than C. In both cases you have a >I disagree if you quailfy your statements properly. It is harder to write GOOD >Pick assembler than GOOD C. It takes time to learn how to do either. If your >statement was true, then why did anyone bother with the language? If you are >purely comparing Pick assembly language then perhaps you wish to illucidate? I guess the basis for this arguement is whether you think good programmers are born or trained. (I think they are born). I have been complented on both my Pick assembler and my C style, both styles are different, I code to suit the language (The biggest complaint I have about C over assembler is that at least assembler has a place [out of the way] for my comments, I am still trying to find a home for my comments in C, although, I do like the new PC editors/IDEs that allow me to make my comments a dirty-grey colour). It took me a week (while I was on a C course) to realise that C is just a transportable assembler, (I have to declare enough room for strings and I have to move them byte at a time), once I began to think in 'assembler mode', I found C easy to use. GOOD code is more about style than syntax. I once worked with a guy on a project and he asked me to look at a program he was having trouble with and I kid-you-not, this guy had written a COBOL program that looked like a FORTRAN program - the first thing I said to him was 'I thought this was a COBOL project' and he said 'it is, see here is my IDENTIFICATION DIVISION, here is my PROCEEDURE DIVISION'. And yes it was going through a COBOL compiler but I still believe a FORTRAN compiler would have done the trick just as well. As a programmer of Pick assember and C, I find 'MIID IR,OS,SM_MASK' and 'strcpy(WorkArea, FileArea)' both extemely readable. >: relatively small language with a large library of routines, in both cases you >: need to ensure you use the right elements (in the right order) in a library >: call or bad things will happen. >And the documentation of the C libraries (at least for Unix) defines exactly >what you can and can't use and do. You learn the same about the Pick subroutines >available through trial and error as it is best to read the documentation and >not believe it (it is 20 years or so out of date). This usually results in a few >corrupt registers and every so often a crashed machine, much to the chagrin of >fellow developers. Perhaps the best way to go about it is to read the subroutine >documentation (if it has any), and use the registers that it tells you not to >;-) I guess I was spoilt in the documentation area. Ultimate employed an EXCELENT documentor (Where are you now, Delores ?). Our documentation was so upto date the ink was always wet. Delores would come to our offices when a project was complete and perform a brain scan and would return a week or two later with documentation that would lead to comments like 'I now understand what is it that I have developed !'. >The one advatange Pick has is the fact that > ^^ or disdvantage is easily argued too! The kernel debugger of a Unix > system is also built in. >: the system debugger is part of the O/S. I get a program that gets a FLZ on pick >: because of a typo or some such, I can 'fix' the errant element in my workspace >: and re-execute the instruction. >Oh really? This works every time does it? No, not every time, but now I don't have it I have lost count of the number of times I have had to recompile a program to fix one MINOR bug so I could get in and fix the BIG BUG ! >: Under unix, if I don't run the program under >: the debugger, I get a core image that is next to useless and if I am under the >: debugger, I might be able to fix the bad data but I cannot re-direct the program >: so I cannot continue testing without a re-compile. >This is one of the most crass statements I ever heard. Just because you don't >understand how to use a core dump does not make it useless. I personally don't >understand... (OK so there is nothing that I would admit to not understanding >;-), but if there were it would not make it useless just because I did not understand This is not a question of understanding, it is one of missing functionality. I know how to use a unix debugger, but if you can't control the execution of the program after it is crashed, I am forced to WAIT for a compile before I can proceed down the path to a bug free program, and if I have been STUPID ENOUGH to not have compiled all my modules with the '-g' option, then all I get to see are hardware registers and machine instructions. REALLY BLOODY HELPFUL !!!! >it =:-). Also, the first thing that a debugger looks for when you load a Unix >executable is a core dump to analyse, so what is your point about running under >the debugger or not? No, I don't want to load the debugger and look back into the past. I want the debugger to be there when a program crashes so I can look at the present, (e.g. what locks/semaphores are set [should I reset them so other processes can continue], what is in shared memory, Oh, I see the problem, my counter was 6 and it should be 3), I want the debugger to take me into the future, I want to be able to change things a possibly re-execute the failed instruction because I know if I can get it running again it will clean itself up and I wont have to go back to the 'cpio' I took last week. >The ability to redirect a program is questionable as if you need to get >back very far in the execution path you could have restarted the program under >the same conditions and hit a break point before you got the current conditions >right. More often than not you will just get lost in conditionals and BSLs. I understand the limitations of being able to control program execution. But when you have two options, bandage up the code so it will release all the resources it has collected and have it stop in an orderly manner or loose two days while a database or system rebuild is performed, I KNOW WHAT IS BEST. I was responsible for ultimate's TCL stacker and there where times during testing that I turned my system into dog meat (you'll never guess what colour I turned the day I overwrote the SYSTEM file !), and sometimes I'd just restore and try again, other times I would rebuild the system and continue on. Recently I have had unix programs trash databases that have required a complete reload of the database becuase the program when toes up and the database consistancy was lost. Suffice to say, I now have a crash recovery program (2 weeks to develop) that will allow me to survive a limited crash. >For the right person, a core dump is a valuable pice of information. You may >have been using one of the myriad of bad Unix debuggers available though. At >least that is not the only one you are forced to use! Also I assure you that if >core dumps were useless to Unix programmers they would have been junked long ago >in favour of something better. I have to agree, a core dump is valuable, but there was a time when people though sharp sticks (Hi Dennis, sorry I can't buy one of your sticks) and a very large expanse of sand were important communications devices. And there is something better, a debugger in the O/S. I've see it (I even written one [I re-wrote ultimate's BASIC debugger]). Remember, you are talking about people who think you can create a database using cat, grep and sed ! These unix people didn't think locking in the O/S was important BECUASE THEY DIDN'T SHARE DATA IN THEIR OFFICE ! >: And debuging in C code on >: MSDOS, well as henry says 'ctl-alt-del' is all that is left ! >I am talking about real operating system not junk like MSDOS. However, I would >disgree here in that in recent times some of the debuggers for thse kind of >debuggers have got pretty good. Not the debuggers, but the IDEs are great for program development, but again, the user types 8 instead of 6 your program dies and you don't know why (becuase the bloody user lied about what they typed !). >: >: is the famous write-only C style. :-) Some people have been doing it for years. >: >Yeah, this is not a language-limited skill. >Quite. Some are born to code and some are not. Did you know there are three types of people in the world, those who can count and those who can't ! >jim. regards, dave. ------------------------------------------------------------------------------- | _ _ | | | | o o | David Rose, | .--_|\ | | ! | Fly By Night Programming, | / \ | | '''=``` | Australia. | \_.--.*/ | | ~ | | v | ------------------------------------------------------------------------------- Most people I know think that I am crazy (.. Billy Thorpe circa 1973) Especially the "application programmers" on comp.databases.pick (me circa 1994) Article 1816 of comp.databases.pick: Newsgroups: comp.databases.pick Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!news.alpha.net!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!heggers From: heggers@netcom.com (Henry Eggers) Subject: Re: # of PICK systems in the world Message-ID: Organization: NETCOM On-line Communication Services (408 261-4700 guest) X-Newsreader: TIN [version 1.2 PL1] References: <31637n$r94@lia.bga.com> <31ajkh$1hc@werple.apana.org.au> <31bjro$dfh@lia.bga.com> Date: Fri, 5 Aug 1994 00:02:43 GMT Lines: 31 Michael K. Makuch (makuch@bga.com) wrote: : In article <31ajkh$1hc@werple.apana.org.au>, : David Rose wrote: : >makuch@bga.com (Michael K. Makuch) writes: [dele] : >>How many PICK systems are there up and running in the world? As far as I can tell, the market is about $50M/yr for platformware to the manufacturer. It works out to about $100 per seat, so that's about 500k seats a year. At a 5-year turn over rate, that's about 2.5m seats. From another point of view, a peak of 100k 'minicomputer' versions is probably about right. Since that point, the PC business has made selling minicomputers difficult, the pc's have become minicomputers, and there has been an unknown proliferation of 'very small systems' operating without unix. But comparing the counts isn't realistic. You use unix machines for all sorts of 'embedded' systems purposes -- all of internet, for instance. You only use one of the other machines when you have a business to run. And it tends to be able to run the whole business. So, it has been suggested for years that there would be a migration to other pastures on the part of the serious applications. Does anyone know where they are going? Novel? Enhanced relational model? VB with ODBC and a server? 'Fourth Generation Languages?' SB+ with Oracle? Nowhere? Regards, hve.