INFO-VAX Mon, 12 Nov 2007 Volume 2007 : Issue 620 Contents: Re: DCL IF / NESTED IF-THEN-ELSE Filezilla connection Re: Hardcopy documentation Re: Process state in HIB while paging Re: Process state in HIB while paging Re: Process state in HIB while paging Q: DCL IF / NESTED IF-THEN-ELSE Re: Q: DCL IF / NESTED IF-THEN-ELSE Re: Q: DCL IF / NESTED IF-THEN-ELSE Re: Q: DCL IF / NESTED IF-THEN-ELSE Re: Q: DCL IF / NESTED IF-THEN-ELSE Re: Q: DCL IF / NESTED IF-THEN-ELSE Re: Q: DCL IF / NESTED IF-THEN-ELSE Re: VAX, VMS and QBUS Devices Re: VAX, VMS and QBUS Devices ---------------------------------------------------------------------- Date: Mon, 12 Nov 2007 15:01:18 -0000 From: "Richard Brodie" Subject: Re: DCL IF / NESTED IF-THEN-ELSE Message-ID: > wrote in message >news:OFBE6B1F44.B71162C3-ON85257391.004F1E11->85257391.00507A6A@metso.com... > What am I missing? I think that the $ ELSE matches the $ THEN, not the previous IF statement, which isn't a block IF. ------------------------------ Date: Mon, 12 Nov 2007 11:44:32 -0700 From: Kevin Handy Subject: Filezilla connection Message-ID: <1194892635_8953@sp12lax.superfeed.net> Has anyone gotten filezilla 3.0.2.1 (under windows) to talk to a VMS system? I've used it on earlier versions of filezilla, but cannot get this to work. I've been trying all morning, and have nothing but grief. I get a timeout, or an empty directory listing. I've tried both active ans passive modes. FTP from the DOS prompt works fine. under the "advanced" tab, I select "Servertype: VMS", so I assume that someone once thought it sould work. Also, if I enter a colon ':' in the "Default remote directory" field, as in "dka0:[xxxx]", it quietly blanks the field. Or, is there a simple FTP gui program that I can use instead? ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- ------------------------------ Date: Mon, 12 Nov 2007 14:22:25 -0000 From: IrishPub Subject: Re: Hardcopy documentation Message-ID: <1194877345.765951.319780@d55g2000hsg.googlegroups.com> On Nov 11, 4:46 pm, VAXman- @SendSpamHere.ORG wrote: > In article , "Robert Jarratt" writes: > > >"IrishPub" wrote in message > >news:1194745876.265898.48990@v3g2000hsg.googlegroups.com... > >> On Nov 10, 2:00 pm, "Robert Jarratt" wrote: > >>> I would be interested but it depends on where you are and how much it > >>> would > >>> cost to ship them (to the UK). I am especially interested in Orange > >>> manuals > >>> as these are the ones I particularly remember. > > >>> Regards > > >>> Rob > > >>> "IrishPub" wrote in message > > >>>news:1194700744.926865.301030@d55g2000hsg.googlegroups.com... > > >>> > Greetings, > > >>> > I have boxes of VMS documentation that I am looking for a new home > >>> > for. I was wondering if there is any interest in this. I have VMS > >>> > 4.x documentation (the Orange covered manuals), VMS 5.x (the Gray > >>> > covered manuals) and OpenVMS documentation (White covers). If there > >>> > is interest I can provide more specifics about which manuals I have > >>> > (all should be near complete sets, but they have been sitting for > >>> > awhile so I would want to check to be sure). > > >>> > I also have various books on VMS, including Internals that I would be > >>> > willing to part with as well. > > >>> > If this is not the right forum, I apologize as I tried to find a group > >>> > that would be appropriate for this. > > >>> > Thanks for taking a look, > >>> > -Ron Patrick > > >> I am located near St Louis, Missouri. The White set is dated May 1993 > >> for Open VMS VAX 6.0 (Open VMS AXP 1.5) > > >Any idea what it would cost to ship the Orange ones to the UK? If I remember > >correctly there were 8 volumes, which Orange ones do you have? > > Then it is incomplete. I have about 20 large orange tomes and about a > dozen smaller orange tomes on my shelf. > > Do you know the publication/version of your white doc set? (V6.*) I > have most of the programer's set (device driver and other intriguing > system programming manuals). May 1993 is the date on one that I just > pulled from the shelf. > > -- > 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 The publication date for the white set is May 1993. Its for Version 6.0 (VMS on VAX) or version 1.5 (VMS on AXP) As far as the Orange set goes, I am sure I have more than 8 volumes... I will get a list together this evening and post. Shipping to UK from US via USPS isn't cheap as there isnt any media mail rate for overseas. I can check into other carriers and see what they have. ------------------------------ Date: Mon, 12 Nov 2007 07:13:05 GMT From: John Santos Subject: Re: Process state in HIB while paging Message-ID: In article , jfmezei.spamnot@vaxination.ca says... > Mozilla eventually eats up all its pgflquo and becomes slow as molasses > running on a Microvax II running at 1/10th normal speed. > > I can see the disk light on the workstation on a "steady on" (the only > thing used on that disk is the page file). > > Yet, the process stays mostly in "HIB" state. I sometimes see it PFW > state for a micro instant if I don't blink. > > Doing a "QUIT" (once I get to the menu) takes a few *minutes* to run. > During that time, the disk activity light is steady on again. And again, > the process remains mostly on HIB state 99% of the time. > > Can someone explain why Mozilla would remain in HIB state when it is > waiting for memory coming from the page file 99% of the time ? Why isn't > it in PFW state ? > > Since Mozilla comes from Unixland, I would find it hard to believe it is > fully AST driven. > > I realise that in your universe, Mozilla runs fine and my universe is > ever so slightly different from yours, but I would still be interested > in what sort of programming paradigm would have resulted in Mozilla > being in HUB even when waiting to access memory that resides in the page > file. > I didn't even know you *could* run Mozilla on a MVII! I'm 99% sure CSWB is Alpha/Itanium only. Is there a Mozilla from elsewhere that will compile/run on a VAX? (I think Mosaic works on VAXes, but that's another story entirely.) Anyway Mozilla (CSWB version) was slow running on an Alpha 1200 (single processor, 5/533 w/512MB, displaying on an AlphaStation 200 4/100 running DEC Unix V4.x), but was usable. I've since moved to an rx2620 dual processor 1.6GHz, 4GB using the console graphics adapter, and its pretty peppy, except it still takes a bit of time to start up. Of course, no one else is using the Itanium much yet (except all our backups go through it to an external USB hard disk, which seems to have no discernable effect on Mozilla's performance), but gradually other developers are shifting over to it. So I think the weird thing about the JF universe is that fact that Mozilla works at all on an MVII, not that it's slow. :-) As to your actual question, are you sure its paging and not just doing regular (async) I/O? If it's using QIO, it might be $HIBER while waiting for a completion AST to $WAKE it, rather than using $WAITEF or $SYNCH (which I think would LEF.) Or if it's threaded, maybe a thread is stalled on PFW, but other threads (or the main thread) is $HIBERing. Haven't dealt enough with threads to know for sure. -- John ------------------------------ Date: Mon, 12 Nov 2007 02:53:19 -0500 From: JF Mezei Subject: Re: Process state in HIB while paging Message-ID: John Santos wrote: > > I didn't even know you *could* run Mozilla on a MVII! No, you can't. But when it fills up its page file quota on the alpha (it is something like 1 gig), Mozilla slows down to a speed that is about 1/10 the speed of a Microvax II ;-( (Like: you have plenty of time to grab a cub of coffee between the time you press on a RELOAD button and the time it actually has completed the reloading). > Or if it's threaded, maybe a thread is stalled on PFW, but > other threads (or the main thread) is $HIBERing. Haven't > dealt enough with threads to know for sure. Ahhh ! That would be the best explanation. Thanks. Next time I get into that situation (in a few days), I will use the newly available features of SHOW PROC/CONt and type "T" instead of "Q" to get thread information. ------------------------------ Date: 12 Nov 2007 07:39:47 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Process state in HIB while paging Message-ID: In article , John Santos writes: > > I didn't even know you *could* run Mozilla on a MVII! I'm 99% sure > CSWB is Alpha/Itanium only. Is there a Mozilla from elsewhere that > will compile/run on a VAX? (I think Mosaic works on VAXes, but that's > another story entirely.) I've been running Mozilla on VAXen for a long, long, time. CSWB is not (or at least didn't used to be) 64 bit only. What you can't get for Mozilla (or any web browser) on VAX is Java support, since a JRE for VAX isn't worth the effort (floating point format issues). ------------------------------ Date: Mon, 12 Nov 2007 09:39:05 -0500 From: norm.raphael@metso.com Subject: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: This is a multipart message in MIME format. --=_alternative 00507A6585257391_= Content-Type: text/plain; charset="US-ASCII" Here is a DCL gosub routine to pick a description out of an element list. If it does not find a match in 1-5 is is supposed to set the LL index variable to zero and pick that one. Somehow, the statement to do that is not being executed. DCL_CHECK does not find any error. What am I missing? $FIND_TCODE: !Gosub $ LL=5 $LOOPT: $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) $ THEN $ LL=LL+1 $ show sym ll $ IF LL .LE. 5 THEN GOTO LOOPT $ ELSE $ IF LL .GT. 5 THEN LL=0 $ ENDIF $ show sym ll $ RDESC=F$ELEMENT(LL,",",TDESC) $ RETURN === -*- Charlie Hammond's unsupported DCL checker (Version V3.4) -*- Checking file TEST.COM;1 12-NOV-2007 09:33:40.69 Checking for DCL_CHECK$ logicals... No translation for logical name DCL_CHECK$* Starting Pass 1 -- 12-NOV-2007 09:33:41.11 ... Starting Pass 2 -- 12-NOV-2007 09:33:41.76 ... Starting Pass 3 -- 12-NOV-2007 09:33:41.86 ... Procedure contains: 14 total lines 14 code lines (including 1 lines (7%) w/ comments) 0 additional continuation lines 0 lines w/i $DECK/$EOD pairs 0 comment only lines (0% of code lines) 0 blank lines 1 diagnostics LINE CODE --DIAGNOSTIC MESSAGE-- 1 LNR-I label "FIND_TCODE" not referenced (warning) -*- END OF LISTING -*- 12-NOV-2007 09:33:42.22 === $FIND_TCODE: !Gosub $ LL=5 $LOOPT: $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) $ THEN $ LL=LL+1 $ show sym ll LL = 6 Hex = 00000006 Octal = 00000000006 $ IF LL .LE. 5 THEN GOTO LOOPT $ ELSE ![What happened to the next statement?] <-- *** $ ENDIF $ show sym ll LL = 6 Hex = 00000006 Octal = 00000000006 $ RDESC=F$ELEMENT(LL,",",TDESC) $ RETURN --=_alternative 00507A6585257391_= Content-Type: text/html; charset="US-ASCII"
Here is a DCL gosub routine to pick a description
out of an element list.  If it does not find
a match in 1-5 is is supposed to set the LL
index variable to zero and pick that one.
Somehow, the statement to do that is not being
executed.  DCL_CHECK does not find any error.

