INFO-VAX Sat, 06 Jan 2007 Volume 2007 : Issue 11 Contents: 7.3.2: BACKUP PATCH V3>V6 ODDNESS Re: 7.3.2: BACKUP PATCH V3>V6 ODDNESS Compiled CGI scripts with problems on SWS 2.1.1 Re: Dec VWS Internals ? Re: DECnet over IP Re: DECnet over IP DECwindows: 100 vs 75 dpi selection Re: FTP Idle Timeout Setting Re: FTP Idle Timeout Setting Re: SHOW CLUSTER and Quorum Re: SIMH hints and tips please Re: SIMH hints and tips please Re: SIMH hints and tips please Re: SYSMAN suggestion: SET ENV /CLUSTER /EXCLUDE= Re: TLZ06 cleaning cycle RE: US Military bans HTML in emails Re: US Military bans HTML in emails Re: US Military bans HTML in emails Re: US Military bans HTML in emails ---------------------------------------------------------------------- Date: 5 Jan 2007 11:25:17 -0800 From: "tadamsmar" Subject: 7.3.2: BACKUP PATCH V3>V6 ODDNESS Message-ID: <1168025117.446310.109720@i15g2000cwa.googlegroups.com> Installed the UPDATE patch that included the BACKUP patch V6. I was at BACKUP V3. The command no longer worked: $ backup/imag/noalia/veri/igno=(label,nobackup) DKB100: - eesl"no seeum"::PCS_DIR_BCK:EESD070105.BCK/save %SYSTEM-F-IVDEVNAM, invalid device name But it works if I unpack the PCS_DIR_BCK: logical name to DSA0:[EES.BCK] ------------------------------ Date: 5 Jan 2007 12:59:49 -0800 From: "Ian Miller" Subject: Re: 7.3.2: BACKUP PATCH V3>V6 ODDNESS Message-ID: <1168030789.257178.90990@s34g2000cwa.googlegroups.com> fixed in V7 kit ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2/VMS732_BACKUP-V0700.ZIPEXE see section 5.2.8 in release notes ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2/VMS732_BACKUP-V0700.txt ------------------------------ Date: Sat, 06 Jan 2007 05:27:26 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Compiled CGI scripts with problems on SWS 2.1.1 Message-ID: <00A61498.C29EFE0A@SSRL.SLAC.STANFORD.EDU> VMSers-- VMS 8.3 (DS20E) SWS 2.1.1 (Apache 2.0.57) We have a problem with some compiled applications running either from CGI-BIN or through the OSU module. Not all applications, and PHP, PERL (through OSU, not MOD_PERL), and SOYMAIL all seem to work fine. When we run WA.EXE (Listserv 14.5) from cgi-bin, or YAHmail (1.84) through the OSU module, there seems to be an issue where any HTTP headers sent from the program aren't recognized as headers. (We vaguely suspect something funny with carriage control or a blank line preceding the HTTP response header, but haven't been able to prove it.) For Firefox, which isn't willing to render HTML unless it got an appropriate content-type header identifying what was coming as HTML, that means the whole HTTP+HTML response shows up as unrendered text. For Internet Explorer, that means cookie-setting and un-setting don't work, as well as unsightly display of headers. Anybody got this working? Did you have to do anything to make it work? Is there some magic DECC$send-http-headers-correctly logical I haven't been able to find in the manual? Thanks, -- Alan ------------------------------ Date: Fri, 5 Jan 2007 11:35:55 -0500 From: "FredK" Subject: Re: Dec VWS Internals ? Message-ID: <459e7e6c$1@usenet01.boi.hp.com> "ChrisQuayle" wrote in message news:67enh.14116$Wy6.13719@newsfe1-win.ntli.net... > FredK wrote: > > Thanks very much, a very valuable introduction. Have been writing a small > windowing gui system for embedded projects and part of the effort has been > to get a historical perspective on early ws windowing systems, which were > similarly constrained by low throughput cpu's and small memory sizes. The > two dec wrl reports on dumb colour frame buffer programming have also been > very valuable. Have a bit of info as on Sun's NeWs system, but am still > digging for info on others. It was really quite difficult to get decent > graphics response and the use of (for example) scaled integer arithmetic, > rather than floats, must have contributed quite a bit, especially if the > data could be organised to enable the use of shifts, rather than multiply > and divide instructions. > The VWS footprint was fairly small. The most complex part of VWS was due to the decision to provide guaranteed backing store. Each application created a viewport and then could map one or more windows into the viewport. From the applications point of view - nothing else was running on the graphics screen. Overlapping windows and backing store were in the early days the toughest thing to get right. Remember that the original MS Windows design supported tiled windows only. The real speed limiter between VWS and X11 was that the UIS interface was procedural and did direct rendering (in the case of the MFB) and a "near" direct rendering on the GLX engine (packets queued to a device driver drawing queue). X11 generates protocol packets that are processed by another process (adding a context switch, scheduler delays, and protocol parsing). Microsoft found out the hard way just how much of a performance hit this was when NT implemented it's GDI originally in the same manner. Even with assists like the LPC interface it was much slower. Also VWS was tightly coupled to VMS. Taking advantage of AST's for example. You could make UIS calls from any mode. The terminal emulator ran as an AST driven extension to a terminal port driver. Etc. >> >> VWS was only implemented on two graphics engines before it was retired - >> a monochrome frame buffer, and the GPX graphics engine. > > I think vws was available on the uVax II/GPX and the monochrome frame > buffer variant. around the vms 4.7 to 5.4 timeframe and was faster than > Decwindows on X, which really needed more memory and cpu throughput. > Decwindows ran far better on the later KA650 series. > It was known at the time that DW was being written that it would be slower than VWS on existing HW. But that as HW got faster, it would not matter. >> >> UISX was implemented as a way to migrate VWS applications. UISX >> implemented the entire VWS programming model on top of X11. In fact, the >> application did not even need to be re-compiled. > > That sounds like typical dec foresight :-)... > It only sounds like foresight. In reality, the DW program manager believed that VWS use would ramp to zero in a linear ramp over a calendar year once DW became available. This proved not to be true, and I proposed UISX as one of a group of porting/migration tools. I was amazed UISX worked as well as it did, but I'm not sure how much use it ever saw. I ported it to Alpha (and even fixed the VAX version so that it did not link against the system image to allow it to be VESTed) - but I'm not sure Touch ever shipped the Alpha version. Trivia note. UISX was originally named XUIS - but it had to be changed because the X11 people wanted the name "XUI" and the copyright/trademark people don't like things that end with "S" because you can't always tell if the "S" is part of the name - or a plural, or posessive, etc. ------------------------------ Date: 5 Jan 2007 16:19:05 -0800 From: Bod43@hotmail.co.uk Subject: Re: DECnet over IP Message-ID: <1168042745.820117.120260@38g2000cwa.googlegroups.com> Aaron Leonard wrote: > [ adding comp.os.vms, my old stomping grounds ] > > On 4 Jan 2007 15:23:16 -0600, briggs@encompasserve.org wrote: > > ~ In article , Aaron Leonard writes: > ~ > On 4 Jan 2007 10:12:34 -0800, "FMonkey" wrote: > ~ > > ~ > ~ > ~ > ~ Thank you for your reply. > ~ > ~ > ~ > ~ Unfortunately the devices I wish to communicate with are not computers, > ~ > ~ or at least not ones that I can install any software on. > ~ > ~ > ~ > ~ I will be generating and interpreting DECnet packets myself on my PC... > ~ > ~ the problem is that my programming language does not have any DECnet > ~ > ~ drivers, or the ability to send or recieve raw or custom made packets > ~ > ~ though my ethernet card. I can however send and recieve TCP or UDP. > ~ > ~ I was hoping I could send a UDP packet to a router and have it strip > ~ > ~ off the UDP header and spit out the DECnet packet I created onto the > ~ > ~ DECnet network. On the flip side I was hoping to route all incomming > ~ > ~ DECnet traffic to my PC. > ~ > ~ > ~ > ~ It was suggested to me to use something called GRE on cisco routers. > ~ > ~ The router would have a DECnet aware feature set. If this is the best > ~ > ~ option, would you know what model of router I would need and what > ~ > ~ software? > ~ > ~ > ~ > ~ I am of course open to a software solution if one exists. > ~ > ~ > ~ > ~ Best regards. > ~ > > ~ > > ~ > Well, I suppose you could buy a router (or, if you wanted to do something > ~ > useful, a pair of routers) that could encapsulate DECnet IV in GRE in IP. > ~ > So this would let you transport DECnet IV packets betwee point A and point > ~ > B via a tunnel over an IP network. > ~ > > ~ > This wouldn't do you any good though, because what you're really saying > ~ > that you're looking for is a protocol translator, to translate between > ~ > your TCP or UDP transport packets and the DECnet IV packets that your > ~ > mystery device wants to see. A DECnet tunnel just takes DECnet packets > ~ > in on one end and spits them out unchanged on the other end, which won't > ~ > do you any good. > ~ > ~ I was the one who suggested GRE (over in comp.protocols.tcp-ip) in > ~ response to a question that asked whether he could generate UDP and > ~ get a Cisco router to strip off the UDP header and put the resulting > ~ DECnet frame on the wire. > ~ > ~ The motivation for the question was that he had the ability to craft > ~ UDP frames on his PC but not the ability to craft DECnet frames. > ~ > ~ If he had the ability to craft GRE frames then a Cisco router > ~ with a Tunnel interface could most certainly strip off the GRE > ~ encapsulation and forward the embedded DECnet packet or, in the > ~ reverse direction, accept a DECnet frame, apply GRE encapsulation > ~ and forward it to the user's PC. > ~ > ~ Whether he has the ability to craft (or receive) GRE frames I haven't > ~ seen answered yet. > ~ > ~ I agree that this is probably not an optimum solution to the underlying > ~ problem. It was merely a response to the question as asked. > > You make your scheme sound a lot easier than it really would be. > > Your picture looks like this: > > > [ PC ] [ router ] > [ app ] [ DECnet ] [ mystery device ] > [ shim] [ GRE ] [ app ] > [ IP ] [ IP ] [ DECnet ] > |______ IP network ____ _____DECnet network___ > > The goal is to get app in PC communicating with app in mystery device. > To achieve this, it would be insufficient for the shim in the PC merely > to take the app data, slap some DECnet/GRE headers on the data, and hunk > the packet out its raw IP interface. The router needs to achieve and > sustain DECnetIV reachability status with the router (or spoofed router) > on the far side of its GRE tunnel, and the DECnet stack in mystery device > needs to achieve and sustain a DECnet NSP (reliable transport) connection > with an NSP state machine in its communications peer. > > So, the "shim" in the PC would have to implement a full DECnet stack, > including routing code - or at least enough of the stack to fool the > router and the mystery device. This would be a nontrivial exercise. > > That's why I predict that the o.p. will wind up having to get a real > DECnet stack for his PC. The quest for a DECnet-TCP (or DECnet-UDP) > transport layer protocol translator will provide chimerical, I predict. > > A proof of nonexistence is difficult to achieve, but if no one in > comp.os.vms has heard of such a protocol translator, that would be > pretty close to such a proof. I have no idea if this could be made to work however:- It strikes me that perhaps a serial link be used between an IP terminal server (whch I know a bit about) and a DECnet terminal server (which I presume exists or existed) to provide the required translation? [ PC ] [ app ] [mystery device ] [ shim] [term serv]__Serial__[term serv] [ app ] [ IP ] [ IP ] [ DECnet ] [ DECnet ] |____IP____ | |____DECnet_____| Now a cisco router can be used as an IP terminal server and may well be able to be a DECnet terminal server. Don't know. If this does work at all there will be some issues. 1. Limited to low bandwidth async links. (115k bps?) 2. The "packets" will not necessarily be maintained as packets on the IP side you will see a TCP stream. DECnet side??? Just a crazy idea - no idea of practicality. ------------------------------ Date: Fri, 05 Jan 2007 19:50:11 -0600 From: David J Dachtera Subject: Re: DECnet over IP Message-ID: <459F0053.EF10A322@spam.comcast.net> Bod43@hotmail.co.uk wrote: > [snip] > I have no idea if this could be made to work however:- > > It strikes me that perhaps a serial link be used between an IP > terminal server (whch I know a bit about) Pardon my butting in here. Aaron cross-posted to comp.os.vms. When you say "IP terminal server", I assume you are referring to any terminal server which will perform both "normal" and "reverse" TELNET. Later DECservers provide(d) support for TCP/IP in this way. > and a DECnet terminal > server (which I presume exists or existed) Not sure what you mean here. "DECnet" does not use "terminal servers". Terminal sessions between systems running a DECnet stack were usually performed using the "SET HOST" command which invokes the RTPAD image. The session is usually conducted using the CTERM (Console Terminal) protocol, a DECnet packet sub-type. In the DEC realm, terminal servers usually operated using LAT or "Local Area Transport", a non-routable protocol which frequently mistaken for being part of DECnet - it is actually a distinct packet type and operates independent of any DECnet stack elements. > to provide the required > translation? > > [ PC ] > [ app ] [mystery device ] > [ shim] [term serv]__Serial__[term serv] [ app ] > [ IP ] [ IP ] [ DECnet ] [ DECnet ] > |____IP____ | |____DECnet_____| > Where you show "DECnet" here substitute either "LAT" or "TELNET". > Now a cisco router can be used as an IP terminal server > and may well be able to be a DECnet terminal server. > Don't know. > > If this does work at all there will be some issues. > 1. Limited to low bandwidth async links. (115k bps?) > 2. The "packets" will not necessarily be maintained as packets > on the IP side you will see a TCP stream. DECnet side??? > > Just a crazy idea - no idea of practicality. This was actually a common solution in the pre-IP days, and it "just worked" without further intervention once you got it going - more reliable than TCP/IP, even! -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 27 Dec 2006 01:53:42 -0500 From: JF Mezei Subject: DECwindows: 100 vs 75 dpi selection Message-ID: <7078a$45921895$cef8887a$28349@TEKSAVVY.COM> When I moved to Alpha, based on the documentation I had read, I enabled 100dpi in the decw$private_setup.com. However, this resulted in huge fonts being used in the traditional DECWINDOWS (DECW$SESSION) for menus, and a few other things. And I tried desperately to set whatever resources differently to reduce the font size, but to no avail. Fonts in other areas of windows seemed reasonable. I decided to switch the dpi to 75. I rebooted the workstation and low and behold, I am back to normal size fonts in the menus. And the text in Mozilla (which doesn't use motif resource files) is also smaller, giving more "real-estate" of text per window (desirable thing). Would it be correct to state that setting the $ decw$server_density == "75" Just changes which fonts will be used and the bitmap fonts in the 75dpi directories represent simply a smaller cellsize than the 100dpi fonts ? In other words, a 10 point bitmap font would appear 25% smaller when in 75dpi versus 100dpi since the 75dpi font would have fewer pixels in its cell ? (since my screen resolution does not change, changing the cell size makes the fonts bigger). The doc said that 100 was the default, but I find it strange that it would result in huge font being used for menus in windows. In terms of scalable fonts, how does VMS decide how many pixels should be used to represent a 10 point high font ? does it use the "postscript" 72dpi resolution to calculate that a 10 point high font should occupy 10/72 inches, and then transform this into the actual monitor's resolution ? In such a case, does the decw$monitor_density matter ? Can I set that variable to an exact value (in my case, 1024/ 11.8" = 86.78 dpi vertically) ------------------------------ Date: Fri, 5 Jan 2007 13:57:56 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: FTP Idle Timeout Setting Message-ID: <07010513575645_2020028F@antinode.org> From: "Techhead" > I am kind of new to VMS. I have Open VMS 8.3. How do I change the FTP > idle timeout setting? Assuming that you use the HP TCPIP product for TCP/IP ("TCPIP SHOW VERSION"): http://h71000.www7.hp.com/doc/index.html http://h71000.www7.hp.com/doc/tcpip56.html http://h71000.www7.hp.com/doc/83final/6526/6526pro.HTML http://h71000.www7.hp.com/doc/83final/6526/6526pro_contents.html http://h71000.www7.hp.com/doc/83final/6526/6526pro_contents_004.html#toc_chapter_16 http://h71000.www7.hp.com/doc/83final/6526/6526pro_041.html#trouble_inactiv_timer_sec 16.2.2.3 Inactivity Timer The larger the inactivity timer value, the longer FTP maintains sessions without timing out. Excessive inactive sessions might slow down performance, degrade security, or prevent other users from establishing sessions. To increase the inactivity timer, change the value of the TCPIP$FTPD_IDLETIMEOUT logical name. The default is 15 minutes. For example: $ DEFINE TCPIP$FTPD_IDLETIMEOUT 01:00:00 It doesn't _say_ DEFINE /SYSTEM (or /EXEC), but I'd assume that you'd need more than just DEFINE. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 5 Jan 2007 10:15:38 -0500 From: "Jilly" Subject: Re: FTP Idle Timeout Setting Message-ID: <459e6b9b$1@usenet01.boi.hp.com> "Techhead" wrote in message news:1168008103.378687.272330@38g2000cwa.googlegroups.com... >I am kind of new to VMS. I have Open VMS 8.3. How do I change the FTP > idle timeout setting? > See the TCPIP Services for OpenVMS manual set and review the docs for the following logicals TCPIP$FTPD_IDLETIMEOUT TCPIP$FTP_KEEPALIVE TCPIP$FTPD_KEEPALIVE ------------------------------ Date: 6 Jan 2007 00:13:08 GMT From: Hans Bachner Subject: Re: SHOW CLUSTER and Quorum Message-ID: JF Mezei wrote: > View of Cluster from system ID 1034 node: BIKE 5-JAN-2007 09:16:42 > > SYSTEMS MEMBERS > NODE SOFTWARE VOTES QUORUM STATUS TRANSITION_TIME > > BIKE VMS V8.3 1 2 MEMBER 5-JAN-2007 07:31 > VELO VMS V7.3 1 2 MEMBER 5-JAN-2007 07:22 > WHEEL VMS V7.3 1 2 MEMBER 5-JAN-2007 07:30 > CHAIN VMS V8.3 1 3 MEMBER 5-JAN-2007 07:37 > > CLUSTER > CL_QUORUM FORMED > > 3 15-DEC-2006 13:36 > > > I am correct is stating that the QUORUM item in SHOW CLUSTER is derived > from the SYSGEN "EXPECTED VOTES" parameter for that node ? Without looking into the sources - probably yes. > Once booted, is it also correct to state that the node specific QUORUM > value is not really used since there is a real cluster-wide quorum > value ? Yes. When a node boots, the quorum computed from the new nodes expected votes, the current quorum and the number of present votes including the new node are compared - the biggest of these values is used. > Would the node-specific quorum value be of any use beyond the initial > boot? (perhaps a limit on how low a SET CLUSTER/EXPECTED_VOTES could > go?) No - SET CLUSTER /EXPECTED is the mechanism to go *below* the expected votes value computed from the individual nodes' settings (or the current active settings in the cluster), e.g. because a voting node has left the cluster for a longer period of time. Hans. ------------------------------ Date: Fri, 05 Jan 2007 20:59:55 +0100 From: Paul Sture Subject: Re: SIMH hints and tips please Message-ID: In article <00A61444.81DC0E08@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG wrote: > In article , > Paul Sture writes: > > > > > >In article <00A6142D.B2816B9E@SendSpamHere.ORG>, > > VAXman- @SendSpamHere.ORG wrote: > > > >> I haven't played with SimH in awhile. Last time, I think, was two VMS > >> boot camps ago. I recall showing Keith Parris VMS running on my Power- > >> Book. It wasn't of much use then with networking notworking. Have you > >> gotten SimH running with networking on OS X? > > > >Networking the thing, or at least seeing how far I get with networking > >is one of my aims here. I wasn't even going there with Panther, but just > >before Christmas I spotted some hopeful looking messages to the effect > >that it might work with Tiger. > > > >So, one Tiger upgrade later, I'm looking at SIMH again... > > Late to the Tiger cage but welcome to the ambush. ;) Let me know how > you make out with it. I may revisit it. > Better late than never. I'll let you know how it goes. -- Paul Sture ------------------------------ Date: Fri, 05 Jan 2007 21:01:41 +0100 From: Paul Sture Subject: Re: SIMH hints and tips please Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > After starting SIMH you can run scripts with the do command. Takes > one arguement: the name of the script file. By habit I call them .do > files. > > sim> do myscript.do Noted thanks. -- Paul Sture ------------------------------ Date: 6 Jan 2007 00:30:34 GMT From: Hans Bachner Subject: Re: SIMH hints and tips please Message-ID: Wilm Boerhout wrote: > on 5-1-2007 17:24 VAXman- @SendSpamHere.ORG wrote... > > [snip] > >> It's too bad that the Charon-VAX thing isn't available on an operating >> system and only on that glorified game console. > > Charon-VAX is also available on an operating system: it runs on top of > Alpha-VMS as well as your "game console". There's even a (somewhat limited) freeware version available which runs on OpenVMS/I64. [1] Hans. [1] http://www.softresint.com/charon-vax/Tools_and_tips.htm#freeipf ------------------------------ Date: Fri, 5 Jan 2007 14:20:31 -0500 From: norm.raphael@metso.com Subject: Re: SYSMAN suggestion: SET ENV /CLUSTER /EXCLUDE= Message-ID: I "Tom Linden" wrote on 01/05/2007 08:25:13 AM: > On Thu, 04 Jan 2007 23:53:18 -0800, JF Mezei > wrote: > > > It would be nice to have the ability to set the SYSMAN environment to > > include all nodes except one or more specific nodes. > > > > eg: > > > > SYSMAN> SET ENV/CLUSTER/EXCLUDE=(node1,node2) > Unless you have a very large cluster, why is this easier than > SYSMAN> SET E/N=(NODE3,NODE4) > ? I build the logicals at node boot, so they are automagically available. All you need is a good mnemonic to remember which logical has which nodes ;). > > > > For instance, you want a command to execute on all nodes except the node > > issuing the SYSMAN command. > > > > Yeah, I know, I can use lexxicals to build a list of nodes, exclude the > > ones I want to exclude, and then setup logicals that can be used by > > system, but a /EXCLUDE would be much cleaner and easier. > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: 5 Jan 2007 11:12:05 -0800 From: "AEF" Subject: Re: TLZ06 cleaning cycle Message-ID: <1168024325.204612.39510@s34g2000cwa.googlegroups.com> Doug Phillips wrote: > AEF wrote: > > Doug Phillips wrote: > > > tadamsmar wrote: > > > > How often should a TLZ06 be cleaned? > > > > > > > > How may 90 M tapes can you fill before you need to clean? > > > > > > > > I tend to clean when I do an image backup, but that might be too often, > > > > only a couple of > > > > 90 M tapes are filled between image backups on some of my systems. > > > > > > > > I hear that cleaning tends to wear out the heads. > > > > > > DEC recommended running a cleaning tape every 2 weeks or after every 50 > > > hours of usage, and the cleaning tapes I've used are good for only 25 > > > cleanings. Cleaning too often does wear out the heads and this usually > > > manifests itself first by showing positioning errors, maybe along with > > > parity errors that don't go away when you clean, then complete failure > > > to mount. All TLZ06's available today are refurbs --- and you could go > > > > Interesting. HP DAT cleaning cartidges say extra cleaning is harmless > > (well, of course they'd say that). Also, circa 2000/2001, a support > > person who came on site to swap some of my TLZ07 drives gave me a copy > > of his secret troubleshooting cheat sheet. It said to try run the > > cleaning tape FOUR time. I kid you not: FOUR times. It also said the > > first two errors in ANAL/ERROR output are the most important to look > > at. > > > > I guess I should look at getting HP cleaning cartridges. I use whatever > brand I find at the local stores. I just looked at the Maxell cleaning > cartridge I've been using and it's good for 40 cleans and recommends > cleaning every 25 hours. Shows how my memory works:-) I find the cartridge runs for more than 40 cleanings. In my TLZ09 manual it says: Digital Equipment Corporation recommends that you perform the head cleaning procedure once every 2 weeks, or after every 24 hours of drive usage, whichever comes first. (Hmmm, what if you use the drive once a month [not to worry -- the data accumulating over the month also exist on another system and on other {daily} tapes].) Under normal conditions, it should not be necessary to exceed this cleaning schedule. If media related [sic] errors begin to occur after only a few hours of use with a new cartridge, you may either have a particularly "dirty" tape or the application you are running may be harder on the media than most typical applications. If this occurs, you may want to revise the cleaning schedule with new tapes, such that a cleaning cycle is executed after 4 or 5 hours of use, then continue with the normal 24 hour interval from that point forward. If a particular data cassette causes problems, try changing to another data cassette. The Stratus manual says for its T601 DAT drive (uses DDS-1): After every 25 hours of normal use, or if the status lights on the DAT drive... Hmmm. What would constitute abnormal use? I guess if you don't achieve "non-stop streaming" (no stops and restarts during a single backup). > > Maybe my experiences with 4mm over the years have been coincidental, > but my sites that follow the 30 to 40 hour rule have some TLZ06/TLZ07 > drives that have been around since they were a new item. I've had > others who lived by "if some's good, more's better" and cleaned weekly > or even daily, and all of those sites have had to replace their drives. > The ones who never cleaned until they got parity errors have had to > replace their drives. (those sites were usually less religious about > tracking tape age, too, though.) Back when I was using DDS-2 tapes the big problem was parity errors and positioning errors part way through the tape. And how far through the tape would vary from drive to drive. One drive might not read a certain tape at all. Another drive might read it fine. If it's an alignment problem, why does it show up only well into mid-tape? On an older hp cleaning cartridge paper insert it says: o Recommeneded cleaning frequency: weekly o Discard your cleaning cartridge after 50 cleaning cycles or when your dds drive immediately ejects the cleaning cartridge without performing a clenaing cycle. o Note that your dds drive will not be damaged by over-cleaning Of course it also says to "use hp C5709A cleaning cartridge for optimum results". > > Keeping track of each tape's usage and replacing tapes as they reach > whatever arbitrary max number of usages that you set (which *really > does* seems to vary by brand and batch and drive and environment and > handling and sun-spot activity and who knows what) into the rotation is > as important as proper cleaning. If you allow older tapes to linger too > long in the rotation, then clean closer to 30 or fewer hours. If your > environment is fairly clean and old tapes are retired before they fall > apart (and you've found a good brand that works for your drive) then 40 > or+ hours is probably best. I use spanking brand-new tapes for the weekly full (image) backups (a few gigs per tape). I have fours sets of Mon-Thu tapes for daily incrementals, which are really small. So it's mostly new tape that passes over the heads. I thought new tape sheds more oxide particles, no? > > Now, many (most?) of the newer 4mm drives are "self cleaning" whatever > that means. Those might not need special cleaning unless an old tape > really dirties the heads, but I still do an occasional (like every 100 > hours or so) run-through with a cleaning cartridge just to help out > that little elf or fairy inside (that's gotta be how it works, no?:-) > > > Several months ago I found that switching from DDS-2 to DDS-1 reduced > > my troubles. > > Good if you don't need the capacity. I've done that, too. Well, I do for my archive backups. But 3 readable tapes is far, far better then 2 unreadable tapes!!! > > Had a client that bought a new Windoze server that had a DDS5 (DAT72) > drive, bought a bunch of tapes at a great qty discount, and tried to > use them in his TLZ07. On the phone: "It keeps spitting the tape out, > and they're brand new tapes. The drive must be broken." > > > But now I'm having trouble with a drive that gets errors > > during a verify pass! When I take the tape out, it is almost entirely > > wound onto the take-up reel! (The last time this drive did this, the > > tape was found to be fine with a separate BACKUP/COMPARE operation!) > > > > Frustrating. I'm now redoing the backup without /VERIFY. I will do a manual BACKUP/COMPARE when it is done! (Fortunately, the drive is static enough that I don't expect many compare errors due to changes on the disk.) (The drive 18 GB in size and it takes a while over narrow SCSI! ) > > > > through a couple before finding a reliable one, even if the seller has > > > tested them thoroughly. You'd probably want a newer drive, i.e. TLZ10, > > > for a replacement. > > > > Maybe more than a couple if you have my luck! > > > > You're right, I just said a couple because it was easier than coming up > with an average;-) I like to think of 4mm DAT as a write-probably/read-maybe medium. :-) > > > > > > > > Parity errors seem to be a good indicator of dirty heads, but by then > > > (if you're running unattended) you've potentially lost a backup. I've > > > found 50 hours to be too close to max, and usually clean after 30 to 40 > > > hours. That works out to monthly for me. Cleaning every 2 weeks could > > > be way too often if usage is light, unless you have a "dirty" > > > environment. > > > > > > If you log your usage, it shouldn't be hard to determine your cleaning > > > cycle. > > > > Well, it can't hurt to try. > > > > Try is all we can do. > > ************************* > "Ever tried. Ever failed. No matter. Try again. Fail again. Fail > better." > (Samuel Beckett, "Worstward Ho", 1984) AEF ------------------------------ Date: Fri, 5 Jan 2007 14:13:49 -0500 From: "Dan Allen" Subject: RE: US Military bans HTML in emails Message-ID: <000601c730fd$a12da210$1f3a0681@sdct.nist.gov> > > The problem to be dealt with (especially by some folks in > your domain :-) is how to provide _assurance_ to management Hmmm... Well done - an astute analysis of the situation and a carefully crafted response. > that good password practices are used by everyone with > access. If passwords are to be used, rule sets are the only > way to ensure a minimum of care. > I have no quibble with the goal - it's the execution I find lacking. And I'm quite familiar, as are you, with the guidance documents we are using. Dan ------------------------------ Date: Fri, 05 Jan 2007 20:54:01 +0100 From: Paul Sture Subject: Re: US Military bans HTML in emails Message-ID: In article <507k5pF1eojd2U1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) wrote: > In article <0e3kdrEJpFNh@eisner.encompasserve.org>, > frey@encompasserve.org (Sharon) writes: > > In article <5073ocF1eojtiU1@mid.individual.net>, bill@cs.uofs.edu (Bill > > Gunshannon) writes: > > > >> "beyond imagination"? probably not. But my experience has been that > >> people who write down passwords write them down no matter how trivial > >> they are. Safe combinations are the same and I have been working with > >> them (and the people who have to know them) for more years than there > >> have been computer passwords. It's more a psychological thing than a > >> real need. One can create very complex passwords that are meaningful > >> to them and thus don't require writing down. > > > > You obviously don't work where I do. I do complex passwords and can > > remember them without writing them down. Except that every little utility > > or > > function at my work requires a password to get into, they all have > > different > > format requirements and they all have different retention and rotation > > requirements. So I have to have a different password for: > > > > access to primary network > > dialin access to primary network > > access to secondary network > > dialin access to secondary network > > voicemail > > timecard system > > paystub system > > training system > > retirement bennies system > > healthcare bennies system > > travel booking system > > amex business account system > > one helpdesk logging system > > another helpdesk logging system > > webex account system > > > > and probably a few others I don't access very often that I'm forgetting. > > > > Sounds more like a management issue than a technical one. We used > to have to use three different (and un-synchronized) passwords here > in the department. Most users considered that unacceptable and we > now have single-signon. If the password is secure there is no reason > to require a bunch of them. Well, no technical reason, there is always > politics. Personally, I am becomeing more and more n favor of the > SmartCard idea. Enough that I have already asked TPTB why the University > doesn't look at that as their ID card. I have it at home, how hard or > expensive can it really be> :-) > I've used a SmartCard system, and though I didn't use it for quite as many applications as Sharon cites, it was an excellent tool. That particular SmartCard implementation offered further functionality, as I could use it to sign on to _any_ PC within the company (for example when attending a training course), and have access to the applications I was authorized for. -- Paul Sture ------------------------------ Date: 5 Jan 2007 14:25:49 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: US Military bans HTML in emails Message-ID: In article <0e3kdrEJpFNh@eisner.encompasserve.org>, frey@encompasserve.org (Sharon) writes: > You obviously don't work where I do. I do complex passwords and can > remember them without writing them down. Except that every little utility or > function at my work requires a password to get into, they all have different > format requirements and they all have different retention and rotation > requirements. So I have to have a different password for: > > access to primary network > dialin access to primary network > access to secondary network > dialin access to secondary network > voicemail > timecard system > paystub system > training system > retirement bennies system > healthcare bennies system > travel booking system > amex business account system > one helpdesk logging system > another helpdesk logging system > webex account system > > and probably a few others I don't access very often that I'm forgetting. VMS did the right thing (in my biased opinion) in supplying the ACME interface that allows applications to rely on Operating System features for secondary authentication (checks over $20,000, etc.). Nobody does password history as well as VMS, especially not some application programmer. Having some of those applications on non-VMS systems is a local problem :-) ------------------------------ Date: 6 Jan 2007 02:00:57 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: US Military bans HTML in emails Message-ID: <508e6pF1ck3ldU1@mid.individual.net> In article <459F00B3.449F964@spam.comcast.net>, David J Dachtera writes: > Paul Sture wrote: >> >> In article <459DC64F.A28F9A39@spam.comcast.net>, >> David J Dachtera wrote: >> >> > Bob Willard wrote in response to the following text: >> >> >> > > >>More as in: >> > > >> min 8 characters >> > > >> min 1 uppercase >> > > >> min 1 lowercase >> > > >> min 1 digit >> > > >> min 1 punctuation >> > > > >> > > > (read: impossible to remember, guaranteed to be written down and subsequently >> > > > compromised) >> > > >> > > Bu11$hit >> > >> > BZZZZZZZZZT! Try again. >> >> Read Bob's response again. It was very funny. I might dispute that "$" >> is a punctuation character, but the rest of the above criteria are there. >> >> "Bul1$shit." works, and shouldn't need writing down. ^ > > Where's the digit? Oops... :-) Even I saw that!! bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ End of INFO-VAX 2007.011 ************************