Is there any way with DMCC 4.2 to keep the session alive until I terminate?

Yes, Please review the Programmer's Guide documentation as it relates to the ResetApplicationSessionTimer message:

<?xml version="1.0" encoding="utf-8"?>
<ResetApplicationSessionTimer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.ecma-international.org/standards/ecma-354/appl_session">
<sessionID>D369E437CF83130B2C87CB65A7349A11-0</sessionID>
<requestedSessionDuration>180</requestedSessionDuration>
</ResetApplicationSessionTimer>

I am sorry, I did not find this section in documentation. Can I try placing code in "OnServerConnectionDownEvent" for "Reconnect". Can I use "StartAutoKeepAlive" with DMCC 4.2 to keep the session alive. Please help me by giving more details.

look for a section titled "Maintaining a Session" in Chapter 3 of Avaya Aura? Application Enablement Services Device, Media and Call Control API XML Programmer's Guide Release 5.2


Maintaining a Session
The example StartApplicationSessionPosResponse message above
contains a value for the actualSessionDuration. This represents the
amount of time in seconds that a session will remain active. Your application
must send periodic ResetApplicationSessionTimer XML messages to the
server in order to keep the session alive. This message represents a "keep
alive" message to reset the timer on a particular session. The server must
receive one such message during each session time-out interval. We
recommend that your application send this "keep alive" message to the
server at intervals that are approximately 1/3 the session duration. This
allows for up to 2 messages to be lost / delayed before the application
session is put into an inactive mode.
So, in order to maintain a session with a180 second duration, a
ResetApplicationSessionTimer message should be sent approximately
every 60 seconds in order to ensure that you maintain an active session.
An example ResetApplicationSessionTimer message is provided below.
<?xml version="1.0" encoding="utf-8"?>
<ResetApplicationSessionTimer
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.ecma-international.org/standards/ecma-
354/appl_session">
<sessionID>469421A9364D46D6444524AE41BEAD72-0</sessionID>
<requestedSessionDuration>180</requestedSessionDuration>
</ResetApplicationSessionTimer>
This must be done before the session expires. If the server receives no such
"heartbeat" at least once during a session time-out interval, it will place the
application session in an inactive state on the server.
The server will respond with a
ResetApplicationSessionTimerPosResponse if the application session
has been kept alive.
The following example shows the structure of the positive response:
<?xml version="1.0" encoding="UTF-8"?>
<ResetApplicationSessionTimerPosResponse
xmlns="http://www.ecma-international.org/standards/ecma-
354/appl_session">
<actualSessionDuration>180</actualSessionDuration>
</ResetApplicationSessionTimerPosResponse>


If the server responds with a esetApplicationSessionTimerNegResponse,
then the application may need to initiate recovery by sending another
StartApplicationSession, with the same SessionID to recover the
session..

Hello, thought I would avoid a new thread but this may be different.

I have a DMCC C++ app that sends & receives xml directly to AES and works fine on our 4.2 AES.

Just deployed it at a customer who has 5.2.2 AES and everything is working fine except that we do not appear to receive the ResetApplicationSessionTimerPosResponse message which causes my app to give up and disconnect after a period of time.
I have double checked that I am not getting it by logging all data received over TCP/IP. Is this a known issue or should I get a ticket logged on behalf of the customer's AES?

I forgot to add that the AES Dmcc logs suggest that the AES believes it is sending the response back but no sign of it at our end.

Please forget my post. As usual I solve the problem shortly after posting on here!

ah good... because it would be strange to exchange enough messages to get a session started successfully, only to fail the ResetSessionKeepAlive exchange.