From owner-srs@net.bio.net Mon Jun 12 23:00:00 1995 Path: biosci!bloom-beacon.mit.edu!spool.mu.edu!usenet.eel.ufl.edu!noc.netcom.net!news.sprintlink.net!aimnet1.aimnet.com!aimnet.aimnet.com!not-for-mail From: chinabus@aimnet.com (Michael Lee) Newsgroups: schule.software,bionet.software.srs,bionet.software.acedb,bionet.software.gcg Subject: Chinese Computer Digest http://www.gy.com Date: 13 Jun 1995 02:32:29 -0700 Organization: AIMNet Corp. Lines: 28 Message-ID: <3rjlvd$gb3@aimnet.aimnet.com> NNTP-Posting-Host: aimnet.aimnet.com Xref: biosci bionet.software.srs:85 bionet.software.acedb:627 bionet.software.gcg:1222 [Chinese Computer Digest] http://www.gy.com Chinese Computer Digest is the first Chinese Computing Magazine on the internet , it has own domain name: gy.com, the homepage of Chinese Computer Digest is at: http://www.gy.com Chinese Computer Digest is the bilingual magazine , it has both English and Chinese version, for the Chinese version, it has both GB Code and Big5 Code. Chinese Computer Digest covers following area: Apple Chinese Software Chinese Windows Software Chinese Educational Software Chinese Computer CD-Title Chinese English Translation Software Chinese Computer Fonts Chinese Personal Digital Assistant Chinese Speaking & Input Software Chinese OCR Software Computer News From China Chinese Software Company Chinese Speaking & Input Software ...... Welcome to Chinese Computer Digest, any suggestion or comments please contact with: Chinese Computer Digest 10787-A South Blany Ave., Cupertino, CA 95014 USA Tel: 408-257-9480 Email: chinabus@gy.com From owner-srs@net.bio.net Tue Jun 13 23:00:00 1995 Path: biosci!galaxy.ucr.edu!ihnp4.ucsd.edu!scripps.edu!usenet From: Akemi Yagi Newsgroups: schule.software,bionet.software.srs,bionet.software.acedb,bionet.software.gcg Subject: Re: Chinese Computer Digest http://www.gy.com Date: 14 Jun 1995 14:57:23 GMT Organization: The Scripps Research Institute Lines: 17 Message-ID: <3rmtcj$ev5@riscsm.scripps.edu> References: <3rjlvd$gb3@aimnet.aimnet.com> NNTP-Posting-Host: energy_pc.scripps.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="-------------------------------16884454920067" X-Mailer: Mozilla 1.1N (Windows; I; 16bit) To: echan@gcrc Xref: biosci bionet.software.srs:86 bionet.software.acedb:633 bionet.software.gcg:1224 This is a multi-part message in MIME format. ---------------------------------16884454920067 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Ed, Heard about this? Akemi ---------------------------------16884454920067 Content-Transfer-Encoding: 7bit Content-Type: ---------------------------------16884454920067-- From owner-srs@net.bio.net Tue Jun 13 23:00:00 1995 Path: biosci!bcm!news.msfc.nasa.gov!sol.ctr.columbia.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet.ucs.indiana.edu!sunflower.bio.indiana.edu!gilbertd From: gilbertd@sunflower.bio.indiana.edu (Don Gilbert) Newsgroups: bionet.software.srs Subject: new Genbank slows srs indexer to crawl Date: 14 Jun 1995 20:39:15 GMT Organization: Biology, Indiana University - Bloomington Lines: 44 Message-ID: <3rnhdj$mf0@usenet.ucs.indiana.edu> NNTP-Posting-Host: sunflower.bio.indiana.edu The latest release of GenBank has put SRSbuild here into a slow crawl. It has been trying to index this release for over 48 hours. It makes progress, but at a snail's pace. My guess is that this is a memory-limit problem. The previous GenBank build on this machine took probably less than 6 hours. The machine that is indexing has (merely) 32MB of real memory, and about 100mb of virtual memory. Is this slowness likely due to srs having to use virtual memory extensively? Or might this indicate some other problem? There are some machines here w/ more memory, but it will be harder for me to run srsindex on them. Another question: if I index just genbank on a different machine, is it likely that I will run into similar problems if I run srsbuild to do the cross-indexing on this original server? I'm using version 4.02 of srs on this server. Thanks for any tips -- Don Here is the current 'ps' output for this process: USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND molbio 24676 0.8 47.4 60144 13396 ? D Jun 12 294:20 srsbuild GENBANK and here is current virtual memory stats output on this server: fly% vmstat 5 procs memory page disk faults cpu r b w avm fre re at pi po fr de sr d0 d1 d2 d3 in sy cs us sy id 0 5 0 0 1920 0 51 1 2 0 0 93 8 0 5 2 171 497 109 8 5 87 1 1 0 0 1932 3 14 588 8 612 0 264 46 0 29 2 532 500 262 18 8 74 0 1 0 0 1952 3 13 640 0 664 0 355 39 0 36 0 552 502 280 6 7 87 0 3 0 0 1908 2 8 564 12 660 16 378 49 0 16 0 493 667 220 7 11 81 0 2 0 0 1964 2 22 828 28 724 0 475 36 0 38 0 555 557 239 6 14 80 1 2 0 0 1876 3 21 792 52 896 0 589 53 0 33 7 647 603 254 10 16 74 The above in my limited experience suggests this machine is paging virtual memory too much (page pi/po are kilobytes paged in/out per second) -- -- d.gilbert--biocomputing--indiana u--bloomington--gilbertd@bio.indiana.edu From owner-srs@net.bio.net Wed Jun 14 23:00:00 1995 Path: biosci!agate!howland.reston.ans.net!Germany.EU.net!news.dfn.de!news.embl-heidelberg.de!usenet From: Thure Etzold Newsgroups: bionet.software.srs Subject: Re: new Genbank slows srs indexer to crawl Date: 15 Jun 1995 16:44:00 GMT Organization: EMBL Heidelberg Lines: 69 Distribution: world Message-ID: <3rpo0g$sj@comet.EMBL-Heidelberg.DE> References: <3rnhdj$mf0@usenet.ucs.indiana.edu> NNTP-Posting-Host: falcon.embl-heidelberg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1S (X11; I; IRIX 5.3 IP20) X-URL: news:3rnhdj$mf0@usenet.ucs.indiana.edu gilbertd@sunflower.bio.indiana.edu (Don Gilbert) wrote: > > >The latest release of GenBank has put SRSbuild here into a slow >crawl. It has been trying to index this release for over 48 hours. >It makes progress, but at a snail's pace. My guess is that >this is a memory-limit problem. The previous GenBank build on this >machine took probably less than 6 hours. > >The machine that is indexing has (merely) 32MB of real memory, and >about 100mb of virtual memory. Is this slowness likely due to >srs having to use virtual memory extensively? Or might this indicate >some other problem? There are some machines here w/ more memory, >but it will be harder for me to run srsindex on them. > The SRS indexing needs physical memory ...performance decreases enormously if the process starts swapping! The memory consumption can be decreased by indexing all indices for genbank in several rounds. The 'srscheck' command has an option '-s' that lets you limit the memory requiremnt (number of kb) ...the size of all the indices is computed by using values in genbank.sdl "/maxIndexSizeKb" and "/alloc_factor=0.8" ..this numbers of course are not always being updated and give only a rough estimate ...but it is possible to force srscheck to split index building into separate rounds. Here is an example: > srscheck -l genbank -xdir /trash/etzold/ -o /dev/tty -s 100000 gives me srsbuild GENBANK -f ' ID DAT ACC DEF KEY ORG AUT TIT REF FTS SL' -xdir \ '/trash/etzold/' -odir 'SRSINX:' -env 'unix' > srscheck -l genbank -xdir /trash/etzold/ -o /dev/tty -s 10000 gives srsbuild GENBANK -f ' ID DAT ACC' -xdir '/trash/etzold/' -odir 'SRSINX:' -env \ 'unix' srsbuild GENBANK -f ' DEF KEY ORG' -xdir '/trash/etzold/' -odir 'SRSINX:' -env \ 'unix' srsbuild GENBANK -f ' AUT TIT REF' -xdir '/trash/etzold/' -odir 'SRSINX:' -env \ 'unix' srsbuild GENBANK -f ' FTS SL' -xdir '/trash/etzold/' -odir 'SRSINX:' -env 'unix' note that for the index compression is ALWAYS done for a single index! >Another question: if I index just genbank on a different machine, >is it likely that I will run into similar problems if I run srsbuild >to do the cross-indexing on this original server? > the index-building needs much less memory and has never been a problem sofar. regards Thure =============================================================================== Thure Etzold | EMBL E-mail: etzold@embl-heidelberg.de | Postfach 10.2209 Tel: (49) 6221 387529 | 69012 Heidelberg Fax: (49) 6221 387517 | Germany From owner-srs@net.bio.net Wed Jun 14 23:00:00 1995 Path: biosci!bloom-beacon.mit.edu!usc!howland.reston.ans.net!pipex!sunsite.doc.ic.ac.uk!hgmp.mrc.ac.uk!news.hgmp.mrc.ac.uk!pmr From: pmr@sanger.ac.uk (Peter Rice) Newsgroups: bionet.software.srs Subject: Re: new Genbank slows srs indexer to crawl Date: 15 Jun 1995 09:43:57 GMT Organization: MRC Human Genome Resource Centre Lines: 36 Message-ID: References: <3rnhdj$mf0@usenet.ucs.indiana.edu> NNTP-Posting-Host: unst.sanger.ac.uk In-reply-to: gilbertd@sunflower.bio.indiana.edu's message of 14 Jun 1995 20:39:15 GMT In article <3rnhdj$mf0@usenet.ucs.indiana.edu> gilbertd@sunflower.bio.indiana.edu (Don Gilbert) writes: > The latest release of GenBank has put SRSbuild here into a slow > crawl. It has been trying to index this release for over 48 hours. > It makes progress, but at a snail's pace. My guess is that > this is a memory-limit problem. The previous GenBank build on this > machine took probably less than 6 hours. > > The above in my limited experience suggests this machine is paging virtual > memory too much (page pi/po are kilobytes paged in/out per second) It does indeed sound like a memory limit. Does your srscheck+srsupdate index GenBank all in one go, or in reasonable chunks? The extra EST data in the new genBank has probably changed the relative index sizes - I certainly saw major differences between EMBL (March-95) and EMBLNEW (Apr-95 onwards) as the WashU-Merck EST data arrived. Changing the relative index sizes in odd/genbank.sdl may help. Oops. I see odd/embl.sdl uses relIndexSize but odd/genbank.sdl uses alloc_factor. Does this also work to split the indexing? One for Thure to answer ...... You can pick up our embl.sdl file to see how we control EMBL and EMBLNEW at present - though I have to edit it any day now when EMBL 43 appears. Aaaarrrrrggghhhh. It's there. Pick up embl.sdl if you dare, but I'll be editing it today ... The URL is http://www.sanger.ac.uk/srs/srsc?-odd+EMBL Otherwise I would guess an alternative machine would be a good solution. Should take less than 48 hours to test it anyway :-) -- ------------------------------------------------------------------------ Peter Rice | Informatics Division E-mail: pmr@sanger.ac.uk | The Sanger Centre Tel: (44) 1223 494967 | Hinxton Hall, Hinxton, Fax: (44) 1223 494919 | Cambs, CB10 1RQ URL: http://www.sanger.ac.uk/~pmr/ | England From owner-srs@net.bio.net Thu Jun 15 23:00:00 1995 Path: biosci!bcm!cs.utexas.edu!howland.reston.ans.net!Germany.EU.net!news.dfn.de!news.embl-heidelberg.de!usenet From: Thure Etzold Newsgroups: bionet.software.srs Subject: Re: new Genbank slows srs indexer to crawl Date: 16 Jun 1995 09:06:10 GMT Organization: EMBL Heidelberg Lines: 23 Distribution: world Message-ID: <3rrhi2$8ab@comet.EMBL-Heidelberg.DE> References: <3rnhdj$mf0@usenet.ucs.indiana.edu> NNTP-Posting-Host: falcon.embl-heidelberg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1S (X11; I; IRIX 5.3 IP20) X-URL: news:PMR.95Jun15104357@unst.sanger.ac.uk pmr@sanger.ac.uk (Peter Rice) wrote: >Changing the relative index sizes in odd/genbank.sdl may help. Oops. I >see odd/embl.sdl uses relIndexSize but odd/genbank.sdl uses alloc_factor. >Does this also work to split the indexing? One for Thure to answer ...... The "alloc_factor" is indeed obsolete and should have been replaced by "relIndexSize". These numbers are easy to obtain: Select the largest *.inx file (only the .inx and not the .ids structure of an index has to be kept in memory during indexing). Assign the size in kb to attribute "maxIndexSizeKb" of object #library. Then compare the size of all other indices' .inx file to the largest and add the "relIndexSize" to the data-fields #field definition - this number must range between 0 and 1. -- =============================================================================== Thure Etzold | EMBL E-mail: etzold@embl-heidelberg.de | Postfach 10.2209 Tel: (49) 6221 387529 | 69012 Heidelberg Fax: (49) 6221 387517 | Germany From owner-srs@net.bio.net Sun Jun 18 23:00:00 1995 Path: biosci!bloom-beacon.mit.edu!usc!howland.reston.ans.net!plug.news.pipex.net!pipex!edi.news.pipex.net!pipex!sunsite.doc.ic.ac.uk!daresbury!bioftp.unibas.ch!news.vub.ac.be!ben!gbottu From: gbottu@ben.vub.ac.be (Guy Bottu) Newsgroups: bionet.software.srs Subject: the vanishing index mystery Date: 19 Jun 1995 15:03:19 GMT Organization: the Belgian EMBnet Node Lines: 11 Message-ID: <3s43jn$9ci@rc1.vub.ac.be> NNTP-Posting-Host: ben.vub.ac.be. X-Newsreader: TIN [version 1.2 PL2] After upgrading from srs 4.4 to srs 4.5, I have observed something strange : the "Sequence" field of TFSITE is not indexed anymore. Yet the srsupdate script contains a line : srsbuild TFSITE -c -f ' SEQ' -xdir 'SRSINX:' -odir 'SRSINX:' -env 'unix' executing this line gives no error message, even when parameter -w is appended, only, the indexes tfsite_seq.* are not made... Did someone ever observe something similar ? Does someone have an idea what might be the cause ? Guy Bottu From owner-srs@net.bio.net Sun Jun 18 23:00:00 1995 Path: biosci!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!Germany.EU.net!news.dfn.de!news.embl-heidelberg.de!usenet From: Thure Etzold Newsgroups: bionet.software.srs Subject: Re: the vanishing index mystery Date: 19 Jun 1995 17:56:36 GMT Organization: EMBL Heidelberg Lines: 46 Distribution: world Message-ID: <3s4dok$o49@comet.EMBL-Heidelberg.DE> References: <3s43jn$9ci@rc1.vub.ac.be> NNTP-Posting-Host: falcon.embl-heidelberg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1S (X11; I; IRIX 5.3 IP20) X-URL: news:3s43jn$9ci@rc1.vub.ac.be gbottu@ben.vub.ac.be (Guy Bottu) wrote: >After upgrading from srs 4.4 to srs 4.5, I have observed something strange : >the "Sequence" field of TFSITE is not indexed anymore. Yet the srsupdate >script contains a line : >srsbuild TFSITE -c -f ' SEQ' -xdir 'SRSINX:' -odir 'SRSINX:' -env 'unix' >executing this line gives no error message, even when parameter -w >is appended, only, the indexes tfsite_seq.* are not made... hi Guy, yes you spotted a problem ...which is that two definitions for the data-field "Sequence" exist. One for SwissProt where the Sequence data-field is the line starting with "SQ" and is for display only and the "Sequence" data-field for Tfsite where the sequence should be really indexed. The solution is to generate a new field type "DNASequence" definition. So just add the following into the file "srsgeneral.sdl": #srsfield /id=%DF_DNASEQ /shortname="SEQ" /name="DNASequence" /build=@F_BLDKEY /itype=key then change the pointer in transfac.sdl from @DF_SEQ to @DF_DNASEQ: #field /itype=key /ftype=@DF_DNASEQ /idtype=@ENTRY_ID /find=sequence /begstr="SE " /nextstr="SE " after running srssection try srsbuild -d tfsite -f dnasequence to test if the sequences are really extracted regards thure =============================================================================== Thure Etzold | EMBL E-mail: etzold@embl-heidelberg.de | Postfach 10.2209 Tel: (49) 6221 387529 | 69012 Heidelberg Fax: (49) 6221 387517 | Germany From owner-srs@net.bio.net Mon Jun 19 23:00:00 1995 Path: biosci!daresbury!bioftp.unibas.ch!news.vub.ac.be!ben!embadmin From: embadmin@ben.vub.ac.be (BEN node administration) Newsgroups: bionet.software.srs Subject: Re: the vanishing index mystery Date: 20 Jun 1995 13:36:09 GMT Organization: Belgian EMBnet Node Lines: 14 Distribution: world Message-ID: <3s6is9$2rr@rc1.vub.ac.be> References: <3s43jn$9ci@rc1.vub.ac.be> <3s4dok$o49@comet.EMBL-Heidelberg.DE> NNTP-Posting-Host: ben.vub.ac.be. X-Newsreader: TIN [version 1.2 PL2] Thanks Thure, you have helped me on the road !!! I have however found a simpler solution. The problem seems to be interference between the /shortname="SEQ" attributes of the objects #srsfield /id=%DF_SEQUENCE and #srsfield /id=%DF_SEQ. I have of course no idea why this should be so, it depends on how SRS works. So, I have replaced : #srsfield /id=%DF_SEQUENCE /itype=show /shortname="SEQ" /name="Sequence" /key=S in the file srsgeneral.sdl by : #srsfield /id=%DF_SEQUENCE /itype=show /shortname="SQ" /name="Sequence" /key=S and everything works fine. Guy Bottu From owner-srs@net.bio.net Tue Jun 27 23:00:00 1995 Path: biosci!agate!sunsite.doc.ic.ac.uk!daresbury!trane.uninett.no!nntp.uio.no!rodrigol From: rodrigol@biomaster.uio.no (Rodrigo Lopez) Newsgroups: bionet.software.srs Subject: prints.sdl Date: 28 Jun 1995 13:39:58 GMT Organization: University of Oslo Lines: 16 Message-ID: <3srm3e$44o@hermod.uio.no> NNTP-Posting-Host: biomaster.uio.no X-Newsreader: TIN [version 1.2 PL2] Hello, I was wondering if anyone has a prints.sdl available somewhere I can 'borrow'. The latest version of this db has a lot of interesting and relevant info that would be nice under the SRS system. R:) -- *************************************************************************** * RODRIGO LOPEZ SERRANO rodrigol@biotek.uio.no * * Norwegian EMBnet node Tel:xx-47-22958756 Fax:xx-47-22694130 * * gopher= biomaster.uio.no 70 WWW= http://biomaster.uio.no/ * *************************************************************************** From owner-srs@net.bio.net Tue Jun 27 23:00:00 1995 Path: biosci!bcm!cs.utexas.edu!howland.reston.ans.net!torn!ccshst05.cs.uoguelph.ca!ccshst01.cs.uoguelph.ca!hzheng From: hzheng@uoguelph.ca (Hui Zheng) Newsgroups: bionet.software.srs Subject: Free Help in UofG to Handle DNA with C/C++. Date: 28 Jun 1995 12:31:34 GMT Organization: University of Guelph Lines: 3 Message-ID: <3sri36$ljf@ccshst05.cs.uoguelph.ca> NNTP-Posting-Host: ccshst01.cs.uoguelph.ca X-Newsreader: TIN [version 1.2 PL2] If your problem can not be solved by general software such as DNASIS, try ask me. I can use assembler if the speed is your key concern. Frank Peng. From owner-srs@net.bio.net Wed Jun 28 23:00:00 1995 Newsgroups: bionet.software.srs Path: biosci!agate!howland.reston.ans.net!EU.net!dkuug!Norway.EU.net!trane.uninett.no!daresbury!hgmp.mrc.ac.uk!ebi.ac.uk!jecop From: jecop@ebi.ac.uk (Jeroen Coppieters) Subject: Re: NRSub release 5 availability Sender: news@ebi.ac.uk (Mr news) Message-ID: Date: Wed, 28 Jun 1995 23:19:55 GMT References: <3ssdmn$sh8@comet.EMBL-Heidelberg.DE> Organization: European Bioinformatics Institute X-Newsreader: TIN [version 1.2 PL2] Lines: 56 Thure Etzold (etzold) wrote: : I am posting this message from Guy Perriere : since I think it is of general interest: ... : Note for SRS developers: there is a slight modification in the : DE field of the entries. Indeed, EMBL sequences are now : referenced with the accession number AND the mnemonic. So, take : care when implementing cross-references between NRSub and EMBL. : I rewrote mu nrsub.sdl file (which you can get from the EBI srs server) as well as the parts in hyperlink.sdl I haven't had the time to upgrade from SRS 4.04 yet, and I still have not found a way to activate the swissprot xref's in hyperlink.sdl If anyone else wants ro look into it, please do, and let me know the changes you made to the sdl files Jeroen : Guy Perriere : Laboratoire de Biometrie, Genetique et : Biologie des Populations, URA CNRS 2055 : Universite Claude Bernard - Lyon 1 : 43, bd. du 11 Novembre 1918 : 69622 Villeurbanne Cedex : France : Email: perriere@biomserv.univ-lyon1.fr : : -- : =============================================================================== : Thure Etzold | EMBL : E-mail: etzold@embl-heidelberg.de | Postfach 10.2209 : Tel: (49) 6221 387529 | 69012 Heidelberg : Fax: (49) 6221 387517 | Germany -- ============================================================== . O . Jeroen Coppieters . O O o O . Software Support O O O O *o O O Jeroen.Coppieters@embl-ebi.ac.uk O O O O( *o )O O (or jecop@ebi.ac.uk) )O O O O o* O O( ++44 1223 494422 O O O O( o* )O O )O O O O *o O O( EMBL Outstation EBI O O O O( *o )O O (European Bioinformatics Institute) )O @ O O o* O O( Hinxton Hall O O O( o* )O(' Hinxton ` O( *o O ' Cambridge CB10 1RQ ` O ' UK http://www.ebi.ac.uk ============================================================== From owner-srs@net.bio.net Wed Jun 28 23:00:00 1995 Path: biosci!daresbury!bioftp.unibas.ch!news.vub.ac.be!idefix.CS.kuleuven.ac.be!Belgium.EU.net!EU.net!Germany.EU.net!news.dfn.de!news.embl-heidelberg.de!usenet From: Thure Etzold Newsgroups: bionet.software.srs Subject: NRSub release 5 availability Date: 28 Jun 1995 20:22:47 GMT Organization: EMBL Heidelberg Lines: 63 Distribution: world Message-ID: <3ssdmn$sh8@comet.EMBL-Heidelberg.DE> NNTP-Posting-Host: falcon.embl-heidelberg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1S (X11; I; IRIX 5.3 IP20) X-URL: news:bionet.software.srs I am posting this message from Guy Perriere since I think it is of general interest: NRSub Release 5 (June 1995) The release 5 of NRSub (the Non-Redundant Bacillus subtilis data base) is now available at the NIG anonymous FTP (ftp.nig.ac.jp or 133.39.3.6) in the directory /pub/db/nrsub. It is also possible to access NRSub through World Wide Web at URLs: http://acnuc.univ-lyon1.fr/nrsub/nrsub.html or http://ddbjs4h.genes.nig.ac.jp/ The distribution includes: - The NRSub database under ACNUC and the sources of the query program for line mode use (file NRSub.tar.Z). - The flat version of NRSub in EMBL format (file NRSub.dat or NRSub.dat.Z). - The binaries of the graphical interface for browsing an ACNUC database (files query_win.*.Z). Query_win.SUN file is for Sun under SunOS, query_win.SOL is for Sun under Solaris, query_win.RS6000 is for IBM RISC, query_win.ALPHA is for DEC Alpha, and query_win.SGI is for Silicon Graphics. NRSub release 5 contains a total of 237 contigs (62 composite) built from the SubtiList database release 7. All these sequences are chromosomal (plasmidic sequences are removed) and totalize 1,380,098 bp. This represents approximatively 33% of the entire Bacillus subtilis chromosome consisting of about 4,165 kbp. These sequences contain 1197 CDS (444 ORFs), 72 tRNAs and 27 rRNAs. Also, 453 bibliographic references can be accessed. Note for SRS developers: there is a slight modification in the DE field of the entries. Indeed, EMBL sequences are now referenced with the accession number AND the mnemonic. So, take care when implementing cross-references between NRSub and EMBL. Guy Perriere Laboratoire de Biometrie, Genetique et Biologie des Populations, URA CNRS 2055 Universite Claude Bernard - Lyon 1 43, bd. du 11 Novembre 1918 69622 Villeurbanne Cedex France Email: perriere@biomserv.univ-lyon1.fr -- =============================================================================== Thure Etzold | EMBL E-mail: etzold@embl-heidelberg.de | Postfach 10.2209 Tel: (49) 6221 387529 | 69012 Heidelberg Fax: (49) 6221 387517 | Germany From owner-srs@net.bio.net Wed Jun 28 23:00:00 1995 Path: biosci!agate!howland.reston.ans.net!EU.net!dkuug!Norway.EU.net!trane.uninett.no!daresbury!hgmp.mrc.ac.uk!sanger.ac.uk!pmr From: pmr@sanger.ac.uk (Peter Rice) Newsgroups: bionet.software.srs Subject: Re: NRSub release 5 availability Date: 29 Jun 1995 08:50:06 GMT Organization: The Sanger Centre Lines: 41 Distribution: world Message-ID: References: <3ssdmn$sh8@comet.EMBL-Heidelberg.DE> NNTP-Posting-Host: unst.sanger.ac.uk In-reply-to: Thure Etzold's message of 28 Jun 1995 20:22:47 GMT In article <3ssdmn$sh8@comet.EMBL-Heidelberg.DE> Thure Etzold writes: > I am posting this message from Guy Perriere > since I think it is of general interest: > > NRSub Release 5 (June 1995) > > Note for SRS developers: there is a slight modification in the > DE field of the entries. Indeed, EMBL sequences are now > referenced with the accession number AND the mnemonic. So, take > care when implementing cross-references between NRSub and EMBL. The Sanger Centre has installed NRSub 5, and has a modified nrsub.sdl file which handles the new DE field syntax. The clues to whether a site has installed NRSub 5 correctly are: a. 237 entries in NRSub (they have the new data) b. more than 200 links to EMBL (they have modified nrsub.sdl) [ Hello Jeroen .... are you there? .... calling EBI .... ] The URL for our nrsub.sdl is, as usual: http://www.sanger.ac.uk/srs/srsc?-odd+NRSUB or via any site's status page, such as: http://www.sanger.ac.uk/srs/status.html and click on the "!?" for NRSUB at The Sanger Centre, then go down to the nrsub.sdl link. That is our local copy of the file. Yet another of the wonders of SRS. -- ------------------------------------------------------------------------ Peter Rice | Informatics Division E-mail: pmr@sanger.ac.uk | The Sanger Centre Tel: (44) 1223 494967 | Hinxton Hall, Hinxton, Fax: (44) 1223 494919 | Cambs, CB10 1RQ URL: http://www.sanger.ac.uk/~pmr/ | England From owner-srs@net.bio.net Thu Jun 29 23:00:00 1995 Newsgroups: bionet.software.srs Path: biosci!daresbury!bioftp.unibas.ch!doelz From: doelz@comp.bioz.unibas.ch (Reinhard Doelz) Subject: Re: srscheck/build colliding with already in progress build Message-ID: <1995Jun30.144605.21001@comp.bioz.unibas.ch> Organization: EMBnet Switzerland [Basel] X-Newsreader: TIN [version 1.2 PL2] References: <3t0u1j$l3@usenet.ucs.indiana.edu> Date: Fri, 30 Jun 1995 14:46:05 GMT Lines: 21 Don Gilbert (gilbertd@sunflower.bio.indiana.edu) wrote: : for instance, creating "index/genbank.lock" files while one build : is in progress so that a new build of the same data will : not start? we run the following (primitive but working) shript: #!/bin/csh ps -ef | grep -v grep | grep -v add | grep srs| grep www >& /tmp/.update.status _1 if ($status != 0) then source /bioz1/software/www/SRS/etc/prep_srs ... (code here ) -- R.Doelz Klingelbergstr.70| Tel. x41 61 267 2247 Fax x41 61 267 2078| Biocomputing CH 4056 Basel| electronic Mail doelz@ubaclu.unibas.ch| Biozentrum der Universitaet Basel|-------------- Switzerland ---------------| EMBnet Switzerland:info@ch.embnet.org From owner-srs@net.bio.net Thu Jun 29 23:00:00 1995 Path: biosci!daresbury!trane.uninett.no!nac.no!Norway.EU.net!EU.net!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet.ucs.indiana.edu!sunflower.bio.indiana.edu!gilbertd From: gilbertd@sunflower.bio.indiana.edu (Don Gilbert) Newsgroups: bionet.software.srs Subject: srscheck/build colliding with already in progress build Date: 30 Jun 1995 13:26:11 GMT Organization: Biology, Indiana University - Bloomington Lines: 13 Message-ID: <3t0u1j$l3@usenet.ucs.indiana.edu> NNTP-Posting-Host: sunflower.bio.indiana.edu I tripped over my fingers yesterday and triggered another slow srsbuild of genbank on my slow system. Then another data update last night triggered srscheck/srsbuild which started rebuilding genbank while the first build was in progress. Is this a situation that can be avoided by, for instance, creating "index/genbank.lock" files while one build is in progress so that a new build of the same data will not start? Thanks, Don -- -- d.gilbert--biocomputing--indiana u--bloomington--gilbertd@bio.indiana.edu From owner-srs@net.bio.net Fri Jun 30 23:00:00 1995 Path: biosci!daresbury!trane.uninett.no!Norway.EU.net!EU.net!news.sprintlink.net!news.clark.net!usenet From: systems@khem.com (bob diggs) Newsgroups: bionet.software.srs Subject: SOFTWARE: Chemical Inventory/Waste Management/Material Safety data Date: 1 Jul 1995 15:44:28 GMT Organization: khem products incorporated Lines: 20 Message-ID: <3t3qgs$80e@clarknet.clark.net> Reply-To: info@khem.com NNTP-Posting-Host: systems.clark.net Mime-Version: 1.0 X-Newsreader: WinVN 0.99.2 If you are interested in the following - Chemical Inventory Tracking Regulatory Compliance Simplified Safety Data Sheets on-line Waste Tracking Chemical Database on-line Total Integration THEN YOU SHOULD VISIT OUR WEB HOME PAGE!!! URL : http://www.khem.com/khem/home.html EMAIL: info@khem.com See you there. Khem Products, Incorporated  From owner-srs@net.bio.net Fri Jun 30 23:00:00 1995 Path: biosci!agate!howland.reston.ans.net!Germany.EU.net!news.dfn.de!news.embl-heidelberg.de!usenet From: Thure Etzold Newsgroups: bionet.software.srs Subject: Re: srscheck/build colliding with already in progress build Date: 1 Jul 1995 17:07:18 GMT Organization: EMBL Heidelberg Lines: 67 Distribution: world Message-ID: <3t3vc6$p4c@comet.EMBL-Heidelberg.DE> References: <3t0u1j$l3@usenet.ucs.indiana.edu> NNTP-Posting-Host: falcon.embl-heidelberg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1S (X11; I; IRIX 5.3 IP20) X-URL: news:3t0u1j$l3@usenet.ucs.indiana.edu similar to reinhard's script we use a perl script that checks first if some srs updating routine already runs ...the script is called by cron every hour - the problem is that cron jobs are "niced" and we want to give SRS indexing a high priority ...btw Don, this also might also have slowed down GenBank indexing...so the trick is to "rsh" the srsupdate command instead of just calling it by "system" ...bit silly ...but works first line says "perl5" but Perl4 should also work! ------------------------------------------------------- #!/usr/pub/bin/perl5 # # program: srsindex # author: thure etzold # date: February 2, 1994 # # checks if some SRS indexing is already in progress and dies ...else # checks and updates indices # # ===================================================================== # modify by : Antoine de Daruvar # date: March 17, 1995 # # - redirect STDOUT and STDERR to files # - move the logfile to /data/update/trace_job # - move the update file to /data/update/temp # - control the size of the log file (run file_restriction) # # ===================================================================== $this_file = $0; $this_file =~ s,.*/,,; open(STDOUT,">/data/update/trace_job/$this_file.out"); open(STDERR,">/data/update/trace_job/$this_file.err"); $tmp = `ps -edalf`; @proc = split ("\n", $tmp); foreach (@proc) { if (/srsbuild/ || /srscheck/ ) { exit; # some indexing job is running already } } $srsupd = "/data/update/temp/srsupd.csh"; $srslog = "/data/update/trace_job/srsupd.log"; $com = "source /opt/srs/etc/prep_srs >>& $srslog; " . "srscheck -o $srsupd >>& $srslog;" . "$srsupd >>& $srslog;date >>& $srslog"; # the rsh is to prevent default nicing for cron jobs system ("rsh phenix \"csh -c \'$com'\""); # avoid overgrowing of the log file (restrict it to 5000 lines) system ("/data/manage/file_restriction $srslog H 5000"); exit; ----------------------------- =============================================================================== Thure Etzold | EMBL E-mail: etzold@embl-heidelberg.de | Postfach 10.2209 Tel: (49) 6221 387529 | 69012 Heidelberg Fax: (49) 6221 387517 | Germany