What am I missing?

$FIND_TCODE: !Gosub
$ LL=5
$LOOPT:
$ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
$  THEN
$ LL=LL+1
$ show sym ll
$ IF LL .LE. 5 THEN GOTO LOOPT
$  ELSE
$  IF LL .GT. 5 THEN LL=0
$ ENDIF
$ show sym ll
$ RDESC=F$ELEMENT(LL,",",TDESC)
$ RETURN

===
-*- Charlie Hammond's unsupported DCL checker (Version V3.4) -*-
Checking file TEST.COM;1
12-NOV-2007 09:33:40.69

Checking for DCL_CHECK$ logicals...
No translation for logical name DCL_CHECK$*

Starting Pass 1 -- 12-NOV-2007 09:33:41.11 ...
Starting Pass 2 -- 12-NOV-2007 09:33:41.76 ...
Starting Pass 3 -- 12-NOV-2007 09:33:41.86 ...

Procedure contains:     14 total lines
                        14 code lines (including 1 lines (7%) w/ comments)
                         0 additional continuation lines
                         0 lines w/i $DECK/$EOD pairs
                         0 comment only lines (0% of code lines)
                         0 blank lines
                         1 diagnostics

 LINE  CODE  --DIAGNOSTIC MESSAGE--
    1  LNR-I  label "FIND_TCODE" not referenced (warning)

