INFO-VAX Thu, 20 Sep 2007 Volume 2007 : Issue 514 Contents: Re: Command fails in batch, seems to work at-ed interactively Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: Hypervisor Re: Hypervisor Re: Hypervisor Re: Hypervisor Re: Hypervisor Re: Hypervisor Re: Hypervisor Re: Impact VMS version on CPU speed Re: Impact VMS version on CPU speed Re: Impact VMS version on CPU speed moving UAF file Re: moving UAF file Re: moving UAF file Re: moving UAF file Re: moving UAF file Re: node and port alloclass, cannot add a node to the cluster Re: tz88 - green-brick for BA350 shelf ---------------------------------------------------------------------- Date: Thu, 20 Sep 2007 09:39:57 -0400 From: norm.raphael@metso.com Subject: Re: Command fails in batch, seems to work at-ed interactively Message-ID: This is a multipart message in MIME format. --=_alternative 004B11A88525735C_= Content-Type: text/plain; charset="US-ASCII" AEF wrote on 09/19/2007 08:23:02 PM: > On Sep 19, 8:19 pm, David J Dachtera > wrote: > > AEF wrote: > > > > > On Sep 17, 9:33 pm, Doug Phillips wrote: > > > > On Sep 17, 8:26 pm, David J Dachtera > > > > wrote: > > > > > > > Doug Phillips wrote: > > > > > > > > On Sep 17, 11:45 am, norm.raph...@metso.com wrote: > > > > > > > This code checks for an empty or blanked PostalZip field. > > > > > > > When run inside the batch, is seems to give a different,incorrect > > > > > > > result then when the code is extracted to another procedure file > > > > > > > and run against the renamed data file. > > > > > > > In this case there is a match and Sever is "1". > > > > > > > In the nomatch case Sever is "3". > > > > > > > Here the "no strings matched" sets Sever to "3" indicating a wrong > > > > > > > result as there should have been a match. > > > > > > > Why would the same code fail to work and later work on the renamed > > > > > > > file. (The diff command is to eliminate the trailing > spaces first.) > > > > > > > [OpenVMS Alpha V7.3-1] > > > > > > > === Actual log excerpt: > > > > > > > Sent file JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML.1, 571384 bytes. > > > > > > > QUIT > > > > > > > <221 > > > > > > > $@mfgcom:check_postal.com "JAM317:[CM_PROD.DATA] > FRONTIER_ATO.XML;1;" > > > > > > > $!$ ffile="jamdata:FRONTIER_SHR.XML_2007090603045085;1" > > > > > > > $ > > > > > > > ffile=f$search(f$parse("JAMDATA:FRONTIER_SHR. > XML_*;",,,,"SYNTAX_ONLY"),3) > > > > > > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA] > FRONTIER_ATO.XML;1;" > > > > > > > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA] > FRONTIER_ATO.XML;1; nl: > > > > > > > > Is the semicolon ";" *after* the version (i.e. .XML;1;) a > posting typo > > > > > > or is it really in your command? > > > > > > > Interesting thought; however, ... > > > > > > > DJAS02::DDACHTERA$ pipe diff/nonumb/igno=trail login.com;1; nl: > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of > special characters > > > > > \;NL\ > > > > > DJAS02::DDACHTERA$ sh sym $status > > > > > $STATUS == "%X00038110" > > > > > > > (VMS V7.3-2, V7.2-2 gives same result interactively.) > > > > > > > Gives a different message/status. > > > > > > Yes it does. It pipes the error to the next command, but it doesn't > > > > display it. The $status is from the last command in the pipe, no? > > > > > Apparently so! See below. > > > > > Try > > > > piping it your example. Here's mine: > > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | type sys$pipe > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special > > > > characters > > > > \;NL\ > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | search sys$pipe > > > > "whatever" > > > > %SEARCH-I-NOMATCHES, no strings matched > > > > > Yes, this extra semicolon appears to be the cause of the problem: > > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE SET > > > %SEARCH-I-NOMATCHES, no strings matched > > > $ PIPE DIFF LOGIN.COM;4 NL: | SEAR SYS$PIPE SET > > > 2 $ set noon > > > 7 $ set terminal/inquire/noeightbit/INSERT/FORM > > > $ > > > > > Apparently, errors in the first steps aren't reported to SYS$ERROR or > > > SYS$ERROR isn't the screen until the last command is run (deja vu: why > > > is this only a warning?!): > > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE invalid > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special > > > characters > > > $ > > > > > This looks like a good reason _not_ to use PIPE in a command > > > procedure. In this case it saves you from working with temporary files > > > and their cleanup but makes troubleshooting more difficult. Friendly > > > comments welcome on this. > > > > I wouldn't go quite that far. Yes it complicates debugging; however see: > > $ HELP PIPE Description Pipelines_and_TEEs Using_TEEs_and_SYS$PIPE > > > > ...for an example of TEE.COM that you can insert into the pipeline and see > > what's actually being PIPEd into SEARCH, in this case. > > > > $ PIPE DIFF LOGIN.COM;4; NL: | @TEE SYS$COMMAND | SEAR SYS$PIPE SET > > > > Probably only works on-line. In batch, send the TEE output to a disk file. > > > > -- > > David J Dachtera > > dba DJE Systemshttp://www.djesys.com/ > > > > Unofficial OpenVMS Marketing Home Pagehttp://www.djesys.com/vms/market/ > > > > Unofficial Affordable OpenVMS Home Page:http://www.djesys.com/vms/soho/ > > > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/ > > > > Unofficial OpenVMS Hobbyist Support Page:http://www.djesys.com/vms/support/ > > OK, thanks. > > AEF > Points taken, but in this case (I covered myself with the "seems" in the subject) the debugging problem was "old eyes" as I failed to see the typo-induced extra ";" from the calling procedure, so none of these issues would have helped bring to light the problem in a "test" scenerio; the real problem, not being understood, was not presented to the testing. --=_alternative 004B11A88525735C_= Content-Type: text/html; charset="US-ASCII"
AEF <spamsink2001@yahoo.com> wrote on 09/19/2007 08:23:02 PM:

