Conference vaxaxp::vmsnotes

449.0. "no cleanup provided for BACKUP$START API?" by CUJO::SAMPSON () Thu Apr 10 1997 23:52

	Hello,

	A co-worker (Amy Murtha) has discovered that the new BACKUP API
for OpenVMS V7.1 (VAX and Alpha), allocates a large amount of *additional*
virtual memory for its buffers, *every* time it is called.  This renders
impractical its repeated use by an application program.

	This problem was already reported quite a while ago,
in TRIFID::EVMS-RAVEN QAR #352.  The problem also exists on
VAX, but I did not find any equivalent QAR in TRIFID::VAX-RAVEN.

	We anticipate that one of our customers is about to start using
this API in an application being developed for OpenVMS Alpha V7.1.
Amy Murtha is also attempting to make use of this API for an in-house
application she is writing for both VAX and Alpha.

	Is there by any chance a way to clean up after BACKUP$START,
that the documentation currently doesn't mention?  If not, is the
problem scheduled to be fixed any time soon by an ECO?  If not, is
an IPMT going to be needed to get the ball rolling?

	Thanks,
	Bob Sampson

QAR #  Status Sev Category     Component        Date in       Date out
-----  ------ --- --------    --------------  ------------  -------------
00352    AK   M     UI        BACKUP          13-JUN-1996   21-JUN-1996
<56>%BACKUP-F-INSBUFSPACE CALLING MANY TIMES THE ROUTINE BACKUP$START.
			QAR Report from OpenVMS QTV Group
			=================================
%QAR-I-ASSIGNED, assigned to BACKUP by SHERENZON at 13-JUN-1996 08:16:48.86
%QAR-I-ASSIGNED, assigned to BACKUP by NEUMEISTER at 21-JUN-1996 12:17:41.55
No answer for QAR report #00352.

:	Is there by any chance a way to clean up after BACKUP$START,
:that the documentation currently doesn't mention?  If not, is the
:problem scheduled to be fixed any time soon by an ECO?  If not, is
:an IPMT going to be needed to get the ball rolling?

    The IPMT is the way.

    As an ugly workaround, use the BACKUP API in a subprocess.

    Thank you, Steve.