INFO-VAX Sat, 27 Jan 2007 Volume 2007 : Issue 53 Contents: Re: FPGA VAX Re: FPGA VAX Re: FPGA VAX Re: FPGA VAX Re: FPGA VAX Re: FPGA VAX Re: How to catch ots$movc3 error in a pascal user process Re: How to catch ots$movc3 error in a pascal user process Re: Kermit Large File Support Re: Make PC drive available to openvms Re: Make PC drive available to openvms Re: PL/I for Itanium Purging across nodes deletes the only version of a file Re: Purging across nodes deletes the only version of a file Re: VMS in the HP hierarchy Re: VMS in the HP hierarchy Re: VMS in the HP hierarchy Was installed with VMSINSTAL, can be upgraded with Polycenter? Re: Was installed with VMSINSTAL, can be upgraded with Polycenter? ---------------------------------------------------------------------- Date: 26 Jan 2007 14:10:30 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: FPGA VAX Message-ID: In article <45b5409e$0$24379$88260bb3@free.teranews.com>, Tim Sneddon writes: > Anyone seen this before? I thought it looked kind of interesting... > > FPGA VAX > > RT Logic is re-implementing VAX computer systems in FPGA for Hewlett Packard. By leveraging HP's VAX intellectual property, RT Logic will provide VAX single-board computers and peripherals to replace legacy systems critical to the maintenance of NATO's Air Defense System. > > The rest can be found at: > > http://www.rtlogic.com/satcom_key_projects.php > > Regards, Tim. Cool. An FPGA VAX could threaten early ALphas for performance. But for plug compatability they probably will have to slow them down. ------------------------------ Date: 26 Jan 2007 14:11:42 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: FPGA VAX Message-ID: In article , "Tom Linden" writes: > > I wonder why Digital/Compaq/HP weren't able to move it to Alpha. What > was it about this code that made them stay on VAX? Just curious. Probably because that $100K VAX was hooked up to $100M custom UNIBUS hardware. ------------------------------ Date: 26 Jan 2007 14:16:56 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: FPGA VAX Message-ID: In article , Stephen Hoffman writes: > It would appear to be a VAX processor built using a field > programmable gate array, rather than with fully- or semi-custom > integrated circuitry. That's not going to be a small FPGA, either. :-) At least one processor, which was almost a PDP-x (can't say which one, but certainly single digit), was implimented in FPGA in the 1990s. One off for only a $1M or so. ------------------------------ Date: 26 Jan 2007 14:17:56 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: FPGA VAX Message-ID: In article , David Mathog writes: > > How is this easier than dusting off the last VAX chip masks and doing a > run or two at a foundry? Given that 90 nm is pretty much standard these > days, and that's probably 10 times the resolution of the last VAX chip > that was made, cranking out a few actual chips shouldn't be that hard. > That is, even if the VAX chip required cutting edge chip technology then > it's not anywhere near that now. A new chip was $5M a pop for a test burn in the early 1980s. ------------------------------ Date: 26 Jan 2007 17:33:30 -0500 From: Rich Alderson Subject: Re: FPGA VAX Message-ID: Stephen Hoffman writes: > It would appear to be a VAX processor built using a field > programmable gate array, rather than with fully- or semi-custom > integrated circuitry. That's not going to be a small FPGA, either. :-) At XKL, we built the Toad-1 System (original code name stood for "Ten on a Desk") using 2 large Altera FPGAs (early 90s value of "large FPGA"). A few years later, we put a similar design into a single Synopsys FPGA. This was a KL-10 superset processor (full PDP-10 instruction set, larger cache and full 30-bit addressing vs. 22 on the KL-10). So a VAX is not that hard to envision using today's parts. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ Date: 26 Jan 2007 23:50:33 GMT From: healyzh@aracnet.com Subject: Re: FPGA VAX Message-ID: David Mathog wrote: > How is this easier than dusting off the last VAX chip masks and doing a > run or two at a foundry? Given that 90 nm is pretty much standard these > days, and that's probably 10 times the resolution of the last VAX chip > that was made, cranking out a few actual chips shouldn't be that hard. > That is, even if the VAX chip required cutting edge chip technology then > it's not anywhere near that now. > Or during all the mergers did Dec/Compaq/HP manage to lose the masks, > so that they have no choice but to do it with an FPGA? For that matter, > why not just run a VAX emulator on an off the shelf CPU and skip the > custom chip entirely? The technology for such things change rapidly. Can those masks still be read? Does the hardware needed to fab those parts still exist anywhere? This is likely cheaper than trying to setup a fab to produce more VAX chips. FPGA implementations of old hardware is big business. The PDP-10, PDP-11, Commodore 64, and probably others have had commercial systems released using FPGA CPU's. There has already been at least one VAX implementation done in FPGA by Tokai University. For a rundown of the FPGA implementations of DEC CPU's that I'm aware of (minus this latest VAX, as I've not had time to update the page), see the following. http://www.aracnet.com/~healyzh/pdp_fpga.html Zane ------------------------------ Date: Fri, 26 Jan 2007 20:25:52 GMT From: Rob Brown Subject: Re: How to catch ots$movc3 error in a pascal user process Message-ID: On Fri, 26 Jan 2007 fkburrie@gmail.com wrote: > One of my pascal programs crashed during ots$movc3 (Openvms 7.3.1) > with pageread error (PAGRDERR) and io status 01F4 (=parity error?). > Addressed memory is mapped to disk. I am hardly an expert on this, but I would expect that such an event would be a hardware error. Does $ SHOW ERROR indicate any errors? What about ANALYZE/ERROR_LOG (or whatever it is that replaced it)? If not, I wonder if the crash could be violent enough that the wrong status is being reported. > According to HELP /message pagrderr an ana /disk /read_check has > been performed without any significant result. Suspicious. > Someone has a clue of what could be the underlying problem and how I > can catch the error? I don't have any clues at all. I found documentation for LIB$MOVC3 and OTS$MOVE3 (but not OTS$MOVC3). The calling parameters are similar for these two routines, but the argument mechanism for the first parameter is different: value vs reference. I would double check the routine and parameters and make sure that the argument calling mechanism is correct. Usually bad parameters or bad calling mechanisms manifest themselves as ACCVIO, but who knows. After that, I am not very imaginative. I would probably try stepping into the routine with the debugger to try to see how my data looks inside the routine and where things are going wrong. hth -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: Fri, 26 Jan 2007 16:27:56 -0500 From: Stephen Hoffman Subject: Re: How to catch ots$movc3 error in a pascal user process Message-ID: fkburrie@gmail.com wrote: > One of my pascal programs crashed during ots$movc3 (Openvms 7.3.1) with > pageread error (PAGRDERR) and io status 01F4 (=parity error?). > Addressed memory is mapped to disk. According to HELP /message pagrderr > an ana /disk /read_check has been performed without any significant > result. The problem is that ots$movc3 does not return a result value > that can be catched by the calling program. Someone has a clue of what > could be the underlying problem and how I can catch the error? Shot-gun answer follows: I'd ECO the OpenVMS Alpha V7.3-1 system to current, and would consider an upgrade to V7.3-2 -- the latter has Prior Version Support status, and thus has more current updates. This approach on the off chance that there's a low-level software error lurking. This does initially look to be hardware-level, however. The usual triggers for PAGRDERR and friends are bad or flaky or failing hardware. In this case, I might wonder if there's a bad block under the pagefile or the common or whatever is storing the page involved, or there is a device-level problem. If there are bad blocks, you can recreate the file or pagefile involved to force the device to reallocate the block. If the block is bad, that is. Disk bad block handling is discussed over in the old ATW area. See Various compilers tend to generate code that calls the OTS$ routines; if this is something the compiler has embedded, you're kinda stuck. You'll have to re-code around the code that cases the compiler to emit the call, or otherwise replace it with a lib$movc3 or lib$movc5 or such. Also check bus length, SCSI cable connections and termination. Check your SCSI chain. There are occasionally SCSI device firmware upgrades, too. Look in SYS$ETC: for those, or check the HP support database(s). If the disk(s) involved in this Alpha are old or overheated or dust-plugged or otherwise potentially degraded, I might well look for a few spares. Well, I might well look for a few spare disks anyway. And a question: is this reproducible in some fashion? Or is this a transient error? Or is this error moving around? -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 27 Jan 2007 01:40:37 GMT From: John Santos Subject: Re: Kermit Large File Support Message-ID: Arne Vajhøj wrote: > Steven M. Schweda wrote: > >> Who needs 64-bit pointers to do I/O with a large file? Hint: How big >> can your file be if you address it by 512-byte blocks, and you use a >> 32-bit (signed, say) integer to specify the block? >> >> For that matter, who needs 64-bit system services, either? > > > 64 bit is about memory addresses not about disk addresses. > > And guess what: some people actually like to be able to call > system services with data they have in P2 space. > >> For a program written in C, like, say, C-Kermit, the capabilities of >> the C run-time library may be important. In this respect, there's some >> version conditionality in DECC$TYPES.H, including this hint: >> >> # if defined(_LARGEFILE) >> # error " Support for large files not available before OpenVMS >> Alpha V7.2" >> # endif > > > That is not a VMS thingy. It is a C thingy. > > C (thanks to its Unix heritage) is byte oriented not block oriented. > > So C needed a change to go above 2/4 GB. > > Arne Exactly, and to get back to the implication of the original post, "why doesn't VMS Kermit support large files?", Frank asked for help from the VMS C-Kermit community when he was doing the original Kermit implementation, and no on stepped forward. (My excuse: I was kind of busy and my dog had a dentist appointment. What's yours?) Anyway, if anyone with a VMS system, a "large" disk, and a (relatively) recent C compiler can volunteer... (I don't know if C on VAX supports large files, so this might require an Alpha or Itanium. On the other hand, even if C doesn't support large files or for older versions of C which don't, QIO does, so there are workarounds. I have no idea how much of the work Frank has already done, or if someone else is already doing at least some of it in the background, in which case we all owe them our thanks.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: 26 Jan 2007 14:09:22 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Make PC drive available to openvms Message-ID: In article , Stephen Hoffman writes: > > Sure. Crack open the Microsoft Windows box, yank the disk drive out > of the box, and connect it into the AlphaServer, aim an INITIALIZE > command at it to overwrite the contents and create the OpenVMS disk > volume structures, MOUNT, and Bob's your uncle. :-) Yeah. Bob says you better use INITIALIZE/ERASE so you can swear to your security folks there are no nasty virii on your system. ------------------------------ Date: 26 Jan 2007 13:12:55 -0800 From: "Doug Phillips" Subject: Re: Make PC drive available to openvms Message-ID: <1169845975.526757.8990@l53g2000cwa.googlegroups.com> On Jan 22, 11:11 am, "potter" wrote: > We have a number of PC's running pathworks 7.3 connected to a network > which also has an alpha server running Openvms 7.2 > > Is it possible to set up a drive on one of the PC's such that the alpha > can "see" it. If so - how? What Mr. Hoffman said. Now, what does the server need to do on the PC's disk? Do you really need to access the whole disk? Probably, you just need one folder or file. Can you create a share on the server and have the PC use it rather than a local folder? If your application can't use a network share, you can build a PC procedure to copy the local file over to the share or do it manually with drag & drop. If you have the Pathworks 32 client and can install DECnet on the PC, you might be able to make that work. Use NFS if you can't find a better way. You probably already have most if those pieces, or at least they're a simple download away. The server's ADMIN program can also "see" the files on a properly shared PC disk. So, it all depends on what you need to do other than just "see" the disk. ------------------------------ Date: 26 Jan 2007 14:20:34 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: PL/I for Itanium Message-ID: In article , "Ruslan R. Laishev" writes: > Hello, All! > > What is the status of the PL/I for Itanium, or company have planed to start > migration software has been written on PL/I from Alpha to Itanium and continue > development process ... > > Can someone provide useful pointers ? www.kednos.com ? ------------------------------ Date: Fri, 26 Jan 2007 20:05:36 GMT From: martyn Subject: Purging across nodes deletes the only version of a file Message-ID: Hi Folks, Anyone seen this behaviour before, if you do a purge of a file on a remote node, where the logical name pointing at the file location is a searchlist which contains the file location twice, then it deletes the only version of the file. This is on VMS 7.3-2 & I'd be interested to know if anyone can reproduce this on VMS 8.x TIA, Martyn E.G. $DIR/FILE 1.1 Directory ESSTSG$SYS_USER:[MARTYN.TEST] 1.1;1 (2419,78,0) Total of 1 file. $DEF/GROUP TESTROOT DISK$DTC_COMMON:[DTC_COMMON.ESSTSG.SYS_USER.MARTYN.TEST] + DSA0:[DTC_COMMON.ESSTSG.SYS_USER.MARTYN.TEST] $DIR/FILE TESTROOT:1.1 Directory DSA0:[DTC_COMMON.ESSTSG.SYS_USER.MARTYN.TEST] 1.1;1 (2419,78,0) 1.1;1 (2419,78,0) Total of 2 files. $PURGE/LOG TESTROOT:1.1 %PURGE-I-NOFILPURG, no files purged $DIR/FILE 0"MARTYN"::TESTROOT:1.1 Directory 0"MARTYN"::DSA0:[DTC_COMMON.ESSTSG.SYS_USER.MARTYN.TEST] 1.1;1 None 1.1;1 None Total of 2 files. $PURGE/LOG 0"MARTYN"::TESTROOT:1.1 %PURGE-I-FILPURG, 0"MARTYN"::DSA0:[DTC_COMMON.ESSTSG.SYS_USER.MARTYN.TEST]1.1;1 deleted (0 blocks) $DIR/FILE TESTROOT:1.1 %DIRECT-W-NOFILES, no files found $WRITE SYS$OUTPUT F$GETSYI("VERSIOn") V7.3-2 $SHO LOG DISK$DTC_COMMON/FU "DISK$DTC_COMMON" [exec] = "DSA0:" [terminal] (LNM$SYSTEM_TABLE) $SHO LOG TESTROOT/FUL/TAB=* "TESTROOT" [super] = "DISK$DTC_COMMON:[DTC_COMMON.ESSTSG.SYS_USER.MARTYN.TEST]" (LNM$GROUP_000007) = "DSA0:[DTC_COMMON.ESSTSG.SYS_USER.MARTYN.TEST]" $ ------------------------------ Date: Fri, 26 Jan 2007 20:44:49 GMT From: Rob Brown Subject: Re: Purging across nodes deletes the only version of a file Message-ID: On Fri, 26 Jan 2007, martyn wrote: > Anyone seen this behaviour before, if you do a purge of a file on > a remote node, where the logical name pointing at the file location > is a searchlist which contains the file location twice, then it > deletes the only version of the file. Yes, I experienced this in 1996, as described in . My solution was "Don't do that!" -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: Fri, 26 Jan 2007 16:57:35 -0500 From: Stephen Hoffman Subject: Re: VMS in the HP hierarchy Message-ID: Sue wrote: > Obviously I can not give details but one of the managers that you think > should not be in the mix (not Scott) has thousands (as in more than a > couple) people in their organization and the numbers go up from there. > Just the day to day running of a business that size would be impossible > with out managment below them. ... > On Jan 24, 12:57 am, JF Mezei wrote: >> From what I have been told: >> >> Sue-> McQuaid -> Fink -> Stallard -> Livermore -> Hurd >> >> Is this part of the problem for VMS ? Too many useless layers between the >> real workers in VMS and the real decision maker at the top ? Ok: you're a firefighter treating and working inside a wrecked vehicle to free a severely injured patient pinned inside the wreckage, and your fire officer tells you to get out; to leave the patient. What do you do, and why? >> Shouldn' McQuaid report directly to Livermore ? Only if Mr Fink and Mr Stallard have no or negative value, and if Ms Livermore has the cycles for it. >> Looks to me like folks such as Stallard feel they are "owed" >> responsabilities and have lobbied over time to have groups report under him >> in order to build a bigger kingdom. Look up "span of control" in the following: http://www.training.fema.gov/EMIWEB/is/IS100CM/ICS01summary.htm >> Would it hurt Livermore to have VMS, HP-UX, Storage, 8086 and IA64 server >> groups report directly to her ? Yes, it would. >> By spreading responsabilities between too many people, it means that there >> is nobody with the information AND power to get things done. People with >> information have no autonomy. People with power have no information. And >> the people in between play games to protect their kingdom. Managing more than five or seven and you're really disconnected from what is going on, either up or down. There are cases where this many can work, but they're comparatively specialized and the folks involved are generally skilled or specialized and performing proscribed and/or longer-duration tasks. Most folks really can't effectively manage more than about five to seven other folks. If things are volatile or if you are providing both direct contributions and management, even three to five can be overwhelming. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Fri, 26 Jan 2007 17:33:05 -0500 From: JF Mezei Subject: Re: VMS in the HP hierarchy Message-ID: <45ba81fb$0$6519$c3e8da3@news.astraweb.com> Sue wrote: > Obviously I can not give details but one of the managers that you think > should not be in the mix (not Scott) has thousands (as in more than a > couple) people in their organization and the numbers go up from there. > Just the day to day running of a business that size would be impossible > with out managment below them. There is a concept called "delegation" and "don't micro manage" And if some manager has so many people below him that he/she can't manage, then instead of creating another hierarchy level, you create another brother from the same parent. For instance (just for discussion), if Stallard has too many people that he can't manage, instead of giving him Fink under him, they should have made Fink report to Livermore. This way Stallard can more easily manage the people under him and Fink as one less layer to go through when he wants to get things done. By flattening the hierarchy, Hurd is in closer contact with what is really happening, and it is more difficult for a single person to advise Hurd to do something that fosters that person's personal agenda. ------------------------------ Date: Sat, 27 Jan 2007 03:19:40 +0100 From: Paul Sture Subject: Re: VMS in the HP hierarchy Message-ID: In article , John Santos wrote: > And if the "brother" now increases the load of their manager above the > quota, you need to bucket split the layer above. And so on until you end > up with the top level (Hurd) having too many people under him, so you need > to insert another level. Just like an RMS file. I think they (HP management) > understand this. :-) I like the analogy :-) -- Paul Sture ------------------------------ Date: Fri, 26 Jan 2007 20:05:20 GMT From: gerry77@no.spam.mail.com Subject: Was installed with VMSINSTAL, can be upgraded with Polycenter? Message-ID: Hello everyone, the subject says almost everything: I'm thinking about upgrading some products, in particular COBOL V2.5 to COBOL V2.8, and I do not know if I'll have to take special precautions because the former was installed from a VMSINSTAL kit and the latter is a PCSI kit. Can I simply type PRODUCT INSTALL COBOL and press Enter? :-) A similar question arises for FORTRAN: actually I have V7.1-1 with RTL V7.1-427 and ECO 2 installed, to upgrade to V7.5-1 do I have to remove previous installed kits or is everything done by Polycenter by typing PRODUCT INSTALL FORTRAN (reading DEC-AXPVMS-FORTRAN-V0705-1-1.PCSI)? Thank you! G. ------------------------------ Date: Fri, 26 Jan 2007 16:41:34 -0500 From: Stephen Hoffman Subject: Re: Was installed with VMSINSTAL, can be upgraded with Polycenter? Message-ID: gerry77@no.spam.mail.com wrote: > the subject says almost everything: I'm thinking about upgrading some > products, in particular COBOL V2.5 to COBOL V2.8, and I do not know if > I'll have to take special precautions because the former was installed > from a VMSINSTAL kit and the latter is a PCSI kit. Can I simply type > PRODUCT INSTALL COBOL and press Enter? :-) > > A similar question arises for FORTRAN: actually I have V7.1-1 with RTL > V7.1-427 and ECO 2 installed, to upgrade to V7.5-1 do I have to remove > previous installed kits or is everything done by Polycenter by typing > PRODUCT INSTALL FORTRAN (reading DEC-AXPVMS-FORTRAN-V0705-1-1.PCSI)? There are installation manuals around. There are usually various caveats and recommendations and lists of requirements, and the install manual and the release notes (if any) are where these tend to be referenced. Here are the Cobol and Fortran manuals: http://h71000.www7.hp.com/doc/cobol.html http://h71000.www7.hp.com/doc/fortran.html Do these have anything about this removal? (I'd expect not, as most existing VMSINSTAL kits don't usually have removal mechanisms, and the VMSINSTAL tool didn't itself provide that. I haven't looked through the whole manual, however.) If not, have at... And if you have a BACKUP/IMAGE of your system disk -- a recommendation that is included in the above manuals, at least for the Fortran Alpha installation manual -- you can restore your disk if something does tip over and leave you deep in the weeds. I would look to the mandatory OpenVMS ECO kit(s) for whatever release this might be, one of which is probably a mandatory PCSI ECO kit. This PCSI ECO isn't specific to compiler upgrades, but it does tend to reduce the frequency of problems with the PCSI database; it removes cases where the PCSI database can get its knickers in a twist. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ End of INFO-VAX 2007.053 ************************