Thanks very much for taking the time to reply, but as I replied to the list
30 minutes after I posted the question, the answer is YES!

Absolute (ie not cursor-relative, no + or - in sequence) screen-relative
addressing works great with the memory locked, goes right where you point
it, ignoring the memory-lock line.

In my case I used memory-relative (absolute) addressing to write each line
of the report into memory (you might be able to do it screen-relative by
rolling the memory thru the screen and then writing to the screen, I dunno),
home-up to get to the top of the screen, move to line 6, turn on memlock,
then using screen-relative addressing, place the cursor on line 3 for user
field-io.  Works fine, installed, users think I'm a god hee hee!

But again, thanks for your interest!

> -----Original Message-----
> From: Ken Graham [mailto:[log in to unmask]]
> Sent: Tuesday, December 21, 1999 9:59 AM
> To: 'Tracy Pierce'
> Subject: RE: 2645 etc Memory Lock properties
>
>
> The simple answer to your question is NO.  The area locked is
> unavailable.
>
> Here is your workaround.  It is messy, but there is no other way to
> accomplish it.
>
> Get both cursor positions, screen relative, and absolute.
>
> Home Up.
>
> Memo Lock Off.
>
> Get relative cursor position ( of Memory Lock Line ).
>
> <Perform IO in Screen Header>
>
> <position cursor at Memory Lock Line>
>
> Memory Lock On.
>
> Position Cursor to initial
> absoluteY-relativeY+screenHeight-MemoryLockY
> position (this places cursor at bottom of screen)
>
> Position Cursor to original relative position.
>
> <Screen is now back to the way it was>
>
>
>
>
> -----Original Message-----
> From: Tracy Pierce [mailto:[log in to unmask]]
> Sent: Friday, December 17, 1999 10:49 AM
> To: [log in to unmask]
> Subject: 2645 etc Memory Lock properties
>
>
> I have a program which runs online, letting the user select
> parameters to be
> fed to a report program, which is then run with its output
> pointed to disk.
> The online program then presents the report to the online
> user, with the
> only whistle being that the first line of the report, known to be page
> headings, is written to line 5 of display memory, then on
> line 6 Memory Lock
> is turned on, and the rest of the report is dumped line-by-line to the
> display.  That all works fine.
>
> But at the end of that cycle, I want to put the cursor in the
> locked area,
> which seems to be inaccessible, apparently because I'm using
> memory-relative
> cursor positioning.  When I try to do the subsequent IO
> sequence at line 3,
> the cursor ends up on line 6, "as close as it can get" to
> line 3. (and of
> course my prompt overwrites the first data line of the report).
>
> Before I go playing with my terminal-IO driver, can someone
> tell me off the
> top whether switching to screen-relative cursor positioning
> for subsequent
> IO will let me place the cursor in the area above the
> Memory-lock line?
>
> This is all being done with pure character-mode; the user can
> actually do
> the IO from anywhere on the screen, but it looks nicer if it
> happens in the
> expected location.  Strictly a cursor positioning problem.
>
> A simple YES answer from one of you terminal IO experts would be most
> welcome; if it's NO, some workaround would be great!
>
> TIA
>
> Tracy Pierce, Systems Programmer
> Golden Gate Bridge, Hwy & Trnsp Dist
> P.O.Box 9000, Presidio Station
> San Francisco, CA  94129-0601
> phone 415-923-2266
> email to [log in to unmask]
>