INFO-VAX Sun, 29 Jun 2008 Volume 2008 : Issue 360 Contents: Re: Expanding a RAID5 array Re: It would be nice to have on VMS Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: Symbol Substitution Mystery Re: TAM (Terminal Access Monitor) Re: TAM (Terminal Access Monitor) Re: TAM (Terminal Access Monitor) Re: TAM (Terminal Access Monitor) Re: Tru64 file system source code now open source Re: Tru64 file system source code now open source ---------------------------------------------------------------------- Date: Sat, 28 Jun 2008 18:31:46 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: Expanding a RAID5 array Message-ID: <644db954-45ba-4c38-95f5-50e297b16aed@t54g2000hsg.googlegroups.com> On Jun 28, 8:19=A0am, "Carmine Castiglia" wrote: > I am running an AlphaServer 1200 with a RAID Array 230/Plus subsystem > installed. =A0This question concerns a RAID 5 array consisting of three > DS-RZ1CB-VW (4.3GB) drives. That just STUPID. Sorry if that sounds `akward', but there is just no excuse fior using a 3 member RAID-5 set. All the pain, hardly any gain. How much room (slots) do you have for additional drives? If you have just 1 slot, roll out all data temporarely to 1 9gb drive, remove 2-way set and and more 9g drives. Please consider using the new (!?) drives for 3 or 4 TIMES x9gb in raid 0+1 configurations. The swxcr is one of the few controllers to allows, and exploit, an 'odd' number of drivers in a true raid 1+0. In a picture, with an Uppercase letter representing a primary copy, and lowercase the second copy the data striping will look like: 1 2 3 A a B b C c D d E hth, Hein. ------------------------------ Date: Sat, 28 Jun 2008 23:27:13 -0400 From: "William Webb" Subject: Re: It would be nice to have on VMS Message-ID: <8660a3a10806282027k43a035dfnc9f6ed1c784f0b20@mail.gmail.com> ------=_Part_28279_2300912.1214710033335 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, Jun 27, 2008 at 10:32 PM, Arne Vajh=F8j wrote: > John Smith wrote: > >> http://www.sybase.com/detail?id=3D1056945 >> >> First time I used Sybase IQ was about 10 years ago for a 2Tb initial loa= d >> data warehouse I designed for a bank. A really great product and waaay f= ast. >> That one was on Solaris. >> >> I don't know of anything comparable to this product on VMS. ....sigh...= . >> > > Sybase dropped VMS support a long time ago. > > The only major database vendor that supports VMS is Oracle. > > Those that want something like Sybase IQ should check out what > Oracle has. > > Arne There is also Intersystems Cache. WWWebb ------=_Part_28279_2300912.1214710033335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Fri, Jun 27, 2008 at 10:32 PM, Arne V= ajh=F8j <arne@vajhoej.dk> wrot= e:
John Smith wrote:
htt= p://www.sybase.com/detail?id=3D1056945

First time I used Sybase IQ was about 10 years ago for a 2Tb initial load d= ata warehouse I designed for a bank. A really great product and waaay fast.= That one was on Solaris.

I don't know of anything comparable to this product on VMS.  ....s= igh....

Sybase dropped VMS support a long time ago.

The only major database vendor that supports VMS is Oracle.

Those that want something like Sybase IQ should check out what
Oracle has.

Arne

There is also Intersystems Cache.

W= WWebb

------=_Part_28279_2300912.1214710033335-- ------------------------------ Date: Sat, 28 Jun 2008 11:10:28 -0700 (PDT) From: Doug Phillips Subject: Re: Symbol Substitution Mystery Message-ID: <23a60f13-6a0a-44df-adbd-fb9a62a14a5e@26g2000hsk.googlegroups.com> On Jun 27, 8:40 pm, David J Dachtera wrote: > AEF wrote: > > [snip] > > Here's the proc. (with SET VERIFY in force) and the resulting job log. > Apologies for text wraps... > > DJAS02::DDACHTERA$ type aef.com > $ set verify > $! > $ zero := one > $ one := two > $ two := three > $ SH SYM ZERO > $ SH SYM ONE > $ SH SYM TWO > $ > $ WRITE SYS$OUTPUT F$STRING("ZERO") > $ WRITE SYS$OUTPUT 'F$STRING("ZERO")' > $ > $ WRITE SYS$OUTPUT F$STRING("'ZERO'") > $ WRITE SYS$OUTPUT 'F$STRING("'ZERO'")' > $ > $ WRITE SYS$OUTPUT F$STRING("''ZERO'") > $ WRITE SYS$OUTPUT 'F$STRING("''ZERO'")' > $! > $ EXIT > DJAS02::DDACHTERA$ > DJAS02::DDACHTERA$ type [-]aef.log > > *************** BATCH JOB - AEF > *********************************************** > > Started on node DJAS02 on Friday, 27-JUN-2008 at 07:40:28.48 > > Job procedure : _DSA60:[USER.DDACHTERA.WORK]AEF.COM;2 > Procedure Date (CDT) : 27-JUN-2008 07:40:21.87 > Job queue name : SYS$BATCH > Job release time : 27-JUN-2008 07:40:28.40 > Job log file : NONE (USER_DISK:[USER.DDACHTERA]AEF.LOG;) > Job log delete : TRUE > Job log print : TRUE > Job log print queue : NONE > Notify user : FALSE > Process name : BATCH_5218 > Process Identifier : 202785B1 > Process Base Priority : 4 > Process User Name : DDACHTERA > Current default : USER_DISK:[USER.DDACHTERA] > > *************** BATCH JOB - AEF > *********************************************** > > It's 7:40 AM on Friday, 27-JUN-2008 > $! > $ zero := one > $ one := two > $ two := three > $ SH SYM ZERO > ZERO = "ONE" > $ SH SYM ONE > ONE = "TWO" > $ SH SYM TWO > TWO = "THREE" > $ > $ WRITE SYS$OUTPUT F$STRING("ZERO") > ZERO > $ WRITE SYS$OUTPUT ZERO > ONE > $ > $ WRITE SYS$OUTPUT F$STRING("'ZERO'") > 'ZERO' > $ WRITE SYS$OUTPUT ONE > TWO > $ > $ WRITE SYS$OUTPUT F$STRING("ONE") > ONE > $ WRITE SYS$OUTPUT ZERO > ONE > $! > $ EXIT > DDACHTERA job terminated at 27-JUN-2008 07:40:28.61 > > Accounting information: > Buffered I/O count: 124 Peak working set size: > 2736 > Direct I/O count: 63 Peak virtual size: 173344 > Page faults: 229 Mounted volumes: 0 > Charged CPU time: 0 00:00:00.09 Elapsed time: 0 > 00:00:00.21 > > DJAS02::DDACHTERA$ zero := one > DJAS02::DDACHTERA$ say F$STRING("''ZERO'") > ONE > DJAS02::DDACHTERA$ say 'F$STRING("''ZERO'")' > ONE > DJAS02::DDACHTERA$ a :='F$STRING("''ZERO'")' > DJAS02::DDACHTERA$ sh sym a > A = "ZERO" > DJAS02::DDACHTERA$ say "''ZERO'" > ONE > DJAS02::DDACHTERA$ > > Tell me, Alan. How did you come by such a knack for finding seeming bugs > in the system? > > D.J.D. It seems like these two should yield the same result, but they don't. WRITE SYS$OUTPUT 'F$STRING("''ZERO'")' WRITE SYS$OUTPUT 'F$STRING("ONE")' In fact, watch what happens to the "''ZERO'" in the commented line. ALPHA1>TYPE AEF12.COM $ set verify $ zero := one $ one := two $! $! WRITE SYS$OUTPUT 'F$STRING("''ZERO'")' !<--!!! $ WRITE SYS$OUTPUT 'F$STRING("''ZERO'")' $! $! WRITE SYS$OUTPUT 'F$STRING("ONE")' $ WRITE SYS$OUTPUT 'F$STRING("ONE")' $! $ set noverify $ EXIT ALPHA1>@AEF12 $ zero := one $ one := two $! $! WRITE SYS$OUTPUT 'F$STRING("'ZERO'")' !<--!!! $ WRITE SYS$OUTPUT ZERO ONE $! $! WRITE SYS$OUTPUT 'F$STRING("ONE")' $ WRITE SYS$OUTPUT ONE TWO $! $ set noverify ALPHA1> Seems strange to me, but there seems to be a clue hidden there, so here's another example: ALPHA1>TYPE AEF3.COM $ set verify $ zero := one $ one := two $ show symbol zero $ show symbol one $ show symbol nada $! $ write sys$output 'f$string("''ZERO'")' $ write sys$output 'nada'ZERO'nada' $ set nover $ EXIT ALPHA1>@AEF3 $ zero := one $ one := two $ show symbol zero ZERO = "ONE" $ show symbol one ONE = "TWO" $ show symbol nada %DCL-W-UNDSYM, undefined symbol - check validity and spelling $! $ write sys$output ZERO ONE $ write sys$output ZERO ONE $ set nover ALPHA1> But, if you change it to 'nada''ZERO'nada' you get: %DCL-W-UNDSYM, undefined symbol - check validity and spelling \ONENADA\ So I have no clue as to how the parser is parsing. Maybe someone has the source and some free time and enough curiosity to figure it out? ------------------------------ Date: Sat, 28 Jun 2008 18:18:24 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Symbol Substitution Mystery Message-ID: In article <23a60f13-6a0a-44df-adbd-fb9a62a14a5e@26g2000hsk.googlegroups.com>, Doug Phillips writes: I'm pretty sure that, at least if the expressions are legal DCL expressions, everything works as expected. If anyone has a particular example which is unclear, please post just that example. Important is not just what the expression parses to, but what WRITE SYS$OUTPUT expects. It behaves differently if given a string or a symbol, of course. ------------------------------ Date: Sat, 28 Jun 2008 12:18:44 -0700 (PDT) From: Doug Phillips Subject: Re: Symbol Substitution Mystery Message-ID: <6ad29ab5-e521-41f3-93c9-0671f8ce92bf@t54g2000hsg.googlegroups.com> On Jun 28, 1:18 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article > <23a60f13-6a0a-44df-adbd-fb9a62a14...@26g2000hsk.googlegroups.com>, Doug > > Phillips writes: refer to that post for examples. > > I'm pretty sure that, at least if the expressions are legal DCL > expressions, everything works as expected. If anyone has a particular > example which is unclear, please post just that example. > > Important is not just what the expression parses to, but what WRITE > SYS$OUTPUT expects. It behaves differently if given a string or a > symbol, of course. As far as dcl_check is concerned the examples already shown are legal (except for 'nada''ZERO'nada' which is suspect): VAX1>@util:dcl_check test1:aef12.com Checking file DKB200:[WORK]AEF12.COM; Procedure contains: 12 total lines 7 code lines (including 0 lines w/ comments) 0 additional continuation lines 0 lines w/i $DECK/$EOD pairs 2 comment only lines 3 blank lines -*- No errors found -*- 28-JUN-2008 12:44:49.49 VAX1>@util:dcl_check test1:aef3.com Checking file DKB200:[WORK]AEF3.COM; Procedure contains: 11 total lines 10 code lines (including 0 lines w/ comments) 0 additional continuation lines 0 lines w/i $DECK/$EOD pairs 0 comment only lines 1 blank lines LINE CODE --DIAGNOSTIC MESSAGE-- 9 PRQ probable error using single-quote (') -*- END OF LISTING -*- 28-JUN-2008 12:45:19.87 They also comply with the rules documented in the FM for the lexical and for 'substitution. It looks to me like F$STRING's parsing is the "culprit" and, granted, the construct of the example is, um, overly coded? belt & braces?, but nonetheless, they are valid statements; yet the results are unexpected to even this old-timer. It might even have something to do with DCL's acceptance of any terminator rather than enforcing matching single-quotes. I don't know. Maybe there's some quantum thing going on? ------------------------------ Date: Sat, 28 Jun 2008 13:11:02 -0700 (PDT) From: AEF Subject: Re: Symbol Substitution Mystery Message-ID: On Jun 28, 2:18 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article > <23a60f13-6a0a-44df-adbd-fb9a62a14...@26g2000hsk.googlegroups.com>, Doug > > Phillips writes: > > I'm pretty sure that, at least if the expressions are legal DCL > expressions, everything works as expected. If anyone has a particular > example which is unclear, please post just that example. > > Important is not just what the expression parses to, but what WRITE > SYS$OUTPUT expects. It behaves differently if given a string or a > symbol, of course. All right, I think I've got it -- now that I've caught up on sleep from an especially "brutal" week sleep-wise. I apologize for posting a little too early. Sorry for not realizing this sooner, but I now recall that when you have expressions of the form "The disk ''F$GETDVI("SYS$SYSDEVICE","DEVNAM")' is the system disk" You need to NOT double up the quotes inside the lexical function (even though it doesn't matter in some cases)! See (1) http://groups.google.com/group/comp.os.vms/msg/b3316b0817bbaacb and (2) http://groups.google.com/group/comp.os.vms/msg/f23d203fcdcc227f I think this pretty much explains all the mysteries I brought up. First, let me thank those who suggested SET VERIFY. Duh! (\:-O) OK, that reminded me to dig out an old program to be able to do this for each trial command one at a time. I call it WC.FOR. (And even though I can't compile it now, I saved the old WC.EXE from a VAX at a previous job running an older version of VMS and it still works on my current VAX systems!) WC uses LIB$GET_FOREIGN to grab the command line and write it to WC.TMP. Now, apostrophe substitution happens before WC writes it to WC.TMP so this serves as a convenient SET VERIFY and a quick way to run the result. Note that if you put an exclamation mark before the command in a command procedure, SET VERIFY will for some reason change '' to ' (I don't know why), so we can't use that. OK, let's go: DCL> WC WSO F$STR("ZERO") WSO F$STR("ZERO") 17 1 FORTRAN STOP DCL> @WC.TMP ZERO DCL> DCL> WC WSO 'F$STR("ZERO")' WSO ZERO 8 1 FORTRAN STOP DCL> @WC.TMP ONE !! OK so far. Everything make sense at this point. DCL> WC WSO F$STR("'ZERO'") WSO F$STR("'ZERO'") 19 1 FORTRAN STOP DCL> @WC.TMP 'ZERO' DCL> What's happening here is still okay. The " puts DCL in "quote mode" so the apostrophe doesn't perform substitution. OK. DCL> WC WSO 'F$STR("'ZERO'")' WSO ONE 7 1 FORTRAN STOP DCL> @WC.TMP TWO DCL> OK, now here things get a little weird. Recall that for expressions such as "The disk ''F$GETDVI("SYS$SYSDEVICE","DEVNAM")' is the system disk" !(3) you should NOT double-up the quotation marks inside the lexical function. And now for some reason, DCL requires the same for 'F$... ()' !. So this means that the quotation mark does NOT put DCL in quote mode, so the apostrophe now performs symbol substitution, 'ZERO' goes to ONE, and all makes sense. DCL> DCL> WC WSO F$STR("''ZERO'") WSO F$STR("ONE") 16 1 FORTRAN STOP DCL> @WC.TMP ONE Again, the quotation mark puts DCL into quote mode and substitution is performed -- OK. DCL> WC WSO 'F$STR("''ZERO'")' WSO ZERO 8 1 FORTRAN STOP DCL> @WC.TMP ONE DCL> But here again, because the lexical function is being forced to evaluate early by the first apostrophe, the quotation mark does NOT put DCL into quote mode, so the '' disappears and again it makes sense! DCL> DCL> WC WSO F$STR('ZERO') WSO F$STR(ONE) 14 1 FORTRAN STOP DCL> @WC.TMP TWO DCL> Here, 'ZERO' goes to ONE and it makes sense. DCL> WC WSO 'F$STR('ZERO')' %DCL-W-EXPSYN, invalid expression syntax - check operators and operands DCL> Now here my guess is that DCL is trying to execute 'F$STR(' which is supported, but not proven by, the following: DCL> WC WSO 'F$STR(' %DCL-W-EXPSYN, invalid expression syntax - check operators and operands DCL> Again, I can't prove that this is what's going on -- we'd have to see the code listings to be certain, but it's as close as I think we'll ever get without them. There are, of course, still some mysteries as can be seen in the second of the links way above. Here's one of them: [From link (2):] DCL$ ev "blah ''f$string(""dka200*"")' blah" blah 0 blah DCL$ ev "blah ''f$string("dka200*")' blah" blah dka200* blah We get 0 in the first case! Why? Because DCL$ ev ""def*"" 0 DCL$ also gives 0. Anyone know why? [End of quote from link (2)] Where does the bleeding zero come from? AEF ------------------------------ Date: Sat, 28 Jun 2008 14:06:49 -0700 (PDT) From: AEF Subject: Re: Symbol Substitution Mystery Message-ID: <6d18012c-be97-4660-ba44-24d69a6a9479@w7g2000hsa.googlegroups.com> On Jun 27, 9:40 pm, David J Dachtera wrote: > AEF wrote: > > [snip] > [...] > DJAS02::DDACHTERA$ a :='F$STRING("''ZERO'")' > DJAS02::DDACHTERA$ sh sym a > A = "ZERO" > DJAS02::DDACHTERA$ say "''ZERO'" > ONE > DJAS02::DDACHTERA$ > > Tell me, Alan. How did you come by such a knack for finding seeming bugs > in the system? > > D.J.D. I don't know, but don't tell the QA dept.! :-) OK, more seriously, I think it's in part my trying to figure out how things work in detail and just curiosity as in, "Hmmm. What would happen if I run such and such?" This actually started with me trying to figure out exactly at what stages DCL performs upcasing. It appears to happen at the beginning of apostrophe substitution, after apostrophe substitution is complete (but not at intermediate stages), and before ampersand substitution. Also, it never happens immediately after ampersand substitution, even when it's forced by apostrophe substitution. So if you have '&zero' !, zero is upcased by ', the & performs substitution, but if the result of that is a lowercase symbol name, ' won't substitute it! (Please, I'm assuming normal symbols names, not mixed-case symbol names produced by tricks. The point is to find out when upcasing happens.) AEF ------------------------------ Date: Sat, 28 Jun 2008 14:10:20 -0700 (PDT) From: AEF Subject: Re: Symbol Substitution Mystery Message-ID: On Jun 28, 5:06 pm, AEF wrote: > On Jun 27, 9:40 pm, David J Dachtera > wrote: > > > AEF wrote: > > > [snip] > > [...] > > DJAS02::DDACHTERA$ a :='F$STRING("''ZERO'")' > > DJAS02::DDACHTERA$ sh sym a > > A = "ZERO" > > DJAS02::DDACHTERA$ say "''ZERO'" > > ONE > > DJAS02::DDACHTERA$ > > > Tell me, Alan. How did you come by such a knack for finding seeming bugs > > in the system? > > > D.J.D. > > I don't know, but don't tell the QA dept.! :-) > > OK, more seriously, I think it's in part my trying to figure out how > things work in detail and just curiosity as in, "Hmmm. What would > happen if I run such and such?" > > This actually started with me trying to figure out exactly at what > stages DCL performs upcasing. It appears to happen at the beginning of > apostrophe substitution, after apostrophe substitution is complete > (but not at intermediate stages), and before ampersand substitution. > Also, it never happens immediately after ampersand substitution, even > when it's forced by apostrophe substitution. > > So if you have '&zero' !, zero is upcased by ', the & performs > substitution, but if the result of that is a lowercase symbol name, ' > won't substitute it! Sorry, I meant ' won't recognize it as a symbol name and will substitute null. > > (Please, I'm assuming normal symbols names, not mixed-case symbol > names or other strange symbols names >produced by various > tricks. The point is to find out when upcasing > happens.) > > AEF ------------------------------ Date: Sat, 28 Jun 2008 21:19:50 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Symbol Substitution Mystery Message-ID: In article , AEF writes: > DCL> WC WSO 'F$STR('ZERO')' > %DCL-W-EXPSYN, invalid expression syntax - check operators and > operands > DCL> > > Now here my guess is that DCL is trying to execute 'F$STR(' which is > supported, but not proven by, the following: > > DCL> WC WSO 'F$STR(' > %DCL-W-EXPSYN, invalid expression syntax - check operators and > operands > DCL> > > Again, I can't prove that this is what's going on -- we'd have to see > the code listings to be certain, but it's as close as I think we'll > ever get without them. I'm not sure. > DCL> WC WSO 'F$STR('ZERO')' This is the equivalent of 'F$STR(ONE)', after the ZERO is expanded. ONE is a symbol and as such is a valid argument to a lexical function, so F$STRING(ONE) should be TWO. Since F$STRING is expanded, then we have WSO TWO, which should give THREE. However, this assumes that the ONE is expanded before F$STRING! Perhaps, since F$STRING and ONE are at the "same level", the order of expansion is not clear, or at least not what you would expect. Normally, arguments to lexicals are strings (in "") or symbols (with no delimiters). Thus, I'm not sure the above is really defined. F$STRING('ZERO') might be OK and behave as expected, since there is only one expansion to do. > DCL$ ev "blah ''f$string(""dka200*"")' blah" > blah 0 blah > DCL$ ev "blah ''f$string("dka200*")' blah" > blah dka200* blah > > We get 0 in the first case! Why? Because > > DCL$ ev ""def*"" > 0 > DCL$ > > also gives 0. Anyone know why? Yes. The "" gets parsed to a "null", then we are left with dka200* as the argument to a lexical function. Since there are no delimiters, a symbol is expected, but this symbol is not defined, so F$STRING gives it the value 0. (I once saw a quite clever example of using "wrong" order of apostrophes in quotes in a SUBMIT command. The result is that it automagically handles cases when the parameters are defined or not. For example, /PARAM=(""'P2'). What is that, you might ask! If P2 is defined, then the "" disappears and we have /PARAM=(BLABLA) (assuming P2:=BLABLA). If P2 is not defined, it expands to nothing, and the "" is a placeholder to the SUBMIT command.) ------------------------------ Date: Sat, 28 Jun 2008 18:28:45 -0400 From: JF Mezei Subject: Re: Symbol Substitution Mystery Message-ID: <4866bb21$0$4931$c3e8da3@news.astraweb.com> I have come to the conclusion that the VMS engineers (who have been conspicusouly absent from this discussions) purposefully put in a neat "easter egg" in the DCL parsing logic, with bets to see how long it would take for someone to spot it, and laugh as we try to speculate on exactly what is happening :-) :-) :-) ------------------------------ Date: Sat, 28 Jun 2008 22:07:18 -0400 From: norm.raphael@metso.com Subject: Re: Symbol Substitution Mystery Message-ID: This is a multipart message in MIME format. --=_alternative 000BAD4185257477_= Content-Type: text/plain; charset="US-ASCII" helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote on 06/28/2008 05:19:50 PM: > In article > , AEF > writes: > > > DCL> WC WSO 'F$STR('ZERO')' > > %DCL-W-EXPSYN, invalid expression syntax - check operators and > > operands > > DCL> > > > > Now here my guess is that DCL is trying to execute 'F$STR(' which is > > supported, but not proven by, the following: > > > > DCL> WC WSO 'F$STR(' > > %DCL-W-EXPSYN, invalid expression syntax - check operators and > > operands > > DCL> > > > > Again, I can't prove that this is what's going on -- we'd have to see > > the code listings to be certain, but it's as close as I think we'll > > ever get without them. > > I'm not sure. > > > DCL> WC WSO 'F$STR('ZERO')' > > This is the equivalent of 'F$STR(ONE)', after the ZERO is expanded. ONE > is a symbol and as such is a valid argument to a lexical function, so > F$STRING(ONE) should be TWO. Since F$STRING is expanded, then we have > WSO TWO, which should give THREE. However, this assumes that the ONE is > expanded before F$STRING! Perhaps, since F$STRING and ONE are at the > "same level", the order of expansion is not clear, or at least not what > you would expect. Normally, arguments to lexicals are strings (in "") > or symbols (with no delimiters). Thus, I'm not sure the above is really > defined. F$STRING('ZERO') might be OK and behave as expected, since > there is only one expansion to do. > > > DCL$ ev "blah ''f$string(""dka200*"")' blah" > > blah 0 blah > > DCL$ ev "blah ''f$string("dka200*")' blah" > > blah dka200* blah > > > > We get 0 in the first case! Why? Because > > > > DCL$ ev ""def*"" > > 0 > > DCL$ > > > > also gives 0. Anyone know why? > > Yes. The "" gets parsed to a "null", then we are left with dka200* as > the argument to a lexical function. Since there are no delimiters, a > symbol is expected, but this symbol is not defined, so F$STRING gives it > the value 0. > > (I once saw a quite clever example of using "wrong" order of apostrophes > in quotes in a SUBMIT command. The result is that it automagically > handles cases when the parameters are defined or not. For example, > /PARAM=(""'P2'). What is that, you might ask! If P2 is defined, then > the "" disappears and we have /PARAM=(BLABLA) (assuming P2:=BLABLA). If > P2 is not defined, it expands to nothing, and the "" is a placeholder to > the SUBMIT command.) > This would of course upcase any mixed- or lower-case value in P2 as it would not be as /PARAM=("''P2'"). --=_alternative 000BAD4185257477_= Content-Type: text/html; charset="US-ASCII"
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote on 06/28/2008 05:19:50 PM:

> In article
> <b579ed3c-f0bb-44f5-95d1-b07d6e77ce73@e53g2000hsa.googlegroups.com>, AEF
> <spamsink2001@yahoo.com> writes:
>
> > DCL> WC WSO 'F$STR('ZERO')'
> > %DCL-W-EXPSYN, invalid expression syntax - check operators and
> > operands
> > DCL>
> >
> > Now here my guess is that DCL is trying to execute  'F$STR('  which is
> > supported, but not proven by, the following:
> >
> > DCL> WC WSO 'F$STR('
> > %DCL-W-EXPSYN, invalid expression syntax - check operators and
> > operands
> > DCL>
> >
> > Again, I can't prove that this is what's going on -- we'd have to see
> > the code listings to be certain, but it's as close as I think we'll
> > ever get without them.
>
> I'm not sure.
>
> > DCL> WC WSO 'F$STR('ZERO')'
>
> This is the equivalent of 'F$STR(ONE)', after the ZERO is expanded.  ONE
> is a symbol and as such is a valid argument to a lexical function, so
> F$STRING(ONE) should be TWO.  Since F$STRING is expanded, then we have
> WSO TWO, which should give THREE.  However, this assumes that the ONE is
> expanded before F$STRING!  Perhaps, since F$STRING and ONE are at the
> "same level", the order of expansion is not clear, or at least not what
> you would expect.  Normally, arguments to lexicals are strings (in "")
> or symbols (with no delimiters).  Thus, I'm not sure the above is really
> defined.  F$STRING('ZERO') might be OK and behave as expected, since
> there is only one expansion to do.
>
> > DCL$ ev "blah ''f$string(""dka200*"")' blah"
> > blah 0 blah
> > DCL$ ev "blah ''f$string("dka200*")' blah"
> > blah dka200* blah
> >
> > We get 0 in the first case! Why? Because
> >
> > DCL$ ev ""def*""
> > 0
> > DCL$
> >
> > also gives 0. Anyone know why?
>
> Yes.  The "" gets parsed to a "null", then we are left with dka200* as
> the argument to a lexical function.  Since there are no delimiters, a
> symbol is expected, but this symbol is not defined, so F$STRING gives it
> the value 0.
>
> (I once saw a quite clever example of using "wrong" order of apostrophes
> in quotes in a SUBMIT command.  The result is that it automagically
> handles cases when the parameters are defined or not.  For example,
> /PARAM=(""'P2').  What is that, you might ask!  If P2 is defined, then
> the "" disappears and we have /PARAM=(BLABLA) (assuming P2:=BLABLA).  If
> P2 is not defined, it expands to nothing, and the "" is a placeholder to
> the SUBMIT command.)
>
This would of course upcase any mixed- or lower-case value in P2 as it

would not be as /PARAM=("''P2'"). --=_alternative 000BAD4185257477_=-- ------------------------------ Date: Sat, 28 Jun 2008 13:54:33 -0400 From: "Richard B. Gilbert" Subject: Re: TAM (Terminal Access Monitor) Message-ID: Jan-Erik Söderholm wrote: > I'm supporting a VMS environment where something > called TAM, Terminal Access Mmonitor, is used. > It's a screen/forms/terminal tool to manage VT > terminals. The available docs are from Digital > and dated 1981-something. Three years before I was VAXinated! There may be/have been such a product but I never encountered it or even any mention of it! ------------------------------ Date: Sat, 28 Jun 2008 19:44:10 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: TAM (Terminal Access Monitor) Message-ID: Richard B. Gilbert wrote: > Jan-Erik Söderholm wrote: >> I'm supporting a VMS environment where something >> called TAM, Terminal Access Mmonitor, is used. >> It's a screen/forms/terminal tool to manage VT >> terminals. The available docs are from Digital >> and dated 1981-something. > > Three years before I was VAXinated! There may be/have been such a > product but I never encountered it or even any mention of it! Maybe I should have mentioned that the TAM-manual (a printout of an Runoff file) is a combined RSX and VMS manuall... :-) TAM *might* have been a local "product" written at the Digital office in Sweden. Anyway, still in heavy use on Alpha 8.2 with 100's of users. Jan-Erik. ------------------------------ Date: Sat, 28 Jun 2008 19:17:06 -0400 From: "William Webb" Subject: Re: TAM (Terminal Access Monitor) Message-ID: <8660a3a10806281617s326cdc8y576be535a592074a@mail.gmail.com> ------=_Part_28100_1545139.1214695027034 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, Jun 28, 2008 at 3:44 PM, Jan-Erik S=F6derholm < jan-erik.soderholm@telia.com> wrote: > Richard B. Gilbert wrote: > >> Jan-Erik S=F6derholm wrote: >> >>> I'm supporting a VMS environment where something >>> called TAM, Terminal Access Mmonitor, is used. >>> It's a screen/forms/terminal tool to manage VT >>> terminals. The available docs are from Digital >>> and dated 1981-something. >>> >> >> Three years before I was VAXinated! There may be/have been such a produ= ct >> but I never encountered it or even any mention of it! >> > > Maybe I should have mentioned that the TAM-manual > (a printout of an Runoff file) is a combined > RSX and VMS manuall... :-) > > TAM *might* have been a local "product" written at > the Digital office in Sweden. > > Anyway, still in heavy use on Alpha 8.2 with 100's > of users. > > Jan-Erik. > To those of us in the US, TAM will always stand for "Technical Account Manager" even though the guys who used to be them have different job titles now. WWWebb ------=_Part_28100_1545139.1214695027034 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Sat, Jun 28, 2008 at 3:44 PM, Jan-Eri= k S=F6derholm <jan-erik.= soderholm@telia.com> wrote:
Richard B. Gilbert wrote:
Jan-Erik S=F6derholm wrote:
I'm supporting a VMS environment where something
called TAM, Terminal Access Mmonitor, is used.
It's a screen/forms/terminal tool to manage VT
terminals. The available docs are from Digital
and dated 1981-something.

Three years before I was VAXinated!  There may be/have been such a pro= duct but I never encountered it or even any mention of it!

Maybe I should have mentioned that the  TAM-manual
(a printout of an Runoff file) is a combined
RSX and VMS manuall... :-)

TAM *might* have been a local "product" written at
the Digital office in Sweden.

Anyway, still in heavy use on Alpha 8.2 with 100's
of users.

Jan-Erik.

To those of us in the US, TAM will always sta= nd for "Technical Account Manager" even though the guys who used = to be them have different job titles now.

WWWebb
------=_Part_28100_1545139.1214695027034-- ------------------------------ Date: Sat, 28 Jun 2008 23:29:19 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: TAM (Terminal Access Monitor) Message-ID: William Webb wrote: > > > On Sat, Jun 28, 2008 at 3:44 PM, Jan-Erik Söderholm > > wrote: > > Richard B. Gilbert wrote: > > Jan-Erik Söderholm wrote: > > I'm supporting a VMS environment where something > called TAM, Terminal Access Mmonitor, is used. > It's a screen/forms/terminal tool to manage VT > terminals. The available docs are from Digital > and dated 1981-something. > > > Three years before I was VAXinated! There may be/have been such > a product but I never encountered it or even any mention of it! > > > Maybe I should have mentioned that the TAM-manual > (a printout of an Runoff file) is a combined > RSX and VMS manuall... :-) > > TAM *might* have been a local "product" written at > the Digital office in Sweden. > > Anyway, still in heavy use on Alpha 8.2 with 100's > of users. > > Jan-Erik. > > > To those of us in the US, TAM will always stand for "Technical Account > Manager" even though the guys who used to be them have different job > titles now. > > WWWebb Yes, that's what Google told me also. :-) In this case, it *is* "Terminal Access Mmonitor". Jan-Erik. ------------------------------ Date: Sat, 28 Jun 2008 19:40:30 +0000 From: ChrisQ Subject: Re: Tru64 file system source code now open source Message-ID: <0tw9k.207380$M63.111047@newsfe13.ams2> JF Mezei wrote: > ChrisQ wrote: > > >> Probably, but the announcement is one of the most thoughtfull >> things i've heard from hp for ages. Not so much what's been done, >> but in attitude. > > > Question here: Does the DEC Unix file system still have an edge over > other modern Unixes ? > > To put it more bluntly: Is HP releasing legacy software to open > source, or does its file system still have competitive advantages ? > > If DEC Unix' file system still has a big edge over others Unixes, it > makes this an interesting move since HP is giving away a technology > that would be better than its own HP-UX. > > Any thoughts on whether this would mke it to mainstream Linux > distributions ? Or would it remain a rarely used add-on file system > without wide distribution ? Whatever the reason, it's an interesting move, though istr reading about Sun making it's new zfs filesystem available for Linux. If that is the case, the cynical might suggest that the hp move is a me-too. Who knows. I ran Tru64 on Alpha for nearly ten years up until late last year, using built from source gnu tools, but the lack of applications (read open source) and further direction meant that I eventually had to bite the bullet and port everything to Solaris 10. I would add that the Sparc replacement is still not as fast interactively as the Alpha it replaces, though it is good enough. As for comparisons, I don't know enough about the filesystems internal design of either to comment - I used ufs in the tru64 days. There are very few original ideas around and most designers borrow bits or concepts from a variety of sources to build new products, or just to stimulate the creative process. It wouldn't surprise me at all to learn that Sun had a good hard look at AdvFs internals during the zfs design phase... Chris ------------------------------ Date: Sat, 28 Jun 2008 21:04:17 -0700 From: "Tom Linden" Subject: Re: Tru64 file system source code now open source Message-ID: On Thu, 26 Jun 2008 10:55:48 -0700, ChrisQ wrote: > Probably, but the announcement is one of the most thoughtfull things > i've heard from hp for ages. Not so much what's been done, but in > attitude. > Before we gush too much about this, note that HP has essentially gone to EMC for the file system for HP-UX, so AdvFS is somewhat superfluous -- PL/I for OpenVMS www.kednos.com ------------------------------ End of INFO-VAX 2008.360 ************************