INFO-VAX Tue, 06 Mar 2007 Volume 2007 : Issue 130 Contents: Re: Alpha firmware questions Re: Alpha firmware questions AlphaServer 8400 MCES register documentation Re: AlphaServer 8400 MCES register documentation Backup VAX7.3 and ODS5 disks Re: Connecting IDE drives to a XP1000 Re: Connecting IDE drives to a XP1000 Re: Connecting IDE drives to a XP1000 Re: Connecting IDE drives to a XP1000 Re: DNS- What I'm NOT doing wrong Re: DNS- What I'm NOT doing wrong Re: History of VMS and related operating systems Re: MediaWiki on OpenVMS? Re: Oracle moves to per-chip licencing OT: Proposed additions to the PDP11 instruction set Re: OT: Proposed additions to the PDP11 instruction set Re: OT: Proposed additions to the PDP11 instruction set Re: OT: Proposed additions to the PDP11 instruction set Re: OT: Quebec Health Care Virus Re: OT: Quebec Health Care Virus Re: SAMBA on OpenVMS with OS X client Re: VMS and storage subsystems documentation ? Re: VMS and storage subsystems documentation ? Re: VMS and storage subsystems documentation ? Re: Wanted: MicroVAX I / VAXstation I owners Re: Wanted: MicroVAX I / VAXstation I owners Re: Wanted: MicroVAX I / VAXstation I owners ---------------------------------------------------------------------- Date: Tue, 06 Mar 2007 12:12:52 -0500 From: Stephen Hoffman Subject: Re: Alpha firmware questions Message-ID: Robert Deininger wrote: > The SRM firmware I have seen is mostly C. The PALcode is mostly > assembler. I've never seen the source for any SROM firmware. > > The FW for most recent Alpha systems is built on VMS. ... > I assume most of the build tools are standard VMS stuff, but I've never > seen any details. Here's an older discussion of what can be involved: http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dtools.pdf This for a specific older configuration and older environment, and undoubtedly not current. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Tue, 06 Mar 2007 19:19:11 GMT From: "FredK" Subject: Re: Alpha firmware questions Message-ID: "JF Mezei" wrote in message news:8a247$45eda50b$cef8887a$1696@TEKSAVVY.COM... >> Robert Deininger wrote: >>> The FW for most recent Alpha systems is built on VMS. > > Stephen Hoffman wrote: >> http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dtools.pdf > > > Many thanks. Is there a reason why firmware for the 21164 and 21264 > systems was buildable only on Windows and Tru64 only ? What > changed to allow more recent ones to be buildable on VMS ? > Wrong question/conclusion. The firmware tools for the reference platforms was created for 3rd party HW developers. The idea was that 3rd parties could design their own systems using the reference platforms as a starting point and have Windows and Tru64 run on them. Tru64 in fact did a lot of work to make this easier to do for a 3rd party developer. VMS on the other hand decided that it made little to no sense... if someone wanted to do a OEM Alpha with VMS on it - then it needed to *be* the reference platform (no work) - or VMS needed to be involved with them because it would be less work than trying to document and export the tools to do platform support outside of VMS. Internally (IIRC) the SRM console group in Marlboro (AlphaServers) was managed in a CMS library, and built on VMS. Various other parts of the firmware may have used other tools ad build environments - but I can't say for sure. At one time, there were at least 3 different source pools for Alpha firmware in 3 different groups. Over time all but one of the groups went out of existance. ------------------------------ Date: Tue, 06 Mar 2007 10:01:00 -0700 From: Jim Mehlhop Subject: AlphaServer 8400 MCES register documentation Message-ID: <45ed9e4d$0$3572$815e3792@news.qwest.net> Does anyone have a AlphaServer 8200/8400 Service Manual in Machine readable format? I am trying to decode a double error halt in a non-primary CPU which caused a CPUSPINWAIT bugcheck on the primary that was watching the failed CPU. The crash does not include much data except for the value of 00000008 in the MCES Machine Check Summary Register. ------------------------------ Date: Tue, 6 Mar 2007 13:12:57 -0500 From: "Island Computers, D B Turner" Subject: Re: AlphaServer 8400 MCES register documentation Message-ID: <12urbo87sr19hcd@news.supernews.com> I sent you the service manuals via email in acrobat format Did you get them? DT -- Island Computers US Corp 2700 Gregory St Savannah GA 31404 Tel: 912 447 6622 x201 Mail: dturner-atnospam-islandco-com (You know what to do with the dashes) "Jim Mehlhop" wrote in message news:45ed9e4d$0$3572$815e3792@news.qwest.net... > Does anyone have a AlphaServer 8200/8400 Service Manual in Machine > readable format? I am trying to decode a double error halt in a > non-primary CPU which caused a CPUSPINWAIT bugcheck on the primary that > was watching the failed CPU. The crash does not include much data > except for the value of 00000008 in the MCES Machine Check Summary Register. > ------------------------------ Date: Tue, 06 Mar 2007 13:42:44 -0500 From: JF Mezei Subject: Backup VAX7.3 and ODS5 disks Message-ID: <70b3a$45edb63a$cef8887a$26809@TEKSAVVY.COM> NTP server on VMS ? $ backup/log appl_alpha:[mosaic41...]*.* appl_vax:[mosaic41...]*.* When executed from a VAX 7.3, it yielded : > %BACKUP-W-NOFILES, no files selected from APPL_ALPHA:[MOSAIC41...]*.*;* When executed from a Alpha 8.3, it worked fine. appl_alpha resides on an ODS5 disk, but that directory hiearchy contains only filenames valid under ODS2. Is the behaviour I experienced valid/documented ? If Backup on VAX is unable to work with any ODS5 disk, I would have expected a more explicit message such as "Cannot use ODS5 disk as source of backup" instead of "no files selected". ------------------------------ Date: Tue, 06 Mar 2007 12:30:43 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Connecting IDE drives to a XP1000 Message-ID: In article <65b0d$45ed45eb$82a13c9d$12613@news1.tudelft.nl>, JOUKJ wrote: >Hi all, > >I'm playing a little with IDE drives on my XP1000. >When I do a "show device" from the running system I see the following >devices DQA0,DQA1,DQB1,DQB0, which suggest that 2 IDE busses are >present. However opening up the machine I can find only one (for DQA). >I see a row of connectors : (SCSI,Floppy,IDE) all for different plugs. > >Where do I have to look for the secondary IDE bus? In the IDE controller chip. IDE chips seem to instantiate all 4 devices, even if there's nothing connected. Many alpha systems don't bring the 2nd IDE bus out onto the system board. If you only find one IDE connector in the XP1000, I think that means the system doesn't implement the DQB bus. ------------------------------ Date: Tue, 6 Mar 2007 14:42:59 +0100 From: "Eberhard Heuser" Subject: Re: Connecting IDE drives to a XP1000 Message-ID: <001201c75ff5$5a843af0$05072286@vg2> ----- Original Message ----- From: "Robert Deininger" To: Sent: Tuesday, March 06, 2007 1:30 PM Subject: Re: Connecting IDE drives to a XP1000 > In article <65b0d$45ed45eb$82a13c9d$12613@news1.tudelft.nl>, JOUKJ > wrote: > >>Hi all, >> >>I'm playing a little with IDE drives on my XP1000. >>When I do a "show device" from the running system I see the following >>devices DQA0,DQA1,DQB1,DQB0, which suggest that 2 IDE busses are >>present. However opening up the machine I can find only one (for DQA). >>I see a row of connectors : (SCSI,Floppy,IDE) all for different plugs. >> >>Where do I have to look for the secondary IDE bus? > > In the IDE controller chip. > > IDE chips seem to instantiate all 4 devices, even if there's nothing > connected. Many alpha systems don't bring the 2nd IDE bus out onto the > system board. > > If you only find one IDE connector in the XP1000, I think that means the > system doesn't implement the DQB bus. Not quite true: there is no device connected to the second IDE plug. Eberhard ------------------------------ Date: 6 Mar 2007 16:53:58 +0100 From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann) Subject: Re: Connecting IDE drives to a XP1000 Message-ID: <45ed8e96$1@merkur.rz.uni-konstanz.de> In article , rdeininger@mindspringdot.com (Robert Deininger) writes: >In article <001201c75ff5$5a843af0$05072286@vg2>, "Eberhard Heuser" > wrote: > >>----- Original Message ----- >>From: "Robert Deininger" >>To: >>Sent: Tuesday, March 06, 2007 1:30 PM >>Subject: Re: Connecting IDE drives to a XP1000 >> >> >>> In article <65b0d$45ed45eb$82a13c9d$12613@news1.tudelft.nl>, JOUKJ >>> wrote: >>> >>>>Hi all, >>>> >>>>I'm playing a little with IDE drives on my XP1000. >>>>When I do a "show device" from the running system I see the following >>>>devices DQA0,DQA1,DQB1,DQB0, which suggest that 2 IDE busses are >>>>present. However opening up the machine I can find only one (for DQA). >>>>I see a row of connectors : (SCSI,Floppy,IDE) all for different plugs. >>>> >>>>Where do I have to look for the secondary IDE bus? >>> >>> In the IDE controller chip. >>> >>> IDE chips seem to instantiate all 4 devices, even if there's nothing >>> connected. Many alpha systems don't bring the 2nd IDE bus out onto >the >>> system board. >>> >>> If you only find one IDE connector in the XP1000, I think that means >the >>> system doesn't implement the DQB bus. >> >>Not quite true: there is no device connected to the second IDE plug. > >Would the second plug be DQA1, or DQBx? > DQBx eberhard ------------------------------ Date: Tue, 06 Mar 2007 12:02:12 -0500 From: Stephen Hoffman Subject: Re: Connecting IDE drives to a XP1000 Message-ID: JOUKJ wrote: > I'm playing a little with IDE drives on my XP1000. > When I do a "show device" from the running system I see the following > devices DQA0,DQA1,DQB1,DQB0, which suggest that 2 IDE busses are > present. However opening up the machine I can find only one (for DQA). > I see a row of connectors : (SCSI,Floppy,IDE) all for different plugs. > > Where do I have to look for the secondary IDE bus? DQ looks for or knows how many IDE buses that can be connected off the southbridge, and not at how many devices are connected off the southbridge. This means you'll regularly see two or more of the DQ devices (DQA0: and DQA1: on the first bus and DQB0: and DQB1: on the second) marked as offline on many systems. DQ doesn't differentiate from "not pinned" and "not connected". IIRC, there are a few Alpha systems around where DQA0: and DQA1: are offline and are either not pinned or not connected, and DQB0: and DQB1: are. The code modification within DQ that would delete any of these dangling UCBs isn't particularly difficult, but AFAIK that's apparently never made it "above the fold" and never been tested and shipped by HP. (And in the department of "no good deed goes unpunished", removing these dangling UCBs might well derail some application somewhere that always expects to find them. Simple changes compiled with an installed base leads to situations becoming Not Simple.) The delete-if-offline change is probably a dozen lines of Macro32 code, give or take. There are various SYS$DQDRIVER ECO kits, however. The AlphaStation XP1000 boxes I've worked with have all had one IDE bus connection. There's no DMA path on this box, either. It's PIO. (I've been told Linux also used the PIO path for this particular southbridge, though I've not confirmed that.) There's an additional wrinkle in the SRM console found on the AlphaStation XP1000, in that it requires specific device configurations from ATAPI devices in order to bootstrap. Many current DVD recorders do not present that, and SRM can't deal with these. There are recording devices that do boot, and one that has been referenced here in the past is the Plextor PX-716A series drives. There are undoubtedly others. Off-hand, I don't know if HP has a supported half-height recorder that is bootable in this box. Newer versions of SRM do not have this limitation, but the most current version of SRM for the AlphaStation XP1000 appears to be frozen at an older release. (I dug into this a while back, and it appears to be a bootstrap-time callback into the SRM firmware that's failing. I didn't run a bus trace to figure out why.) Newer SRM seems rather more tolerant of the default ATAPI device settings for the connected CD-R/RW or DVD+R/RW device. There are some related media-recording discussions at: http://64.223.189.234/node/28 And if somebody has an AlphaStation XP1000 with a second IDE -- that 54-25090-01 revision F series motherboard mentioned else-thread -- I'd certainly be interested in hearing about that. I've not encountered one. Hoff -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Tue, 06 Mar 2007 11:17:18 -0500 From: sol gongola Subject: Re: DNS- What I'm NOT doing wrong Message-ID: Paul Sture wrote: > In article <45ECE2B5.6609A56F@spam.comcast.net>, > David J Dachtera wrote: > >> Marcin 'Rambo' Roguski wrote: >>> TCPIP> SET NAME/SYSTEM /ENABLE >>> >>> And all is good now :D >>> >>> Why it hasn't been engaged, I have no idea- but after adding that >>> suboption even if domain name mismatches (which is actually true, >>> because id.uw.edu.pl is not authoritative reply: authoritative is >>> InDz.noname.net.icm.edu.pl), resolver works like charm... >>> >>> Now to get a mozilla :D >>> I wonder, is there an implementation of VNC for VMS? >> O.k. I'll bite: What is VNC? >> > > "Virtual Network Computing" from the University of Cambridge. You can > control one system from another. > > http://www.cl.cam.ac.uk/research/dtg/attarchive/vnc/index.html > > To the OP, yes, there is a VMS port of the VNC viewer which is what I > used to use to control my PC indoors from a VAX outdoors when the > weather was fine :-) > > The port is available from links at: > > http://www.cl.cam.ac.uk/research/dtg/attarchive/vnc/platforms.html#vms > I remmember a vnc client, not a vnc server. ------------------------------ Date: Tue, 6 Mar 2007 17:57:01 +0100 From: Marcin 'Rambo' Roguski Subject: Re: DNS- What I'm NOT doing wrong Message-ID: <20070306175701.8c9af71d.m_roguski@yahoo.com> > I remmember a vnc client, not a vnc server. Yup, in deed, just viewer, not server- although it shouldn't be impossible to port the server. I not the one who's gonna do it (just yet), though... Happy news, AS is now in its third day of uptime, pretty good result for machine that was supposed to be dead :) Rambo ------------------------------ Date: 6 Mar 2007 06:25:24 -0800 From: "UnderMine" Subject: Re: History of VMS and related operating systems Message-ID: <1173191118.727900.88370@s48g2000cws.googlegroups.com> On Mar 1, 9:22 pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <1172677904.174207.242...@h3g2000cwc.googlegroups.com>, "UnderMine" writes: > > > Hi, > > > I am currently updating my graphical timeline of Non-Unix operating > > systems and would be interested in any additional information about > > VMS releases. I am especally interested in the release and history of > > VAXELN and MicroVMS as I have been unable to get reliable information > > on these. > > VAXEln is not VMS. It just runs on VAXes, like VMS, ULTRIX, and BSD > UNIX. What exactly is the genealagy of VAXELN? My understanding was that it originally branched from VMS and then developed independantly. VMS -> VAXELN (influence/code?) VMS -> Project Mica (1986-1988) (influence/code?) Mica -> NT (influence/code?) - http://www.businessreviewonline.com/blog/archives/2005/10/ballmer_microso.html Does anyone have version release dates for VAXELN? Thanks Paddy ------------------------------ Date: 6 Mar 2007 04:08:27 -0800 From: "Ian Miller" Subject: Re: MediaWiki on OpenVMS? Message-ID: <1173182907.085492.311990@c51g2000cwc.googlegroups.com> you may want to ask over in the forums on the VAMP site http://vamp.issinoho.com/ ------------------------------ Date: Tue, 6 Mar 2007 09:41:15 -0800 From: "Malcolm Dunnett" Subject: Re: Oracle moves to per-chip licencing Message-ID: <45eda78a$1@flight> "Malcolm Dunnett" wrote in message news:45ed9691$1@flight... > "David J Dachtera" wrote in message > news:45ECDF2D.9488C788@spam.comcast.net... > FWIW Oracle 10g Standard Edition is available for Itanium systems > running HP-UX and for Alpha systems running Tru64 Unix, but not for > either platform running VMS. So there are current and future HP choices > for deploying Standard Edition, just not on VMS. > I've just been informed that Oracle will release Standard Edition 10.2 on VMS (Alpha and Itanium) by the end of May. Stay tuned ... ------------------------------ Date: Tue, 06 Mar 2007 11:09:07 -0500 From: JF Mezei Subject: OT: Proposed additions to the PDP11 instruction set Message-ID: <5040b$45ed9239$cef8887a$13081@TEKSAVVY.COM> Saw this as a "quote of the day" on a web site... Proposed Additions to the PDP-11 Instruction Set: BBW Branch Both Ways BEW Branch Either Way BBBF Branch on Bit Bucket Full BH Branch and Hang BMR Branch Multiple Registers BOB Branch On Bug BPO Branch on Power Off BST Backspace and Stretch Tape CDS Condense and Destroy System CLBR Clobber Register CLBRI Clobber Register Immediately CM Circulate Memory CMFRM Come From -- essential for truly structured programming CPPR Crumple Printer Paper and Rip CRN Convert to Roman Numerals ------------------------------ Date: 6 Mar 2007 16:28:31 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: OT: Proposed additions to the PDP11 instruction set Message-ID: <555j5eF21d8nnU1@mid.individual.net> In article , sol gongola writes: > JF Mezei wrote: >> Saw this as a "quote of the day" on a web site... >> >> Proposed Additions to the PDP-11 Instruction Set: >> >> BBW Branch Both Ways >> BEW Branch Either Way >> BBBF Branch on Bit Bucket Full >> BH Branch and Hang >> BMR Branch Multiple Registers >> BOB Branch On Bug >> BPO Branch on Power Off >> BST Backspace and Stretch Tape >> CDS Condense and Destroy System >> CLBR Clobber Register >> CLBRI Clobber Register Immediately >> CM Circulate Memory >> CMFRM Come From -- essential for truly structured programming >> CPPR Crumple Printer Paper and Rip >> CRN Convert to Roman Numerals > > I remember some of these, and others from my old IBM OS/360 days. How about the old Motorola Instruction - HCF -- Halt and Catch Fire :-) 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 ------------------------------ Date: Tue, 06 Mar 2007 11:54:32 -0500 From: "Richard B. gilbert" Subject: Re: OT: Proposed additions to the PDP11 instruction set Message-ID: <45ED9CC8.3030203@comcast.net> JF Mezei wrote: > Saw this as a "quote of the day" on a web site... > > Proposed Additions to the PDP-11 Instruction Set: > > BBW Branch Both Ways > BEW Branch Either Way > BBBF Branch on Bit Bucket Full > BH Branch and Hang > BMR Branch Multiple Registers > BOB Branch On Bug > BPO Branch on Power Off > BST Backspace and Stretch Tape > CDS Condense and Destroy System > CLBR Clobber Register > CLBRI Clobber Register Immediately > CM Circulate Memory > CMFRM Come From -- essential for truly structured programming > CPPR Crumple Printer Paper and Rip > CRN Convert to Roman Numerals EPI Execute Programmer Immediate BADC Branch and Dump Core LACC Load and Clear Core RWP Rewind Printer ------------------------------ Date: Tue, 6 Mar 2007 18:44:32 +0000 (UTC) From: "Dr Ivan D. Reid" Subject: Re: OT: Proposed additions to the PDP11 instruction set Message-ID: On Tue, 06 Mar 2007 11:54:32 -0500, Richard B. gilbert wrote in <45ED9CC8.3030203@comcast.net>: > JF Mezei wrote: >> Saw this as a "quote of the day" on a web site... >> Proposed Additions to the PDP-11 Instruction Set: >> >> BBW Branch Both Ways >> BEW Branch Either Way >> BBBF Branch on Bit Bucket Full >> BH Branch and Hang >> BMR Branch Multiple Registers >> BOB Branch On Bug >> BPO Branch on Power Off >> BST Backspace and Stretch Tape >> CDS Condense and Destroy System >> CLBR Clobber Register >> CLBRI Clobber Register Immediately >> CM Circulate Memory >> CMFRM Come From -- essential for truly structured programming >> CPPR Crumple Printer Paper and Rip >> CRN Convert to Roman Numerals > EPI Execute Programmer Immediate > BADC Branch and Dump Core > LACC Load and Clear Core > RWP Rewind Printer HCF Halt and Catch Fire -- Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration, Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN KotPT -- "for stupidity above and beyond the call of duty". ------------------------------ Date: Mon, 05 Mar 2007 01:39:44 -0500 From: Dave Froble Subject: Re: OT: Quebec Health Care Virus Message-ID: JF Mezei wrote: > Alfred Falk wrote: >> If by "broken" you mean that the well-off cannot jump queues ahead of >> the poor... well, I don't count that as broken. (And I qualify under >> StatsCan definitions as "wealthy".) > > One only need to look at GM/Ford/Chrysler in the USA. Their lack of > competitiveness (or near bankrupcy status as is he case now) is to a > large extent due to the health care costs their promised to cover for > their employees, even after retirement. > > In the end, GM/Ford/Chrysler plants are more productive in canada partly > because the corporations are not held responsible for health care costs > directly (even though they pay higher taxes, in the end it comes out > quite advantageously versus their USA operations). > > The young car plants setup by foreign car makers in the USA also have a > huge advantage since they don't yet have retired people to support. > > The canadian system is sustainable in the long term because older > corporations are not penalised for having generated many retired people. > It puts young companies on an equal footing with old established > elephants in terms of health care/tax responsabilities. This is not the > case in the USA. > > > Much is being said about the cost of having iddle computing power. The > same can be said of medical equipment. When people brag about being > able to get an MRI within minutes of a doctor ordering it, it means that > the MRI machine is severely underused. > > At the end of the month, that hospital is paying for MRI machine of a > certain capacity, but not using it to its fullest extent. So the cost > per patient using MRI is much higher. > > When you have a MRI machine that is used 100%, you may have a waiting > list for it, but at the end of the month, you are getting far better > return on your investment and lower cost per patient. (and waiting lists > are not FIFO. There are priorities that doctors assign and someone > really needing an MRI asap gets it ASAP.). I would have to compare this example to CPU, memory, disk storage, and such. For each, you want some excess, to cover heavy periods, and not be overextended. I doubt there will be one participant here that would argue with that statement. If an MRI machine is scheduled for 100% utilization, then I suggest that more MRI machines are needed. Just for example, if all were running at 80%, then there would be the capability of inserting emergencies without impacting scheduled MRIs. The proper number may not be 80%, but surely something under 100%. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 ------------------------------ Date: Tue, 06 Mar 2007 22:47:24 +0800 From: Paul Repacholi Subject: Re: OT: Quebec Health Care Virus Message-ID: <87hcsyig3n.fsf@k9.prep.synonet.com> Dave Froble writes: > If an MRI machine is scheduled for 100% utilization, then I suggest > that more MRI machines are needed. Just for example, if all were > running at 80%, then there would be the capability of inserting > emergencies without impacting scheduled MRIs. The proper number may > not be 80%, but surely something under 100%. NMRI, CT, and PET scanners can be run at VERY high utilization with the right policy and scheduling. Early AM, out patiens on way to work, Late PM, the home run shift. All day, booked outpatients, just like every one does it. Random times, emergency and urgent cases. All those waiting have their time slid back. All night, in patients. There already here and it, as a rule, does not matter when you wake them up and wheel them in. Oh, you need to fit pre-prep patients into pretty fixed slots. NMRI is a bit of a pain because the imaging times are longer, and once in a blue moon they lose the field, and the LHe :( That can knock them out for several days. Pet scanners have their own `fun' issues, mainly relating to patients who `glow in the dark' and you want to sit WAYYYY over there! ;) ------------------------------ Date: Tue, 06 Mar 2007 15:20:56 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SAMBA on OpenVMS with OS X client Message-ID: <00A64361.972B879E@SendSpamHere.ORG> In article , Paul Sture writes: > > >In article <00A641D1.5601C314@SendSpamHere.ORG>, > VAXman- @SendSpamHere.ORG wrote: > >> Here's what I'm seeing. >> >> A share mapped to an ODS-2 drive is no problem. I can open, edit and close >> a file with TextEdit. I can also open a terminal session and do all that I >> want to do from the command line. A share mapped to an ODS-5 volume is the >> problematic one. I can, like with the mapped ODS-2 share, do most anything >> I want from the command line; however, I cannot save any file editted using >> TextEdit. I find files of the form .dat### on the share. I am thinking it >> has something to do with the ODS-5 filenaming semantics and the renaming of >> the temporary file .dat### that TextEdit creates. >> >> In both cases, the protections that are displayed look identical: >> >> [~] % cd /Volumes >> [/Volumes] % ls -ls >> 8 lrwxr-xr-x 1 root admin 1 Mar 3 21:52 Hard Drive -> / >> 32 drwx------ 1 vaxman admin 16384 Dec 31 1969 squyrm ; ODS-2 >> 32 drwx------ 1 vaxman admin 16384 Dec 31 1969 squyrm-web ; ODS-5 >> > >My equivalent listing has today's date and times. "Dec 31 1969" being >before the Unix start date, could this be a cause or by-product of your >problem? > >Another thought: from a post you made here last week, you were looking >at DECC$EFS_* logicals. Do you have those logicals present in the target >environment? > >On my system, both the NMBD and SMDB_BGnnnn processes show "Parse Style: >Traditional" and "Case Lookup: Blind". That was for David Jones's OSU web server. I wanted to modify the code for the DIRECTORY server so that it would display: This^_filename^_has^_spaces.txt as This filename has spaces.txt As well as other non-traditional OpenVMS filenaming characters without the ^ escape. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Tue, 06 Mar 2007 12:24:43 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: VMS and storage subsystems documentation ? Message-ID: In article <7d78$45ece398$cef8887a$13197@TEKSAVVY.COM>, JF Mezei wrote: >David J Dachtera wrote: >> More to the point: VMS does not know/care what is being presented: a single >> physical spindle, a RAIDset, etc. All it sees is a LUN (Logical UNit) that looks >> like a disk and reports a certain size/geometry. The size can change, within the > >Yeah, but doesn't VMS need to know about whatever card is used to connect >the computer to the disk array ? Or do those cards synthesize a SCSI >interface to the firmware and OS ? VMS disks that are connected via SCSI, SAS, and FibreChannel all use the SCSI disk class driver, SYS$DKDRIVER.EXE. The lower-level, adapter-specific port drivers all present a common interface to the class driver. ------------------------------ Date: Tue, 06 Mar 2007 11:32:31 -0500 From: JF Mezei Subject: Re: VMS and storage subsystems documentation ? Message-ID: <6bb6b$45ed97b4$cef8887a$15341@TEKSAVVY.COM> Robert Deininger wrote: > VMS disks that are connected via SCSI, SAS, and FibreChannel all use the > SCSI disk class driver, SYS$DKDRIVER.EXE. The lower-level, > adapter-specific port drivers all present a common interface to the class > driver. Does this mean that a utility such as RZDISK could be used against a drive on VMS and whatever SCSI commands sent by RZDISK would be interpreted by the storage array and a response synthesised based on how that logical drive had been configured ? ------------------------------ Date: Tue, 06 Mar 2007 12:09:38 -0500 From: Stephen Hoffman Subject: Re: VMS and storage subsystems documentation ? Message-ID: JF Mezei wrote: > Robert Deininger wrote: >> VMS disks that are connected via SCSI, SAS, and FibreChannel all use the >> SCSI disk class driver, SYS$DKDRIVER.EXE. The lower-level, >> adapter-specific port drivers all present a common interface to the class >> driver. > > Does this mean that a utility such as RZDISK could be used against a > drive on VMS and whatever SCSI commands sent by RZDISK would be > interpreted by the storage array and a response synthesised based on how > that logical drive had been configured ? He who tosses unexpected SCSI commands at an arbitrary device receives what is deserved. Corruption, crash, fire, flood, pestilence, etc. Mr Deininger is referring to the class-port interface; to the internal layering of the device driver stack below the driver presenting the user and application I/O interface, and above driver that provides the particular controller interface. The SCSI protocol itself operates over SCSI, SAS, parallel and serial ATAPI, USB, IP (via iSCSI) and probably a couple of other buses. There are differences among the various devices. USB, for instance, fully introduced the concept of the random and unexpected device disconnect. Here's a high-level intro to the I/O model used on OpenVMS: http://64.223.189.234/node/114 -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: 6 Mar 2007 13:11:18 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Wanted: MicroVAX I / VAXstation I owners Message-ID: <5557jmF2330chU2@mid.individual.net> In article <1hujxz8.wdjujs1j4gr4zN%usenet@hoffart.de>, usenet@hoffart.de (Goetz Hoffart) writes: > Richard B. gilbert wrote: > >> Apple really shot themselves in the foot with the Mac. > > It was the only product that worked and selled at that time. And it > worked quite well till the mid-90s. There were (are?) a lot of CPM users who might disagree with the idea that the Mac was the only product that worked!! > >> The original Mac >> came with only 64KB of memory (shortage of the right kind of chip or >> something). > > 128 KB. And a somewhat experienced hobbyist could solder in additional > RAM stacking onto the existing one's for a full 512 KB. I remember the ads for "the fat Mac" which was the first one I saw with 512K. If you were the kind of computer user who felt comfortable taking a soldering iron to your home computer there were a lot of system available. :-) > >> The only way to develop software for the Mac was to buy a >> Lisa. > > Right. Not very unusual for a new product. PowerMac G5 were used for > some XBox development. So what? So what? How long would the PC have lasted if writing softwafre for it required that you buy a scond computer that cost 5 time as much as the PC? And, having used the Lisa, I was not impressed. And, while I have a number of different models of M68K Macs still in my computer room I still see them as little more than toys. I had other M68K based systems running UNix that ran circles around the Mac from the very beginning (not all of them Suns, either!) > >> Then there was the closed architecture; no slots where you could >> plug in a hard disk controller, etc, etc, etc. > > Missing SCSI was a mistake, right. > >> The graphic arts people loved them, and still do. There was nothing >> there that anybody else needed or wanted > > A Mac simply works. You didn't have to learn DOS. You could work on an > 68000/8 in a productive way you couldn't with a 286/16. Even then, Intel was not the only other alternative. > >> and the Mac became a "niche" machine. > > Which says nothing about the quality of the product. I don't know many > markets where the best selling product is the best. I can only go by personal experience (which is, for the individual, the only benchmark that really matters) but I was never impressed with the Mac and I certainly am not now being as it is nothing but another (inferior) Unix system with a strange Window Manager. 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 ------------------------------ Date: Tue, 06 Mar 2007 22:56:26 +0800 From: Paul Repacholi Subject: Re: Wanted: MicroVAX I / VAXstation I owners Message-ID: <87d53mifol.fsf@k9.prep.synonet.com> no.spam@no.uce.bellatlantic.net writes: > The 11/730 was a bit faster (faster IO devices) but still very slow. > The other difference was the 730 could expand further than a > Microvax-I making it marginally more useful. A 730 with a UDA50 and NO IDC was almost tolerable. I used to use one that had been dropped down a coal mine. You could hear it doing the cab rock-rattle-and-roll from miles away! Mind, I did boot it in the morning to use after the day at the plant. (TU-58s, remember...) ------------------------------ Date: 6 Mar 2007 18:09:13 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Wanted: MicroVAX I / VAXstation I owners Message-ID: <555p29F22u8dgU1@mid.individual.net> In article <51deb$45ed9bb9$cef8887a$17098@teksavvy.com>, JF Mezei writes: > Bill Gunshannon wrote: >> So what? How long would the PC have lasted if writing softwafre >> for it required that you buy a scond computer that cost 5 time >> as much as the PC? > > The mac was designed as an appliance with much of the software included > with it. MAcPaint, MacWrite etc etc. > > > >> And, having used the Lisa, I was not impressed. >> And, while I have a number of different models of M68K Macs still >> in my computer room I still see them as little more than toys. I >> had other M68K based systems running UNix that ran circles around >> the Mac from the very beginning (not all of them Suns, either!) > > Your unix systems did not have a GUI. Actually, some did. But that is really irrelevant as this was still BW (Before Windows) and the majority of computers (and computing) did not use a GUI. > I saw a Lisa at university (one > professor had gotten a demo), but my first mac was a Mac+. Saw the Mac first. I wasn't impressed. It ran simple programs slower than any other 68K I worked on. Sadly, the people at Apple never seemed to be overly concerned about things like efficiency and in those days, it was important. > > the MAC's user interface was way ahead of what was generally available for > home computers back then. Only when compared to the way we do things today. Everybody didn't have GUI's back then and most didn't really need or want one. And there were others. I had an OS9 system on a 6809 that had a GUI (of sorts) that it could run. But it usually just slowed down production rather than speeding it up. I actually experimented with my daughter (who was pre-school at the time) and it became obvious real fast that the mouse was not intuitively obvious. It required a good deal practice before it impreoved productivity. And all the time the GUI just ate up resources better spent on getting the job done. > And while it appears that precursors to the mac+ > were really crippled (as some have said, no SCSI, memory not upgradable), > it appears to me that they were "betas" not quite ready for prime time. But > the MAc+ was a good machine. Matter of opinion. > > Its achile's heel was b/w small screen which became a marketing an issue > once DOS gained primitive colour capabilities. But for desktop publishing > at the time, colour wasn't an issue. And cosnider that the MAC (at least > with the +) had full postscript support and proper font support. It took > ages before microsoft's products got to that point. And yet, the most popular word processors grew on the PC without havng this wondrous PostScript capability. Go figure. > > > And when you look at others, the overall user interface was copied from the > MAC , but in a much less graceful manner. It took Microsoft perhaps 10 > years to even start to approach what the mac had in 1986. Which wasn't even close to what MIT had been doing for a few years already. (Hint: What ran on Ultrix ont he VAX with QVSS in 1985?) And even to get that far Apple had to steal their GUI code from Xerox. > > > When you look at Motif, it really lagged behind in terms of widgets (for > instance vertical resizable frames within a window). Motif was hardly the only thing available (and is probably the worst example, especially when you get into the poitics involved, but that a tory for another discussion.) And, as long as we are comparing capabilities, when did the Mac get the ability to display graphics on remote displays? You and VaxMan can stick with your Macs. I'll choose productivity over cute every time. 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.130 ************************