From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 20-SEP-1993 21:33:55.26 To: EVERHART CC: Subj: $GETLKI and LKI$_LOCKS problem X-Newsgroups: comp.os.vms Subject: $GETLKI and LKI$_LOCKS problem Message-ID: <1993Sep20.170627.1@nl101.ittpub.nl> From: ptdsc_hv@nl101.ittpub.nl (Hans van Veen - ITT Publitec) Date: 20 Sep 93 17:06:27 WET+0100 Organization: ITT Publitec R+D BV, Amsterdam Nntp-Posting-Host: nl103 Nntp-Posting-User: pmiss_ao Lines: 394 To: Info-VAX@KL.SRI.COM X-Gateway-Source-Info: USENET BEWARE: SYS$GETLKI and VMS V5.5/V6.0 Any programs using the $GETLKI system service, AND using the LKIDEF structure defined in SYS$SHARE:STARLET.MLB or SYS$SHARE:FORSYSDEF.TLB (LKIDEF.H is -still- OK), might get in trouble when relinking the program(s). The size of the LKIDEF structure in the libraries mentioned above has changed. Digital added 4 quadwords to the structure, but $GETLKI is not yet aware of this. So any call to $GETLKI using the Digital defined structure, will still get you your information, but completly mis-aligned. Here's my question to Digital, and their response; After relinking a program which uses $GETLKI and LKI$_LOCKS, I discovered a somewhat nasty change to the definition of the LKIDEF structure in both SYS$SHARE:STARLET.MLB and FORSYSDEF.TLB (LKIDEF.H is -still- OK). The changes to LKIDEF are marked with: "==>" !*** MODULE $LKIDEF *** ! + ! ! Get Lock Information Data Identifier Definitions ! ! **** NOTE **** ! ! New items must always be added to the END of each item list ! (preceeding the ENDlistname item) so that users will not have ! to relink. ! - ! ITEM LIST BLOCKS PARAMETER LKI$K_LENGTH = '00000018'X ! LENGTH OF LIST BLOCK WITHOUT BYTE RANGEINFO PARAMETER LKI$C_LENGTH = '00000018'X ! LENGTH OF LIST BLOCK WITHOUT BYTE RANGEINFO ==> PARAMETER LKI$K_BR_LENGTH = '00000038'X ! LENGTH OF LIST BLOCK WITH BYTE RANGE INFO ==> PARAMETER LKI$C_BR_LENGTH = '00000038'X ! LENGTH OF LIST BLOCK WITH BYTE RANGE INFO ! ** TSKID longword unsigned; /* TASK ID (Latent support FOR MULTITASK) STRUCTURE /LKIDEF/ UNION MAP INTEGER*4 LKI$L_MSTLKID ! LOCK ID ON MASTER END MAP MAP INTEGER*4 LKI$L_LOCKID ! OLD SYMBOL END MAP END UNION INTEGER*4 LKI$L_PID ! PROCESS ID UNION MAP INTEGER*4 LKI$L_MSTCSID ! CSID OF MASTER END MAP MAP INTEGER*4 LKI$L_SYSID ! OLD SYMBOL END MAP END UNION BYTE LKI$B_RQMODE ! REQUEST MODE BYTE LKI$B_GRMODE ! GRANTED MODE BYTE LKI$B_QUEUE ! LOCK QUEUE BYTE %FILL ! SPARE BYTE UNION MAP INTEGER*4 LKI$L_LKID ! LOCK ID ON PROCESS NODE END MAP MAP INTEGER*4 LKI$L_REMLKID ! OLD SYMBOL END MAP END UNION UNION MAP INTEGER*4 LKI$L_CSID ! CSID OF PROCESS NODE END MAP MAP INTEGER*4 LKI$L_REMSYSID ! OLD SYMBOL END MAP END UNION ==> INTEGER*4 LKI$Q_RQSTART(2) ! REQUEST RANGE START ==> INTEGER*4 LKI$Q_RQLENGTH(2) ! REQUEST RANGE LENGTH ==> INTEGER*4 LKI$Q_GRSTART(2) ! GRANTED RANGE START ==> INTEGER*4 LKI$Q_GRLENGTH(2) ! GRANTED RANGE LENGTH ! ** constant "MT_LENGTH" equals . prefix LKI$ tag K; /* LENGTH OF LIST BLOCK ! ** /* WITH MULTITASK INFO. ! ** constant "MT_LENGTH" equals . prefix LKI$ tag C; /* LENGTH OF LIST BLOCK ! WITH MULTITASK INFO. . . . . (Skipped the rest) . . . Digital's reply Following article explains what happend..... (this is my interpretation - original was dutch) [OpenVMS] $GETLKI with LKI$_LOCKS Returns Wrong Size Record Structure COPYRIGHT (c) 1988, 1993 by Digital Equipment Corporation. ALL RIGHTS RESERVED. No distribution except as provided under contract. \------------------------------------------------------------------ \ Note to specialists at CSC/CS, CSC/AT, CSC/MA: \ \ If a customer experiences this problem and a resolution from \ engineering is not present, please record this with the CSCBUG \ facility using the command: \ \ $ CSCBUG COUNT CWPS-0009 srq_number \ \------------------------------------------------------------------ OP/SYS: OpenVMS VAX Versions 5.5, 5.5-1, 5.5-2, 6.0 NEW_5.5 COMPONENT: Cluster-wide Process Service Extension SOURCE: Digital Customer Support Center SYMPTOM: Programs using the $GETLKI system service with the LKI$_LOCKS item code may receive unexpected results in the return buffer. DIGITAL RESPONSE: This problem has been reported to OpenVMS VAX Engineering. ANALYSIS: The $GETLKI system service called with the LKI$_LOCKS item code returns multiple lock information in blocks of 24 bytes. A change in OpenVMS VAX V5.5 changed the size of the information block in the $LKIDEF structure definition module to be 56 bytes. If a program using $LKIDEF is relinked under OpenVMS VAX V5.5 or greater, the program code generated expects to find an array of 56 byte structure in the return buffer, but the system service still correctly returns 24 bytes per structure. WORKAROUND: Redefine the LKIDEF structure. To do this, extract the $LKIDEF module from the programming language definition file and remove the following fields: LKI$Q_RQSTART ! REQUEST RANGE START LKI$Q_RQLENGTH ! REQUEST RANGELENGTH LKI$Q_GRSTART ! GRANTED RANGE START LKI$Q_GRLENGTH ! GRANTED RANGE LENGTH Use this new structure definition to generate the program executable. \ \ \ ADDITIONAL INFORMATION: \ \ Included below a FORTRAN program that demonstrates this problem. Run this \ program from two different processes at the same time. It will \ display information about 2 locks on the object. \ \ To compile, link and run the program do the following: \ \ $ FORTRAN GETLKI \ $ LINK GETLKI \ $ RUN GETLKI \ \ -------------------------------------------------------------------------- \ PROGRAM GETLKI \ \ implicit integer*4 (a-z) \ \ integer*2 lk_list(12) \ integer*4 lk_item(6),lkid(2),iosb(2),stat \ integer*4 tot_size, lock_size \ character*1 char \ character*30 filenm,x \ \ include '($lckdef)' \ include '($lkidef)' ! Contains the structure LKIDEF \ \ C Use the lkidef structure definition for the call to $getlki. \ \ record /lkidef/ lki(3) \ \ C Create our own structure that looks like the older, 24 byte, definition. \ \ STRUCTURE /LKIDEF1/ \ UNION \ MAP \ INTEGER*4 LKI$L_MSTLKID ! LOCK ID ON MASTER \ END MAP \ MAP \ INTEGER*4 LKI$L_LOCKID ! OLD SYMBOL \ END MAP \ END UNION \ INTEGER*4 LKI$L_PID ! PROCESS ID \ UNION \ MAP \ INTEGER*4 LKI$L_MSTCSID ! CSID OF MASTER \ END MAP \ MAP \ INTEGER*4 LKI$L_SYSID ! OLD SYMBOL \ END MAP \ END UNION \ BYTE LKI$B_RQMODE ! REQUEST MODE \ BYTE LKI$B_GRMODE ! GRANTED MODE \ BYTE LKI$B_QUEUE ! LOCK QUEUE \ BYTE FILL ! SPARE BYTE \ UNION \ MAP \ INTEGER*4 LKI$L_LKID ! LOCK ID ON PROCESS NODE \ END MAP \ MAP \ INTEGER*4 LKI$L_REMLKID ! OLD SYMBOL \ END MAP \ END UNION \ UNION \ MAP \ INTEGER*4 LKI$L_CSID ! CSID OF PROCESS NODE \ END MAP \ MAP \ INTEGER*4 LKI$L_REMSYSID ! OLD SYMBOL \ END MAP \ END UNION \ END STRUCTURE \ \ RECORD/lkidef/lki1(3) \ \ equivalence (lk_list,lk_item) \ \ data filenm /'GETLKI.FOR '/ \ \ type * \ type *, ' * Start of lock pgm' \ \ stat = SYS$ENQW(,%val(LCK$K_NLMODE),lkid, \ * ,filenm,,,,,,) \ \ type *,' 1st enq stats : ',stat,lkid(1) \ type *,' lock id : ',lkid(2) \ \ type *,' Starting; will attempt to lock file GETLKI.FOR ' \ \ C \ C If the file is already locked, the SYS$ENQ will drop thru to \ C the SYS$GETLKI call. If SYS$ENQW is used, the ENQUE will \ C wait until the resource is free. SYS$ENQ is used here in this \ C example such that we may study the LKI$_BLOCKING information. \ C \ \ stat = SYS$ENQ(,%val(LCK$K_EXMODE),lkid,%val(LCK$M_CONVERT) \ * ,filenm,,,,,,) \ \ \ C Itemlist for SYS$GETLKIW \ \ lk_list(1) = 168 \ lk_list(2) = lki$_locks \ lk_item(2) = %loc(lki) \ lk_item(3) = i_notused \ lk_item(4) = 0 \ C \ C Get the BLOCKING information if the access to the resource \ C is blocked, otherwise, return all LKI$L_xxx values with \ C ZERO's in them. \ C \ \ STAT = SYS$GETLKIW(,LKID(2),LK_ITEM,IOSB,,,) \ if (.not. stat) call lib$stop(%val(stat)) \ if (.not. iosb(1)) call lib$stop(%val(iosb(1))) \ \ C Print out the information at the beginning of the array of records. \ C It is correct for the first lock. \ type * \ type *,'lki$l_lockid =', lki(1).lki$l_lockid \ type *,'lki$l_pid =', lki(1).lki$l_pid \ type *,'lki$l_sysid =', lki(1).lki$l_sysid \ type *,'lki$b_rqmode =', lki(1).lki$b_rqmode \ type *,'lki$b_grmode =', lki(1).lki$b_grmode \ type *,'lki$b_queue =', lki(1).lki$b_queue \ type *,'lki$l_remlkid =', lki(1).lki$l_remlkid \ type *,'lki$l_remsysid =', lki(1).lki$l_remsysid \ type * \ \ C Print out the additional "new" fields of that first record. It doesn't \ C look like valid information. \ \ type *,'LKI$Q_RQSTART = ', lki(1).LKI$Q_RQSTART(1), \ 1 lki(1).LKI$Q_RQSTART(2) \ type *,'LKI$Q_RQLENGTH = ',lki(1).LKI$Q_RQLENGTH(1), \ 1 lki(1).LKI$Q_RQLENGTH(2) \ type *,'LKI$Q_GRSTART = ', lki(1).LKI$Q_GRSTART(1), \ 1 lki(1).LKI$Q_GRSTART(2) \ type *,'LKI$Q_GRLENGTH = ',lki(1).LKI$Q_GRLENGTH(1), \ 1 lki(1).LKI$Q_GRLENGTH(2) \ \ length_to_move = 72 \ \ C Move the data from the "new" record structure into the old, 24 byte \ C record structure. \ \ status = lib$movc3 (length_to_move,lki(1),lki1(1)) \ if (.not. status) call LIB$SIGNAL(%val(status)) \ \ C Print out the first 2 records of the smaller structure. Looks valid. \ \ type * \ type *,'lki$l_lockid =', lki1(1).lki$l_lockid \ type *,'lki$l_pid =', lki1(1).lki$l_pid \ type *,'lki$l_sysid =', lki1(1).lki$l_sysid \ type *,'lki$b_rqmode =', lki1(1).lki$b_rqmode \ type *,'lki$b_grmode =', lki1(1).lki$b_grmode \ type *,'lki$b_queue =', lki1(1).lki$b_queue \ type *,'lki$l_remlkid =', lki1(1).lki$l_remlkid \ type *,'lki$l_remsysid =', lki1(1).lki$l_remsysid \ type * \ \ type * \ type *,'lki$l_lockid =', lki1(2).lki$l_lockid \ type *,'lki$l_pid =', lki1(2).lki$l_pid \ type *,'lki$l_sysid =', lki1(2).lki$l_sysid \ type *,'lki$b_rqmode =', lki1(2).lki$b_rqmode \ type *,'lki$b_grmode =', lki1(2).lki$b_grmode \ type *,'lki$b_queue =', lki1(2).lki$b_queue \ type *,'lki$l_remlkid =', lki1(2).lki$l_remlkid \ type *,'lki$l_remsysid =', lki1(2).lki$l_remsysid \ type * \ \ type *,'waiting ....' \ \ read(5,999)x \ 999 format(a) \ end \ ------------------------------------------------------------------------ \ \ \ REFERENCES: \ \ Note #2627 in VMSNOTES discusses this problem. \ \ CLDs, QARs, and Case-ids (SPRs/Elevations) reported on this problem: \ \ CLDs: \ QARs: SPR_VMS_V5 #02290 \ Case-Ids: ICA-44203 \ Field Service Log #: CXOQC03A4 \ CHAMP/CSC Service Request (SRQ) #: C921113-1779 \ IPMT case-id: \ \ \ CONTRIBUTORS: \ \ Technical: \ Chris Heisler (173849) of LST \ Caroline Butterworth (302957) of LST \ Karen Meadows (166532) of INTDRV \ \\ PIPE_TO_STARS VMS SYSTEM CWPS \\ ALPS 173849 302957 VSGTC 77276 120517 INTDRV 166532 \\ SPR_ICA-44203 FSLOG_CXOQC03A4 SRC921113001779 CSCBUG_CWPS-0009 \\ %001 Outstanding questions: 1. Only LKI$_LOCKS or also LKI$BLOCKEDBY/LKI$_BLOCKING involved 2. Will we be notified when/if those additional quadwords will be used by $GETLKI 3. Were was this change documented in the 1st place ????? Thats all, just beware...... Hans van Veen --->>> Happiness is just an illusion filled with sadness and confusion. <<<--- Hans van Veen Email: hansv@ittpub.nl ITT Publitec PSI%022846811423::VANVEEN Datacenter/SSS Phone: +31 20 56 76 797 Hoekenrode 1 Fax : +31 20 69 10 374 1102 BR AMSTERDAM Netherlands --->>> It's not reality that's important, but how you perceive things <<<---