INFO-VAX Tue, 13 Nov 2007 Volume 2007 : Issue 621 Contents: Re: Filezilla connection Re: Filezilla connection Re: Filezilla connection Re: Hardcopy documentation Re: Hardcopy documentation Re: Hardcopy documentation Re: Hardcopy documentation Re: Hardcopy documentation LANCP SHO DEV /CHAR doesn't Re: LANCP SHO DEV /CHAR doesn't Re: LANCP SHO DEV /CHAR doesn't Latest TCPware DRIVERS patch seems to break inbound DECnet Re: Mylex 960 question Re: OpenVMS Group at XING Re: Process state in HIB while paging 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 RRCCCCCCCCCCCCCCCCCCCCCCCCCCCCCRRRRRRCVRRRRRRRRRRRRRRRRRRR SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes ---------------------------------------------------------------------- Date: Mon, 12 Nov 2007 12:52:31 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Filezilla connection Message-ID: <07111212523127_202002A8@antinode.org> From: Kevin Handy > Or, is there a simple FTP gui program that I can use instead? Long ago, I had some success using SmartFTP ("http://smartftp.com/"). It could be broken by now, but it's worth a try, and they did fix a couple of VMS-related bugs a few years ago. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 13 Nov 2007 01:00:17 -0000 From: ian.s.burgess@gmail.com Subject: Re: Filezilla connection Message-ID: <1194915617.814676.306570@q5g2000prf.googlegroups.com> I have been using Filezilla 2.2.18 to FTP to and from a VMS site using Win95, Win 2000 and XP with no problems. I've not tried Version 3 Prior to Filezilla I used WSFTP-LE, but much prefer filezilla. Ian On Nov 13, 4:44 am, Kevin Handy wrote: > 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.comThe #1 Newsgroup Service in the World! 120,000+ Newsgroups > ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- ------------------------------ Date: Tue, 13 Nov 2007 06:15:44 +0100 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: Filezilla connection Message-ID: <4739332a$0$243$e4fe514c@news.xs4all.nl> I use Filezilla V2.x every day to VMS without any issues. I tried V3 some time ago but went back to V2 since V3 was buggy with respect to VMS. Reports the issues to the author. Jur. Kevin Handy wrote, On 12-11-2007 19:44: > 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 22:03:07 GMT From: "Robert Jarratt" Subject: Re: Hardcopy documentation Message-ID: "IrishPub" wrote in message news: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. > Must be my poor memory about the 8 volumes then, or was it that the system calls was volume 8? It is hard to remember back 20+ years. Please do let me know what you have and how much it would cost, but I have to say that funds are limited and if it is too much I may have to pass, or perhaps just have a subset if you are prepared to do this. Thanks Rob ------------------------------ Date: Mon, 12 Nov 2007 23:11:40 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Hardcopy documentation Message-ID: In article , "Robert Jarratt" writes: {...snip...} >Must be my poor memory about the 8 volumes then, or was it that the system >calls was volume 8? It is hard to remember back 20+ years. Please do let me With age comes something but I can't remember what! :) >know what you have and how much it would cost, but I have to say that funds >are limited and if it is too much I may have to pass, or perhaps just have a >subset if you are prepared to do this. If I could find it in my heart to part with my set, I'd let you have it. I've held onto the old manuals as it's a sort of personal d|i|g|i|t|a|l museum. I did part with some stuff simply because I needed some breath- ing room some time ago. (uVAX-II, 9 track, Pro-350, etc., etc.) IIRC, Bob Koehler and a friend of his came to inherit some of this memorabilia. I gave a couple of VAXen (3100 series) and Alphas (AS200) away too to a few "hobbyists". They really had no value for sale. I asked only to be reimbursed the shipping costs. -- 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: Mon, 12 Nov 2007 20:13:07 -0500 From: JF Mezei Subject: Re: Hardcopy documentation Message-ID: <90bda$4738fa26$cef8887a$7187@TEKSAVVY.COM> VAXman- @SendSpamHere.ORG wrote: > With age comes something but I can't remember what! :) Mr VAXman, are you now out of hospital ? Are you OK ? Many were concerned when you made the announcement you were at hospital. And more importantly, if you were to be invited to a formal black tie event, would you wish the host to formally announce your arrival and introduce you as "Mister and Mrs VAXman" ? ------------------------------ Date: Tue, 13 Nov 2007 02:13:24 -0000 From: IrishPub Subject: Re: Hardcopy documentation Message-ID: <1194920004.940632.125240@o80g2000hse.googlegroups.com> On Nov 12, 5:11 pm, VAXman- @SendSpamHere.ORG wrote: > In article , "Robert Jarratt" writes: > > {...snip...} > > >Must be my poor memory about the 8 volumes then, or was it that the system > >calls was volume 8? It is hard to remember back 20+ years. Please do let me > > With age comes something but I can't remember what! :) > > >know what you have and how much it would cost, but I have to say that funds > >are limited and if it is too much I may have to pass, or perhaps just have a > >subset if you are prepared to do this. > > If I could find it in my heart to part with my set, I'd let you have it. > I've held onto the old manuals as it's a sort of personal d|i|g|i|t|a|l > museum. I did part with some stuff simply because I needed some breath- > ing room some time ago. (uVAX-II, 9 track, Pro-350, etc., etc.) IIRC, > Bob Koehler and a friend of his came to inherit some of this memorabilia. > > I gave a couple of VAXen (3100 series) and Alphas (AS200) away too to a > few "hobbyists". They really had no value for sale. I asked only to be > reimbursed the shipping costs. > -- > 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 Ugh - maybe its my memory that doesn't have the correct parity... I checked what I have and realized I was confused because some of the orange binders had their manuals replaced with the gray set. Anyway, what I have in Orange is: System Services RTL System Manager's Manual RMS Fortran Reference Ada Reference Together (with the binders I have them in) they weigh in at 26 lbs. Postage would be ~$105 to England. ------------------------------ Date: Tue, 13 Nov 2007 02:54:50 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Hardcopy documentation Message-ID: <_l8_i.8626$jd6.6736@newsfe08.lga> In article <90bda$4738fa26$cef8887a$7187@TEKSAVVY.COM>, JF Mezei writes: > > >VAXman- @SendSpamHere.ORG wrote: >> With age comes something but I can't remember what! :) > >Mr VAXman, are you now out of hospital ? Are you OK ? Many were >concerned when you made the announcement you were at hospital. Thank you for your sincere concern, JF. We have never met face to face but I would hope to someday. Indeed, I am out of the hospital. As many here know, I suffer from some chronic illnesses -- diabetes and nephritis and a slew of other unpleasant adjuncts. In the past few months, stress from a vile, cruel and despicable origin have me under a great deal of stress. In my condition, the stress has had a very detrimental effect upon my health. I am out of the hospital and I see my doctor later this week. That's all I will say public- ly as my health is not the type of thing I'd like openly discussed in c.o.v. I'll entertain anybody's concerns if they ask privately. There are some other details of my life that have occurred over the past 3+ years or so that I will, most definitely, not discuss here. >And more importantly, if you were to be invited to a formal black tie >event, would you wish the host to formally announce your arrival and >introduce you as "Mister and Mrs VAXman" ? ;) Many of my friends refer to my lovely wife and Mrs. VAXman. She doesn't seem to mind as she understands the plaudits of the title. However, I don't think I would or could do a formal black tie event. A tux and tie would stymie my blue-jeans, T-shirt, sandals and pony- tail liberty. -- 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: Mon, 12 Nov 2007 20:58:47 +0100 From: Wilm Boerhout Subject: LANCP SHO DEV /CHAR doesn't Message-ID: <4738b0ad$0$25482$ba620dc5@text.nova.planet.nl> VAX/VMS 7.3, all patches applied. MC LANCP SHO DEV XQA0 /CHAR complains about /CHAR (unrecognized qualifier) and doesn't show the characteristics. 1. Can I get LANCP to work? 2. If no, any other way to get the LAN SPEED, duplex mode etc.? -- Wilm Boerhout Zwolle, NL remove OLD PAINT from return address to reply ------------------------------ Date: Mon, 12 Nov 2007 15:09:35 -0500 From: JF Mezei Subject: Re: LANCP SHO DEV /CHAR doesn't Message-ID: <1e1f2$4738b303$cef8887a$22260@TEKSAVVY.COM> Wilm Boerhout wrote: > VAX/VMS 7.3, all patches applied. > > MC LANCP SHO DEV XQA0 /CHAR complains about /CHAR (unrecognized Yep this is an Alpha only feature. (as per the HELP SHOW DEV /CHAR) SHOW DEV XQA0: /PARA does provide LANCP> show dev /par eza0: Device Parameters EZA0: Value Parameter ----- --------- Normal Controller mode 08-00-2B-BC-66-F1 Hardware LAN address CSMA/CD Communication medium External Internal loopback mode ----------------------------------------------------- On Alpha 8.3: it provides more info: LANCP> show dev ewa0/par Device Characteristics EWA0: Value Characteristic ----- -------------- 1500 Device buffer size Normal Controller mode External Internal loopback mode 08-00-2B-86-D8-7E Default MAC address (Hardware LAN address) Multicast address list Ethernet Communication medium FF-FF-FF-FF-FF-FF MAC address (Current LAN address) 128 Minimum receive buffers 256 Maximum receive buffers Yes Full duplex enable Yes Full duplex operational AA-00-04-00-0B-04 MAC address (Current LAN address) TwistedPair Line media type 100 Line speed (mbps) Disabled Auto-negotiation Disabled Flow control Disabled Jumbo frames 0 Failover priority > 1. Can I get LANCP to work? LANCP works on VAX. It just doesn't show you as much information. ------------------------------ Date: Tue, 13 Nov 2007 06:17:40 +0100 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: LANCP SHO DEV /CHAR doesn't Message-ID: <4739339d$0$243$e4fe514c@news.xs4all.nl> Hey, it's a vax and that does officially not know about anything more than 10MBps. As said, SHOW DEV/PARAMETER is the best you can get. Jur. Wilm Boerhout wrote, On 12-11-2007 20:58: > VAX/VMS 7.3, all patches applied. > > MC LANCP SHO DEV XQA0 /CHAR complains about /CHAR (unrecognized > qualifier) and doesn't show the characteristics. > > 1. Can I get LANCP to work? > 2. If no, any other way to get the LAN SPEED, duplex mode etc.? > ------------------------------ Date: Tue, 13 Nov 2007 02:12:50 GMT From: John Santos Subject: Latest TCPware DRIVERS patch seems to break inbound DECnet Message-ID: Heads-up to all. I recently installed the latest TCPware DRIVERS patch, DRIVERS_V572P081 on several systems and then discovered that inbound DECnet-over-IP connections (both set host and FAL) no longer work. Outbound works fine. The symptom is after a minute or so you get a "%SYSTEM-F-LINKEXIT, network partner exited" error and it seems to leave an INET connection in "CLOSE-WAIT" state on the destination system. This bug happens on both VAX and Alpha systems (don't have an Itanium with TCPware to try it on.) The VAXes are VMS V7.3/TCPware V5.7-2. The Alphas are VMS V8.3 with TCPware V5.7-2. I have one Alpha that still has the DRIVERS_V572P050 version of the patch on it, which works fine. Taking a shot in the dark, I copied PWIPDRIVER.EXE from it to one of the broken Alphas and rebooted it, and it now works again. (The curious thing is PWIPDRIVER isn't listed in any of the DRIVERS patch release notes as a modified module, but each DRIVERS patch seems to build a new one!) Am forwarding this to Process Software as well. -- John ------------------------------ Date: Mon, 12 Nov 2007 22:46:46 +0200 From: =?ISO-8859-1?Q?Uusim=E4ki?= Subject: Re: Mylex 960 question Message-ID: <4738bb38$0$3197$9b536df3@news.fv.fi> Malcolm Dunnett wrote: > H Vlems wrote: > >> Of course it turned out to be a little more complicated because the >> ARC software wouldn't load the >> RA200RCU.EXE utility. The first suspect was the floppy itself, though >> it could be read on a PC. >> A copy failed and also a third one with a fresh copy of RA200RCU.EXE >> from another source. >> Hardware failure? No, it appeared that the flat cable was no longer >> connected to the floppy drive. > > IIRC you can also find a copy of RA200RCU on the Alpha firmware update > CDs, under a Storageworks directory. > >> But it works, thanks again! >> Hans >> Exactly, the RA200RCU.EXE is on the Firmware CD (in UTILITY\SWXCRMGR directory), but I would recommend the RA200SRL.EXE, which can be used with a VT Terminal. It resides in the same directory. Real computers don't have graphics adapters. ;-) ------------------------------ Date: Mon, 12 Nov 2007 21:50:48 -0600 From: David J Dachtera Subject: Re: OpenVMS Group at XING Message-ID: <47391F18.EA28D924@spam.comcast.net> Hans Bachner wrote: > > David J Dachtera wrote: > > > "Lukas Th. Hey" wrote: > >> > >> Hi there, > >> > >> there finally is an OpenVMS group newly added to the community. I > >> wonder there wasn't any other VMS-related group before: > >> > >> https://www.xing.org/net/openvms/ > > > > That site requires registration, > > Yes it does. > > I think the posting was mainly aimed at Xing (formerly OpenBC, Open > Business Club) members. Maybe a second goal was to attract more OpenVMS > community members to Xing. Membership is free. ...and joining the group is annoying since its not immediate. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://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: Tue, 13 Nov 2007 00:58:30 GMT From: John Santos Subject: Re: Process state in HIB while paging Message-ID: In article , koehler@eisner.nospam.encompasserve.org says... > 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). > Thanks Bob for setting me straight. I thought the Java issue was the show stopper, but I guess Mozilla must not really need it. BTW, I once heard a rumor that DEC (Compaq?) got Java working on VAX very early on, but it wouldn't pass the test procedures if they built it using VAX floating point (differences in the low-order bits) and if they built it with IEEE emulation, it was far too slow to be useable. Maybe JF would have been happy with it, though :-) :-) :-) -- John ------------------------------ Date: Mon, 12 Nov 2007 12:01:05 -0800 From: Doug Phillips Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: <1194897665.387179.230560@o38g2000hse.googlegroups.com> On Nov 12, 10:42 am, norm.raph...@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 > Yes, it is. In your original code the endif terminates the preceding if-then-else, not the one-liner if-then. > > > instead of forcing: > > > > $if > > > $then > > > $ > > > $endif > And that's the way it's working. > > > I would surely like to know what the expected behavior is, and > > > if this violates the syntax. Too bad Charlie retired. > You've described the expected behavior. > > 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. > There's still too much code. > 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. > That's the way it works. > Probably if I had put a replacement statement > before the $ELSE the parser would have recovered. > > It's better this way, however. > I disagree. You have your answer, but if this code is close to being the actual code you use (obviously you don't init LL = 5) but you do have a known highest element number (5 in your example), you don't need an ELSE: $FIND_TCODE: !Gosub $ LL = 0 $LOOPT: $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) $ THEN $ LL=LL+1 $ show sym ll $ IF LL .LE. 5 THEN GOTO LOOPT $ LL = 0 ! you know what LL is, why test it again? $ ENDIF $ show sym ll $ RDESC=F$ELEMENT(LL,",",TDESC) $ RETURN or better yet: $FIND_TCODE: !Gosub $ LL = 5 $LOOPT: $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) $ THEN $ LL=LL-1 $ show sym ll $ IF LL .GT. 0 THEN GOTO LOOPT $ ! it's zero, you don't need to set it. $ ENDIF $ show sym ll $ RDESC=F$ELEMENT(LL,",",TDESC) $ RETURN Or, I imagine someone will post an elegant little perl one-liner;-) ------------------------------ Date: Mon, 12 Nov 2007 16:03:41 -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 0073B0BD85257391_= Content-Type: text/plain; charset="US-ASCII" Doug Phillips wrote on 11/12/2007 03:01:05 PM: > On Nov 12, 10:42 am, norm.raph...@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 > > > > Yes, it is. In your original code the endif terminates the preceding > if-then-else, not the one-liner if-then. > > > > > instead of forcing: > > > > > > $if > > > > $then > > > > $ > > > > $endif > > > > And that's the way it's working. > > > > > I would surely like to know what the expected behavior is, and > > > > if this violates the syntax. Too bad Charlie retired. > > > > You've described the expected behavior. > > > > 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. > > > > There's still too much code. > > > 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. > > > > That's the way it works. That's not the way it appeared to work. > > > Probably if I had put a replacement statement > > before the $ELSE the parser would have recovered. > > > > It's better this way, however. > > > > I disagree. > > You have your answer, but if this code is close to being the actual > code you use (obviously you don't init LL = 5) but you do have a known > highest element number (5 in your example), you don't need an ELSE: > > > $FIND_TCODE: !Gosub > $ LL = 0 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL+1 > $ show sym ll > $ IF LL .LE. 5 THEN GOTO LOOPT > $ LL = 0 ! you know what LL is, why test it again? > $ ENDIF > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN > This is so! > > or better yet: > > $FIND_TCODE: !Gosub > $ LL = 5 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL-1 > $ show sym ll > $ IF LL .GT. 0 THEN GOTO LOOPT > $ ! it's zero, you don't need to set it. > $ ENDIF > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN > Well, they are ascending in probable hits, but if I make the table entries descending in probable hits, that solution is indeed better yet (,if no one has to read the code ;) ). > Or, I imagine someone will post an elegant little perl one-liner;-) > I don't do perl. --=_alternative 0073B0BD85257391_= Content-Type: text/html; charset="US-ASCII"



