| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1008.1 | Works alright with ECO04. I'll retry with ECO03 asap | AZUR::HUREZ | Connectivity & Computing Services @VBE. DTN 828-5159 | Fri Feb 28 1997 08:54 | 113 |
| Hello,
What is the value of the SYS$SHARE:SNS$SHR.EXE image file
identification field, as it is visible using
analyze/image/inter SYS$SHARE:SNS$SHR.EXE
followed with 4 return key hits...?
If it is any lower than V2.2-11, then you have one of the field test
versions of the ECO03. The released version should take care of the
problem...
As a matter of fact, I modified the test program as follows so that it
would compile (in guessing mode, hoping it would be OK: I'm no Cobol
programmer ;-) and tried it with the ECO04 FT on OpenVMS VAX V6.1. It
works alright... I'll retry asap with the ECO03 (I'm sorry I've got no
OpenVMS V6.2 around to perform tests), although changes from ECO03 to
ECO04 were very few and unlikely to have any impact in that area...
Regards,
-- Olivier.
----------------------------------------------------------------------------
IDENTIFICATION DIVISION.
PROGRAM-ID. test_sns.
AUTHOR. Peter Vermeulen.
DATE-WRITTEN. 26-feb-1997.
********************************************************************************
*
* Program for demonstrating hibernating process (state HIB) after calling
* LIB$FIND_IMAGE_SYMBOL for routine in SNS$SHR.
*
* This program runs on VMS V6.2 (Alpha) and uses Watchdog version 2.2
* and hangs using Watchdog V2.2 ECO 3.
*
*
* History:
* --------
* 27 feb 1997 PLV Version 1.0
*
********************************************************************************
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 return_status PIC S9(09) COMP.
01 user_procedure PIC S9(09) COMP.
01 argument_list.
03 arg_count PIC 9(09) COMP.
03 arg_address1 POINTER VALUE REFERENCE message_descr.
03 arg_address2 POINTER VALUE REFERENCE target_node_descr.
03 arg_address3 POINTER VALUE REFERENCE transport_descr.
01 message_descr.
03 message_lengte PIC S9(9) COMP.
03 FILLER POINTER VALUE REFERENCE dcm_messg_text.
01 target_node_descr.
03 target_node_lengte PIC S9(9) COMP VALUE 0.
03 FILLER POINTER.
01 transport_descr.
03 transport_lengte PIC S9(9) COMP VALUE 6.
03 FILLER POINTER VALUE REFERENCE transport.
01 transport PIC X(06) VALUE "DECnet".
01 dcm_messg_text PIC X(58).
PROCEDURE DIVISION.
hoofd SECTION.
BEGIN.
***
* Setup message for Watchdog.
***
MOVE "This is only a test" TO dcm_messg_text.
CALL "str$trim" USING
BY DESCRIPTOR dcm_messg_text
BY DESCRIPTOR dcm_messg_text
BY REFERENCE message_lengte IN message_descr.
***
* Get the address of routine SNS$ADD_MESSAGE in shareable image
* SYS$SHARE:SNS$SHR.EXE.
***
CALL "lib$find_image_symbol" USING
BY DESCRIPTOR "SNS$SHR"
BY DESCRIPTOR "SNS$ADD_MESSAGE"
BY REFERENCE user_procedure
BY DESCRIPTOR "SYS$SHARE:*.EXE"
GIVING return_status.
***
* If success call routine SNS$ADD_MESSAGE.
* Total arguments is 3 (message_text, target_node_name & transport).
* Target node is not set which means local node is used.
***
IF return_status IS SUCCESS
THEN
MOVE 3 TO arg_count IN argument_list
CALL "lib$callg" USING
BY REFERENCE argument_list
BY VALUE user_procedure
GIVING return_status
END-IF.
STOP RUN.
END PROGRAM test_sns.
|
| 1008.2 | IPMTed | UTRTSC::WDEBAKKER | Feed your head | Mon Mar 03 1997 04:21 | 22 |
|
I've already made an IPMT-case for this problem, but just
to be complete:
Olivier,
The Image Identification Information of SNS$SHR looks like this:
image name: "SNS$SHR"
image file identification: "V2.2-11"
image file build identification: ""
link date/time: 26-FEB-1997 16:12:34.74
linker identification: "A11-35"
The problem occurs _only_ on the Alpha platform, therefore it
is not reproducible on OpenVMS VAX versions.
The customer is running V6.2-1H3, we can reproduce it in-house
with V6.2
Regards,
Willem
|
| 1008.3 | I just tried it on Alpha as well... | AZUR::HUREZ | Connectivity & Computing Services @VBE. DTN 828-5159 | Mon Mar 03 1997 05:15 | 19 |
| Hello,
I tried it again, with SNS$SHR.EXE V2.2-11, on OpenVMS Alpha V6.1,
using the modified source as posted in my previous reply and the V2.4
Cobol compiler (out of the recentmost OpenVMS software library
distribution)... It works alright! It must be an incompatibility
with either the OpenVMS V6.2 libraries or your version of the Cobol
compiler.
Could you please also check that there's only one instance of the
SNS$SHR.EXE on the customer's system (there could be two of them,
one in SYS$SYSROOT:[SYSLIB], another one in SYS$COMMON:[SYSLIB], or
if old versions could not be purged for some reason) and that the
installed one actually is the V2.2-11 ( $ instal list sys$share:sns$shr ).
Thanks,
-- Olivier.
|
| 1008.4 | Well... | UTRTSC::WDEBAKKER | Feed your head | Mon Mar 03 1997 10:04 | 30 |
|
I'm not quite sure what you've changed in the source, but
I've extracted the (modified) source from .1, it still
fails on OpenVMS Alpha V6.2
I'm using DEC COBOL V2.4-863.
$ instal list sys$share:sns$shr.exe/full
DISK$AXPVMSSYS:<SYS0.SYSCOMMON.SYSLIB>.EXE
SNS$SHR;2 Open Hdr Shar Lnkbl
Entry access count = 1
Current / Maximum shared = 0 / 4
Global section count = 24
There's only 1 copy of SNS$SHR.EXE
$ dir sys$share:sns$shr.exe
Directory SYS$COMMON:[SYSLIB]
SNS$SHR.EXE;2
Total of 1 file.
If I use the pre-ECO03 version of SNS$SHR.EXE (the standard V2.2 one)
and INSTALL/REPLACE it, then it works correctly.
Replacing it again with the SNS$SHR.EXE mentioned above and
INSTALL/REPLACing it, it will fail again.
Willem
|
| 1008.5 | | UTRTSC::WDEBAKKER | Feed your head | Mon Mar 03 1997 10:13 | 21 |
|
FWIW, the id of the 'standard' V2.2 SNS$SHR.EXE which does _not_
show the problem, is
Image Identification Information
image name: "SNS$SHR"
image file identification: "V2.2-02"
image file build identification: ""
link date/time: 3-MAR-1997 16:07:01.89
linker identification: "A11-35"
The id of the ECO 3 version, which _does_ show the problem is:
Image Identification Information
image name: "SNS$SHR"
image file identification: "V2.2-11"
image file build identification: ""
link date/time: 26-FEB-1997 16:12:34.74
linker identification: "A11-35"
|
| 1008.6 | This was discussed and closed offline. Works alright now. | AZUR::HUREZ | Connectivity & Computing Services @VBE. DTN 828-5159 | Wed Mar 12 1997 10:49 | 1 |
|
|