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

Conference clt::cobol

Title:	VAX/DEC COBOL
Notice:	Kit,doc,performance talk info-->DIR/KEY=KIT or DOC or PERF_TALK
Moderator:	PACKED::BRAFFITT

Created:	Mon Feb 03 1986
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3250
Total number of notes:	13077

3246.0. "Any advice about this behavior after 10K patch installed" by PADKOA::COSTEUX () Wed Jun 04 1997 08:25

    A customer has installed the patch VAXLIBR06_070 on system running
    OVMS-V5.5-2. On this system he runs a Cobol written application
    (Cobol-V4.4-65). This application does updates on an indexed file
    including duplicated keys. Before the patch installation his program
    ran fine. The customer states that after the patch has been installed
    his application program returns a status code 02 (success) when he
    updates the file mentioned above. As this code was not tested (because
    he was never returned) the program did not work fine. The customer has
    modified his program to test this returned code and to make it working 
    as before. Since this modification there is no more problem.
    I dont't see how the program behavior has been impacted by the patch.
    Is it because the LIBRTL or other images modified by this patch ?
    Any advice is welcome.
    
    Thanks in advance.
    
    Jean-Pierre

T.R	Title	User	Personal Name	Date	Lines
3246.1	Some details on VAX COBOL V5.3 and V5.4	PACKED::BRAFFITT		`Wed Jun 04 1997 10:29`	21
	> A customer has installed the patch VAXLIBR06_070 on system running > OVMS-V5.5-2. On this system he runs a Cobol written application > (Cobol-V4.4-65). This application does updates on an indexed file > including duplicated keys. Before the patch installation his program I'm not exactly sure about the OpenVMS patch kit naming, but I thought a patch kit with a name like VAXLIBR06_070 would not be something you would install on VAX/VMS V5.5-2. Anyway, VAX COBOL V5.3 and the VAX COBOL RTL V5.3 are the current supported versions on VAX/VMS V5.5-2 through Sep-1997. If the customer upgrades to to VAX COBOL V5.3 before they upgrade to VAX COBOL V5.4, make sure they get the VAX COBOL V5.3 TIMA kit (COBOLVAXE01053 - see note 2963.35). As of Sep-1997, VAX COBOL V5.4 will be the only supported version of VAX COBOL (requiring OpenVMS VAX V6.1 at a minimum). Also, there is a new option (/CHECK=DUPLICATE_KEYS) in these later versions of VAX COBOL that allows a programmer to verify at runtime whether or not the COBOL program source specification for DUPLICATES matches the actual file.
3246.2	extremely unlikely to be the LIBR ECO	GIDDAY::GILLINGS	a crucible of informative mistakes	`Thu Jun 05 1997 00:51`	44
	re .1: > a patch kit with a name like VAXLIBR06_070 would not be something you > would install on VAX/VMS V5.5-2. Yes it would. The naming scheme is a bit odd. The "070" represents the highest version that the ECO applies to. re .0: What we're dealing with here is an issue of cause an effect. The customer has observed an apparent difference in behaviour and assumed that it's due to the ECO because of the temporal coincidence. Given the nature of the reported difference and the nature of the ECO, it is EXTREMELY unlikely that the two are even remotely related. If the customer is concerned about the ECO kit, there are 3 options I can suggest: 1) Restore his system disk from the backup taken prior to installing the ECO 2) Use the documented method to back out the ECO: $ @SYS$UPDATE:LIBRTL$ECO_DROP.COM 3) Try running the program against the original RTLs. They should still be in SYS$SHARE as old versions. Assuming a "plain vanilla" installation of the ECO, try: $ DEFINE LIBRTL SYS$SHARE:LIBRTL.EXE;-1 $ DEFINE LIBRTL2 SYS$SHARE:LIBRTL2.EXE;-1 $ RUN program and see if the behaviour changes. It is almost certain that something else is going on here. John Gillings, Sydney CSC Note: We've had many calls to the CSC reporting problems claimed to be due to installing the LIBR ECO. So far, only 1 has been genuine, and that was a customer whos program was expecting an INVTIME error when a delta time exceeded 10000 days.