[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

622.0. "F$GETQUI loop !" by TAV02::ZVI_P (Here we are) Wed May 21 1997 05:58

Hi
  A customer just sent me an interesting DCL, f$getqui case:

  For some unknown reason they define a system logical name identical to
a generic queue name. 
 
  When they run a DCL procedure that checks queues status on their system
it loops forever on that logical name.

Here is a log of that case:

$!*  A dcl procedure

$ type x.com
$ !  p1 = 0 show queue names
$ !       1 check queue status
$ !
$ loop:
$    que= f$getqui("display_queue","queue_name", "*")
$    if que .eqs. "" then $exit
$    sho symb que
$    if .not. p1 then goto loop
$!
$!    *** This 2nd f$getqui causes the problem - the context is corrupted.
$!
$    isstopped = f$getqui("display_queue","queue_stopped",que,"freeze_context")
$    goto loop
$

$! print jsut queue names

$ @x 0
  QUE = "FL6$LN05"
  QUE = "LR"
  QUE = "LSA11"
  QUE = "LSA11_GEN"
  QUE = "SYS$BATCH"
  QUE = "UCX$SMTP_ORTAL_00"
  QUE = "UCX$SMTP_ORTAL_01"

$!*  problem demonstartion:

$ @x 1
  QUE = "FL6$LN05"
  QUE = "LR"
  QUE = "LSA11"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"
  QUE = "LSA11_GEN"

 Interrupt

$

			Thanks
			Zvi  


T.RTitleUserPersonal
Name
DateLines
622.1Looks Like They Did It To Themselves...XDELTA::HOFFMANSteve, OpenVMS EngineeringWed May 21 1997 10:0810
:  For some unknown reason they define a system logical name identical to
:a generic queue name. 
:  When they run a DCL procedure that checks queues status on their system
:it loops forever on that logical name.

   Then the logical name will "redirect" the queue name.

   You can try a QAR, but I would not expect much sympathy. 

622.2bug; two workaroundsAUSS::GARSONDECcharity Program OfficeWed May 21 1997 20:4329
    re .*
    
    This seems like a bug. However .1 may be right that you will not get
    a fix.
    
    Question: Why is it necessary to specify the queue name at all when
    FREEZE_CONTEXT is specified? It does not seem logical that it is
    required (but maybe I overlooked something) and not specifying it
    should avoid the problem. An *apparent* workaround is to specify "*" in
    the second f$getqui() call for the queue name. This makes some kind of
    sense.

    Failing that, either FREEZE_CONTEXT should not translate logical names
    (?) or an option should be available to suppress logical name
    translation.
    
    A general workaround is to include the following line before the second
    f$getqui()
    
    $ assign/user/trans=term 'que 'que
    
    and the following line after the second f$getqui()
    
    $ deas/user 'que
    
    Note that you get an infinite loop in the unmodified procedure because
    the logical name is alphabetically higher than the equivalence name. If
    the reverse were true then you would miss out on some queues but at
    least you wouldn't loop. (-: