  Performance profiling, memory management? 
 The Question is:
 
1. ALPHA-PC DECNET communication
The real-time communication is often used in our applications between ALPHA
and PC, But sometimes the prompt "PIPE BROKEN", so the user often ask me
Why? The communication protocol is PATHWORK(on PC) or UCX generally. I want
to solve this problem for user
 radically, would you like to give me a suggestions?
 
 
2. Real  timer
Previously, my formerly staff used a timer program to check that every
modules cost times in a real-time program ON VAX . There is problems when I
use the same timer program to check the same modules ON ALPHA. can you help
me to solve it?
TIMER.MAR
        .title  timer
        .psect  meastime,pic,con,rel,lcl,noshr,exe,rd,wrt,long
        $IPLDEF
        $pr780def
timer:: .word   0
        $cmkrnl_s       get
        movl    r0,@4(ap)
        ret
get:    .word   0
        mfpr    #pr$_ipl,(sp)+
        setipl  #ipl$_hwclk
        mfpr    #pr780$_icr,r0
        subl2   #-&lt;10*1000&gt;,r0
        mull2   #10,r0
        addl2   g^exe$gq_systime,r0
        setipl  -(sp)
        ret
        .end
The command procedure as follows:
        $MAC TIMER.MAR+SYS$LIBRARY:LIB.MLB/LIB
 
when I try to solve the problem modify source timer and command procedure as
follows ON ALPHA:
TIMER.MAR
.title  timer
         .psect
meastime,pic,con,rel,lcl,noshr,exe,rd,wrt,long
        $IPLDEF
        $prdef
        .macro  timer timer,get
timer:: .word   0
        $cmkrnl_s       get
        movl    r0,@4(ap)
        ret
get:    .word   0
        mfpr    #pr$_ipl,(sp)+
        setipl  #ipl$_hwclk
        mfpr    #pr780$_icr,r0
        subl2   #-&lt;10*1000&gt;,r0
        mull2   #10,r0
        addl2   g^exe$gq_systime,r0
        setipl  -(sp)
        ret
;       .endm
        .end
The command procedue as follows:
   $Mac/mig/deb/flag=all
TIMER.MAR+SYS$LIBRARY:LIB.MLB/LIB+ -
        alpha$library:starlet/lib+ -
        alpha$library:arch_defs.mar
the compiler and link is OK, but when I run test
program arise problems
 
3.  Lock Page
In my a real-time program, my formerly staff used a LOCK PAGE program to
reduce the exchange time between program or data and DISK. The rotine as
follows:
LOCKPAGE.MAR
        .TITLE LOCK_WS_MAC
        .PSECT $$$$$A,NOWRT,NOEXE,NOVEC
START_OF_PROG::
 
        .PSECT _____Z,WRT,EXE,VEC
END_OF_PROG::
        .END
 
INIT_APP.FOR
        integer*4 I_ACOMON_START
        integer*4 I_ACOMON_END
        COMMON/COM000/I_ACOMON_START
        COMMON/COM999/I_ACOMON_END
 
        EXTERNAL START_OF_PROG,END_OF_PROG
 
 
COMMON_LENGTH=%LOC(I_ACOMON_END)-%LOC(I_ACOMON_START)+4
        INADR(1)=%LOC(START_OF_PROG)
        INADR(2)=%LOC(END_OF_PROG)+COMMON_LENGTH
        ISTAT=SYS$LCKPAG(INADR,RETADR,)
 
My question is:
     a. There are many process or mudule and common data in the
applications, how to check if the pages(or memory) are locked ?
     b. If I want to migrate the program to Windows NT, How can I do? The
event flag(EF) is often used in the OpenVMS system, is there any substitute
method to solve this problem?
     c. Would you like to give me suggestion if I want to migrate the
application to windows NT?
 
thank you very much!
 
 
 The Answer is:
 
  First, please realize that "real-time" is effectively meaningless -- that
  phrase can have as many different meanings as there are participants in a
  particular discussion.  Specific information on the timing and the latency
  requirements can be and is of central interest in determining the particular
  "real-time" approach(es) and options that are available.
 
  Please contact the Compaq Customer Support center for the "PIPE BROKEN"
  error, as additional details on the configuration, product version(s),
  ECO levels, and such will be required.  Start with an upgrade to the
  current ECO and version levels, however.
 
  The usual approach for timing code involves the use of the LIB$STAT_TIMER,
  LIB$SHOW_TIMER, and related calls.  For lower-level system cycle counters
  (rpcc, rscc) on OpenVMS Alpha, please see topic 2734 here in Ask The Wizard.
 
  The locking of pages is seldom actually required, particularly when the
  system is configured with memory appropriate for the task.  (With the
  ability of most Alpha systems to support a gigabyte (and often more) of
  physical memory and with the far higher speed of Alpha processes, most
  VAX application ports are not lacking for available physical memory or
  processor performance.  That said, Alpha systems tend to have far better
  performance with available physical memory configured, and Alpha systems
  tend to be rather more sensitive to this than OpenVMS VAX systems.  (The
  locking of memory tends to be a workaround for a memory-constrained system,
  or for an application with extreme performance constraints.)
 
  When locking is required (usually either due to extremely high performance
  requirements, or due to extremely low latency requirements), the existing
  OpenVMS system services for locking pages of memory into physical memory
  ($LCKPAG) as well as the oft-prefered locking of the pages into the working
  set ($LKWSET) are available.  Information on the operation of these calls
  is available in the OpenVMS documentation.  Information on the status of
  pages of memory is available using the ANALYZE/SYSTEM SHOW PAGE command.
  Memory-resident sections are also available in the traditional process
  virtual address space, as well as in the process portion of 64-bit space.
 
  Discussions of Windows NT are outside the purview of the OpenVMS Wizard.
 
