Message-ID: <3C2D4708.6EA1B913@gazonk.del> From: "Foobar T. Clown" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: "blocking factors" (Was: Tapes) References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 48 X-Trace: +rUPLp/kijhmN5IH8EDdFpQRv5/KZso+5pU9jCzPNlrrHXRj3DVidbcvQzCHsZSwbVykVHebAMvN!hTKuXDCFUXnpt0uZC7lhKdAE/kDG8V3BGJXEtL5h9d4pZDMgBNdOv73kmSxFczoPpg== X-Complaints-To: abuse@gtei.net X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly NNTP-Posting-Date: Sat, 29 Dec 2001 04:30:38 GMT Distribution: world Date: Sat, 29 Dec 2001 04:30:39 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!out.nntp.be!propagator-SanJose!in.nntp.be!feedwest.news.agis.net!aleron.net!paloalto-snh1.gtei.net!news.gtei.net!paloalto-snr2.gtei.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97745 "Arargh!" wrote: > > "Foobar T. Clown" wrote: [...about block sizes on 1/2 inch mag tape...] > Every system that I worked on that could read a 9-track tape, could > read up to 32767 bytes/block. [...] I gotta admit, I never had to deal with tape blocks as small as 80 bytes either, but I do remember being careful not to exceed 1600 byte reads and writes (80-byte records, with a "blocking factor" of 20). What I don't remember is whether that limit was imposed by some system that I actually laid hands on, or whether it was just handed down to me as "common wisdom" from someone older and wiser than myself. It might have been the limit on the size of DISK reads and writes on the IBM 1130 at the place where I worked that summer when I was 17. I remember just about giving my boss a heart attack on my second week on the job. It seems that when they ran the weekly update of I-forget- which-two-moby-databases (maybe inventory vs. shop orders or some such), the job terminated after less than ten minutes instead of the usual two hours. He'd reluctantly given permission for me to change the program the week before, but I guess he didn't fully understand what I'd set out to accomplish. Now, I know that when it AIN'T broke, you AREN'T supposed to fix it, but this was a special case: See, they sat me at this empty desk that was *IN* the machine room, and the reason why it was there in the first place is that it had been PUT there SPECIFICALLY to keep the disk drive from walking across the room when they ran that particular weekly job. Naturally, the first time I saw it happen (felt it is more like), I asked the operator what he was running, and I dove into the code, and I did not come up for air until I knew what had to be done. Allocate a couple of 1600 byte arrays (there's that number I was telling you about), some index variables, replace all of the I/O statements with calls on a couple of magic subroutines... See, the one database was on an inner track, and the other one was somewhere out near the edge of the platter, and this weekly job only used a couple of minutes of CPU time. It spent the rest of the whole goddam two hours seeking back and forth between the two files. All I did was give it a couple of disk buffers so it could read and write twenty records at a time instead of one at a time the way it had done for the past ten years. Boss sure paid a lot closer attention the next time I said I wanted to "fix" something. -- Foo! ###### From: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: 29 Dec 2001 05:12:45 GMT Organization: The National Capital FreeNet Lines: 25 Message-ID: References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> Reply-To: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) NNTP-Posting-Host: freenet10 X-Trace: freenet9.carleton.ca 1009602765 5574 134.117.136.30 (29 Dec 2001 05:12:45 GMT) X-Complaints-To: complaints@ncf.ca NNTP-Posting-Date: 29 Dec 2001 05:12:45 GMT X-Given-Sender: ab528@freenet10.carleton.ca (Heinz W. Wiggeshoff) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!nntp.abs.net!feeder.qis.net!nntp1.roc.gblx.net!nntp.gblx.net!nntp.gblx.net!xcski.com!freenet-news!FreeNet.Carleton.CA!ab528 Xref: chonsp.franklin.ch alt.folklore.computers:97765 "Foobar T. Clown" (fubar@gazonk.del) writes: > > I gotta admit, I never had to deal with tape blocks as small as 80 bytes > either, but I do remember being careful not to exceed 1600 byte reads > and writes (80-byte records, with a "blocking factor" of 20). What I > don't remember is whether that limit was imposed by some system that I > actually laid hands on, or whether it was just handed down to me as > "common wisdom" from someone older and wiser than myself. ... "There are 8 million stories in the IBM I/O system, and this is just one of them." (Hint - B&W TV days.) So this expert consultant is asked to load a tape (2400' 6250 bpi) of data from Statistics Canada into a VSAM KSDS. Short logical records, don't recall the tape BLKSIZE. Very short primary key, < 16 bytes. Circa 50,000 records, 4331 with 3350 disks. Friggin job took more than 3 hours using a PL/I program which wrote to VSAM. I presorted the tape using SYNCSORT, and loaded the VSAM dataset using the IBM utility - total clock time went below 10 minutes. Moral of the story: 1) don't use VSAM as a batch sort utility, 2) get rid of morons ASAP. But they never listen. ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: Sat, 29 Dec 2001 10:56:54 -0500 Organization: ='SEQUENTIAL' Lines: 11 Distribution: world Message-ID: References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> NNTP-Posting-Host: p-068.newsdawg.com User-Agent: MT-NewsWatcher/3.1 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Mail-Copies-To: nobody Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!pln-e!spln!dex!extra.newsguy.com!newsp.newsguy.com!howard Xref: chonsp.franklin.ch alt.folklore.computers:97771 In article <3C2D4708.6EA1B913@gazonk.del>, "Foobar T. Clown" wrote: > Boss sure paid a lot closer attention the next time I said I wanted to > "fix" something. So it was actually -working properly- in 2 minutes? -- Howard S Shubs "Run in circles, scream and shout!" "I hope you have good backups!" Xerox is the anti-Microsoft. And visa-versa. ###### From: genew@mail.ocis.net (Gene Wirchenko) Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: Sat, 29 Dec 2001 16:48:50 GMT Organization: Posted via Supernews, http://www.supernews.com Message-ID: <3c2d5d67.48918293@news.ocis.net> Reply-To: genew@mail.ocis.net References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> X-Newsreader: Forte Free Agent 1.1/32.230 X-Complaints-To: newsabuse@supernews.com Lines: 17 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!feeder.qis.net!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97759 "Foobar T. Clown" wrote: [snip] >Boss sure paid a lot closer attention the next time I said I wanted to >"fix" something. In what way? Was he more or less inclined to let you fix? Why? Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. ###### From: Dave Daniels Subject: Re: "blocking factors" (Was: Tapes) Newsgroups: alt.folklore.computers Date: Sun, 30 Dec 2001 11:52:23 +0000 (GMT) Message-ID: <4af0f56685dave_daniels@argonet.co.uk> References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> User-Agent: Pluto/2.02e (RISC-OS/4.03) Organization: None Lines: 13 NNTP-Posting-Host: usercc97.uk.uudial.com X-Trace: 1009713354 news.dial.pipex.com 237 62.188.151.109 X-Complaints-To: abuse@uk.uu.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeed.wirehub.nl!bnewspeer00.bru.ops.eu.uu.net!bnewsifeed02.bru.ops.eu.uu.net!bnewspost00.bru.ops.eu.uu.net!emea.uu.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97802 In article , Heinz W. Wiggeshoff wrote: > So this expert consultant is asked to load a tape (2400' 6250 bpi) of > data from Statistics Canada into a VSAM KSDS. Short logical records, > don't recall the tape BLKSIZE. Very short primary key, < 16 bytes. > Circa 50,000 records, 4331 with 3350 disks. Friggin job took more > than 3 hours using a PL/I program which wrote to VSAM. Do we mention SMP APPLYs taking several days to run here? Dave Daniels ###### Message-ID: <3C2F609B.18998A33@gazonk.del> From: "Foobar T. Clown" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 27 X-Trace: /K49oBfkhrJdi6UOUgcLbHd2kjcLGB7puoY+T2o/2OywAy+5oS+E48OhrrSATqBxqGeAiQZrZOVz!BP8JfGVm0WRYzNtPmkeGcXdt6m1+0xBdMZO1IraGwc0+3O8rwVLne9+vjYcqBO3P4Q== X-Complaints-To: abuse@gtei.net X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly NNTP-Posting-Date: Sun, 30 Dec 2001 18:43:50 GMT Distribution: world Date: Sun, 30 Dec 2001 18:43:51 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!nntp-cust.primenet.com!feedwest.news.agis.net!aleron.net!paloalto-snh1.gtei.net!news.gtei.net!paloalto-snr2.gtei.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97788 Howard S Shubs wrote: > > [...about my story...] > So it was actually -working properly- in 2 minutes? IIRC, the job took something like six or ten minutes to run after I changed it, not two; and yes, it really worked. I *MAY* be guilty of embellishing the tale a little, but I wasn't kidding when I said that the original program spent almost all of its time waiting for disk I/O. I don't know what the worst case seek time for that disk drive was, but I bet it was hundreds of milliseconds, and this program would read or write a single card image from an inner track, and then seek to an outer track to read or write another, and so-on and so-on for close to two hours. Well, O.K., That's where I may be stretching the truth. I don't really remember how long the job took to run before or after. The only part I remember for sure was that I changed the program to read and write twenty sequential records at a time, and the result was a near 20x speedup. Oh, well, the other part I remember for sure is that my boss was every bit as incredulous as you are. We had to run some reports and spend a while scrutinizing the printouts before he would agree that the improved version of the program really had done what it was supposed to do. -- Foo! ###### Message-ID: <3C2F6449.2AF655D1@gazonk.del> From: "Foobar T. Clown" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> <3c2d5d67.48918293@news.ocis.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 19 X-Trace: /wObnc+D0PBb6C8kj1B3+C9ZPSTUXPN7dem3YTA33NpxNZEv9UT9VorAf0PVBw+Qng3YJdDJ75ao!Yp+al6JwnkDMb8obqWlx25eohNg2LMWF5cu3G/B770a7lYB+Tf/QEDJek70LKNCZGQ== X-Complaints-To: abuse@gte.net X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly NNTP-Posting-Date: Sun, 30 Dec 2001 19:00:09 GMT Distribution: world Date: Sun, 30 Dec 2001 19:00:09 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!paloalto-snh1.gtei.net!news.gtei.net!paloalto-snr1.gtei.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97789 Gene Wirchenko wrote: > > "Foobar T. Clown" wrote: > > [snip] > > >Boss sure paid a lot closer attention the next time I said > >I wanted to "fix" something. > > In what way? Was he more or less inclined to let you fix? Why? Not more or less inclined, just more likely to pay attention. I don't think he had thought about the consequences if I screwed up until after we ran the program for real. He was expecting that I would just shave a few minutes off the run time, so when it completed in a small fraction of the original time, he was suddenly panicked by the thought I might have destroyed the database. -- Foo! ###### Sender: lynn@LYNNPC Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> Reply-To: Anne & Lynn Wheeler From: Anne & Lynn Wheeler Message-ID: Organization: Wheeler&Wheeler Lines: 78 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Dec 2001 20:32:11 GMT NNTP-Posting-Host: 64.156.36.107 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1009744331 64.156.36.107 (Sun, 30 Dec 2001 12:32:11 PST) NNTP-Posting-Date: Sun, 30 Dec 2001 12:32:11 PST X-Received-Date: Sun, 30 Dec 2001 12:32:10 PST (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!feed.news.nacamar.de!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97798 "Foobar T. Clown" writes: > I gotta admit, I never had to deal with tape blocks as small as 80 bytes > either, but I do remember being careful not to exceed 1600 byte reads > and writes (80-byte records, with a "blocking factor" of 20). What I > don't remember is whether that limit was imposed by some system that I > actually laid hands on, or whether it was just handed down to me as > "common wisdom" from someone older and wiser than myself. standard vm distribution program was called vmfplc ... originally written for generating the monthly plc tapes (vm had monthly fixes & update tapes .... in source of course ... that was sent out to every customer). the format was data blocked 4k-byte record preceeded by 64-byte record file MFD entry (some lore that original dos was patterned after a simplified cms filesytsem ... with various kinds of changes ... including MFT/FAT instead of MFD). for the original cmsback, I did a version called vmxplc ... which blocked up to four 4k records into a single block and collapsed the MFD entry appended to the first tape block to a file. A very large percentage of files on the tape were 4k bytes (or less) so vmfplc was mostly a 4k record (at 6250 bpi ... .65in) plus .5in inter-record gap plus 64byte record (at 6250 bpi ... .01in) plus .5 inter-record gap ... effectively .65in of data for every inch of inter-record gap (40 precent data) For worst case scenario on small files, vmxplc changed that to 4k+64 byte record (.65in) for every .5in inter-record gap (nearly 50% increase in amount of data on a tape). random refs: http://www.garlic.com/~lynn/2001n.html#66 Holy Satanism! Re: Hyper-Threading Technology - Intel information. http://www.garlic.com/~lynn/99.html#149 OS/360 (and descendents) VM system? vmxplc also had a trick for my page-mapped file system. The VMFPLC FST record preceeded the first data block. I wanted the data block aligned on a 4k boundary ... so the 64byte FST was appended to the end of the first data block record for a file; not preceeding it. The obvious mapping would have had the sequence of vmxplc data records in the same order as the vmfplc sequence ... but collapsing multiple tape records into a single one. The problem would be if 64byte FST was prepended to a data record ... brought in on a page boundary ... the actual start of the data would be offset by 64bytes. The VMXPLC tape I/O operation was set to read 16k+64 with starting address on 4k boundary. The residual count from the I/O operation would indicate whether exact multiple of 4k was read or some multiple of 4k plus 64bytes (indicating the start of a new file). Since all the data records came in aligned on page boundary ... and if the disk was in pagged-mapped format ... then it was a trivial page-out operation for loading from tape to disk (modulo the appended 64byte FST for start of new file). The disk->tape was even easier with simple scatter/gather i/o. paged mapped filesystem http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door http://www.garlic.com/~lynn/94.html#2 Schedulers http://www.garlic.com/~lynn/94.html#5 Schedulers http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist http://www.garlic.com/~lynn/94.html#42 bloat http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory http://www.garlic.com/~lynn/95.html#14 characters http://www.garlic.com/~lynn/96.html#19 IBM 4381 (finger-check) http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century) http://www.garlic.com/~lynn/2000.html#75 Mainframe operating systems http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs) http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ? http://www.garlic.com/~lynn/2001c.html#89 database (or b-tree) page sizes http://www.garlic.com/~lynn/2001d.html#77 Pentium 4 Prefetch engine? http://www.garlic.com/~lynn/2001e.html#19 SIMTICS http://www.garlic.com/~lynn/2001f.html#9 Theo Alkema http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...) -- Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/ ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: Sun, 30 Dec 2001 15:59:14 -0500 Organization: ='SEQUENTIAL' Lines: 16 Distribution: world Message-ID: References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> <3C2F609B.18998A33@gazonk.del> NNTP-Posting-Host: p-018.newsdawg.com User-Agent: MT-NewsWatcher/3.1 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Mail-Copies-To: nobody Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newscore.univie.ac.at!newsgate.cistron.nl!news.tele.dk!small.news.tele.dk!171.64.14.106!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!howard Xref: chonsp.franklin.ch alt.folklore.computers:97826 In article <3C2F609B.18998A33@gazonk.del>, "Foobar T. Clown" wrote: > Oh, well, the other part I remember for sure is that my boss was every > bit as incredulous as you are. We had to run some reports and spend a > while scrutinizing the printouts before he would agree that the improved > version of the program really had done what it was supposed to do. One thing I'm aware of is just HOW SLOW the 1130 was. It wasn't built for speed; it was built to be CHEAP. You figured out a more effective use of the resources, which is a GOOD thing. -- Howard S Shubs "Run in circles, scream and shout!" "I hope you have good backups!" Xerox is the anti-Microsoft. And visa-versa. ###### Message-ID: <3C2FF8AE.9F83FB8E@ev1.net> From: Charles Richmond Reply-To: richmond@ev1.net Organization: Cannine Computer Center X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 23 NNTP-Posting-Host: 12.237.69.87 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc51.ops.asp.att.net 1009769852 12.237.69.87 (Mon, 31 Dec 2001 03:37:32 GMT) NNTP-Posting-Date: Mon, 31 Dec 2001 03:37:32 GMT Date: Mon, 31 Dec 2001 03:37:32 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!newsfeed.direct.ca!look.ca!wn1feed!wn2feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97828 "Heinz W. Wiggeshoff" wrote: > > [snip...] [snip...] [snip...] > > So this expert consultant is asked to load a tape (2400' 6250 bpi) of > data from Statistics Canada into a VSAM KSDS. Short logical records, > don't recall the tape BLKSIZE. Very short primary key, < 16 bytes. > Circa 50,000 records, 4331 with 3350 disks. Friggin job took more > than 3 hours using a PL/I program which wrote to VSAM. > > I presorted the tape using SYNCSORT, and loaded the VSAM dataset > using the IBM utility - total clock time went below 10 minutes. > > Moral of the story: 1) don't use VSAM as a batch sort utility, > 2) get rid of morons ASAP. > I am sure that most companies *would* get rid of all the morons... but the echoes in all those empty buildings would be maddening!!! -- +-------------------------------------------------------------+ | Charles and Francis Richmond | +-------------------------------------------------------------+ ###### From: jcmorris@mitre.org (Joe Morris) Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: 2 Jan 2002 14:22:49 GMT Organization: The MITRE Corporation Lines: 23 Message-ID: References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> <4af0f56685dave_daniels@argonet.co.uk> Reply-To: jcmorris@mitre.org NNTP-Posting-Host: jmorris-pc.mitre.org X-Trace: top.mitre.org 1009981369 9662 128.29.114.13 (2 Jan 2002 14:22:49 GMT) X-Complaints-To: usenet@news.mitre.org NNTP-Posting-Date: 2 Jan 2002 14:22:49 GMT X-Newsreader: NN version 6.5.6 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!newstransit.mitre.org!news.mitre.org!jcmorris Xref: chonsp.franklin.ch alt.folklore.computers:97841 Dave Daniels writes: >Do we mention SMP APPLYs taking several days to run here? Using which version of SMP? It seemed to me that there was an astable flip-flop somewhere in the design process for SMP: performance would switch back and forth between "agonizingly inefficient" and "slow". The concept behind SMP was good, and when I made a statement to that effect during the announcement of SMP at a SHARE meeting in Houston I think that I shocked Jerry Feinman (at the time the IBM rep to the OS/360 project). I'm told that after the presentation he was in a car with some other IBMers and commented to them that "IBM must have done something right. Joe Morris said something good about it." ...and speaking of SMP, has *anyone* here with OS/360 experience ever heard of anybody who actually used the Update Analysis Program (IHGUAP) that shipped with the earlier versions of the system? Or, for later systems, the JCAMOD maintenance program? Both were intended to "automate" some of the tasks of maintaining the OS itself. Neither seemed to be of much use (IMNSHO), especially IHGUAP. Joe Morris ###### From: Dave Daniels Subject: Re: "blocking factors" (Was: Tapes) Newsgroups: alt.folklore.computers Date: Thu, 03 Jan 2002 20:22:02 +0000 (GMT) Message-ID: <4af33367a5dave_daniels@argonet.co.uk> References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> <4af0f56685dave_daniels@argonet.co.uk> User-Agent: Pluto/2.02e (RISC-OS/4.03) Organization: None Lines: 24 NNTP-Posting-Host: useray73.uk.uudial.com X-Trace: 1010092434 news.dial.pipex.com 237 62.188.139.163 X-Complaints-To: abuse@uk.uu.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!lnewspeer00.lnd.ops.eu.uu.net!lnewspost00.lnd.ops.eu.uu.net!emea.uu.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:97988 In article , Joe Morris wrote: > Using which version of SMP? It seemed to me that there was an astable > flip-flop somewhere in the design process for SMP: performance would > switch back and forth between "agonizingly inefficient" and "slow". It was SMP4 under OS/VS1, and we were applying several PUT tapes' worth of maintenance to CICS in one go. We were running on a 4341. > The concept behind SMP was good, and when I made a statement to that > effect during the announcement of SMP at a SHARE meeting in Houston SMP was, and is, a good idea. The problem, or, at least the problem I found, was understanding how it was organised and what it did. But, the principle was easy enough and as long as you did not try to be clever then it was okay. It was when you spent two or three days trying to figure out how to apply a usermod which you could have done outside SMP control in an hour that you questioned its value. Dave Daniels ###### From: Brian Inglis Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: Fri, 04 Jan 2002 22:38:46 -0700 Organization: Systematic Software Lines: 42 Message-ID: <5pna3uk7oqmlbup1fnd4br2mt21v52a305@4ax.com> References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> <4af0f56685dave_daniels@argonet.co.uk> <4af33367a5dave_daniels@argonet.co.uk> Reply-To: Brian.Inglis@SystematicSw.ab.ca NNTP-Posting-Host: h-207-148-140-214.dial.cadvision.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news3.cadvision.com 1010209127 25138 207.148.140.214 (5 Jan 2002 05:38:47 GMT) X-Complaints-To: news@cadvision.com NNTP-Posting-Date: Sat, 5 Jan 2002 05:38:47 +0000 (UTC) X-Newsreader: Forte Agent 1.8/32.548 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!821914!news.imp.ch!sunqbc.risq.qc.ca!nntp.cadvision.com!207.228.64.17.MISMATCH!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:98092 On Thu, 03 Jan 2002 20:22:02 +0000 (GMT), Dave Daniels wrote: >In article , > Joe Morris wrote: >> Using which version of SMP? It seemed to me that there was an astable >> flip-flop somewhere in the design process for SMP: performance would >> switch back and forth between "agonizingly inefficient" and "slow". > >It was SMP4 under OS/VS1, and we were applying several PUT tapes' >worth of maintenance to CICS in one go. We were running on a >4341. > >> The concept behind SMP was good, and when I made a statement to that >> effect during the announcement of SMP at a SHARE meeting in Houston > >SMP was, and is, a good idea. The problem, or, at least the problem >I found, was understanding how it was organised and what it did. >But, the principle was easy enough and as long as you did not try >to be clever then it was okay. It was when you spent two or three >days trying to figure out how to apply a usermod which you could >have done outside SMP control in an hour that you questioned its >value. OTOH the VM equivalent update process required you to add IIRC a line to the XXXXXX UPDATE (or was it CONTROL) file containing a line like LCL00001, then you invoked the editor with: XEDIT XXXXXX ( UPDATE SID LCL00001 did your (source) mods interactively and did a SAVE, generating file XXXXXX LCL00001 which would be applied by UPDATE any time the module was built thereafter. If PUT or PTF mods conflicted later, you'd get an error message and have to reconsider your changes, as in any other source control merge process. Thanks. Take care, Brian Inglis Calgary, Alberta, Canada -- Brian.Inglis@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca) fake address use address above to reply tosspam@aol.com abuse@aol.com abuse@yahoo.com abuse@hotmail.com abuse@msn.com abuse@sprint.com abuse@earthlink.com abuse@cadvision.com abuse@ibsystems.com uce@ftc.gov spam traps ###### Sender: lynn@LYNNPC Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> Reply-To: Anne & Lynn Wheeler From: Anne & Lynn Wheeler Message-ID: Organization: Wheeler&Wheeler Lines: 27 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jan 2002 00:50:51 GMT NNTP-Posting-Host: 209.245.4.225 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1010278251 209.245.4.225 (Sat, 05 Jan 2002 16:50:51 PST) NNTP-Posting-Date: Sat, 05 Jan 2002 16:50:51 PST X-Received-Date: Sat, 05 Jan 2002 16:50:53 PST (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!nntp-relay.ihug.net!ihug.co.nz!logbridge.uoregon.edu!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:98123 as was pointed at there was a little memory leakage (inter record gap size) over 20 years. so from: http://www.digital-interact.co.uk/site/html/reference/media_9trk.html .... Because these drives were originally start stop drives they needed space between data blocks in order to be able to do this. This space is known as the inter block gap (ibg) and is 0.6 inches for 800/1600 and 0.3 inches for 6250. This need for an ibg caused the tape usage to be very inefficient when used with small block sizes. ... The following chart gives an indication of the capacities of using a standard 2400 ft tape with varying block sizes. 512 Byte 1 Kbyte 2 Kbyte 4Kbyte 8Kbyte Gapless 800 bpi 11.6 Mb 15.3 Mb 18.3 Mb 20.2 Mb 21.4 Mb 22.6 Mb 1600 bpi 15.5 Mb 22.5 Mb 30 Mb 36.1 Mb 40.2 Mb 45.3 Mb 6250 bpi 35.1 Mb 58.6 Mb 87.6 Mb 116.8 Mb 140.7 Mb 176.8 Mb -- Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/ ###### From: Jim Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: 6 Jan 2002 16:03:03 -0600 Lines: 33 Message-ID: <060120021702138807%eduorg@com.net> References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit User-Agent: Thoth/1.4.2 (Carbon/OS X) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!novia!novia!sequencer.newscene.com!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:98175 In article , Anne & Lynn Wheeler wrote: > as was pointed at there was a little memory leakage (inter record gap > size) over 20 years. > > so from: > http://www.digital-interact.co.uk/site/html/reference/media_9trk.html Speaking of Blocking Factors....... A long time ago in a job far, far away I was given the assignment of converting some data on an IBM mainframe tape to a format that could be used on a PC. We had a 1600BPI Qualstar tape drive connected to a PC (I still have one of these drives, BTW), and ordinarily this was an easy task. You just load the tape, select the EBCDIC to ASCII conversion on read and let it rip. Unfortunately, this tape was in the Power VSE format, which consisted of variable length blocks containing variable length records. So I had to de-block this myself. The only language available to do it was MS QuickBASIC 2 (or maybe 3 - it's been nearly 20 years!). Anyways, I had to read the tape into a disk file as-is, then using the documentation I had on the Power VSE format, write a program to convert the file into a new file of fixed length records. It was ugly, but it worked just fine. For the EBCDIC to ASCII conversion, I just wrote the new, fixed length record file to tape and read it back in, converting it on the read. Ahhhh, those were the days! Jim ###### From: "David Carey" Newsgroups: alt.folklore.computers References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> Subject: Re: "blocking factors" (Was: Tapes) Lines: 47 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Sun, 13 Jan 2002 15:18:02 GMT NNTP-Posting-Host: 24.217.196.59 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1010935082 24.217.196.59 (Sun, 13 Jan 2002 07:18:02 PST) NNTP-Posting-Date: Sun, 13 Jan 2002 07:18:02 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sun, 13 Jan 2002 07:17:55 PST (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news-koe1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:98630 "Foobar T. Clown" wrote in message news:3C2D4708.6EA1B913@gazonk.del... > "Arargh!" wrote: > > > > "Foobar T. Clown" wrote: > [...about block sizes on 1/2 inch mag tape...] > > > Every system that I worked on that could read a 9-track tape, could > > read up to 32767 bytes/block. [...] > > I gotta admit, I never had to deal with tape blocks as small as 80 bytes > either, but I do remember being careful not to exceed 1600 byte reads > and writes (80-byte records, with a "blocking factor" of 20). What I > don't remember is whether that limit was imposed by some system that I > actually laid hands on, or whether it was just handed down to me as > "common wisdom" from someone older and wiser than myself. Blocking factors were a matter of trade-offs: The advantage of big blocks was more data on the tape (fewer inter-record-gaps, and faster IO (fewer start-stops). You had to reserve enough memory to read an entire block and also to build the output block prior to the actual write. My first job (in 1965) was on an IBM 1401 with 8,000 characters of memory. 80 by 10 vs. 80 by 20 could really make a difference in the memory available to do the programming. Later systems that could overlap IO with processing meant that you needed to allocate 2 buffers for input and output, but memory sizes were getting larger. We replaced the 1401 with a Honeywell 200 with 16,384 characters. The H-200 could read/write/process simultaneously. Even later the primary trade-off had to do with write error recovery. A slight flaw in the magnetic coating on the tape would result in a read-after-write-error. Recovery involved a backspace over the bad block, erasing a section of tape (usually computed to be equal to the size of the failed block), and re-writing the bad block. Really big blocks would be more likely to find a bad tape spot and result excessive recovery operations. (At least this is what I was taught, back in the "old days".) Regards, David ###### From: Jim Thomas Newsgroups: alt.folklore.computers Subject: Re: "blocking factors" (Was: Tapes) Date: 14 Jan 2002 13:42:41 -1000 Organization: Canada France Hawai`i Telescope Lines: 13 Message-ID: References: <6w0W7.1920$E82.5671@typhoon.bart.nl> <3C2BBD39.B271D2F0@gazonk.del> <3C2D4708.6EA1B913@gazonk.del> NNTP-Posting-Host: atlas.cfht.hawaii.edu X-Trace: news.hawaii.edu 1011051761 9453 128.171.80.135 (14 Jan 2002 23:42:41 GMT) X-Complaints-To: usenet@hawaii.edu NNTP-Posting-Date: 14 Jan 2002 23:42:41 GMT X-Newsreader: Gnus v5.7/Emacs 20.6 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!news.hawaii.edu!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:98887 >>>>> "David" == David Carey writes: David> .... Later systems that could overlap IO with processing meant that David> you needed to allocate 2 buffers for input and output, but memory David> sizes were getting larger. We replaced the 1401 with a Honeywell David> 200 with 16,384 characters. The H-200 could read/write/process David> simultaneously. .... Actually the 1401 had an overlap option that allowed tape operations simultaneously with processing too. And it could have 16K too. For more memory and multiple channels one had to wait for the 1410. Jim