-*- END OF LISTING -*-   12-NOV-2007 09:33:42.22

===

$FIND_TCODE: !Gosub
$ LL=5
$LOOPT:
$ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
$  THEN
$ LL=LL+1
$ show sym ll
  LL = 6   Hex = 00000006  Octal = 00000000006
$ IF LL .LE. 5 THEN GOTO LOOPT
$  ELSE ![What happened to the next statement?]  <-- ***
$ ENDIF
$ show sym ll
  LL = 6   Hex = 00000006  Octal = 00000000006
$ RDESC=F$ELEMENT(LL,",",TDESC)
$ RETURN


--=_alternative 00507A6585257391_=-- ------------------------------ Date: Mon, 12 Nov 2007 10:01:03 -0500 From: "Ken Robinson" Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: <7dd80f60711120701q578537e5w8a14b5d2ac8718b@mail.gmail.com> On Nov 12, 2007 9:39 AM, wrote: > > Here is a DCL gosub routine to pick a description > out of an element list. If it does not find > a match in 1-5 is is supposed to set the LL > index variable to zero and pick that one. > Somehow, the statement to do that is not being > executed. DCL_CHECK does not find any error. > > What am I missing? > > $FIND_TCODE: !Gosub > $ LL=5 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL+1 > $ show sym ll > $ IF LL .LE. 5 THEN GOTO LOOPT > $ ELSE > $ IF LL .GT. 5 THEN LL=0 > $ ENDIF > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE" in "$ RDESC=F$ELEMENT(LL,",",TDESC)"? Try: $FIND_TCODE: !Gosub $ LL=5 $LOOPT: $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) $ THEN $ LL=LL+1 $ show sym ll $ IF LL .LE. 5 THEN GOTO LOOPT $ endif $ IF LL .GT. 5 THEN LL=0 $ show sym ll $ RDESC=F$ELEMENT(LL,",",Tcode) $ sho sym rdesc $ RETURN Ken ------------------------------ Date: Mon, 12 Nov 2007 10:25:14 -0500 From: norm.raphael@metso.com Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: This is a multipart message in MIME format. --=_alternative 0054B45A85257391_= Content-Type: text/plain; charset="US-ASCII" "Ken Robinson" wrote on 11/12/2007 10:01:03 AM: > On Nov 12, 2007 9:39 AM, wrote: > > > > Here is a DCL gosub routine to pick a description > > out of an element list. If it does not find > > a match in 1-5 is is supposed to set the LL > > index variable to zero and pick that one. > > Somehow, the statement to do that is not being > > executed. DCL_CHECK does not find any error. > > > > What am I missing? > > > > $FIND_TCODE: !Gosub > > $ LL=5 > > $LOOPT: > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > > $ THEN > > $ LL=LL+1 > > $ show sym ll > > $ IF LL .LE. 5 THEN GOTO LOOPT > > $ ELSE > > $ IF LL .GT. 5 THEN LL=0 > > $ ENDIF > > $ show sym ll > > $ RDESC=F$ELEMENT(LL,",",TDESC) > > $ RETURN > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE" > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"? Well, the code certainly behaves as if the endif is in the wrong place, but it isn't. I will try structured if-the-else for all the if-statements and I'm sure that will fix it, but I suspect I have uncovered an ambiguity due to backward compatibility allowing if-then-else to be: $if then $endif instead of forcing: $if $then $ $endif I would surely like to know what the expected behavior is, and if this violates the syntax. Too bad Charlie retired. And no, TDESC should be TDESC. It matches the code in one element table and move the description from another element table, but that's not relevent and since I didn't include that part of the procedure, you can't know that. > > Try: > > $FIND_TCODE: !Gosub > $ LL=5 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL+1 > $ show sym ll > $ IF LL .LE. 5 THEN GOTO LOOPT > $ endif > $ IF LL .GT. 5 THEN LL=0 > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",Tcode) > $ sho sym rdesc > $ RETURN > > Ken --=_alternative 0054B45A85257391_= Content-Type: text/html; charset="US-ASCII"



"Ken Robinson" <kenrbnsn@gmail.com> wrote on 11/12/2007 10:01:03 AM:

> On Nov 12, 2007 9:39 AM,  <norm.raphael@metso.com> wrote:
> >
> > Here is a DCL gosub routine to pick a description
> > out of an element list.  If it does not find
> > a match in 1-5 is is supposed to set the LL
> > index variable to zero and pick that one.
> > Somehow, the statement to do that is not being
> > executed.  DCL_CHECK does not find any error.
> >
> > What am I missing?
> >
> > $FIND_TCODE: !Gosub
> > $ LL=5
> > $LOOPT:
> > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
> > $  THEN
> > $ LL=LL+1
> > $ show sym ll
> > $ IF LL .LE. 5 THEN GOTO LOOPT
> > $  ELSE
> > $  IF LL .GT. 5 THEN LL=0
> > $ ENDIF
> > $ show sym ll
> > $ RDESC=F$ELEMENT(LL,",",TDESC)
> > $ RETURN
>
> The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE"
> in "$ RDESC=F$ELEMENT(LL,",",TDESC)"?

Well, the code certainly behaves as if the endif is in the wrong place,
but it isn't.  I will try structured if-the-else for all the
if-statements and I'm sure that will fix it, but I suspect I have
uncovered an ambiguity due to backward compatibility allowing
if-then-else to be:

$if <condition> then <statement>
$endif
instead of forcing:

$if <condition>
$then
$<statement>
$endif

I would surely like to know what the expected behavior is, and
if this violates the syntax.  Too bad Charlie retired.

And no, TDESC should be TDESC.  It matches the code in one
element table and move the description from another
element table, but that's not relevent and since I didn't
include that part of the procedure, you can't know that.

>
> Try:
>
> $FIND_TCODE: !Gosub
> $ LL=5
> $LOOPT:
> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
> $  THEN
> $    LL=LL+1
> $    show sym ll
> $    IF LL .LE. 5 THEN GOTO LOOPT
> $ endif
> $ IF LL .GT. 5 THEN LL=0
> $ show sym ll
> $ RDESC=F$ELEMENT(LL,",",Tcode)
> $ sho sym rdesc
> $ RETURN
>
> Ken
 --=_alternative 0054B45A85257391_=-- ------------------------------ Date: Mon, 12 Nov 2007 10:48:25 -0500 From: "Ken Robinson" Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: <7dd80f60711120748j60ea8c6br91989b132441b1e3@mail.gmail.com> On Nov 12, 2007 10:25 AM, wrote: > > > > > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM: > > > > On Nov 12, 2007 9:39 AM, wrote: > > > > > > Here is a DCL gosub routine to pick a description > > > out of an element list. If it does not find > > > a match in 1-5 is is supposed to set the LL > > > index variable to zero and pick that one. > > > Somehow, the statement to do that is not being > > > executed. DCL_CHECK does not find any error. > > > > > > What am I missing? > > > > > > $FIND_TCODE: !Gosub > > > $ LL=5 > > > $LOOPT: > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > > > $ THEN > > > $ LL=LL+1 > > > $ show sym ll > > > $ IF LL .LE. 5 THEN GOTO LOOPT > > > $ ELSE > > > $ IF LL .GT. 5 THEN LL=0 > > > $ ENDIF > > > $ show sym ll > > > $ RDESC=F$ELEMENT(LL,",",TDESC) > > > $ RETURN > > > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE" > > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"? > > Well, the code certainly behaves as if the endif is in the wrong place, > but it isn't. I will try structured if-the-else for all the > if-statements and I'm sure that will fix it, but I suspect I have > uncovered an ambiguity due to backward compatibility allowing > if-then-else to be: > > $if then > $endif > That syntax is illegal > instead of forcing: > > $if > $then > $ > $endif > > I would surely like to know what the expected behavior is, and > if this violates the syntax. Too bad Charlie retired. You original "if" block was (annotated by me) $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) $ THEN $ LL=LL+1 $ show sym ll $ IF LL .LE. 5 THEN GOTO LOOPT $ ELSE ! this else goes with the original "IF" not the one above it $ IF LL .GT. 5 THEN LL=0 ! this line will only get executed when the original "if" is "false" $ ENDIF Ken > > And no, TDESC should be TDESC. It matches the code in one > element table and move the description from another > element table, but that's not relevent and since I didn't > include that part of the procedure, you can't know that. > > > > > > > Try: > > > > $FIND_TCODE: !Gosub > > $ LL=5 > > $LOOPT: > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > > $ THEN > > $ LL=LL+1 > > $ show sym ll > > $ IF LL .LE. 5 THEN GOTO LOOPT > > $ endif > > $ IF LL .GT. 5 THEN LL=0 > > $ show sym ll > > $ RDESC=F$ELEMENT(LL,",",Tcode) > > $ sho sym rdesc > > $ RETURN > > > > Ken > ------------------------------ Date: Mon, 12 Nov 2007 11:13:29 -0500 From: JF Mezei Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: <46b54$47387bab$cef8887a$4590@TEKSAVVY.COM> norm.raphael@metso.com wrote: > $FIND_TCODE: !Gosub > $ LL=5 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL+1 > $ show sym ll > $ IF LL .LE. 5 THEN GOTO LOOPT > $ ELSE > $ IF LL .GT. 5 THEN LL=0 > $ ENDIF > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN Missing ENDIF for the IF FCODE .NES. F$ELEMENT. The RETURN statement executes within the THEN of the IF FCODE. The RETURN probably unwinds any IF/ENDIF and hence no errors. It helps to properly indent code when you have nested IFs. Also, this is just my opinion, but I tend to not mix one line with multiple line THEN/ELSE statements. It makes it easier to determine when an endif is needed or not. aka: $IF hungry .eqs. 1 $THEN $ GOTO SNACK_BAR $ELSE $ DO THIS $ DO THAT $ENDIF ------------------------------ Date: Mon, 12 Nov 2007 11:42:27 -0500 From: norm.raphael@metso.com Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: This is a multipart message in MIME format. --=_alternative 005BC5CD85257391_= Content-Type: text/plain; charset="US-ASCII" "Ken Robinson" wrote on 11/12/2007 10:48:25 AM: > On Nov 12, 2007 10:25 AM, wrote: > > > > > > > > > > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM: > > > > > > > On Nov 12, 2007 9:39 AM, wrote: > > > > > > > > Here is a DCL gosub routine to pick a description > > > > out of an element list. If it does not find > > > > a match in 1-5 is is supposed to set the LL > > > > index variable to zero and pick that one. > > > > Somehow, the statement to do that is not being > > > > executed. DCL_CHECK does not find any error. > > > > > > > > What am I missing? > > > > > > > > $FIND_TCODE: !Gosub > > > > $ LL=5 > > > > $LOOPT: > > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > > > > $ THEN > > > > $ LL=LL+1 > > > > $ show sym ll > > > > $ IF LL .LE. 5 THEN GOTO LOOPT > > > > $ ELSE > > > > $ IF LL .GT. 5 THEN LL=0 > > > > $ ENDIF > > > > $ show sym ll > > > > $ RDESC=F$ELEMENT(LL,",",TDESC) > > > > $ RETURN > > > > > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE" > > > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"? > > > > Well, the code certainly behaves as if the endif is in the wrong place, > > but it isn't. I will try structured if-the-else for all the > > if-statements and I'm sure that will fix it, but I suspect I have > > uncovered an ambiguity due to backward compatibility allowing > > if-then-else to be: > > > > $if then > > $endif > > > > That syntax is illegal > > > > instead of forcing: > > > > $if > > $then > > $ > > $endif > > > > I would surely like to know what the expected behavior is, and > > if this violates the syntax. Too bad Charlie retired. > > You original "if" block was (annotated by me) > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL+1 > $ show sym ll > $ IF LL .LE. 5 THEN GOTO LOOPT > $ ELSE ! this else goes with the original "IF" not the one above it > $ IF LL .GT. 5 THEN LL=0 ! this line will only get executed > when the original "if" is "false" > $ ENDIF > I simplified it to: $FIND_TCODE: !Gosub $ LL=5 $LOOPT: $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) $ THEN $ LL=LL+1 $ show sym ll $ IF LL .GT. 5 $ THEN $ LL=0 $ ELSE $ GOTO LOOPT $ ENDIF $ ENDIF $ show sym ll $ RDESC=F$ELEMENT(LL,",",TDESC) $ RETURN It was redundent to check for ".GT. 5" and also ".LE. 5" for if not one then of course the other. The crux of the problem is that within an $IF $THEN $ $ $ELSE $ $ $ENDIF that $ should be able to be the (valid) statement $IF then and that in the complex IF-THEN-ELSE the "$THEN" must be on it's own line to distinguish between the two forms. Probably if I had put a replacement statement before the $ELSE the parser would have recovered. It's better this way, however. -Norm > Ken > > > > > > > And no, TDESC should be TDESC. It matches the code in one > > element table and move the description from another > > element table, but that's not relevent and since I didn't > > include that part of the procedure, you can't know that. > > > > > > > > > > > > Try: > > > > > > $FIND_TCODE: !Gosub > > > $ LL=5 > > > $LOOPT: > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > > > $ THEN > > > $ LL=LL+1 > > > $ show sym ll > > > $ IF LL .LE. 5 THEN GOTO LOOPT > > > $ endif > > > $ IF LL .GT. 5 THEN LL=0 > > > $ show sym ll > > > $ RDESC=F$ELEMENT(LL,",",Tcode) > > > $ sho sym rdesc > > > $ RETURN > > > > > > Ken > > --=_alternative 005BC5CD85257391_= Content-Type: text/html; charset="US-ASCII"



"Ken Robinson" <kenrbnsn@gmail.com> wrote on 11/12/2007 10:48:25 AM:

> On Nov 12, 2007 10:25 AM,  <norm.raphael@metso.com> wrote:
> >
> >
> >
> >
> > "Ken Robinson" <kenrbnsn@gmail.com> wrote on 11/12/2007 10:01:03 AM:
> >
> >
> >  > On Nov 12, 2007 9:39 AM,  <norm.raphael@metso.com> wrote:
> >  > >
> >  > > Here is a DCL gosub routine to pick a description
> >  > > out of an element list.  If it does not find
> >  > > a match in 1-5 is is supposed to set the LL
> >  > > index variable to zero and pick that one.
> >  > > Somehow, the statement to do that is not being
> >  > > executed.  DCL_CHECK does not find any error.
> >  > >
> >  > > What am I missing?
> >  > >
> >  > > $FIND_TCODE: !Gosub
> >  > > $ LL=5
> >  > > $LOOPT:
> >  > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
> >  > > $  THEN
> >  > > $ LL=LL+1
> >  > > $ show sym ll
> >  > > $ IF LL .LE. 5 THEN GOTO LOOPT
> >  > > $  ELSE
> >  > > $  IF LL .GT. 5 THEN LL=0
> >  > > $ ENDIF
> >  > > $ show sym ll
> >  > > $ RDESC=F$ELEMENT(LL,",",TDESC)
> >  > > $ RETURN
> >  >
> >  > The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE"
> >  > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"?
> >
> > Well, the code certainly behaves as if the endif is in the wrong place,
> > but it isn't.  I will try structured if-the-else for all the
> > if-statements and I'm sure that will fix it, but I suspect I have
> > uncovered an ambiguity due to backward compatibility allowing
> > if-then-else to be:
> >
> > $if <condition> then <statement>
> > $endif
> >
>
> That syntax is illegal
>
>
> > instead of forcing:
> >
> > $if <condition>
> > $then
> > $<statement>
> > $endif
> >
> > I would surely like to know what the expected behavior is, and
> > if this violates the syntax.  Too bad Charlie retired.
>
> You original "if" block was (annotated by me)
>
> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
> $    THEN
> $        LL=LL+1
> $        show sym ll
> $        IF LL .LE. 5 THEN GOTO LOOPT
> $    ELSE    ! this else goes with the original "IF" not the one above it
> $       IF LL .GT. 5 THEN LL=0   ! this line will only get executed
> when the original "if" is "false"
> $ ENDIF
>

