[Info-vax] Listeners in VMS Basic, was: Re: Integrity iLO Configuration?

Dave Froble davef at tsoft-inc.com
Tue Jul 13 13:21:52 EDT 2021


On 7/13/2021 10:47 AM, Stephen Hoffman wrote:
> On 2021-07-12 23:12:57 +0000, Dave Froble said:
>
>> On 7/12/2021 4:16 PM, Stephen Hoffman wrote:
>>> On 2021-07-09 23:45:31 +0000, Dave Froble said:
>>>
>>>> Just because some agree, doesn't make them right.
>>>>
>>>> But, Ok, a practical example, tell me, too many comments, not enough
>>>> comments, what?
>>>>
>>>> ;+
>>>> ;       Base block must be > 0
>>>> ;       # of blocks must be > 0 & < 128
>>>> ;       End block must be <= EOF block
>>>> ;       Grant lock if caller has exclusive access to the file
>>>> ;-
>>>>
>>>> MOVZWL  #SS$_ABORT,R0           ; Assume failure
>>>> TSTL    R3                      ; Base block zero?
>>>> BNEQU   020$                    ; No, continue
>>>> 010$:   BRW     RETURN                  ; Yes, return
>>>> 020$:   TSTL    R4                      ; Block count zero?
>>>> BEQLU   010$                    ; Yes, return
>>>> CMPL    #127,R4                 ; Block count <= 127
>>>> BLSSU   010$                    ; No, return
>>>> MOVAB   -1(R3)[R4],R5           ; Last block to lock
>>>> CMPL    CIB_L_FILSIZ(R7),R5     ; LE filesize?
>>>> BGEQU   030$                    ; Yes, continue
>>>> MOVL    CIB_L_FILSIZ(R7),R5     ; Else lock only to EOF
>>>
>>>
>>> BLEQU, not BLSSU? Or BLSSU with 128?
>>>
>>> I'd suggest using a string constant for 127 (or 128) rather than a
>>> magic number, too.
>>>
>>
>> Now I'm sorry I started this ...
>>
>> Ok, could you expound upon your comments?  I'm totally not understanding.
>>
>> This particular code is from 1984, and written by Ben Carter, a much
>> better Macro-32 programmer than I have ever been.
>
> Yeah, ignore my previous, I'm mis-reading the code; the CMPL.
>
> The control flow in this Macro32 is not what I'd choose. I prefer errors
> to be branches or RSBs or RETs, with mainline flow straight through.
>
>
> CIB_K_IOLIM = 128
>
> ; R3 block address
> ; R4 block count
> ; R5 address + count - 1
> ; R7 file context block
>
> {following branch located somewhere within BRB range, but interstitial}
> 010$:
>    BRW          RETURN                          ; helper branch for the
> exit {would prefer a RET here}
>
> ENTRY:
>    MOVZWL #SS$_ABORT,R0           ; Assume failure
>    TSTL         R3                                       ; block address
> zero?
>    BEQLU     010$                                  ; Yes, exit via
> helper BRW
>    TSTL         R4                                       ; block count
> zero?
>    BEQLU     010$                                  ; yes, done, return
>    CMPL       #CIB_K_IOLIM,R4         ; limit <= block count?
>    BLEQU     010$                                  ;  Yes, exit via
> helper BRW
>    MOVAB    -1(R3)[R4],R5                 ; address of last block to lock
>    CMPL       CIB_L_FILSIZ(R7),R5   ; filesize < address of last block?
>    BGEQU    030$                                  ; Yes, continue
>    MOVL       CIB_L_FILSIZ(R7),R5  ; Else lock only to the EOF
>    ...
> 030$: ...
>
>
> {It seems the original code is storing an address in a field named
> filesize. Which is weird.}

For grins I went back and read some of the code.

CIB stands for channel information block, and there is a block for each 
open channel.  So the filesize of the file open on that channel seems to 
be relevant.

As for storing an address, even with my greatly diminished Macro-32 
skills, I don't see that.  Perhaps the comment is misleading.  The block 
number (address) for the last block to lock is moved to R5, then if the 
value of R5 is greater than the last block in the file, the value of the 
last block in the file is moved to R5.

Perhaps it's just my illiteracy in C, but I find the code in this old 
database product rather easy to read.  To be fair, being the architect 
of the product might play some part in understanding what's going on.

:-)

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486



More information about the Info-vax mailing list