MACRO 32 question

[marchunan]

Hi all,

This is Archunan. Happy contacting you all as a vsitor again after a long time. I need to learn this renamed forum ot use my previous userID.

I have a question on my MACRO 32 which currently runs on Itanium//OpenVMS 821. The purpose of this simple program is retreves few login sysgem paramter values for reporting purpose. All login parameter ITEM names are declared below in SYSGEN_ITMLST. The function KAN_CPX_SYSGEN moves all the itemlist values ( GETSYIW routine has been called above ) to R6. Please see the descriptor details.

Few related code snagit

ACCOUNT_STRING: .BLKB   UAF$S_USERNAME          ; Generic account name

                .LONG   0

ACCOUNT_INFO:   .BLKB   1024                    ; Generic account information

                .LONG   0

ACCOUNT_INFO1:  .LONG   8                   ; Generic account information

GETSYI:

                $GETSYIW EFN=WEFN,ITMLST=SYSGEN_ITMLST1

SYSGEN_ITMLST:

        ITMLST  4,SYI$_LGI_BRK_LIM,LGI_BRK_LIM,0.

        ....

        .LONG   0                               ;END OF LIST

SYSGEN_ITEMS_TABLE:

        .ADDRESS LGI_BRK_LIM

        .ADDRESS LGI_BRK_LIM_TEXT

        .ADDRESS LGI_BRK_LIM_DSC

        ......

SYSGEN_ITEMS_TABLE_SIZE = <.-SYSGEN_ITEMS_TABLE>/12

LGI_BRK_LIM_TEXT:       .ASCID  /LGI_BRK_LIM/

LGI_BRK_LIM_DSC:        .ASCID  ! (Brklim) / Login Breakin count!

...

ASCII_NUM_DSC:  .WORD   12

                .BYTE   DSC$K_DTYPE_T

                .BYTE   DSC$K_CLASS_S

                .ADDRESS ASCII_NUMBUF

ASCII_NUMBUF:   .BLKB   12

:The function which retrieves the breakin limit....

.ENTRY  KAN_CPX_SYSGEN,^M<R2,R3,R4,R5,R6,R7,R8,R9>

        MOVAL   SYSGEN_ITEMS_TABLE,R6   ;GET TABLE OF ITEMS TO REPORT

        MOVL    #SYSGEN_ITEMS_TABLE_SIZE,R7

20$:

        PUSHAQ  ASCII_NUM_DSC           ;RESULTANT STRING DESCRIPTOR

        PUSHL   (R6)+                   ;GET VALUE

        CALLS   #2,G^OTS$CVT_L_TI       ;CONVERT LOGIN FAILURES

        BLBC    R0,30$

        MOVL    (R6)+,R2                ;GET ITEM DESCRIPTOR

        MOVZWL  (R2),R0

        MOVL    4(R2),R1

        MOVC3   R0,(R1),ACCOUNT_STRING  ;COPY ITEM NAME

        CLRB    (R3)                    ;NULL TERMINATE

        MOVZWL  ASCII_NUM_DSC,R0

        MOVL    ASCII_NUM_DSC+4,R1

        MOVC3   R0,(R1),ACCOUNT_INFO    ;COPY VALUE

        MOVL    (R6)+,R2                ;GET DESCRIPTION

        MOVZWL  (R2),R0

        MOVL    4(R2),R1

        MOVC3   R0,(R1),(R3)            ;APPEND DESCRIPTION

        CLRB    (R3)                    ;NULL TERMINATE

        ............................................................... <New code> to be added (given below) to test the value in ACCOUNT_INFO. 

        CALLS   #3,RPT_LOGIN_BRK           ;routine to report the ITM lists values

        SOBGTR  R7,20$                  ;DO NEXT ONE...

        MOVZWL  #SS$_NORMAL,R0

        RET

30$:

        MOVL    R0,R2                   ;SAVE ERROR

        PUSHL   #0

        PUSHAB  OTSCVT_MSG              ;SEND MESSAGE

        PUSHL   R0                      ;SEND ERROR CODE

        PUSHL   #0

        CALLS   #4,G^SYSERR_RPT         ;REPORT ERROR

        MOVL    R2,R0                   ;RESTORE ERROR

        RET

<FF>

My question is that I would like to test & report only when LGI_BRK_LIM value is > 5. I tested this with the following code... 

<New code>

      MOVAL   ASCII_NUM_DSC,R0

      MOVZBL  (R0),R1                                ; len of buf string, converted into dec

      MOVL    4(R0),R0                                ; get buf address

      MOVC3   R1,(R0),ACCOUNT_INFO1  ; move "           6" to the descriptor ACCOUNT_INFO1

      .........?                                      Here I need to COMP (or SUB) integer 5 from with the value in ACCOUNT_INFO1. I tried OTS$ routine to convert,  "           6" to integer, but still CMP returns always greater than 5. Seems there are some junk characters in the descriptor

      BGTR    26$

      RET

26$:

      call to Report program

      Ret

Thanks

Archie

[Steven Schweda]

> [...] MACRO 32 [...]

   WHY?  (If doing things the hard way causes problems, then why not try
the easy way?)

   I don't know enough Macro 32 to do anything, but I can't see your
call to $GETSYI.

   If you want the integer value returned by $GETSYI, then why are you
converting it into a string using OTS$CVT_L_TI ?

> I tried some unsuccesful ways to extract this string 5 as a number for
> comparison.

   Wasn't it a number before you started playing with it?

[abrsvc]

The code shown is oncomplete, but I'd agree with Steven.  You already have the value prior to the conversion to a sring.  Perhaps the string form is needed for the output, but save the initial value in a register that is not used and test for thatt later.  For example, something like this:

                Movzbl (r6),r10

                remaining code to convert to strings (account info)

               cmpb R10,#5

                BLEQ 10$

                calls #3, reporting routine

10$:

[Hoff]

Please post your complete example.  It appears the do-not-care event flag isn't being used here, for instance, and there does not appear to be an IOSB specified and verified.  If you're seeking to learn Macro32, then there are various other coding errors here, in other words.

Is there a reason why a language as primitive and comparatively expensive as assembler is in use here?  (It'd be more effective rewrite this sequence in C than to debug this case, this even given C isn't all that much better than assembler in terms of its maintenance and features.  (This usually implies you're not doing this assembler work commercially, or that there's a large base of Macro32 here and no plans to migrate.)  

If you're working in a business environment that lacks access to compilers, then python, Perl, DCL or one of the other "free" languages would be a more effective use of your time.  (I would hesitate to suggest Bliss, but that's also free.)  The DCL lexical functions including f$getsyi can fetch these details, for instance.

There's C code to fetch various information from SYSUAF using $getsyiw calls in this C source code library, too.

There are other source code examples around.

And OpenVMS I64 V8.2-1? That's a very old and rather sketchy release; is there a reason why you're using that release and not something more current?  There are latent errors in the older versions of the Macro32 compiler on OpenVMS I64.

[John Gillings]

Archunan,

   I'm a bit confused by your problem description. You say you want to test LGI_BRK_LIM? It appears you have a variable called LGI_BRK_LIM referenced in the item list for $GETSYI (there is no definition for the macro ITMLST, so I can't be certain).

If that's the case, the code should be

CMPL LGI_BRK_LIM,#5

BLEQ SkipReport

... code for report

Most of the complexity here seems to involve conversions, formatting and building output strings. I find the easiest way to deal with this in MACRO32 is using $FAO.

[marchunan]

Steven, I have called $GETSYI before come to this procedure and got the required sysgen values. And as you suggesed I tested the values before converting also. Thanks Steven.

[marchunan]

It should work as per the suggested code, but I see CMP didn't work as R10 didn't have correct value. Thanks abrsvc

[marchunan]

Hi Hoff, thanks for your response. This is very huge applciation. the initial developer is one of the greatest VMS programmer on my view. I wonder seeing his code. He must be from DEC engg team or DEC engg team have helped him from the shoulder.We don't have any idea of converting to C. V8.2-1 is my build server and I use this version as per HP eng. suggestion.

[marchunan]

Sorry for the delayed response. somehow the issue been resolved and I completed the build also.

Thanks John, Steven, Hoff, & abrsvc.

I didn't past the itmlst declaration, desc, getsyi call,,,. tested SYI$_LGI_BRK_LIM, but somehow I miss moving the getsyi return values properily between stack and register on the calls to $GETSYI, LIB$TRAVERSE_TREE, and $FAO. And I had difficulties looking into the register values during the debug. Anyway the issue been resolved with the help of quick small c program call.

Thanks to everyone for your valuable time.

Thanks
Archunan

[marchunan]

This issue has been resolved, I don't know how to close this topic. I will close shortly.