I vaguely remember something similar happening a long time ago to us. Seems
it was it was in switch to MPE/iX 5.0 ?  Some fix in how VPLUS handled
certain terminal types?

If I am remembering correctly (which I must admit is a long stretch), the
fix involved making sure:

1) Forms file was compiled with the following terminal families turned on.

<T> from the main Formspec menu.

 FORMSPEC/V B.06.08 Terminal/Language Selection MenuFORMS FILE:
BT1000CV.SRCIPM



        Select (X) the terminals on which you will use this forms file:


               [X]  HP264X Family     [ ]  HP3075A, HP3076A, HP3081A


               [X]  HP262X, HP239X,   [ ]  HP2627A, HP2397A
                    HP7009X Families

               [ ]  IBM 3270          [ ]  Reserved

2) Making certain our terminal emulator (Reflections) was responding with
the HP70092, HP70096 terminal type.
<Setup>
<Terminal...>
<Terminal Type> file tab
<HP70092, HP70096> radio button



-----Original Message-----
From: John Pollard [mailto:[log in to unmask]]
Sent: Thursday, February 21, 2002 4:17 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] VPLUS - security enhancement failure


"Roy Brown" <[log in to unmask]>

> Well, I can answer half of this - if you press 'Enter' on a form, or
any
> field on a form, VPLUS takes that as a 'touch', and marks it for
> recompilation.
>
> If you don't want this to happen, read the forms using only the other
> function keys - Next and Previous, field or Form, don't have this
> effect.

I think you misunderstood me.  I was not stumped by the fact that
pressing the enter key flagged the form for recompilation - indeed, I
knew this would happen.  I was stumped by the fact the the recompilation
produced different output when the forms file had not had any changes
made to it.

And, since ultimately, I *do* wish to modify the form, I must get past
whatever is changing the security field processing.  I only introduced
the info about the pressing Enter with no changes into this discussion,
to help stress the fact that I was not modifying the definition of the
password field (nor any field) - that VPLUS was taking it on itself to
do so - even when *nothing* in the entire forms file had been changed.

> And a half-answer of the other point is that this could happen if you
> were doing the new compile in a later copy of VPLUS, which might well
> have addressed some issues regarding escape sequence sequencing.
> Were you?

This I can not answer for sure, I do not know the specific history of
either the form or our version(s) of VPLUS.  That is, I can not tell you
for certain when the form was changed last, nor by what version of
VPLUS.  But my belief is that it was changed last sometime in 1999 and
that we had the same version of VPLUS then as we do now.

But why would "addressing some issues regarding escape sequence
sequencing" result in causing what used to work, to not work anymore.
(Assuming that the "addressing" of those issues did not introduce a
bug).  We have had this basic forms file for probably over 15 years -
some of the literal data on the screen has changed (like the "version"
of our system - which I would now like to change again), but the basics
have been the same.  I had thought that the capability to prevent a
VPLUS field from echoing what was keyed in it was very old, very well
proven "technology"; not needing much in  the way of "improvement".
Maybe I was mistaken.

I had a suggestion from someone not on this list to try using FORMSPEC
on a *true* terminal to see if somehow the terminal emulator was
confusing matters.  I will try this on Monday.

Thanks.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *