INFO-VAX Sat, 13 Oct 2007 Volume 2007 : Issue 560 Contents: Bigger isn't always better! Re: Bigger isn't always better! Re: Bigger isn't always better! Re: Bigger isn't always better! Re: Canadians flee Canadian socialized Hillary type healthcare for U.S. SAMBA/CIFS (Was:Re: Bigger isn't always better!) Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Re: Technical Q&A (Was Re: Actual VMS Technical Qeustion! DECnet Phase IV partly ---------------------------------------------------------------------- Date: Sat, 13 Oct 2007 11:51:41 GMT From: VAXman- @SendSpamHere.ORG Subject: Bigger isn't always better! Message-ID: This past summer I helped a customer to upgrade to VMS V8.3. It took quite a bit of time because they are a 24x7 operation and there is very little downtime. We scheduled one Saturday afternoon each month. The machine would go down, we'd back up the system disk and then update to V8.3. On 3 of the 4 occasions, the system was restored to its prior version as something was discovered that would not function under V8.3. We finally got all of the necessary software bits updates, ironed out all of the wrinkles and they had been running on V8.3 since Labor Day weekend. Advanced Server was the biggest PITA! Yesterday morning I reveived a call from a panicking system manager. One of the apps they rely upon just stopped working. I asked him the typical questions trying to ascertain if they have changed anything on the system. Of course, the answer was "No!" They were in a panic and were ready to revert back to the old system version. I convinced them that that was stupid because the app was working up until yesterday. I was not familiar with the app in question. About an hour later, I received a call from the system manager and I was told that one of the users had been logged in for several days and the app still worked for them. Hmm. So we set out to see what was different. I suspected a logical name change or something similar but that was not the problem. I was given instructions on how to access this app. So, I logged into their system and then I decided I would log in again and log everything. I issued a $ SET HOST/LOG 0 from the telnet session I'd created when I logged in. He walked me through the app and it worked!!! Hmm! What was different from my SET HOST session and my TELNET session that would cause such an issue. I told them that logging in with the SET HOST 0 worked, so they used it as a user work-around until I had an answer. I needed to leave and go on an errand. While driving, it dawned on as to what their problem was. My telnet session created device TNA13301: Their software app was still assuming a maximum of 9999. When I returned home, I logged into their system and set DEVICE_NAMING to 4 and edited MODPARAMS.DAT to reflect the same. I then informed the system manager there of my supposition that it was the length of the device name causing the problem and that I set their DEVICE_NAMING SYSGEN param to 4 to restore the old limit at 9999. They were not convinced. So, I took it upon myself to use my favorite DELTA hack and I patched the TNA0 UCB$W_UNIT_SEED to 1. I logged in again and now I had TNA5: (several logins already!) and the app worked! I reported this and they were delighted. Not only did they no longer need the double login work-around but they didn't need a reboot in the middle of their workday! A reboot is scheduled for this evening. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Sun, 14 Oct 2007 00:51:43 +0930 From: Mark Daniel Subject: Re: Bigger isn't always better! Message-ID: <13h1olv48585h29@corp.supernews.com> VAXman- @SendSpamHere.ORG wrote: > This past summer I helped a customer to upgrade to VMS V8.3. It took > quite a bit of time because they are a 24x7 operation and there is > very little downtime. We scheduled one Saturday afternoon each month. > The machine would go down, we'd back up the system disk and then update > to V8.3. On 3 of the 4 occasions, the system was restored to its prior > version as something was discovered that would not function under V8.3. > > We finally got all of the necessary software bits updates, ironed out > all of the wrinkles and they had been running on V8.3 since Labor Day > weekend. Advanced Server was the biggest PITA! > > Yesterday morning I reveived a call from a panicking system manager. > One of the apps they rely upon just stopped working. I asked him the > typical questions trying to ascertain if they have changed anything on > the system. Of course, the answer was "No!" They were in a panic and > were ready to revert back to the old system version. I convinced them > that that was stupid because the app was working up until yesterday. > > I was not familiar with the app in question. About an hour later, I > received a call from the system manager and I was told that one of the > users had been logged in for several days and the app still worked for > them. Hmm. So we set out to see what was different. I suspected a > logical name change or something similar but that was not the problem. > > I was given instructions on how to access this app. So, I logged into > their system and then I decided I would log in again and log everything. > I issued a $ SET HOST/LOG 0 from the telnet session I'd created when I > logged in. He walked me through the app and it worked!!! Hmm! What > was different from my SET HOST session and my TELNET session that would > cause such an issue. > > I told them that logging in with the SET HOST 0 worked, so they used it > as a user work-around until I had an answer. I needed to leave and go > on an errand. While driving, it dawned on as to what their problem was. > > My telnet session created device TNA13301: Their software app was still > assuming a maximum of 9999. When I returned home, I logged into their > system and set DEVICE_NAMING to 4 and edited MODPARAMS.DAT to reflect the > same. > > I then informed the system manager there of my supposition that it was > the length of the device name causing the problem and that I set their > DEVICE_NAMING SYSGEN param to 4 to restore the old limit at 9999. They > were not convinced. So, I took it upon myself to use my favorite DELTA > hack and I patched the TNA0 UCB$W_UNIT_SEED to 1. I logged in again and > now I had TNA5: (several logins already!) and the app worked! I reported > this and they were delighted. Not only did they no longer need the double > login work-around but they didn't need a reboot in the middle of their > workday! A reboot is scheduled for this evening. Excellent war-horse story. Haven't enjoyed such a good read on c.o.v. in a long time! Congratulations BTW. -- Yossarian: They're not going to send a crazy man out to be killed, are they? Doc Daneeka: Who else will go? [Joseph Heller; Catch-22] ------------------------------ Date: Sat, 13 Oct 2007 09:23:06 -0700 From: Neil Rieck Subject: Re: Bigger isn't always better! Message-ID: <1192292586.516288.78220@t8g2000prg.googlegroups.com> On Oct 13, 7:51 am, VAXman- @SendSpamHere.ORG wrote: > This past summer I helped a customer to upgrade to VMS V8.3. It took > quite a bit of time because they are a 24x7 operation and there is > very little downtime. We scheduled one Saturday afternoon each month. > The machine would go down, we'd back up the system disk and then update > to V8.3. On 3 of the 4 occasions, the system was restored to its prior > version as something was discovered that would not function under V8.3. > > We finally got all of the necessary software bits updates, ironed out > all of the wrinkles and they had been running on V8.3 since Labor Day > weekend. Advanced Server was the biggest PITA! > > Yesterday morning I reveived a call from a panicking system manager. > One of the apps they rely upon just stopped working. I asked him the > typical questions trying to ascertain if they have changed anything on > the system. Of course, the answer was "No!" They were in a panic and > were ready to revert back to the old system version. I convinced them > that that was stupid because the app was working up until yesterday. > > I was not familiar with the app in question. About an hour later, I > received a call from the system manager and I was told that one of the > users had been logged in for several days and the app still worked for > them. Hmm. So we set out to see what was different. I suspected a > logical name change or something similar but that was not the problem. > > I was given instructions on how to access this app. So, I logged into > their system and then I decided I would log in again and log everything. > I issued a $ SET HOST/LOG 0 from the telnet session I'd created when I > logged in. He walked me through the app and it worked!!! Hmm! What > was different from my SET HOST session and my TELNET session that would > cause such an issue. > > I told them that logging in with the SET HOST 0 worked, so they used it > as a user work-around until I had an answer. I needed to leave and go > on an errand. While driving, it dawned on as to what their problem was. > > My telnet session created device TNA13301: Their software app was still > assuming a maximum of 9999. When I returned home, I logged into their > system and set DEVICE_NAMING to 4 and edited MODPARAMS.DAT to reflect the > same. > > I then informed the system manager there of my supposition that it was > the length of the device name causing the problem and that I set their > DEVICE_NAMING SYSGEN param to 4 to restore the old limit at 9999. They > were not convinced. So, I took it upon myself to use my favorite DELTA > hack and I patched the TNA0 UCB$W_UNIT_SEED to 1. I logged in again and > now I had TNA5: (several logins already!) and the app worked! I reported > this and they were delighted. Not only did they no longer need the double > login work-around but they didn't need a reboot in the middle of their > workday! A reboot is scheduled for this evening. > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM > > "Well my son, life is like a beanstalk, isn't it?" > > http://tmesis.com/drat.html Thanks for sharing this. While I don't think your problem will affect me (but then again you never know) I am currently preparing for an upgrade from OpenVMS-8.2 to OpenVMS-8.3 just so we can use the new HP version of CIFS (a.k.a. SAMBA) Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html http://www3.sympatico.ca/n.rieck/links/openvms_demos.html ------------------------------ Date: Sat, 13 Oct 2007 17:01:42 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Bigger isn't always better! Message-ID: In article <1192292586.516288.78220@t8g2000prg.googlegroups.com>, Neil Rieck writes: > > >On Oct 13, 7:51 am, VAXman- @SendSpamHere.ORG wrote: >> This past summer I helped a customer to upgrade to VMS V8.3. It took >> quite a bit of time because they are a 24x7 operation and there is >> very little downtime. We scheduled one Saturday afternoon each month. >> The machine would go down, we'd back up the system disk and then update >> to V8.3. On 3 of the 4 occasions, the system was restored to its prior >> version as something was discovered that would not function under V8.3. >> >> We finally got all of the necessary software bits updates, ironed out >> all of the wrinkles and they had been running on V8.3 since Labor Day >> weekend. Advanced Server was the biggest PITA! >> >> Yesterday morning I reveived a call from a panicking system manager. >> One of the apps they rely upon just stopped working. I asked him the >> typical questions trying to ascertain if they have changed anything on >> the system. Of course, the answer was "No!" They were in a panic and >> were ready to revert back to the old system version. I convinced them >> that that was stupid because the app was working up until yesterday. >> >> I was not familiar with the app in question. About an hour later, I >> received a call from the system manager and I was told that one of the >> users had been logged in for several days and the app still worked for >> them. Hmm. So we set out to see what was different. I suspected a >> logical name change or something similar but that was not the problem. >> >> I was given instructions on how to access this app. So, I logged into >> their system and then I decided I would log in again and log everything. >> I issued a $ SET HOST/LOG 0 from the telnet session I'd created when I >> logged in. He walked me through the app and it worked!!! Hmm! What >> was different from my SET HOST session and my TELNET session that would >> cause such an issue. >> >> I told them that logging in with the SET HOST 0 worked, so they used it >> as a user work-around until I had an answer. I needed to leave and go >> on an errand. While driving, it dawned on as to what their problem was. >> >> My telnet session created device TNA13301: Their software app was still >> assuming a maximum of 9999. When I returned home, I logged into their >> system and set DEVICE_NAMING to 4 and edited MODPARAMS.DAT to reflect the >> same. >> >> I then informed the system manager there of my supposition that it was >> the length of the device name causing the problem and that I set their >> DEVICE_NAMING SYSGEN param to 4 to restore the old limit at 9999. They >> were not convinced. So, I took it upon myself to use my favorite DELTA >> hack and I patched the TNA0 UCB$W_UNIT_SEED to 1. I logged in again and >> now I had TNA5: (several logins already!) and the app worked! I reported >> this and they were delighted. Not only did they no longer need the double >> login work-around but they didn't need a reboot in the middle of their >> workday! A reboot is scheduled for this evening. >> >> -- >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM >> >> "Well my son, life is like a beanstalk, isn't it?" >> >> http://tmesis.com/drat.html > >Thanks for sharing this. While I don't think your problem will affect >me (but then again you never know) I am currently preparing for an >upgrade from OpenVMS-8.2 to OpenVMS-8.3 just so we can use the new HP >version of CIFS (a.k.a. SAMBA) FWIW, the impetus behind the upgrade WAS to use CIFS/SAMBA. It turns out that SAMBA was grossly inadequate for the job compared to an older PathWorks version the site was running. Fortunately, Advanced Server V7.2-B (?IIRC) was available to fill that void. There were numerous buggers in the AS V7.2-B that were uncovered (I wrote here about the PCB$V_NODELET bit being set on the PWRK$LMSRV causing _more_ than its fair share of unpleasantness.) but the HP folks did fix those issues. (I believe the PCB$V_NODELET is still set though.) One of the people at this customer's site opened a text document on a Weendoze PeeCee with whatever app that they had used before and SAMBA presented a gobbledegook of run-on lines devoid of record breaks. I would check out SAMBA carefully before putting it into production. I have it installed here and try to use it with OS X. I can read files from a SAMBA served disk but trying to store a file on the SAMBA disk is impossible. I have NFS to fall back upon so it is not of any real concern to me but IMHO SAMBA is not ready for prime-time yet. YMMV. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Sat, 13 Oct 2007 09:30:45 -0700 From: Neil Rieck Subject: Re: Canadians flee Canadian socialized Hillary type healthcare for U.S. Message-ID: <1192293045.067014.124320@e9g2000prf.googlegroups.com> On Oct 11, 7:39 pm, ultra...@gmail.com wrote: > this is what Hillary has in store for you ... > > http://www.foxnews.com/story/0%2C2933%2C300939%2C00.html > The one thing worse than the relgiously obsessed mind is the politically obsessed mind. With all the wonders in the world why would you allow yourself to be distracted by anything coming from Fox? Get a life. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: Sat, 13 Oct 2007 13:46:07 -0400 From: bradhamilton Subject: SAMBA/CIFS (Was:Re: Bigger isn't always better!) Message-ID: <4711045F.8020402@comcast.net> VAXman- @SendSpamHere.ORG wrote: > In article <1192292586.516288.78220@t8g2000prg.googlegroups.com>, Neil Rieck writes: [...] >> Thanks for sharing this. While I don't think your problem will affect >> me (but then again you never know) I am currently preparing for an >> upgrade from OpenVMS-8.2 to OpenVMS-8.3 just so we can use the new HP >> version of CIFS (a.k.a. SAMBA) > > FWIW, the impetus behind the upgrade WAS to use CIFS/SAMBA. It turns > out that SAMBA was grossly inadequate for the job compared to an older > PathWorks version the site was running. Fortunately, Advanced Server > V7.2-B (?IIRC) was available to fill that void. There were numerous > buggers in the AS V7.2-B that were uncovered (I wrote here about the > PCB$V_NODELET bit being set on the PWRK$LMSRV causing _more_ than its > fair share of unpleasantness.) but the HP folks did fix those issues. > (I believe the PCB$V_NODELET is still set though.) > > One of the people at this customer's site opened a text document on a > Weendoze PeeCee with whatever app that they had used before and SAMBA > presented a gobbledegook of run-on lines devoid of record breaks. I > would check out SAMBA carefully before putting it into production. I > have it installed here and try to use it with OS X. I can read files > from a SAMBA served disk but trying to store a file on the SAMBA disk > is impossible. I have NFS to fall back upon so it is not of any real > concern to me but IMHO SAMBA is not ready for prime-time yet. YMMV. > Folks, Please consider continuing to share your experiences involving upgrading from SAMBA 2.2.8 or migrating from AS to CIFS. I had a bad experience attempting to upgrade from 2.2.8 to an earlier iteration of CIFS last year, and have been looking for others who have made a successful transition to attempt to learn from their experiences. Thanks! ------------------------------ Date: Sat, 13 Oct 2007 10:20:05 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Message-ID: In article <5ZxME8OuXNUO@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: >In article , david20@alpha2.mdx.ac.uk writes: >> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > >>>The ability to accept unauthenticated connections certainly is real >>>security. > >> Which if he wishes the system administrator can control using a stateful >> firewall either on dedicated hardware or on the box itself eg Linux Iptables. > >And one can protect an IP-only machine by fronting it with a machine >that speaks DECnet. So what ? Which is different from protecting a machine by specifying rules for the SAME protocol suite which with IPtables is done on the same machine. If you can specify rules for the protocol suite which solve the problem then you can not argue that the problem is with the PROTOCOL SUITE. (You could complain that certain implementations of the TCPIP protocol suite such as DEC TCPIP services don't provide either the hooks to implement or an actual stateful firewall - thus forcing you to use an external firewall. But that is an implementation decision by HP/COMPAQ/DEC. I think Multinet and TCPWARE do provide some such capabilities but am not sure what level of control they provide.) The argument being made was that DECNET provided more security than TCPIP because the system administrator was in control - users couldn't just setup programs waiting for internet connections without privileges - with iptables or other firewalls the system administrator is in control since no connections can be made to those high ports unless it is allowed by the firewall. David Webb Security team leader CCSS Middlesex University ------------------------------ Date: Sat, 13 Oct 2007 10:26:04 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Message-ID: In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: >In article , david20@alpha2.mdx.ac.uk writes: >> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>>In article , david20@alpha2.mdx.ac.uk writes: >>>> >>>> As far as I am aware the only authentication ever done with DECNET objects is >>>> to require the incoming connection to supply the target username and password >>>> or appropriate proxy information. This is no different from applications under >>>> TCPIP. >>> >>> This is very different. Any fool application programmer can open >>> an IP socket and accept connections without action by the system >>> admin, who might be or find someone competent to determine whether >>> the code is full of security holes. >>> >> Only to high port numbers not to well-known ports unless he has the required >> privileges. > >Restrictins on "well-known port numbers" only guard against impersonating >an official service. > >They do nothing to prevent a security-unaware user from programming >something that violates organization security policy by using a high >port number. Which I think is what I said in the statement above. There was another similar posting in which I answered more fully talking about protecting high-port numbers by the use of stateful firewalls (either on external boxes or on the system itself). David Webb Security team leader CCSS Middlesex University ------------------------------ Date: 13 Oct 2007 05:42:21 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Message-ID: In article , david20@alpha2.mdx.ac.uk writes: > In article <5ZxME8OuXNUO@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: >>In article , david20@alpha2.mdx.ac.uk writes: >>> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> >>>>The ability to accept unauthenticated connections certainly is real >>>>security. >> >>> Which if he wishes the system administrator can control using a stateful >>> firewall either on dedicated hardware or on the box itself eg Linux Iptables. >> >>And one can protect an IP-only machine by fronting it with a machine >>that speaks DECnet. So what ? > Which is different from protecting a machine by specifying rules for the > SAME protocol suite which with IPtables is done on the same machine. But exactly the same as having to buy another piece of gear. ------------------------------ Date: 13 Oct 2007 05:45:38 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: TCPIP SMTP receiver issues (SYSTEM-F-NOLINKS) Message-ID: <+kq29A1$EX+C@eisner.encompasserve.org> In article , david20@alpha2.mdx.ac.uk writes: > In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: >>In article , david20@alpha2.mdx.ac.uk writes: >>> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>>>In article , david20@alpha2.mdx.ac.uk writes: >>>>> >>>>> As far as I am aware the only authentication ever done with DECNET objects is >>>>> to require the incoming connection to supply the target username and password >>>>> or appropriate proxy information. This is no different from applications under >>>>> TCPIP. >>>> >>>> This is very different. Any fool application programmer can open >>>> an IP socket and accept connections without action by the system >>>> admin, who might be or find someone competent to determine whether >>>> the code is full of security holes. >>>> >>> Only to high port numbers not to well-known ports unless he has the required >>> privileges. >> >>Restrictins on "well-known port numbers" only guard against impersonating >>an official service. >> >>They do nothing to prevent a security-unaware user from programming >>something that violates organization security policy by using a high >>port number. > > Which I think is what I said in the statement above. There was another similar > posting in which I answered more fully talking about protecting high-port > numbers by the use of stateful firewalls (either on external boxes or on the > system itself). The business about "well known ports" is a red herring. The issue we were discussing was the ability of a random user of arbitrary motive and competence to accept unauthenticated inbound connections. What percentage of TCP/IP machines are protected against that ? What percentage of DECnet machines are protected against that ? ------------------------------ Date: Sat, 13 Oct 2007 10:46:17 -0700 From: Doug Phillips Subject: Re: Technical Q&A (Was Re: Actual VMS Technical Qeustion! DECnet Phase IV partly Message-ID: <1192297577.724412.59160@t8g2000prg.googlegroups.com> On Oct 11, 4:08 pm, AEF wrote: > On Oct 11, 3:02 pm, Keith Parris wrote: > > > For folks here in need of answers to technical questions, or who have > > technical knowledge to contribute, I highly recommend the HP IT Resource > > Center Forums on OpenVMS as a far-superior alternative to this > > newsgroup:http://forums1.itrc.hp.com/service/forums/familyhome.do?familyId=288 > > Well, this isn't going to improve the S/N ratio of COV, now, is it? > > ITRC is a bit of a pain. I can't remember my cryptic user name. You don't need to remember the CA number. You can log in using the email address you gave when you joined. (The one in your ITRC profile.) It *is* case sensitive, as is the password. If you can't get in with your email address (probably a case problem) and you really want to find your CA number, assuming you've ever posted to the forum, search the forum for your "Forum user name" to find one of your old posts. (not the login name, but the name you entered into your profile when you joined) Then, click on your name to see your public profile and the URL will contain your CA number after the ?userId= string. > Sometimes have to wait days for my password. Why don't they have wider > space in which to put questions and output? Why isn't it a fixed-width > font? When posting, look beneath the text input box and find a check-box that says: "[ ] Retain format(spacing). URLs will not be clickable." Click that box first. > Why the ugly Web-page formatting? Why the wizard/guru/olympian/ > rock_star/savior/hero/superman/captain Kirk/champion/starter/loser/ > handyman-icon system which rewards volume times quality instead of > quality itself? > The "hats for points" bit seems rather silly but if some people get enjoyment from earning points and getting promotions, and that keeps them active in the forum, then I don't see it as a bad thing. What I smile about is the fact that first you become a Pro, then a Graduate. Seems backwards to me, as does the fact that you "advance" from Wizard to King to Pharaoh to Olympian. I liked the green Pro hat best, but if you keep getting points you lose the nice green hat and get a ugly blue mortarboard. The only real noise at ITRC is the new-hat congratulatory threads but those are easy to spot and ignore -- or you can post a congratulation to every one and get points for just showing up. > I'll try there if I don't get a good answer here. > NETCONFIG does the DEFINE OBJECT's for both TASK and FAL so they should both display in LIST. If someone has PURGEd one, it won't display in LIST. If someone has CLEARed one, it won't display in SHOW. If you inherited this situation, then DEFINE and SET the OBJECTs however *you* want them. If you do that and the problem comes back, then there's probably a .com file someplace that's fighting you. ------------------------------ End of INFO-VAX 2007.560 ************************