INFO-VAX Tue, 13 Nov 2007 Volume 2007 : Issue 622 Contents: Re: Filezilla connection Re: Filezilla connection Re: Hardcopy documentation Re: Process state in HIB while paging Re: Q: DCL IF / NESTED IF-THEN-ELSE Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes VAMP back online ---------------------------------------------------------------------- Date: Tue, 13 Nov 2007 18:59:15 +1100 From: Gremlin Subject: Re: Filezilla connection Message-ID: <13jimakdmqhhs11@corp.supernews.com> Steven M. Schweda wrote: > 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 I also use FileZilla, having tried and dropped SmartFTP and others. Small bugs with directory creation, but otherwise works well to OVMS8.2 from XP64 ------------------------------ Date: 13 Nov 2007 07:22:30 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Filezilla connection Message-ID: In article <1194892635_8953@sp12lax.superfeed.net>, Kevin Handy writes: > 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 strongly suggest you "upgrade" to an earlier version of Filezilla. I'm using 2.2.29 with no big problems and based on you're post I'm not updating it soon. > > under the "advanced" tab, I select "Servertype: VMS", > so I assume that someone once thought it sould work. I've never got Filezilla to recognise VMS nodes as VMS. It seems to handle LIST output properly, but it's setting for "show all versions" doesn't work (and I'm not running my Multinet server in UNIX emulation mode). ------------------------------ Date: 13 Nov 2007 07:29:15 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Hardcopy documentation Message-ID: In article , "Robert Jarratt" writes: > > 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. I think the VMS 2 Blue Shelf was about 8 volumes. ------------------------------ Date: 13 Nov 2007 07:31:41 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Process state in HIB while paging Message-ID: <8oFDXsGT3yeY@eisner.encompasserve.org> In article , John Santos writes: > 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. I did here (or read in c.o.v) that they tried IEEE emulation and it was much too slow. I got the impression they didn't even try to port the JRE because of the results of that test. ------------------------------ Date: Tue, 13 Nov 2007 09:27:43 -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 004F700E85257392_= Content-Type: text/plain; charset="US-ASCII" FrankS wrote on 11/12/2007 06:31:18 PM: > 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. Well, yes and no. I did have a blind spot, and your analysis below has made me see it, thank you immensely. > > 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. > The actual routine initializes it to "1". The posted version is a test/shortened version as the earlier iterations are uninteresting in the contect of the question. > 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. Yes I know that. That wasn't my problem. > > 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. No, I intended the ELSE to drop to line 10, and you are correct about your point in c) below - that is where I got myself blinded. > > 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.) > Yes, I had intended the no-match case to drop to line 10, not line 12, but as you point out, that will not occur as written. I have since changed the code, and as has been pointed out elsewhere it can be further simplified. If my Logic 201 professor were alive he'd be turning over in his grave. > > 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 > Yes, this is much cleaner. I got caught up in the illogic and missed the forest. -Norm P.S. This horse is now not only dead, but dogfood. --=_alternative 004F700E85257392_= Content-Type: text/html; charset="US-ASCII"



FrankS <sapienza@noesys.com> wrote on 11/12/2007 06:31:18 PM:

> 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.


Well, yes and no.  I did have a blind spot, and your analysis below
has made me see it, thank you immensely.
>
> 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.
>


The actual routine initializes it to "1".  The posted version is
a test/shortened version as the earlier iterations are uninteresting
in the contect of the question.

> 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.

Yes I know that.  That wasn't my problem.

>
> 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.

No, I intended the ELSE to drop to line 10, and you are correct about
your point in c) below - that is where I got myself blinded.

>
> 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.)
>

Yes, I had intended the no-match case to drop to line 10, not line 12,
but as you point out, that will not occur as written.  I have since
changed the code, and as has been pointed out elsewhere it can be
further simplified.

If my Logic 201 professor were alive he'd be turning over in his gravtal > problem with the logic, perhaps related to your misunderstanding of > the correct IF statement syntax. Well, yes and no. I did have a blind spot, and your analysis below has made me see it, thank you immensely. > > 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. > The actual routine initializes it to "1". The posted version is a test/shortened version as the earlier iterations are uninteresting in the contect of the question. > 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. Yes I know that. That wasn't my problem. > > 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. No, I intended the ELSE to drop to line 10, and you are correct about your point in c) below - that is where I got myself blinded. > > 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.) > Yes, I had intended the no-match case to drop to line 10, not line 12, but as you point out, that will not occur as written. I have since changed the code, and as has been pointed out elsewhere it can be further simplified. If my Logic 201 professor were alive he'd be turning over in his grave. > > 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 > Yes, this is much cleaner. I got caught up in the illogic and missed the forest. -Norm P.S. This horse is now not only dead, but dogfood. --=_alternative 004F700E85257392_= Content-Type: text/html; charset="US-ASCII"



