Xref: utzoo alt.folklore.computers:9155 comp.periphs:3407 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mintaka!think.com!spool2.mu.edu!sdd.hp.com!usc!jarthur!uunet!rufus!drake.almaden.ibm.com!drake From: drake@drake.almaden.ibm.com Newsgroups: alt.folklore.computers,comp.periphs Subject: Re: External Sorting Message-ID: <475@rufus.UUCP> Date: 30 Jan 91 08:52:27 GMT References: <1991Jan28.031017.19886@comp.vuw.ac.nz> <467@rufus.UUCP> Sender: news@rufus.UUCP Organization: IBM Almaden Research Center Lines: 27 In article yossie@fnal.fnal.gov (Yossie Silverman) writes: >Does IBM still include a "READ BACKWARDS" instruction in their tape >drives? This instruction, I am told (and it seems logical) is primarily >for sort routines, where reading backwards on the tape could actually save >some time. Of course the bytes come in reversed, but that just needs some >extra code to deal with. Yes, current drives still have a "Read Backward" command. As previously mentioned, this does NOT result in the bytes being placed in memory backwards; the buffer appears "normal" after the I/O operation has completed. The one case where "read backwards" doesn't work is if the new "IDRC" feature is being used. This feature lets the tape drive perform compression in hardware on data as it is written on the tape (transparently to applications). If a particular tape is written using IDRC, then "read backwards" actually has to jockey the tape around and read forwards, not backwards. Read Backwards is also apparently used in commercial transaction processing systems such as IMS where a tape drive is constantly keeping a log of transactions as they are executed. Read Backwards is used in recovery to examine the log without rewinding the tape...potentially a Big Win. Sam Drake / IBM Almaden Research Center Internet: drake@ibm.com BITNET: DRAKE at ALMADEN Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861