> On Sep 19, 8:19 pm, David J Dachtera <djesys...@spam.comcast.net>
> wrote:
> > AEF wrote:
> >
> > > On Sep 17, 9:33 pm, Doug Phillips <dphil...@netscape.net> wrote:
> > > > On Sep 17, 8:26 pm, David J Dachtera <djesys...@spam.comcast.net>
> > > > wrote:
> >
> > > > > Doug Phillips wrote:
> >
> > > > > > On Sep 17, 11:45 am, norm.raph...@metso.com wrote:
> > > > > > > This code checks for an empty or blanked PostalZip field.
> > > > > > > When run inside the batch, is seems to give a different,incorrect
> > > > > > > result then when the code is extracted to another procedure file
> > > > > > > and run against the renamed data file.
> > > > > > > In this case there is a match and Sever is "1".
> > > > > > > In the nomatch case Sever is "3".
> > > > > > > Here the "no strings matched" sets Sever to "3" indicating a wrong
> > > > > > > result as there should have been a match.
> > > > > > > Why would the same code fail to work and later work on the renamed
> > > > > > > file.  (The diff command is to eliminate the trailing
> spaces first.)
> > > > > > > [OpenVMS Alpha V7.3-1]
> > > > > > > === Actual log excerpt:
> > > > > > > Sent file JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML.1, 571384 bytes.
> > > > > > > QUIT
> > > > > > > <221
> > > > > > > $@mfgcom:check_postal.com "JAM317:[CM_PROD.DATA]
> FRONTIER_ATO.XML;1;"
> > > > > > > $!$ ffile="jamdata:FRONTIER_SHR.XML_2007090603045085;1"
> > > > > > > $
> > > > > > > ffile=f$search(f$parse("JAMDATA:FRONTIER_SHR.
> XML_*;",,,,"SYNTAX_ONLY"),3)
> > > > > > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]
> FRONTIER_ATO.XML;1;"
> > > > > > > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]
> FRONTIER_ATO.XML;1;  nl:
> >
> > > > > > Is the semicolon ";" *after* the version (i.e. .XML;1;) a
> posting typo
> > > > > > or is it really in your command?
> >
> > > > > Interesting thought; however, ...
> >
> > > > > DJAS02::DDACHTERA$ pipe diff/nonumb/igno=trail login.com;1; nl:
> > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of
> special characters
> > > > >  \;NL\
> > > > > DJAS02::DDACHTERA$ sh sym $status
> > > > >   $STATUS == "%X00038110"
> >
> > > > > (VMS V7.3-2, V7.2-2 gives same result interactively.)
> >
> > > > > Gives a different message/status.
> >
> > > > Yes it does. It pipes the error to the next command, but it doesn't
> > > > display it. The $status is from the last command in the pipe, no?
> >
> > > Apparently so! See below.
> >
> > >  Try
> > > > piping it your example. Here's mine:
> >
> > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | type sys$pipe
> > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
> > > > characters
> > > >  \;NL\
> > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | search sys$pipe
> > > > "whatever"
> > > > %SEARCH-I-NOMATCHES, no strings matched
> >
> > > Yes, this extra semicolon appears to be the cause of the problem:
> >
> > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE SET
> > > %SEARCH-I-NOMATCHES, no strings matched
> > > $ PIPE DIFF LOGIN.COM;4 NL: | SEAR SYS$PIPE SET
> > >     2   $ set noon
> > >     7   $ set terminal/inquire/noeightbit/INSERT/FORM
> > > $
> >
> > > Apparently, errors in the first steps aren't reported to SYS$ERROR or
> > > SYS$ERROR isn't the screen until the last command is run (deja vu: why
> > > is this only a warning?!):
> >
> > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE invalid
> > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
> > > characters
> > > $
> >
> > > This looks like a good reason _not_ to use PIPE in a command
> > > procedure. In this case it saves you from working with temporary files
> > > and their cleanup but makes troubleshooting more difficult. Friendly
> > > comments welcome on this.
> >
> > I wouldn't go quite that far. Yes it complicates debugging; however see:
> > $ HELP PIPE Description Pipelines_and_TEEs Using_TEEs_and_SYS$PIPE
> >
> > ...for an example of TEE.COM that you can insert into the pipeline and see
> > what's actually being PIPEd into SEARCH, in this case.
> >
> > $ PIPE DIFF LOGIN.COM;4; NL: | @TEE SYS$COMMAND | SEAR SYS$PIPE SET
> >
> > Probably only works on-line. In batch, send the TEE output to a disk file.
> >
> > --
> > David J Dachtera
> > dba DJE Systemshttp://www.djesys.com/
> >
> > Unofficial OpenVMS Marketing Home Pagehttp://www.djesys.com/vms/market/
> >
> > Unofficial Affordable OpenVMS Home Page:http://www.djesys.com/vms/soho/
> >
> > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/
> >
> > Unofficial OpenVMS Hobbyist Support Page:http://www.djesys.com/vms/support/
>
> OK, thanks.
>
> AEF
>
Points taken, but in this case (I covered myself with the "seems" in the subject)