Doug Phillips <dphill46@netscape.net> wrote on 11/12/2007 03:01:05 PM:

> On Nov 12, 10:42 am, norm.raph...@metso.com wrote:
> > "Ken Robinson" <kenrb...@gmail.com> wrote on 11/12/2007 10:48:25 AM:
> > > On Nov 12, 2007 10:25 AM,  <norm.raph...@metso.com> wrote:
> >
> > > > "Ken Robinson" <kenrb...@gmail.com> wrote on 11/12/2007 10:01:03 AM:
> >
> > > >  > On Nov 12, 2007 9:39 AM,  <norm.raph...@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> > "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 > > > > Yes, it is. In your original code the endif terminates the preceding > if-then-else, not the one-liner if-then. > > > > > instead of forcing: > > > > > > $if > > > > $then > > > > $ > > > > $endif > > > > And that's the way it's working. > > > > > I would surely like to know what the expected behavior is, and > > > > if this violates the syntax. Too bad Charlie retired. > > > > You've described the expected behavior. > > > > 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. > > > > There's still too much code. > > > 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. > > > > That's the way it works. That's not the way it appeared to work. > > > Probably if I had put a replacement statement > > before the $ELSE the parser would have recovered. > > > > It's better this way, however. > > > > I disagree. > > You have your answer, but if this code is close to being the actual > code you use (obviously you don't init LL = 5) but you do have a known > highest element number (5 in your example), you don't need an ELSE: > > > $FIND_TCODE: !Gosub > $ LL = 0 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL+1 > $ show sym ll > $ IF LL .LE. 5 THEN GOTO LOOPT > $ LL = 0 ! you know what LL is, why test it again? > $ ENDIF > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN > This is so! > > or better yet: > > $FIND_TCODE: !Gosub > $ LL = 5 > $LOOPT: > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) > $ THEN > $ LL=LL-1 > $ show sym ll > $ IF LL .GT. 0 THEN GOTO LOOPT > $ ! it's zero, you don't need to set it. > $ ENDIF > $ show sym ll > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN > Well, they are ascending in probable hits, but if I make the table entries descending in probable hits, that solution is indeed better yet (,if no one has to read the code ;) ). > Or, I imagine someone will post an elegant little perl one-liner;-) > I don't do perl. --=_alternative 0073B0BD85257391_= Content-Type: text/html; charset="US-ASCII"



Doug Phillips <dphill46@netscape.net> wrote on 11/12/2007 03:01:05 PM:

> On Nov 12, 10:42 am, norm.raph...@metso.com wrote:
> > "Ken Robinson" <kenrb...@gmail.com> wrote on 11/12/2007 10:48:25 AM:
> > > On Nov 12, 2007 10:25 AM,  <norm.raph...@metso.com> wrote:
> >
> > > > "Ken Robinson" <kenrb...@gmail.com> wrote on 11/12/2007 10:01:03 AM:
> >
> > > >  > On Nov 12, 2007 9:39 AM,  <norm.raph...@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
> >
>
> Yes, it is. In your original code the endif terminates the preceding
> if-then-else, not the one-liner if-then.
>
> > > > instead of forcing:
> >
> > > > $if <condition>
> > > > $then
> > > > $<statement>
> > > > $endif
> >
>
> And that's the way it's working.
>
> > > > I would surely like to know what the expected behavior is, and
> > > > if this violates the syntax.  Too bad Charlie retired.
> >
>
> You've described the expected behavior.
>
> > > 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.
> >
>
> There's still too much code.
>
> > 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.
> >
>
> That's the way it works.


That's not the way it appeared to work.

>
> > Probably if I had put a replacement statement
> > before the $ELSE the parser would have recovered.
> >
> > It's better this way, however.
> >
>
> I disagree.
>
> You have your answer, but if this code is close to being the actual
> code you use (obviously you don't init LL = 5) but you do have a known
> highest element number (5 in your example), you don't need an ELSE:
>
>
> $FIND_TCODE: !Gosub
> $ LL = 0
> $LOOPT:
> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
> $  THEN
> $     LL=LL+1
> $     show sym ll
> $     IF LL .LE. 5 THEN GOTO LOOPT
> $     LL = 0  ! you know what LL is, why test it again?
> $  ENDIF
> $ show sym ll
> $ RDESC=F$ELEMENT(LL,",",TDESC)
> $ RETURN
>

This is so!

>
> or better yet:
>
> $FIND_TCODE: !Gosub
> $ LL = 5
> $LOOPT:
> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
> $  THEN
> $     LL=LL-1
> $     show sym ll
> $     IF LL .GT. 0 THEN GOTO LOOPT
> $     ! it's zero, you don't need to set it.
> $  ENDIF
> $ show sym ll
> $ RDESC=F$ELEMENT(LL,",",TDESC)
> $ RETURN
>


Well, they are ascending in probable hits, but
if I make the table entries descending in
probable hits, that solution is indeed better
yet (,if no one has to read the code  ;) ).

> Or, I imagine someone will post an elegant little perl one-liner;-)
>
I don't do perl.
--=_alternative 0073B0BD85257391_=-- ------------------------------ Date: Mon, 12 Nov 2007 15:31:18 -0800 From: FrankS Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: <1194910278.471123.15480@50g2000hsm.googlegroups.com> I'm sure this is beating a dead horse, but you had a fundamental problem with the logic, perhaps related to your misunderstanding of the correct IF statement syntax. I've indented your original posting to show how the IF blocks are being matched and added line numbers to help point out the problems ... 1> $ FIND_TCODE: 2> $ LL = 5 3> $ LOOPT: 4> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE) 5> $ THEN 6> $ LL=LL+1 7> $ show sym ll 8> $ IF LL .LE. 5 THEN GOTO LOOPT 9> $ ELSE 10> $ IF LL .GT. 5 THEN LL=0 11> $ ENDIF 12> $ show sym ll 13> $ RDESC=F$ELEMENT(LL,",",TDESC) 14> $ RETURN Comments: a) In line 2, I'm guessing you really mean to initialize LL = 1, and not LL = 5. Unless you were testing the end condition and forgot to change it back before posting. You stated that you wanted to check the items at positions 1 thru 5 and return the 0th item only if no other matches were found. If that's correct, then you would never initialize it to zero. b) As has been pointed out, when you want to use the IF-THEN-ELSE- ENDIF, you *must* put the corresponding THEN on a seperate line. The ELSE and ENDIF on lines 9 and 11, respectively, are matched to the IF/ THEN on lines 4 and 5. It appears that you are expecting the ELSE to have been matched to the IF on line 8. That's not correct, and shows you aren't familiar with the correct syntax. c) Take the snippet as-is, and applying the correct behaviour based on how you typed it, we can see that when LL reaches the value of six, the IF on line 8 fails, and the code falls through to line 12. The value of LL is never reset to zero, which is exactly the behaviour that should be expected from this code. In addition, the IF on line 10 is only executed when a matching value is found in the list, and in that case we know LL must be between 1 and 5. So the entire ELSE clause is useless. (Again, that's not what you were expecting, but it is the way the snippet will work.) My preference in this particular case would be to not even use IF-THEN- ELSE-ENDIF. In this example you also aren't jumping out of an IF- ENDIF block, which is just a minor nicety. $ FIND_TCODE: $ LL = 1 $ $ LOOPT: $ IF (FCODE .EQS. F$ELEMENT(LL, ",", TCODE)) THEN GOTO LOOPDONE $ $ LL = LL + 1 $ IF (LL .LE. 5) THEN GOTO LOOPT $ $ LL = 0 $ $ LOOPDONE: $ RDESC = F$ELEMENT(LL, ",", TDESC) $ $ RETURN ------------------------------ Date: Mon, 12 Nov 2007 22:02:06 -0600 From: David J Dachtera Subject: Re: Q: DCL IF / NESTED IF-THEN-ELSE Message-ID: <473921BE.7EB7AE55@spam.comcast.net> norm.raphael@metso.com wrote: > [snip] > === > > $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?] <-- *** Not displayed if not executed. > $ ENDIF > $ show sym ll > LL = 6 Hex = 00000006 Octal = 00000000006 > $ RDESC=F$ELEMENT(LL,",",TDESC) > $ RETURN -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://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: Mon, 12 Nov 2007 20:14:10 -0500 From: "KENNETH DOLAN, SOCIAL SECURITY NUMBER 317-84-6287" Subject: RRCCCCCCCCCCCCCCCCCCCCCCCCCCCCCRRRRRRCVRRRRRRRRRRRRRRRRRRR Message-ID: <1194920050_10675@sp12lax.superfeed.net> RECCCCCCCCCCCCCCCCCCCCCGRCCRCCCCCCCCCCCCCCCCRRRRRRSGDDFFR ------------------------------ Date: Mon, 12 Nov 2007 19:46:29 -0800 From: "Tom Linden" Subject: SYS$GRANT_LICENSE output codes Message-ID: The LMF System Service Manual indicate two possible, optional output codes, LMF$_PROD_TOKEN and LMF$_HW_ID. I am unable to get either to work. I created an appropriate license pak in a separate testing lmf database and loaded the license. But when running the test, the status which should be 1 if the call is successful, got 12. When I comment out the item_list for the HW_ID it returns 1, so it clearly found the license. Anyone have experience with this call? I am not convinced it works as documented. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: 12 Nov 2007 21:53:34 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: In article , "Tom Linden" writes: > The LMF System Service Manual indicate two possible, optional > output codes, LMF$_PROD_TOKEN and LMF$_HW_ID. I am unable to get > either to work. I created an appropriate license pak in a > separate testing lmf database and loaded the license. But > when running the test, the status which should be 1 if the call > is successful, got 12. When I comment out the item_list for the > HW_ID it returns 1, so it clearly found the license. 12 is SS$_ACCVIO. so without looking at the book I would say you have something wrong in by-reference/by-value land. I would say you should remove a dot, but I do not believe you used Bliss. > Anyone have experience with this call? I am not convinced it > works as documented. LJK/Security licenses use both of those fields, but I don't believe you programmed it in Ada either. ------------------------------ Date: Mon, 12 Nov 2007 21:25:32 -0800 From: "Tom Linden" Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: On Mon, 12 Nov 2007 19:53:34 -0800, Larry Kilgallen wrote: > In article , "Tom Linden" > writes: > >> The LMF System Service Manual indicate two possible, optional >> output codes, LMF$_PROD_TOKEN and LMF$_HW_ID. I am unable to get >> either to work. I created an appropriate license pak in a >> separate testing lmf database and loaded the license. But >> when running the test, the status which should be 1 if the call >> is successful, got 12. When I comment out the item_list for the >> HW_ID it returns 1, so it clearly found the license. > > 12 is SS$_ACCVIO. so without looking at the book I would say you > have something wrong in by-reference/by-value land. I would say > you should remove a dot, but I do not believe you used Bliss. > >> Anyone have experience with this call? I am not convinced it >> works as documented. > > LJK/Security licenses use both of those fields, but I don't believe > you programmed it in Ada either. Quite right, this is the declaration declare 1 license_items, 2 prod_date, 3 length fixed bin(15) initial (8), 3 item fixed bin(15) initial (lmf$_prod_date), 3 bufadr pointer initial (addr(binary_date)), 3 retlen fixed bin(31) initial (0), 2 prod_version, 3 length fixed bin(15) initial (4), 3 item fixed bin(15) initial (lmf$_prod_version), 3 bufadr pointer initial (addr(compiler_version)), 3 retlen fixed bin(31) initial (0), 2 hw_id, 3 length fixed bin(15) initial (31), 3 item fixed bin(15) initial (lmf$_hw_id), 3 bufadr pointer initial (addr(hardware_id)), 3 retlen fixed bin(31) initial (0), 2 endlist, 3 length fixed bin(15) initial (0), 3 item fixed bin(15) initial (0), 3 bufadr pointer initial (null()), 3 retlen fixed bin(31) initial (0); where declare compiler_version(2) fixed bin(15) static readonly initial (MINOR_VERSION, MAJOR_VERSION); declare binary_date bit(64) aligned static; declare hardware_id char(31) static init( ''); The call works if I commented out the hw_id substructure. As far as I can tell this definition conforms to the documentation, which requires the bufadr to be a pointer to a buffer of storage for sending/receiving data to/from the call. -- PL/I for OpenVMS www.kednos.com ------------------------------ End of INFO-VAX 2007.621 ************************