Re: SQL history lost moving to new i

This is an often discussed situation here and elsewhere; IIRC there was and should still be a KB article on the IBM support pages. There is a means both to pare down to one session and to prevent ever getting a new session. For the former, the algorithm used by STRSQL to either reuse or start a new session enables an existing session from another device to be reused; this also means multiple sessions can still appear to be /randomly floating/ amongst the more specific yet still multiple names. For the latter, do not ever start a second SQL session while another is active [in a separate (group) job or call level].

http://archive.midrange.com/midrange-l/200801/msg00230.html

Regards, Chuck

elehti wrote:

Buck, Wow, THANK you for your insightful recommendation that
developers who run STRSQL have named sessions (Workstation ID).

I changed my device naming to named sessions (e.g. ELEHTIA1,
ELEHTIB1, etc.) from QPADEV*, based on your comment! My SQL
history had been randomly floating from session to session mysteriously, and sometimes I would lose the SQL history for days
at a time, and get it back with the QPADEV* name from before.

All developers here have named sessions, not QPADEV* But as
a double check, I did DMPSYSOBJ ISQLST* and the saved
statements are nowhere to be found.