HECnet

hecnet@lists.dfupdate.se

2 participants
15583 discussions

Easiest way to do 'sed' type search and replace on VMS...

by sampsa＠mac.com

On 9 Feb 2013, at 02:05, Johnny Billquist <bqt at softjar.se> wrote: On 2013-02-09 00:59, Sampsa Laine wrote: I'm thinking of tweaking the HECNET infoservice* on RHESUS, and figured it'd be nice if the nodes in the output of NCP SHOW KNOWN NODES were hyperlinks. On Unix I would just replace all the "(" characters with an opening <a> + "(" tag and all the ")" with a closing </a> tag + ")" using sed. What's the correct DCL way to do this? sampsa * This is the page I'm thinking of tweaking: http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com TECO? :-) <FS($(<a>$FS)$</a>)$;> But I don't think just a <a> tag would be enough, would it? Wouldn't you want a href in there, and so on? Of course, but I left that out for the sake of brevity. How do I invoke TECO on VMS? I've only heard apocryphal tales of it's less than simple syntax, never actually used it.. sampsa

12 years, 8 months

Easiest way to do 'sed' type search and replace on VMS...

by bqt＠softjar.se

On 2013-02-09 00:59, Sampsa Laine wrote: I'm thinking of tweaking the HECNET infoservice* on RHESUS, and figured it'd be nice if the nodes in the output of NCP SHOW KNOWN NODES were hyperlinks. On Unix I would just replace all the "(" characters with an opening <a> + "(" tag and all the ")" with a closing </a> tag + ")" using sed. What's the correct DCL way to do this? sampsa * This is the page I'm thinking of tweaking: http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com TECO? :-) <FS($(<a>$FS)$</a>)$;> But I don't think just a <a> tag would be enough, would it? Wouldn't you want a href in there, and so on? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 8 months

Easiest way to do 'sed' type search and replace on VMS...

by sampsa＠mac.com

I'm thinking of tweaking the HECNET infoservice* on RHESUS, and figured it'd be nice if the nodes in the output of NCP SHOW KNOWN NODES were hyperlinks. On Unix I would just replace all the "(" characters with an opening <a> + "(" tag and all the ")" with a closing </a> tag + ")" using sed. What's the correct DCL way to do this? sampsa * This is the page I'm thinking of tweaking: http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com

12 years, 8 months

VS4000/90: Up and running!

by bqt＠softjar.se

On 2013-02-08 23:31, Jordi Guillaumes i Pons wrote: El 08/02/2013, a les 23:14, Johnny Billquist <bqt at softjar.se> va escriure: And the problem is just that the boot rom uses a more restricted disk block addressing, limiting the booting to disks of less than 1G. (Actually, you can boot from larger disks as well, as long as the boot rom don't need to read from anything above 1G.) Nice to know. IIRC I read about the firmware dropping the high bits of the block address so at some point in time the writes against the disk would "wrap around" and trash the first 4GBs... but it seems its quite an urban legend :) No. That is correct. And it's 1G, not 4G. SCSI commands comes in some different flavors. Old VAXstations (and some others) used 6 byte SCSI commands, which limited the block numbers to 20 bits (some say 21, but I think it is 20). Later systems use 10 byte SCSI commands, which allows for 32 bit block numbers. What happens is that if you go above 20 bits in the SCSI commands of those old VAXen, they will just use the low 20 bits of the block number, so you will indeed wrap. See http://labs.hoffmanlabs.com/node/218 if you want a few more details. BTW, This is a nice sight: $ sh net VAX/VMS Network status for local node 7.61 BITXOO on 8-FEB-2013 23:26:08.76 The next hop to the nearest area router is node 7.60 BITXOV. Node Links Cost Hops Next Hop to Node 7.61 BITXOO 0 0 0 (Local) -> 7.61 BITXOO 7.6 MBSERV 0 3 1 UNA-0 -> 7.6 MBSERV 7.60 BITXOV 0 3 1 UNA-0 -> 7.60 BITXOV 7.64 BITXO1 0 3 1 UNA-0 -> 7.64 BITXO1 7.65 BITXO2 0 3 1 UNA-0 -> 7.65 BITXO2 7.67 BITXO4 0 3 1 UNA-0 -> 7.67 BITXO4 7.68 BITXO5 0 3 1 UNA-0 -> 7.68 BITXO5 7.70 BITXOT 0 3 1 UNA-0 -> 7.70 BITXOT 7.71 BITXOR 0 3 1 UNA-0 -> 7.71 BITXOR 7.72 BITXOM 0 3 1 UNA-0 -> 7.72 BITXOM 7.74 BITXOW 0 3 1 UNA-0 -> 7.74 BITXOW 7.79 BITXT0 0 3 1 UNA-0 -> 7.79 BITXT0 :-) Emulated Unibus-machine, or the real deal? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 8 months

VS4000/90: Up and running!

by jg＠jordi.guillaumes.name

El 08/02/2013, a les 23:14, Johnny Billquist <bqt at softjar.se> va escriure: And the problem is just that the boot rom uses a more restricted disk block addressing, limiting the booting to disks of less than 1G. (Actually, you can boot from larger disks as well, as long as the boot rom don't need to read from anything above 1G.) Nice to know. IIRC I read about the firmware dropping the high bits of the block address so at some point in time the writes against the disk would "wrap around" and trash the first 4GBs... but it seems its quite an urban legend :) BTW, This is a nice sight: $ sh net VAX/VMS Network status for local node 7.61 BITXOO on 8-FEB-2013 23:26:08.76 The next hop to the nearest area router is node 7.60 BITXOV. Node Links Cost Hops Next Hop to Node 7.61 BITXOO 0 0 0 (Local) -> 7.61 BITXOO 7.6 MBSERV 0 3 1 UNA-0 -> 7.6 MBSERV 7.60 BITXOV 0 3 1 UNA-0 -> 7.60 BITXOV 7.64 BITXO1 0 3 1 UNA-0 -> 7.64 BITXO1 7.65 BITXO2 0 3 1 UNA-0 -> 7.65 BITXO2 7.67 BITXO4 0 3 1 UNA-0 -> 7.67 BITXO4 7.68 BITXO5 0 3 1 UNA-0 -> 7.68 BITXO5 7.70 BITXOT 0 3 1 UNA-0 -> 7.70 BITXOT 7.71 BITXOR 0 3 1 UNA-0 -> 7.71 BITXOR 7.72 BITXOM 0 3 1 UNA-0 -> 7.72 BITXOM 7.74 BITXOW 0 3 1 UNA-0 -> 7.74 BITXOW 7.79 BITXT0 0 3 1 UNA-0 -> 7.79 BITXT0 Now, if I could just fix poor BITXO3 (which is a VS 3100 with a toasted cache in the mobo...). Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES

12 years, 8 months

VS4000/90: Up and running!

by bqt＠softjar.se

On 2013-02-08 21:52, Jordi Guillaumes i Pons wrote: Oh, now I need a disk for that machine. Right now it is running diskless as a satellite of my 4000/60, paging via ethernet (ouch!). I have some SCA-68-50 pin adapters for SCSI disks, and I have used those with success with 4GB drives, but I have read somewhere the vaxstation firmware can't handle disks bigger than that. Anyone knows if that is true? Can I plug in a generic, big SCSI disk and hope it will work? Sigh. The misinformation that keeps spreading. The problem is for specific older VAXen. I think it's even only specific 3100 models. And the problem is just that the boot rom uses a more restricted disk block addressing, limiting the booting to disks of less than 1G. (Actually, you can boot from larger disks as well, as long as the boot rom don't need to read from anything above 1G.) Once the OS starts, it uses its own device driver, and then you don't have the restriction either. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 8 months

VS4000/90: Up and running!

by jg＠jordi.guillaumes.name

El 08/02/2013, a les 22:11, Dennis Boone <drb at msu.edu> va escriure: I thought the situation was that NOS chips were available, not new ones? Honestly, though, I might hack on even a new one: potting a battery with a limited life span is the dumbest thing since russian roulette with a pistol. Well, as I wrote, I bought 2. One of them is dead. So now I have two dead chips to practice surgery with :) The one in the 4000/60 will die one of these days too... Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES

12 years, 8 months

VS4000/90: Up and running!

by jg＠jordi.guillaumes.name

El 08/02/2013, a les 22:10, Brian Hechinger <wonko at 4amlunch.net> va escriure: Tell that to the 146GB SCA SCSI disks I have in my 4000/90. One word of warning, the disk carrier won't fit back into the machine with the SCA/50-pin adapters. The cables hit the inside "wall" between the disks and 5.25" bay. Nice! As for the ugly fitting, I have already a SCA 4GB disk in the 4000/60, so I know what are you talking about ;) Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES

12 years, 8 months

VS4000/90: Up and running!

by drb＠msu.edu

I keep reading about people cracking open those chips, and I always wonder why they bother. They're neither expensive nor difficult to find brand-new. Why would one find it worth the time to spend an afternoon performing surgery on that chip to replace the battery when you can get a new one on the way for about eight bucks? I thought the situation was that NOS chips were available, not new ones? Honestly, though, I might hack on even a new one: potting a battery with a limited life span is the dumbest thing since russian roulette with a pistol. De

12 years, 8 months

VS4000/90: Up and running!

by b4＠gewt.net

On 8 Feb 2013, at 16:10, Brian Hechinger <wonko at 4amlunch.net> wrote: On 2/8/2013 3:52 PM, Jordi Guillaumes i Pons wrote: Oh, now I need a disk for that machine. Right now it is running diskless as a satellite of my 4000/60, paging via ethernet (ouch!). I have some SCA-68-50 pin adapters for SCSI disks, and I have used those with success with 4GB drives, but I have read somewhere the vaxstation firmware can't handle disks bigger than that. Anyone knows if that is true? Can I plug in a generic, big SCSI disk and hope it will work? Tell that to the 146GB SCA SCSI disks I have in my 4000/90. Nice! One word of warning, the disk carrier won't fit back into the machine with the SCA/50-pin adapters. The cables hit the inside "wall" between the disks and 5.25" bay. -brian

12 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet