|
HP OpenVMS Systemsask the wizard |
|
The Question is:
We've been using an utility written in macro for a long time. Now we have
upgraded to OpenVMS 7.3-1, and when we try to link it we get this error mesagge:
$link getproclocks,GETPRLOCK_DEFS
%LINK-W-NUDFSYMS, 3 undefined symbols:
%LINK-I-UDFSYM, EXE$CVT_EPID_TO_PCB
%LINK-I-UDFSYM, LKB$L_OWNQFL
%LINK-I-UDFSYM, PCB$L_LOCKQFL
%LINK-W-USEUNDEF, undefined symbol EXE$CVT_EPID_TO_PCB referenced
in psect $LINKAGE offset %X00000080
in module GETPROCLOCKS file
PTECDISK:[PTEC.BDAT.CSUAREZ.UTILES]GETPROCLOCKS.OBJ;1
%LINK-W-USEUNDEF, undefined symbol PCB$L_LOCKQFL referenced
in psect $LINKAGE offset %X00000090
in module GETPROCLOCKS file
PTECDISK:[PTEC.BDAT.CSUAREZ.UTILES]GETPROCLOCKS.OBJ;1
%LINK-W-USEUNDEF, undefined symbol LKB$L_OWNQFL referenced
in psect $LINKAGE offset %X00000098
in module GETPROCLOCKS file
PTECDISK:[PTEC.BDAT.CSUAREZ.UTILES]GETPROCLOCKS.OBJ;1
Seems to me that these routines (PCB$L_LOCKQFL, LKB$L_OWNQFL) are no longer
available, maybe they were replaced by new ones or placed in another object
library.
Is this so? Which are the new routines? How do I call them?
Thanks for your time.
Rgds,
Carlos
ps.: here is the source code of the macro programs involved:
$type getprlock_defs.mar
..TITLE GETPRLOCK_DEFS
..LIBRARY "SYS$LIBRARY:LIB.MLB"
$LKBDEF GLOBAL
$PCBDEF GLOBAL
..END
$type getproclocks.mar
.title getproclocks
.ident 'V1.1-0'
; This subroutine returns a list of lockids for a given process that are
; in waiting or granted state. This list is built without acquiring any
; synchronization so it can be wrong....
; There are several lines that need adjusting depending on whether this is a
; VAX or an Alpha. These lines can be found by searching for ###
; Aplha Build Instructions
; $ macro/mig getproclocks
; $ link/sysexe getproclocks
; Vax Build Instructions
; Change lines as required for VAX
; $ macro getproclocks
; $ link getproclocks,sys$input:/opt
; sys$system:sys.stb/sele
; ^Z
; ### VAX Comment the next line out
.link 'sys$loadable_images:process_management.stb' /selective_search
.library 'sys$share:lib.mlb'
$ssdef
$lkbdef
$pcbdef
.psect _data,wrt,noexe
buffer: .long 0
buflen: .long 0
pid: .long 0
fail: .long 0
prompt: .ascid 'Enter PID: '
result: .ascid ' '
bb: .blkb 512
symnum: .ascid 'lockcnt'
symnumval: .ascid '00000000'
symdsc: .ascid 'lock0000'
symdsc_2: .quad 0
symval: .ascid ' '
nodename: .blkb 32
nodename_l: .long 0
syi_itms: .word 32
.word SYI$_NODENAME
.address nodename
.address nodename_l
.long 0
.psect _code,nowrt,exe
.entry getproclocks,^m<r2,r3,r4,r5,r6,r7>
; 4(ap) lv pid
; 8(ap) ala pointer to memory to receive list
; 12(ap) lv number of entries that fit in list
cmpl (ap),#3
beql 8$
movl #ss$_insfarg,r0
4$: ret
8$:
; Check system is valid node.
The Answer is : Please use LINK/SYSEXE (and often also /NOSYSLIB) when linking against the OpenVMS kernel structures. The provided example was incomplete, and the OpenVMS Wizard cannot confirm that the LINK command was the error. Additionally, the LKB$L_OWNQFL and PCB$L_LOCKQFL cells were promoted from longword ($L) to quadword ($Q) entries; to LKB$Q_OWNQFL and PCB$Q_LOCKQFL. You may (will) need to modify your code accordingly. $ search sys$share:*.req _OWNQFL,_LOCKQFL macro LKB$Q_OWNQFL = 112,0,0,1 %; literal LKB$S_OWNQFL = 8; ! Owner queue forward link macro PCB$Q_LOCKQFL = 872,0,0,1 %; literal PCB$S_LOCKQFL = 8; ! Lock queue forward link If you require assistance in porting code or in obtaining alternatives to existing kernel-mode hacks, please contact HP Services for assistance.
|