FrankS <sapienza@noesys.com> wrote on 11/12/2007 06:31:18 PM:

> 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.


Well, yes and no.  I did have a blind spot, and your analysis below
has made me see it, thank you immensely.
>
> 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.
>


The actual routine initializes it to "1".  The posted version is
a test/shortened version as the earlier iterations are uninteresting
in the contect of the question.

> 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.

Yes I know that.  That wasn't my problem.

>
> 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.

No, I intended the ELSE to drop to line 10, and you are correct about
your point in c) below - that is where I got myself blinded.

>
> 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.)
>

Yes, I had intended the no-match case to drop to line 10, not line 12,
but as you point out, that will not occur as written.  I have since
changed the code, and as has been pointed out elsewhere it can be
further simplified.

If my Logic 201 professor were alive he'd be turning over in his grave.
 

>
> 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
>

Yes, this is much cleaner.  I got caught up in the illogic and
missed the forest.

-Norm

P.S.

This horse is now not only dead, but dogfood.
--=_alternative 004F700E85257392_=-- ------------------------------ Date: Tue, 13 Nov 2007 12:44:47 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: <3%g_i.28$sT6.10@newsfe10.lga> 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. > >Anyone have experience with this call? I am not convinced it >works as documented. I have been using both without any issues. First off, if you've received 12 (^x0C) back from SYS$GRANT_LICENSE, that is an ACCVIO. I would suspect that you have something amuck in your item list being passed to SYS$GRANT_LICENSE. Tom here a simple bit of Macro that invokes SYS$GRANT_LICENSE. Change the PRODUCT, PRODUCER, MY_TOKEN and MY_HW_ID values as needed. This shows how to get the TOKEN and HW_ID and then what to do with that info once it has been obtained. ;++ ; Copyright 2007 Brian Schenkenberger ; You know what you need to do if you want to use it. ;-- $LMFDEF $LICENSEDEF .PSECT DATA,WRT,NOEXE,5 LMFITM: .WORD LMF$K_VERSIONLEN,LMF$_PROD_VERSION .ADDRESS PRODUCT_VERSION,0 .WORD LMF$K_TOKENLEN,LMF$_PROD_TOKEN .ADDRESS PRODUCT_TOKEN,TOKEN_LENGTH .WORD LMF$K_HW_IDLEN,LMF$_HW_ID .ADDRESS PRODUCT_HW_ID,HW_ID_LENGTH,0 PROD_VERSION: .WORD minor,major ; Vmajor.minor PROD_TOKEN: .LONG 0[+1] ; retrieved token string TOKEN_LENGTH: .LONG 0 ; retrieved token length PROD_HW_ID: .LONG 0[+1] ; retrieved HW ID string HW_ID_LENGTH: .LONG 0 ; retrieved HW ID length CONTEXT: .LONG 0[16] PRODUCER: .ASCID "TOM_LINDEN" .ALIGN LONG PRODUCT: .ASCID "TOMS_PROD" .ALIGN LONG MY_HW_ID: "whatever HW ID" MY_TOKEN: "whatever TOKEN" .PSECT CODE,NOWRT,EXE,5 .ENTRY DEMO_FOR_TOM,0 $GRANT_LICENSE_S - ; invoke $GRANT_LICENSE PRDNAM = PRODUCT,- PRDUCER = PRODUCER,- CONTXT = CONTEXT,- ITMLST = LMFITM BLBS R0,10$ RET 10$: MOVAB MY_TOKEN,R0 MOVZWL R0,R0 MOVZWL TOKEN_LENGTH,R2 MOVAB PROD_TOKEN,R3 CMPC5 R0,(R1),#0,R2,(R3) BEQL 20$ ; if both strings equal, TOKEN OK MOVL #LICENSE$_INVALID_TOKEN,R0 ; return bad token RET 20$: MOVAB MY_HW_ID,R0 MOVZWL R0,R0 MOVZWL HW_ID_LENGTH,R2 MOVAB PROD_HW_ID,R3 CMPC5 R0,(R1),#0,R2,(R3) BEQL 30$ ; if both strings equal, HW_ID OK MOVL #LICENSE$_INVALID_HW_ID,R0 ; return bad HW ID RET 30$: ; rest of your program... RET .END DEMO_FOR_TOM Disclaimer: It's early in the morning. I had a really bad night's sleep, I have a whopper of a headache and I have not had enough caffeine yet. -- 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: Tue, 13 Nov 2007 12:54:45 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: In article , "Tom Linden" writes: > > >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. 2 hw_id, 3 length fixed bin(15) initial (lmf$k_hw_idlen), 3 item fixed bin(15) initial (lmf$_hw_id), 3 bufadr pointer initial (addr(hardware_id)), 3 retlen fixed bin(31) initial (0), <===<<< (*) SYS$GRANT_LICENSE will want to return the length of the retrieved HW ID. (*) Is this specified properly? Sorry, my PL/I is rusty. -- 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: Tue, 13 Nov 2007 08:49:16 -0500 From: John Reagan Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: VAXman- @SendSpamHere.ORG wrote: > In article , "Tom Linden" writes: > 2 hw_id, > 3 length fixed bin(15) initial (lmf$k_hw_idlen), > 3 item fixed bin(15) initial (lmf$_hw_id), > 3 bufadr pointer initial (addr(hardware_id)), > 3 retlen fixed bin(31) initial (0), <===<<< (*) > > SYS$GRANT_LICENSE will want to return the length of the retrieved HW ID. > (*) Is this specified properly? Sorry, my PL/I is rusty. > Bingo! HW_ID & PROD_TOKEN want to return their length. You can't say "don't bother" like you can with other item-based services. I just checked the source to verify that behavior. Why? No clue. I didn't see a real need to be "different" but that is the way it is coded. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Tue, 13 Nov 2007 15:31:21 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: In article , John Reagan writes: > > >VAXman- @SendSpamHere.ORG wrote: >> In article , "Tom Linden" writes: > >> 2 hw_id, >> 3 length fixed bin(15) initial (lmf$k_hw_idlen), >> 3 item fixed bin(15) initial (lmf$_hw_id), >> 3 bufadr pointer initial (addr(hardware_id)), >> 3 retlen fixed bin(31) initial (0), <===<<< (*) >> >> SYS$GRANT_LICENSE will want to return the length of the retrieved HW ID. >> (*) Is this specified properly? Sorry, my PL/I is rusty. >> > >Bingo! HW_ID & PROD_TOKEN want to return their length. You can't say >"don't bother" like you can with other item-based services. I just >checked the source to verify that behavior. Why? No clue. I didn't see >a real need to be "different" but that is the way it is coded. If the item's length is NOT returned, properly verifying that the retrieved TOKEN or the HW_ID is correct can be problematic. -- 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: Tue, 13 Nov 2007 07:39:37 -0800 From: "Tom Linden" Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: On Tue, 13 Nov 2007 05:49:16 -0800, John Reagan wro= te: > VAXman- @SendSpamHere.ORG wrote: >> In article , "Tom = >> Linden" writes: > >> 2 hw_id, >> 3 length fixed bin(15) initial (lmf$k_hw_idlen), >> 3 item fixed bin(15) initial (lmf$_hw_id), >> 3 bufadr pointer initial (addr(hardware_id)), >> 3 retlen fixed bin(31) initial (0), <=3D=3D=3D= <<< (*) >> SYS$GRANT_LICENSE will want to return the length of the retrieved HW= = >> ID. >> (*) Is this specified properly? Sorry, my PL/I is rusty. >> > > Bingo! HW_ID & PROD_TOKEN want to return their length. You can't say= = > "don't bother" like you can with other item-based services. I just = > checked the source to verify that behavior. Why? No clue. I didn't s= ee = > a real need to be "different" but that is the way it is coded. It could be becaused these are the only two items which return a string,= = and by specifying the length it avoids a potential buffer overrun. I changed it to read 3 retlen fixed bin(31) initial (31), but am still getting SS$_ACCVIO. I also tried lenth 12, which is what I= am expecting. -- = PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 13 Nov 2007 08:28:32 -0800 From: "Tom Linden" Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: On Tue, 13 Nov 2007 04:44:47 -0800, VAXman- <@SendSpamHere.ORG> wrote: > In article , "Tom Linde= n" = > 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. >> >> Anyone have experience with this call? I am not convinced it >> works as documented. > > I have been using both without any issues. > > First off, if you've received 12 (^x0C) back from SYS$GRANT_LICENSE, t= hat > is an ACCVIO. I would suspect that you have something amuck in your i= tem > list being passed to SYS$GRANT_LICENSE. > > Tom here a simple bit of Macro that invokes SYS$GRANT_LICENSE. Change= = > the > PRODUCT, PRODUCER, MY_TOKEN and MY_HW_ID values as needed. This shows= = > how > to get the TOKEN and HW_ID and then what to do with that info once it = has > been obtained. > > > ;++ > ; Copyright 2007 Brian Schenkenberger > ; You know what you need to do if you want to use it. > ;-- > > $LMFDEF > $LICENSEDEF > > .PSECT DATA,WRT,NOEXE,5 > > LMFITM: .WORD LMF$K_VERSIONLEN,LMF$_PROD_VERSION > .ADDRESS PRODUCT_VERSION,0 > .WORD LMF$K_TOKENLEN,LMF$_PROD_TOKEN > .ADDRESS PRODUCT_TOKEN,TOKEN_LENGTH > .WORD LMF$K_HW_IDLEN,LMF$_HW_ID > .ADDRESS PRODUCT_HW_ID,HW_ID_LENGTH,0 > > PROD_VERSION: .WORD minor,major ; Vmajor.minor > PROD_TOKEN: .LONG 0[+1] ; retrieved token string > TOKEN_LENGTH: .LONG 0 ; retrieved token length = > PROD_HW_ID: .LONG 0[+1] ; retrieved HW ID string > HW_ID_LENGTH: .LONG 0 ; retrieved HW ID length > Brian, Are the strings 0 terminated? If, e.g., LMF$K_TOKENLEN =3D 4 does that = mean the returned string is length 5? > CONTEXT: .LONG 0[16] > > PRODUCER: .ASCID "TOM_LINDEN" > .ALIGN LONG > > PRODUCT: .ASCID "TOMS_PROD" > .ALIGN LONG > > MY_HW_ID: "whatever HW ID" > > MY_TOKEN: "whatever TOKEN" > > .PSECT CODE,NOWRT,EXE,5 > .ENTRY DEMO_FOR_TOM,0 > > $GRANT_LICENSE_S - ; invoke $GRANT_LICENSE > PRDNAM =3D PRODUCT,- > PRDUCER =3D PRODUCER,- > CONTXT =3D CONTEXT,- > ITMLST =3D LMFITM > BLBS R0,10$ > RET > > 10$: MOVAB MY_TOKEN,R0 > MOVZWL R0,R0 > MOVZWL TOKEN_LENGTH,R2 > MOVAB PROD_TOKEN,R3 > CMPC5 R0,(R1),#0,R2,(R3) > BEQL 20$ ; if both strings equal, TOKEN OK > > MOVL #LICENSE$_INVALID_TOKEN,R0 ; return bad token > RET > > 20$: MOVAB MY_HW_ID,R0 > MOVZWL R0,R0 > MOVZWL HW_ID_LENGTH,R2 > MOVAB PROD_HW_ID,R3 > CMPC5 R0,(R1),#0,R2,(R3) > BEQL 30$ ; if both strings equal, HW_ID= OK > = > MOVL #LICENSE$_INVALID_HW_ID,R0 ; return bad HW ID > RET > > > 30$: ; rest of your program... > > > RET > .END DEMO_FOR_TOM > > > > Disclaimer: It's early in the morning. I had a really bad night's = > sleep, > I have a whopper of a headache and I have not had enough caffeine yet.= > -- = PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 13 Nov 2007 18:02:48 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: In article , "Tom Linden" writes: > > >On Tue, 13 Nov 2007 04:44:47 -0800, VAXman- <@SendSpamHere.ORG> wrote: > >> In article , "Tom Linde= >n" = > >> 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. >>> >>> Anyone have experience with this call? I am not convinced it >>> works as documented. >> >> I have been using both without any issues. >> >> First off, if you've received 12 (^x0C) back from SYS$GRANT_LICENSE, t= >hat >> is an ACCVIO. I would suspect that you have something amuck in your i= >tem >> list being passed to SYS$GRANT_LICENSE. >> >> Tom here a simple bit of Macro that invokes SYS$GRANT_LICENSE. Change= > = > >> the >> PRODUCT, PRODUCER, MY_TOKEN and MY_HW_ID values as needed. This shows= > = > >> how >> to get the TOKEN and HW_ID and then what to do with that info once it = >has >> been obtained. >> >> >> ;++ >> ; Copyright 2007 Brian Schenkenberger >> ; You know what you need to do if you want to use it. >> ;-- >> >> $LMFDEF >> $LICENSEDEF >> >> .PSECT DATA,WRT,NOEXE,5 >> >> LMFITM: .WORD LMF$K_VERSIONLEN,LMF$_PROD_VERSION >> .ADDRESS PRODUCT_VERSION,0 >> .WORD LMF$K_TOKENLEN,LMF$_PROD_TOKEN >> .ADDRESS PRODUCT_TOKEN,TOKEN_LENGTH >> .WORD LMF$K_HW_IDLEN,LMF$_HW_ID >> .ADDRESS PRODUCT_HW_ID,HW_ID_LENGTH,0 >> >> PROD_VERSION: .WORD minor,major ; Vmajor.minor >> PROD_TOKEN: .LONG 0[+1] ; retrieved token string >> TOKEN_LENGTH: .LONG 0 ; retrieved token length = > >> PROD_HW_ID: .LONG 0[+1] ; retrieved HW ID string >> HW_ID_LENGTH: .LONG 0 ; retrieved HW ID length >> > >Brian, >Are the strings 0 terminated? If, e.g., LMF$K_TOKENLEN =3D 4 does that = >mean >the returned string is length 5? This being VMS, I would tend to say NO to the null terminated string! You will receive a length (1 word in size) which, in conjunction with the address of the TOKEN string storage, could be used as a VMS string descriptor. See the diagram below. +-----------------+-----------------+ | LMF$_PROD_TOKEN | LMF$K_TOKENLEN | +-----------------+-----------------+ .--| PRODUCT_TOKEN |---------------. | +-----------------+-----------------+ | .--|--| TOKEN_LENGTH | | | | +-----------------+-----------------+ | | | | | | | | `->PRODUCT_TOKEN: .LONG 0[+1] | `---->TOKEN_LENGTH: .LONG 0 | | | | | DSC$K_ DSC$K_ | | +--------+--------+-------v---------+ | |CLASS_S |DTYPE_T | --- | | +-----------------+-----------------+ | | <---------|---------------' +-----------------+-----------------+ I haven't drawn ASCII data structures in a VMS newsgroup in ages. -- 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: Tue, 13 Nov 2007 18:06:25 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: In article , "Tom Linden" writes: > > >On Tue, 13 Nov 2007 05:49:16 -0800, John Reagan wro= >te: > >> VAXman- @SendSpamHere.ORG wrote: >>> In article , "Tom = > >>> Linden" writes: >> >>> 2 hw_id, >>> 3 length fixed bin(15) initial (lmf$k_hw_idlen), >>> 3 item fixed bin(15) initial (lmf$_hw_id), >>> 3 bufadr pointer initial (addr(hardware_id)), >>> 3 retlen fixed bin(31) initial (0), <=3D=3D=3D= ><<< (*) >>> SYS$GRANT_LICENSE will want to return the length of the retrieved HW= > = > >>> ID. >>> (*) Is this specified properly? Sorry, my PL/I is rusty. >>> >> >> Bingo! HW_ID & PROD_TOKEN want to return their length. You can't say= > = > >> "don't bother" like you can with other item-based services. I just = > >> checked the source to verify that behavior. Why? No clue. I didn't s= >ee = > >> a real need to be "different" but that is the way it is coded. > >It could be becaused these are the only two items which return a string,= > = > >and >by specifying the length it avoids a potential buffer overrun. > >I changed it to read > > 3 retlen fixed bin(31) initial (31), > >but am still getting SS$_ACCVIO. I also tried lenth 12, which is what I= > am >expecting. Where are you storing the return length? 3 retlen pointer initial (addr(return_length)) is what you want and then initialize the storage location 'return_length' to 0. -- 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: Tue, 13 Nov 2007 03:42:29 -0800 From: issinoho Subject: VAMP back online Message-ID: <1194954149.580043.212610@v3g2000hsg.googlegroups.com> VAMP is back on-line at the usual address (http://vamp.issinoho.com) I moved house about 6 months ago and have only recently got my broadband back, and even more recently got a static IP. At present it is running under Windows as I've yet to recommission my Alpha, however I felt the resource was worth having in the meantime. ------------------------------ End of INFO-VAX 2007.622 ************************