I simplified it to:

$FIND_TCODE: !Gosub
$ LL=5
$LOOPT:
$ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
$ THEN
$ LL=LL+1
$ show sym ll
$  IF LL .GT. 5
$  THEN
$   LL=0
$  ELSE
$   GOTO LOOPT
$  ENDIF
$ ENDIF
$ show sym ll
$ RDESC=F$ELEMENT(LL,",",TDESC)
$ RETURN

It was redundent to check for ".GT. 5" and also
".LE. 5" for if not one then of course the other.

The crux of the problem is that within an
$IF <condition_1>
$THEN
$<statement_t1>
$<statement_t2>
$ELSE
$<statement_e1>
$<statement_e2>
$ENDIF

that
$<statement_pn>
should be able to be the (valid) statement
  $IF <condition_x> then <statement_y>

and that in the complex IF-THEN-ELSE the
"$THEN"
must be on it's own line to distinguish
between the two forms.

Probably if I had put a replacement statement
before the $ELSE the parser would have recovered.

It's better this way, however.

-Norm

> Ken
>
>
>
> >
> > And no, TDESC should be TDESC.  It matches the code in one
> > element table and move the description from another
> > element table, but that's not relevent and since I didn't
> > include that part of the procedure, you can't know that.
> >
> >
> >
> > >
> >  > Try:
> >  >
> >  > $FIND_TCODE: !Gosub
> >  > $ LL=5
> >  > $LOOPT:
> >  > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
> >  > $  THEN
> >  > $    LL=LL+1
> >  > $    show sym ll
> >  > $    IF LL .LE. 5 THEN GOTO LOOPT
> >  > $ endif
> >  > $ IF LL .GT. 5 THEN LL=0
> >  > $ show sym ll
> >  > $ RDESC=F$ELEMENT(LL,",",Tcode)
> >  > $ sho sym rdesc
> >  > $ RETURN
> >  >
> >  > Ken
> >
 --=_alternative 005BC5CD85257391_=-- ------------------------------ Date: Mon, 12 Nov 2007 12:27:28 -0500 From: sol gongola Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: norm.raphael@metso.com wrote: > > > > > "Ken Robinson" wrote on 11/12/2007 10:48:25 AM: > >> On Nov 12, 2007 10:25 AM, wrote: >> > >> > >> > >> > >> > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM: >> > >> > >> > > On Nov 12, 2007 9:39 AM, wrote: >> > > > >> > > > Here is a DCL gosub routine to pick a description >> > > > out of an element list. If it does not find >> > > > a match in 1-5 is is supposed to set the LL >> > > > index variable to zero and pick that one. >> > > > Somehow, the statement to do that is not being >> > > > executed. DCL_CHECK does not find any error. >> > > > >> > > > What am I missing? >> > > > >> > > > $FIND_TCODE: !Gosub >> > > > $ LL=5 >> > > > $LOOPT: >> > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) >> > > > $ THEN >> > > > $ LL=LL+1 >> > > > $ show sym ll >> > > > $ IF LL .LE. 5 THEN GOTO LOOPT >> > > > $ ELSE >> > > > $ IF LL .GT. 5 THEN LL=0 >> > > > $ ENDIF >> > > > $ show sym ll >> > > > $ RDESC=F$ELEMENT(LL,",",TDESC) >> > > > $ RETURN >> > > >> > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE" >> > > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"? >> > >> > Well, the code certainly behaves as if the endif is in the wrong place, >> > but it isn't. I will try structured if-the-else for all the >> > if-statements and I'm sure that will fix it, but I suspect I have >> > uncovered an ambiguity due to backward compatibility allowing >> > if-then-else to be: >> > >> > $if then >> > $endif >> > >> >> That syntax is illegal >> >> >> > instead of forcing: >> > >> > $if >> > $then >> > $ >> > $endif >> > >> > I would surely like to know what the expected behavior is, and >> > if this violates the syntax. Too bad Charlie retired. >> >> You original "if" block was (annotated by me) >> >> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) >> $ THEN >> $ LL=LL+1 >> $ show sym ll >> $ IF LL .LE. 5 THEN GOTO LOOPT >> $ ELSE ! this else goes with the original "IF" not the one above it >> $ IF LL .GT. 5 THEN LL=0 ! this line will only get executed >> when the original "if" is "false" >> $ ENDIF >> > > I simplified it to: > > $FIND_TCODE: !Gosub > $ LL=5 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL+1 > $ show sym ll > $ IF LL .GT. 5 > $ THEN > $ LL=0 > $ ELSE > $ GOTO LOOPT > $ ENDIF > $ ENDIF > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN > > It was redundent to check for ".GT. 5" and also > ".LE. 5" for if not one then of course the other. > > The crux of the problem is that within an > $IF > $THEN > $ > $ > $ELSE > $ > $ > $ENDIF > > that > $ > should be able to be the (valid) statement > $IF then > > and that in the complex IF-THEN-ELSE the > "$THEN" > must be on it's own line to distinguish > between the two forms. > > Probably if I had put a replacement statement > before the $ELSE the parser would have recovered. > > It's better this way, however. > > -Norm > >> Ken >> >> >> >> > >> > And no, TDESC should be TDESC. It matches the code in one >> > element table and move the description from another >> > element table, but that's not relevent and since I didn't >> > include that part of the procedure, you can't know that. >> > >> > >> > >> > > >> > > Try: >> > > >> > > $FIND_TCODE: !Gosub >> > > $ LL=5 >> > > $LOOPT: >> > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) >> > > $ THEN >> > > $ LL=LL+1 >> > > $ show sym ll >> > > $ IF LL .LE. 5 THEN GOTO LOOPT >> > > $ endif >> > > $ IF LL .GT. 5 THEN LL=0 >> > > $ show sym ll >> > > $ RDESC=F$ELEMENT(LL,",",Tcode) >> > > $ sho sym rdesc >> > > $ RETURN >> > > >> > > Ken >> > $IF then is a single line conditional. It does not involve or allow ELSE or ENDIF there is no $IF then else IF-then-else has to be multiple line. AND the number of endif statements have to balance the IF statements ------------------------------ Date: 12 Nov 2007 07:34:28 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: VAX, VMS and QBUS Devices Message-ID: In article <5pmcv7Fs09frU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: > OK, here's a quastion that may seem rather strange, but I am serious. > If I put a QBUS extender on a VAX 4000-100 can I put an RXV11 on it? > Will VMS recognize it and allow access to RX01/RX02 disks? And, lastly, > if this will actually work, can VMS recognize and read any PDP-11 formats? As far as the hardware question: I think so, but maybe someone who knows will pipe in. Check the I/O user's guide to see of the RXV11 is a recognised driver (I think it is). Files-11 ODS-1 is a common native format for RSX-11 on your PDP-11 and VMS on your VAX (but not on Alpha or IA-64). If the PDP-11 disk is not Files-11, it may be one of the formats recognised by the VMS EXCHANGE utility (RT-11 or DOS (DEC's DOS, not MS-DOS), which will let you initialize disks in those formats and exchange files between those and native format disks. ------------------------------ Date: 12 Nov 2007 13:38:36 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: VAX, VMS and QBUS Devices Message-ID: <5pr3asFsdjbdU1@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <5pmcv7Fs09frU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >> OK, here's a quastion that may seem rather strange, but I am serious. >> If I put a QBUS extender on a VAX 4000-100 can I put an RXV11 on it? >> Will VMS recognize it and allow access to RX01/RX02 disks? And, lastly, >> if this will actually work, can VMS recognize and read any PDP-11 formats? > > As far as the hardware question: I think so, but maybe someone who > knows will pipe in. Check the I/O user's guide to see of the RXV11 > is a recognised driver (I think it is). > > Files-11 ODS-1 is a common native format for RSX-11 on your PDP-11 and > VMS on your VAX (but not on Alpha or IA-64). > > If the PDP-11 disk is not Files-11, it may be one of the formats > recognised by the VMS EXCHANGE utility (RT-11 or DOS (DEC's DOS, not > MS-DOS), which will let you initialize disks in those formats and > exchange files between those and native format disks. > Thank you. Time to revive another old system. 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 ------------------------------ End of INFO-VAX 2007.620 ************************