the debugging problem was "old eyes" as I failed to see the typo-induced extra
";" from the calling procedure, so none of these issues would have helped bring
to light the problem in a "test" scenerio; the real problem, not being understood,
was not presented to the testing.
--=_alternative 004B11A88525735C_=-- ------------------------------ Date: 20 Sep 2007 11:06:43 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: despair Message-ID: <5lf2i3F7nogaU1@mid.individual.net> In article <46F1AC1A.4000900@comcast.net>, "Richard B. Gilbert" writes: > Bob Koehler wrote: >> In article <5lahrdF7ce1fU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> >>>You new here? There has been a long running (more than a decade at >>>least) notion here that it is either the Operating System or the >>>langauge that makes for bad programs. Unix and C are at the top of >>>the list. >> >> >> Really? And all this time I thought was both. >> > > Unix and C both HELP to make bad programs. Bullcrap. > What's REALLY responsible > for bad programs is usually bad programmers. Not usually, always. 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: Thu, 20 Sep 2007 05:02:07 -0700 From: AEF Subject: Re: despair Message-ID: <1190289727.115216.215320@19g2000hsx.googlegroups.com> On Sep 19, 10:44 pm, "Paul Raulerson" wrote: > > -----Original Message----- > > From: Richard B. Gilbert [mailto:rgilber...@comcast.net] > > Sent: Wednesday, September 19, 2007 6:09 PM > > To: Info-...@Mvb.Saic.Com > > Subject: Re: despair > > > Bob Koehler wrote: > > > In article <5lahrdF7ce1...@mid.individual.net>, b...@cs.uofs.edu > > (Bill Gunshannon) writes: > > > >>You new here? There has been a long running (more than a decade at > > >>least) notion here that it is either the Operating System or the > > >>langauge that makes for bad programs. Unix and C are at the top of > > >>the list. > > > > Really? And all this time I thought was both. > > > Unix and C both HELP to make bad programs. What's REALLY responsible > > for bad programs is usually bad programmers. Another fun thing is the > > program that must be running in production in four days! Then you get > > to spend the next eighteen months finding and fixing all the bugs! > > Unix and C can be combined to make some darn right elegant programs. Trying > to put C on VMS is - well - > it is not elegant. Because VMS was never designed to support the things that > C takes for granted. Not that it > cannot be made to, but it just does not. And UNIX is foreign ground to most > VMS people. > > C, by the way is often referred to as Portable PDP-11 Assembler, and with > good reason. > > Now that abortion of Strousoup- C++ - that is something I could happily > never have to deal with again. > But it *isn't* C. > > For example, to print out the command line arguments and environment for a C > program takes the following code; > > #include > > int main (int argc, char *argv[], char *envp[]) { > > int c; > > for (c=1; c< argc; c++) { > printf ("Argument #%0d: %s\n", c, argv[c]); > } > > c=0; > while (envp[c] != NULL) { > printf ("Env: %s\n", envp[c++]); > } > > } > > (If that preserved the formatting that is.) > > While it is possible to do the same in say, Macro-11, or COBOL, it just > isn't as elegant. How about DCL? $ SHOW SYMBOL /LOCAL/ALL at the beginning of your code will show all the arguments! I don't know what you mean by "environment"? So what *do* you mean by "environment"? > > Conversely- the stuff that VMS and COBOL do elegantly, nothing else in the > world does as well. > Not even PL/I, though it has its own set of things it does better than > anything else. :) > > -Paul AEF ------------------------------ Date: Thu, 20 Sep 2007 08:15:18 -0400 From: "Richard B. Gilbert" Subject: Re: despair Message-ID: <46F26456.4090403@comcast.net> Paul Raulerson wrote: > >>-----Original Message----- >>From: Richard B. Gilbert [mailto:rgilbert88@comcast.net] >>Sent: Wednesday, September 19, 2007 6:09 PM >>To: Info-VAX@Mvb.Saic.Com >>Subject: Re: despair >> >>Bob Koehler wrote: >> >>>In article <5lahrdF7ce1fU1@mid.individual.net>, bill@cs.uofs.edu >> >>(Bill Gunshannon) writes: >> >>>>You new here? There has been a long running (more than a decade at >>>>least) notion here that it is either the Operating System or the >>>>langauge that makes for bad programs. Unix and C are at the top of >>>>the list. >>> >>> >>> Really? And all this time I thought was both. >>> >> >>Unix and C both HELP to make bad programs. What's REALLY responsible >>for bad programs is usually bad programmers. Another fun thing is the >>program that must be running in production in four days! Then you get >>to spend the next eighteen months finding and fixing all the bugs! > > > > Unix and C can be combined to make some darn right elegant programs. Trying > to put C on VMS is - well - > it is not elegant. Because VMS was never designed to support the things that > C takes for granted. Not that it > cannot be made to, but it just does not. And UNIX is foreign ground to most > VMS people. I never said that programs written in C are, ipso facto, bad. C, especially the K&R dialect, makes it easy to write bad code. The creative freedom it gives you also gives you the freedom to do things that are most unwise, if not downright evil! Now you can write bad code in just about any language but a language like ADA makes it difficult to write bad code. ADA might be the most difficult language to write in but if someone's life is going to depend on your code ADA is a very good language to write it in. ------------------------------ Date: 20 Sep 2007 12:50:49 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: despair Message-ID: <5lf8l9F7trbuU1@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <00d701c7fb30$289a6ec0$79cf4c40$@com>, "Paul Raulerson" writes: >> >> Unix and C can be combined to make some darn right elegant programs. Trying >> to put C on VMS is - well - >> it is not elegant. Because VMS was never designed to support the things that >> C takes for granted. Not that it >> cannot be made to, but it just does not. And UNIX is foreign ground to most >> VMS people. > > That's just about the most inaccurate description of C on VMS and > UNIX to VMS people that I've read in the last few years. > >> >> Conversely- the stuff that VMS and COBOL do elegantly, nothing else in the >> world does as well. >> Not even PL/I, though it has its own set of things it does better than >> anything else. :) > > Forget VMS and COBOL; VAX-11 Fortran 77 became THE defacto industry > standard. I still remember when HP and Sun were pushing how > compatable thier f77 compilers were with "VAX Fortran". And how, exactly would Fortran77 difer from one implementation to another? Oh wait, you are talking about all that stuff the DEC put in that wasn't Fortran77. I see. Actually, all that what you said above shows is that at one time DEC was the leader int he industry. The stuff that DEC added wasn't necessarily a good thing, but becasue they were the leader everyone else had to follow. Too bad they gave all that up in order to be another Intel/MS camp follower. 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: Thu, 20 Sep 2007 13:01:51 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: despair Message-ID: <3buIi.22$mS7.19@newsfe12.lga> In article <46F26456.4090403@comcast.net>, "Richard B. Gilbert" writes: > > >Paul Raulerson wrote: >> >>>-----Original Message----- >>>From: Richard B. Gilbert [mailto:rgilbert88@comcast.net] >>>Sent: Wednesday, September 19, 2007 6:09 PM >>>To: Info-VAX@Mvb.Saic.Com >>>Subject: Re: despair >>> >>>Bob Koehler wrote: >>> >>>>In article <5lahrdF7ce1fU1@mid.individual.net>, bill@cs.uofs.edu >>> >>>(Bill Gunshannon) writes: >>> >>>>>You new here? There has been a long running (more than a decade at >>>>>least) notion here that it is either the Operating System or the >>>>>langauge that makes for bad programs. Unix and C are at the top of >>>>>the list. >>>> >>>> >>>> Really? And all this time I thought was both. >>>> >>> >>>Unix and C both HELP to make bad programs. What's REALLY responsible >>>for bad programs is usually bad programmers. Another fun thing is the >>>program that must be running in production in four days! Then you get >>>to spend the next eighteen months finding and fixing all the bugs! >> >> >> >> Unix and C can be combined to make some darn right elegant programs. Trying >> to put C on VMS is - well - >> it is not elegant. Because VMS was never designed to support the things that >> C takes for granted. Not that it >> cannot be made to, but it just does not. And UNIX is foreign ground to most >> VMS people. > >I never said that programs written in C are, ipso facto, bad. > >C, especially the K&R dialect, makes it easy to write bad code. The >creative freedom it gives you also gives you the freedom to do things >that are most unwise, if not downright evil! > >Now you can write bad code in just about any language but a language >like ADA makes it difficult to write bad code. ADA might be the most >difficult language to write in but if someone's life is going to depend >on your code ADA is a very good language to write it in. Ada -- 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: Thu, 20 Sep 2007 06:34:58 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Wed, 19 Sep 2007 19:44:25 -0700, Paul Raulerson wrote: > Conversely- the stuff that VMS and COBOL do elegantly, nothing else in > the > world does as well. > Not even PL/I, though it has its own set of things it does better than > anything else. Elegance may be in the eye of the beholder, simplicity is certainly a key criterion for that appellation. PL/I semantically subsumes a number of languages, principally Cobol and Fortran. So I would say that the attribution you confer on VMS&Cobol applies, a fortiori, to VMS&PL/I, but then I may be prejudiced:-) -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 20 Sep 2007 14:00:03 +0000 From: "Paul Raulerson" Subject: Re: despair Message-ID: ----=_vm_0011_W9605427041_15238_1190296803 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >How about DCL? > >$ SHOW SYMBOL /LOCAL/ALL > >at the beginning of your code will show all the arguments! In UNIX, the equivalent "DCL" command is: $ env >What is the environment It is roughly equivalent to LOGICALS under VMS, but has signficant differences in the way it used and way it interacts per process. Sort of like the differences in used /SYSTEM on a DEFINE. I believe, though I am not positive, that the idea for LOGICALS in VMS actually came from UNIX. IIRC, I read that in an AT&T Systems Journal a long time ago. Don't take any of that as a cut at VMS, it isn't. -Paul ----=_vm_0011_W9605427041_15238_1190296803-- ------------------------------ Date: Thu, 20 Sep 2007 07:56:38 -0700 From: AEF Subject: Re: despair Message-ID: <1190300198.603942.15560@19g2000hsx.googlegroups.com> On Sep 20, 10:00 am, "Paul Raulerson" wrote: > >How about DCL? > > >$ SHOW SYMBOL /LOCAL/ALL > > >at the beginning of your code will show all the arguments! > > In UNIX, the equivalent "DCL" command is: > > $ env I don't see how. Example 1: $ TYPE PNS.COM $ SHOW SYMBOL/LOCAL/ALL $ @PNS PARAM1 PARAM2 PARAM3 P1 = "PARAM1" P2 = "PARAM2" P3 = "PARAM3" P4 = "" P5 = "" P6 = "" P7 = "" P8 = "" $ Example 2: bash-2.03$ cat huh $ env bash-2.03$ ls -l huh -rw-r--r-x 1 afeldman other 6 Sep 20 10:54 huh bash-2.03$ huh bash: ./huh: Permission denied bash-2.03$ Looks pretty different to me! > >What is the environment > > It is roughly equivalent to LOGICALS under VMS, but has signficant differences in the way it used and way it interacts per process. Sort > of like the differences in used /SYSTEM on a DEFINE. > > I believe, though I am not positive, that the idea for LOGICALS in VMS > actually came from UNIX. IIRC, I read that in an AT&T Systems Journal > a long time ago. Say what? > > Don't take any of that as a cut at VMS, it isn't. > > -Paul AEF ------------------------------ Date: Thu, 20 Sep 2007 10:03:03 -0500 From: Ron Johnson Subject: Re: despair Message-ID: On 09/20/07 06:06, Bill Gunshannon wrote: > In article <46F1AC1A.4000900@comcast.net>, > "Richard B. Gilbert" writes: >> Bob Koehler wrote: >>> In article , bill@cs.uofs.edu (Bill Gunshannon) writes: >>> >>>> You new here? There has been a long running (more than a decade at >>>> least) notion here that it is either the Operating System or the >>>> langauge that makes for bad programs. Unix and C are at the top of >>>> the list. >>> >>> Really? And all this time I thought was both. >>> >> Unix and C both HELP to make bad programs. > > Bullcrap. I agree with Richard. C's[0] null-terminated strings, lack of bounds checking in arrays and memxxx functions, and manual heap control are open invitations to all sorts of nasty bugs. Those open invitations mean that C isn't, IMNSHO, suitable for anything beyond squeezing kernels into PDP-11s. Burroughs got it right by making an ALGOL variant it's system programming language. (I *think* it has had try-catch since the 1960s.) [0] And by extension Unix, since just about everything in the Unix world is written in C or C++, or calls libraries written in C. >> What's REALLY responsible >> for bad programs is usually bad programmers. > > Not usually, always. > > bill > -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Thu, 20 Sep 2007 10:10:55 -0500 From: Ron Johnson Subject: Re: despair Message-ID: <34wIi.225$sS6.189@newsfe14.lga> On 09/20/07 09:00, Paul Raulerson wrote: >> How about DCL? >> >> $ SHOW SYMBOL /LOCAL/ALL >> >> at the beginning of your code will show all the arguments! > > In UNIX, the equivalent "DCL" command is: > > $ env > >> What is the environment > > It is roughly equivalent to LOGICALS under VMS, but has > signficant differences in the way it used and way it interacts > per process. Sort > of like the differences in used /SYSTEM on a DEFINE.> > I believe, though I am not positive, that the idea for LOGICALS in VMS > actually came from UNIX. IIRC, I read that in an AT&T Systems Journal > a long time ago. Oh *puh-leeze*. Unix has *NOTHING* even *remotely* similar to logicals. Unix environment variables are closely akin to *symbols*. The concept of "logical" (probably) came from the mainframe world (and then was expanded into what we know and love today. With your mainframe background, I'm really surprised that you haven't noticed the similarity between DCL logicals an JCL library member name specifications that are then used in COBOL FD definitions. (It's been 19 years since I've used a mainframe, so my terminology is probably a bit off.) > Don't take any of that as a cut at VMS, it isn't. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Thu, 20 Sep 2007 15:41:51 -0000 From: "David P. Murphy" Subject: Re: despair Message-ID: <1190302911.932321.162750@w3g2000hsg.googlegroups.com> On Sep 20, 10:56 am, AEF wrote: > bash-2.03$ ls -l huh > -rw-r--r-x 1 afeldman other 6 Sep 20 10:54 huh > bash-2.03$ huh > bash: ./huh: Permission denied > bash-2.03$ > > Looks pretty different to me! Well, it helps if you do it right. "permission denied" is an error. You want "echo $*" instead of "env": $ ls -l test1 -rwxrwxr-x 1 dpm dpm 30 Sep 20 11:38 test1 $ cat test1 echo hello echo $* echo world $ ./test1 hello world $ ./test1 this is a test 'of command line args' hello this is a test of command line args world $ Keeping command-line arguments and aliases in separate namespaces makes sense. ok dpm ------------------------------ Date: Thu, 20 Sep 2007 12:02:48 -0400 From: JF Mezei Subject: Re: despair Message-ID: Ron Johnson wrote: > C's[0] null-terminated strings, lack of bounds checking in arrays > and memxxx functions, and manual heap control are open invitations > to all sorts of nasty bugs. C's flaws are well known. And a good programmer will ensure he doesn't fall into those traps. Yes, C is a two wheeled bike without the training wheels to ensure you don't fall. Other languages still have the training wheels to ensure you don't try to do something which the language designers didn't plan. But that means that you can do things in C that other languages don't let you do. And with the pedantic ANSI C, there is a lot more checking of your program, function definitions etc than ever before. ------------------------------ Date: Thu, 20 Sep 2007 09:04:34 -0700 From: AEF Subject: Re: despair Message-ID: <1190304274.861469.213160@50g2000hsm.googlegroups.com> On Sep 20, 11:41 am, "David P. Murphy" wrote: > On Sep 20, 10:56 am, AEF wrote: > > > bash-2.03$ ls -l huh > > -rw-r--r-x 1 afeldman other 6 Sep 20 10:54 huh > > bash-2.03$ huh > > bash: ./huh: Permission denied > > bash-2.03$ > > > Looks pretty different to me! > > Well, it helps if you do it right. "permission denied" is an error. > > You want "echo $*" instead of "env": > > $ ls -l test1 > -rwxrwxr-x 1 dpm dpm 30 Sep 20 11:38 test1 > $ cat test1 > echo hello > echo $* > echo world > $ ./test1 > hello > > world > $ ./test1 this is a test 'of command line args' > hello > this is a test of command line args > world > $ > > Keeping command-line arguments and aliases in > separate namespaces makes sense. > > ok > dpm Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating how his suggested equivalent doesn't work. Why the "./"? I know it runs things a little differently than without it, but I forget exactly how. AEF ------------------------------ Date: Thu, 20 Sep 2007 09:22:37 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Thu, 20 Sep 2007 09:02:48 -0700, JF Mezei wrote: > But that means that you can do things in C that other languages don't > let you do. Example please? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 20 Sep 2007 09:24:15 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Thu, 20 Sep 2007 09:04:34 -0700, AEF wrote: > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > how his suggested equivalent doesn't work. Why the "./"? I know it > runs things a little differently than without it, but I forget exactly > how. That has to do with the PATH environment variable which tells the shell the order of search. ./ just means current directory -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 20 Sep 2007 16:37:08 +0000 (UTC) From: m.kraemer@gsi.de (Michael Kraemer) Subject: Re: despair Message-ID: In article , Ron Johnson writes: > > C's[0] null-terminated strings, lack of bounds checking in arrays > and memxxx functions, and manual heap control are open invitations > to all sorts of nasty bugs. > > Those open invitations mean that C isn't, IMNSHO, suitable for > anything beyond squeezing kernels into PDP-11s. > > Burroughs got it right by making an ALGOL variant it's system > programming language. (I *think* it has had try-catch since the 1960s.) > > [0] And by extension Unix, since just about everything in the Unix > world is written in C or C++, or calls libraries written in C. > Unless you have forgotten several smileys or irony tags, I think that's nonsense, sorry. The things you can do wrong in C/C++ are incorrect in any other language as well. It has been one of the first lessons in my programming courses (Fortran) that you should not write to locations you do not own. Back then the pitfalls were mostly array indices, with more modern languages these would be pointers. And the advantage of languages supporting e.g. bounds checking, PL/I for example (sorry Tom), is not that large. For that, you need descriptor areas, and these can be overwritten or trashed as well. Which is rather easy since arguments are passed by reference (IIRC) and not by value, as in C. Moreover, in the old times when I still coded PL/I, the recommendation was to enable bounds checking only for testing, but to disable for production, for performance reasons. Unfortunately the most nasty errors occur at production time, not at testing time. Wrong pointers can't be checked easily anyway. I have experienced less C seg faults than protection exceptions in the old PL/I mainframe days. There's a lot of useful and correct C/C++ code out there, and with a bit of discipline and usage of builtin facilities like type checking, sizeof(), etc this isn't really a problem. BTW, zero-terminated strings ("ASCIZ",IIRC) are a specialty of those ancient PDP-11 boxes, would you call them trash therefore ? ------------------------------ Date: Thu, 20 Sep 2007 17:23:24 -0000 From: "David P. Murphy" Subject: Re: despair Message-ID: <1190309004.596183.14100@19g2000hsx.googlegroups.com> On Sep 20, 12:04 pm, AEF wrote: > On Sep 20, 11:41 am, "David P. Murphy" wrote: >> Well, it helps if you do it right. "permission denied" is an error. > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > how his suggested equivalent doesn't work. Why the "./"? I know it > runs things a little differently than without it, but I forget exactly > how. Holy . . . just man up and admit you don't know what you're talking about. In fact don't bother posting if your examples don't even work. The truth is that Paul's suggestion _is_ correct --- your ignorance blinded you. "env" or "set" will show all of the environmental variables, which are the closest thing to logical names, while "alias" will show all of aliases, which are the equivalent to symbols. Trying to map concepts between operating systems can be haphazard, so you can't expect a one-on-one relationship on any given topic. For instance, I think unix's separation of command-line arguments and all other tokens is a good idea, unlike DCL's seemingly haphazard P1-P8 symbols. ok dpm ------------------------------ Date: Thu, 20 Sep 2007 10:27:46 -0700 From: AEF Subject: Re: despair Message-ID: <1190309266.107100.248910@50g2000hsm.googlegroups.com> On Sep 20, 12:24 pm, "Tom Linden" wrote: > On Thu, 20 Sep 2007 09:04:34 -0700, AEF wrote: > > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > > how his suggested equivalent doesn't work. Why the "./"? I know it > > runs things a little differently than without it, but I forget exactly > > how. > > That has to do with the PATH environment variable which tells the shell > the order of search. ./ just means current directory > > -- > PL/I for OpenVMSwww.kednos.com There must be something more to it. Aren't you already in the current directory? Is there some way to be somewhere else? You could use SYS $DISK:[] as the same in VMS (as long as you're not a directory such as SYS$STARTUP) to mean "current directory", but few people bother to type it in! (Though typing [] for current directory can in the case of being in SYS$STARTUP be used to refer to the "current directory" instead! But I don't see how that would apply in Unix.) AEF ------------------------------ Date: Thu, 20 Sep 2007 10:43:07 -0700 From: AEF Subject: Re: despair Message-ID: <1190310187.976050.106480@19g2000hsx.googlegroups.com> On Sep 20, 1:23 pm, "David P. Murphy" wrote: > On Sep 20, 12:04 pm, AEF wrote: > > > On Sep 20, 11:41 am, "David P. Murphy" wrote: > >> Well, it helps if you do it right. "permission denied" is an error. > > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > > how his suggested equivalent doesn't work. Why the "./"? I know it > > runs things a little differently than without it, but I forget exactly > > how. > > Holy . . . just man up and admit you don't know what you're talking > about. > In fact don't bother posting if your examples don't even work. The > truth > is that Paul's suggestion _is_ correct --- your ignorance blinded you. > > "env" or "set" will show all of the environmental variables, which are > the closest thing to logical names, while "alias" will show all of > aliases, > which are the equivalent to symbols. What in tarnation does this have to do with showing the arguments given to a program? His example wasn't supposed to show logical names or symbols; it was supposed to show the arguments given on the command line! In DCL these happen to be the symbols P1..P8. In Unix it's something else. Yes, I know that env shows the environment variables (on a command line at least). So what? The point was to show the arguments given to a program. He said what the equivalent was, I tried it, it didn't work. If there's some secret Unix incantation like the ./ bit and substituting echo $* for env, it should be explained. This is a VMS newsgroup!!! Not Unix. Unix expertise should not be assumed. > Trying to map concepts between > operating systems can be haphazard, so you can't expect a one-on-one > relationship on any given topic. For instance, I think unix's > separation > of command-line arguments and all other tokens is a good idea, unlike > DCL's seemingly haphazard P1-P8 symbols. > > ok > dpm I don't follow your argument. Paul Raulerson wrote: > For example, to print out the command line arguments and environment for a C > program takes the following code; > > #include > > int main (int argc, char *argv[], char *envp[]) { > > int c; > > for (c=1; c< argc; c++) { > printf ("Argument #%0d: %s\n", c, argv[c]); > } > > c=0; > while (envp[c] != NULL) { > printf ("Env: %s\n", envp[c++]); > } > > } So he said you could list the arguments with the first part of the above code. So I said this is how you do it in DCL: >How about DCL? >$ SHOW SYMBOL /LOCAL/ALL >at the beginning of your code will show all the arguments! Then he said: > In UNIX, the equivalent "DCL" command is: > > $ env I then posted the result of running that in a shell script and showed that it didn't do what Paul said it would. Then you came in and complained that my example didn't work. Of course it didn't work. That was the point! I don't think we're communicating well here. AEF ------------------------------ Date: Thu, 20 Sep 2007 13:45:01 -0400 From: "Richard B. Gilbert" Subject: Re: despair Message-ID: <46F2B19D.7040407@comcast.net> Paul Raulerson wrote: >>How about DCL? >> >>$ SHOW SYMBOL /LOCAL/ALL >> >>at the beginning of your code will show all the arguments! > > > In UNIX, the equivalent "DCL" command is: > > $ env > > >>What is the environment > > > It is roughly equivalent to LOGICALS under VMS, but has signficant differences in the way it used and way it interacts per process. Sort > of like the differences in used /SYSTEM on a DEFINE. > > I believe, though I am not positive, that the idea for LOGICALS in VMS > actually came from UNIX. IIRC, I read that in an AT&T Systems Journal > a long time ago. I think that Unix "environment" is a LOT closer to symbols in VMS than it is to logical names. I find VMS symbols a lot easier to work with than Unix environment variables. Doing arithmetic with symbols is certainly easier! ------------------------------ Date: 20 Sep 2007 12:49:58 -0500 From: briggs@encompasserve.org Subject: Re: despair Message-ID: In article <1190309266.107100.248910@50g2000hsm.googlegroups.com>, AEF writes: > On Sep 20, 12:24 pm, "Tom Linden" wrote: >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF wrote: >> > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating >> > how his suggested equivalent doesn't work. Why the "./"? I know it >> > runs things a little differently than without it, but I forget exactly >> > how. >> >> That has to do with the PATH environment variable which tells the shell >> the order of search. ./ just means current directory >> >> -- >> PL/I for OpenVMSwww.kednos.com > > There must be something more to it. No. There isn't anything more to it. > Aren't you already in the current > directory? Yes. You are. But that doesn't mean that a token that you type at the beginning of a command line is treated as a request to look for like-named file in the current directory and execute it, if found. It is treated as a request to look for a like-named file in your $PATH and execute it, if found. Your current directory may or may not be in your $PATH. One common anti-trojan measure is to ensure that the current directory is not in your $PATH. Just as on VMS, the current default directory is used as a default directory in which files specified with unqualified file names are found or created and as a starting point for locating files specified with relative directory names. (On Unix, relative names are names such as foo/bar.dat or ../../foo/bar.dat and on VMS relative names are names such as [.foo]bar.dat or [--.foo]bar.dat) > Is there some way to be somewhere else? You could use SYS > $DISK:[] as the same in VMS (as long as you're not a directory such as > SYS$STARTUP) to mean "current directory", but few people bother to > type it in! Compare to DCL$PATH. If SYS$DISK:[] is not in DCL$PATH then the existence of FOO.EXE in your default directory will not make "$ FOO BAR" a meaningful DCL command. Same way, if ./ is not in $PATH then the existence of foo in your default directory will not make "csh> foo bar" a meaningful C shell command. > (Though typing [] for current directory can in the case of > being in SYS$STARTUP be used to refer to the "current directory" > instead! But I don't see how that would apply in Unix.) > > AEF > ------------------------------ Date: Thu, 20 Sep 2007 10:28:55 +0200 From: "P. Sture" Subject: Re: Hypervisor Message-ID: In article <5lahudF7ce1fU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) wrote: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > In article <5ladeqF77o7eU1@mid.individual.net>, bill@cs.uofs.edu (Bill > > Gunshannon) writes: > >> > >> How about "Control Program/Monitor"? > >> > > > > Resource Sharing Executive - 64M+ > > I like it!!!!! > > bill Virtual Management System. :-) -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: 20 Sep 2007 11:45:07 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Hypervisor Message-ID: <5lf4q3F7qqqcU1@mid.individual.net> In article , "P. Sture" writes: > In article <5lahudF7ce1fU2@mid.individual.net>, > bill@cs.uofs.edu (Bill Gunshannon) wrote: > >> In article , >> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> > In article <5ladeqF77o7eU1@mid.individual.net>, bill@cs.uofs.edu (Bill >> > Gunshannon) writes: >> >> >> >> How about "Control Program/Monitor"? >> >> >> > >> > Resource Sharing Executive - 64M+ >> >> I like it!!!!! >> >> bill > > Virtual Management System. Why not? I understand the VMS acronym is available. :-) 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: Thu, 20 Sep 2007 13:58:27 +0200 From: "P. Sture" Subject: Re: Hypervisor Message-ID: In article <5lahudF7ce1fU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) wrote: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > In article <5ladeqF77o7eU1@mid.individual.net>, bill@cs.uofs.edu (Bill > > Gunshannon) writes: > >> > >> How about "Control Program/Monitor"? > >> > > > > Resource Sharing Executive - 64M+ > > I like it!!!!! > > bill Virtual Management System. or even Virtual Machine System -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Thu, 20 Sep 2007 11:52:18 -0400 From: JF Mezei Subject: Re: Hypervisor Message-ID: <85e5$46f29734$cef8887a$25894@TEKSAVVY.COM> > Virtual Management System. > Virtual Machine System Or Virtual Machine Supervisor Or Virtual Machine Service ------------------------------ Date: Thu, 20 Sep 2007 18:58:46 +0200 From: "P. Sture" Subject: Re: Hypervisor Message-ID: In article <85e5$46f29734$cef8887a$25894@TEKSAVVY.COM>, JF Mezei wrote: > > Virtual Management System. > > Virtual Machine System > > > Or Virtual Machine Supervisor I like that. > Or Virtual Machine Service Or Virtual Machine Services? -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Thu, 20 Sep 2007 17:12:10 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Hypervisor Message-ID: P. Sture wrote: > In article <85e5$46f29734$cef8887a$25894@TEKSAVVY.COM>, > JF Mezei wrote: > >>> Virtual Management System. >>> Virtual Machine System >> >> Or Virtual Machine Supervisor > > I like that. > >> Or Virtual Machine Service > > Or Virtual Machine Services? > "VMS Management System" ? On an Rdb meeting many years ago, someone asked what "SQL" stands for and the speeker said it ment "SQL Query Language"... Jan-Erik. ------------------------------ Date: Thu, 20 Sep 2007 17:13:49 +0000 (UTC) From: m.kraemer@gsi.de (Michael Kraemer) Subject: Re: Hypervisor Message-ID: In article , "P. Sture" > > Virtual Management System. as opposed to "Real management system" ? That is, a VMS is sth with really no management ? ------------------------------ Date: Thu, 20 Sep 2007 00:38:37 -0700 From: wim.versteeg@ns.nl Subject: Re: Impact VMS version on CPU speed Message-ID: <1190273917.669874.260850@57g2000hsv.googlegroups.com> On 19 sep, 15:47, John Reagan wrote: > wim.verst...@ns.nl wrote: > > The SYSTEM_CHECK parameter has on both machines the value 0. Both > > machines are used for production purposes and there are no compilers > > installed. So i used a very small Pascal program for comparison: > > If you want a longer Pascal compilation to reduce the noise level, you > can try: > > $ pascal /terminal=stat /noobject /envir=tmp.pen /align=vax - > sys$Library:starlet.pas > > That should take several seconds of CPU time and even more seconds of > elapsed time (lots of I/O to read the source and write the environment > file). It took 4 or 5 CPU seconds on my XP1000 along with my pretty > slow SCSI disks. On our GS1280 with nice 'n fast fibre disks, it flew. > > $ pascal/noobj/envir=tmp.pen/terminal=stat/align=vax - > sys$Library:starlet.pas > CPU time: 0.62 seconds > Elapsed time: 1.74 seconds > Pagefaults: 1104 > I/O Count: 4019 > Peak memory: 0 kilobytes > Source lines: 49154 > 0 bytes per source line > 4756838 lines per CPU minute > 1694965 lines per elapsed minute > > -- > John Reagan > OpenVMS Pascal/Macro-32/COBOL Project Leader > Hewlett-Packard Company John, I think you misunderstood me. Both ES40's are production machines without compilers installed. So i compiled the HBPRM source on a development machine and copied the executable to both the ES40's. I ran that image 99 times in a row and the results are as follows: On the 7.1-2 machine the total run took : Charged CPU time: 0 01:10:44.95 Elapsed time: 0 01:10:47.66 Lowest number of ticks: 4005 Highest number of ticks: 5055 Average after 99 runs : 4287 ticks per run. And on the 7.2-1 machine: Charged CPU time: 0 01:09:10.45 Elapsed time: 0 01:09:13.23 Lowest number of ticks: 3826 Highest number of ticks: 5052 Average after 99 runs : 4192 ticks per run. So, the 7.2-1 machine is a bit faster. My conclusion is that in our version of 7.2-1 there is indeed a DCL bug. But one we can live with. Thanks for all your contributions. ------------------------------ Date: Thu, 20 Sep 2007 10:30:26 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Impact VMS version on CPU speed Message-ID: <6ZrIi.9228$ZA.4766@newsb.telia.net> wim.versteeg@ns.nl wrote: > My conclusion is that in our > version of 7.2-1 there is indeed a DCL bug... Are you sure it's a *bug* ?? Jan-Erik. ------------------------------ Date: Thu, 20 Sep 2007 04:22:32 -0700 From: wim.versteeg@ns.nl Subject: Re: Impact VMS version on CPU speed Message-ID: <1190287352.839170.54470@k79g2000hse.googlegroups.com> On 20 sep, 12:30, Jan-Erik S=F6derholm wrote: > wim.verst...@ns.nl wrote: > > My conclusion is that in our > > version of 7.2-1 there is indeed a DCL bug... > > Are you sure it's a *bug* ?? > > Jan-Erik. My tests confirm B.Z. Lederman's recollection. ------------------------------ Date: Thu, 20 Sep 2007 09:47:51 -0400 From: "Hank Vander Waal" Subject: moving UAF file Message-ID: <6988545@MVB.SAIC.COM> Can I just copy the UAF file from a alpha VMS 7.1 system to an Itanium system on 8.3 or do I have to extract and parse it out and re-add ? ------------------------------ Date: Thu, 20 Sep 2007 15:00:22 +0100 From: "R.A.Omond" Subject: Re: moving UAF file Message-ID: Hank Vander Waal wrote: > Can I just copy the UAF file from a alpha VMS 7.1 system to an Itanium > system on 8.3 or do I have to extract and parse it out and re-add ? Yes, you can copy it. No, you don't need to do anything else. Don't forget to copy all the other "important" files, like the Rightslist, Mailuaf, Proxies etc. that go along with the UAF. ------------------------------ Date: Thu, 20 Sep 2007 11:57:46 -0400 From: JF Mezei Subject: Re: moving UAF file Message-ID: <15e6e$46f2987c$cef8887a$25894@TEKSAVVY.COM> Hank Vander Waal wrote: > Can I just copy the UAF file from a alpha VMS 7.1 system to an Itanium > system on 8.3 or do I have to extract and parse it out and re-add ? As others have said, yes you can. One good "inspiration" is SYS$MANAGER:SYLOGICALS.COM ( or .TEMPLATE ). This gives you a list of the "moveable" files on the system. Going through it, you may find other files you wish to move along with the SYSUAF.DAY (rightlists, proxy, mail profile, password history etc etc) ------------------------------ Date: Thu, 20 Sep 2007 07:21:08 -0700 From: Bob Gezelter Subject: Re: moving UAF file Message-ID: <1190298068.299009.286180@d55g2000hsg.googlegroups.com> On Sep 20, 8:47 am, "Hank Vander Waal" wrote: > Can I just copy the UAF file from a alpha VMS 7.1 system to an Itanium > system on 8.3 or do I have to extract and parse it out and re-add ? Hank, Yes, you will also need to copy the related files (proxies and rightslist). While the old files will work, the various quota values should be re- evaluated. The appropriate quotas on Itanium are larger than those on Alpha. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Thu, 20 Sep 2007 10:20:34 -0400 From: "Ken Robinson" Subject: Re: moving UAF file Message-ID: <7dd80f60709200720g6f73445arecf58171ac7d4799@mail.gmail.com> On 9/20/07, R.A.Omond wrote: > Hank Vander Waal wrote: > > Can I just copy the UAF file from a alpha VMS 7.1 system to an Itanium > > system on 8.3 or do I have to extract and parse it out and re-add ? > > Yes, you can copy it. No, you don't need to do anything else. > > Don't forget to copy all the other "important" files, like the > Rightslist, Mailuaf, Proxies etc. that go along with the UAF. > You will probably have to adjust some of the process quotas once you move the file. Ken ------------------------------ Date: Wed, 19 Sep 2007 23:45:31 -0700 From: "Bart.Zorn@gmail.com" Subject: Re: node and port alloclass, cannot add a node to the cluster Message-ID: <1190270731.708402.147570@50g2000hsm.googlegroups.com> HBVS does not require ALLOCLASS to be non-zero. It requires the participating disk devices to have a non-zero allocation class. In an environment with only FC attached disks, setting ALLOCLASS to zero on all systems has the advantage that, for instance, local attached CD or tape drives get a name like $DQA0:, which is more descriptive than $n$DQA0: Bart Zorn On Sep 20, 2:43 am, David J Dachtera wrote: > Anton Shterenlikht wrote: > > [snip] > > All nodes boot from MSA1000, OKAPI from $1$DGA1: and DONKEY from $1$DGA2: > > > I set up the MSA LUNs via CLI, so the above disks names are as they > > appear in VMS. > > > I understand that number "1" in the above disk names is a port > > allocation class. Is that correct? > > No. Fibre-channel disks always get ALLOCLASS 1. Fibre channel tapes always get > ALLOCLASS 2. > > Port allocation classes are assigned in SYS$SYSTEM:SYS$DEVICES.DAT like so: > > [Port MYNODE$PKA] > allocation class = 10 > > ..., for example, will cause all the direct-attached SCSI drives (including HSZ > units) to be $10$DKAu: > > > I assigned both nodes a node allocation class, also 1. > > Do I need to do this if the port allocation is already in use? > > If you intend to use HBVS, it may be a requirement that the node's ALLOCLASS is > non-zero. I'd use something other than 1 or 2, myself. > > > I run DECnet-Plus on both nodes. > > YYYYEEECCCHHHH! > > -- > David J Dachtera > dba DJE Systemshttp://www.djesys.com/ > > Unofficial OpenVMS Marketing Home Pagehttp://www.djesys.com/vms/market/ > > Unofficial Affordable OpenVMS Home Page:http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/ > > Unofficial OpenVMS Hobbyist Support Page:http://www.djesys.com/vms/support/ ------------------------------ Date: Thu, 20 Sep 2007 08:51:49 +0100 From: "Tim Jackson" Subject: Re: tz88 - green-brick for BA350 shelf Message-ID: <46f222f6_1@glkas0286.greenlnk.net> "Michael Austin" wrote in message news:PKlHi.27107$eY.23499@newssvr13.news.prodigy.net... > Does any one have one of these old devices they want to get rid of - > cheaply? I have one that flashes all lights on the front after a power > glitch. I had 2 in this shelf - and luckily only one of them got hit. I > have tried re-seating and following the instructions to clear the error, > but it looks like it is toast. > > Or if you just have the drive - I am sure my former DEC FS skills can take > care of placing it into the canister. > > Michael Austin > my address in the from: field is obviously bogus. > m a u s t i n AT f i r s t d b a s o u r c e DOT c o m We had a similar problem earlier this year where one of the tape devices in a shelf was flashing all its lights. We tried reseating it and other things to clear the fault but it kept coming back. We swapped it for a new device but that then started showing the same problems. Eventually it was found to be a faulty PSU and since that was replaced no more problems. Could it be your PSU baring in mind you did have a power glitch? ------------------------------ End of INFO-VAX 2007.514 ************************