I have a number of datasets that contain sql commands.  
Lines which contain -- in columns 1 and 2 indicate a 
comment line.

If I connect using screen surfer and attempt to edit one of 
these datasets, all lines displayed on the screen replace 
the leading -- characters with spaces.  This destroys the 
dataset, turning comment lines into statements that are 
interpreted as sql commands.

The inability to preserve the original text creates a 
serious problem since data is changed without warning.

There is code in Screensurfer that removes dashes and 
underscores from entry fields if...there is more than one 
dash.

This is because many screens have dashes filling the fields 
or underscore characters, and if these are sent to the HTML 
page, the user can't key-into the field.

On the way back, if a field has this condition, spaces 
should be converted back to the dashes, but in fact there 
may be a problem due to the 2 dashes.

Generally, Screensurfer is optimized for business and other 
data-oriented applications.  Editing SQL doesn't really fall 
into this category--do you have a potential use for 
Screensurfer as a production server that requires this 
feature?

Our Data Security group has hundreds of predefined SQL 
procedures which are modified to grant/revoke permissions 
to an individual logonid.  These procedures contain many 
lines that are commented out with leading dashes.

For example, in some applications, there are a number of 
DB2 tables or plans that may be granted to an individual.  
All tables and plans are listed in the procedure, but those 
that we are not granting to an individual are commented out.

When all comments are replaced with blanks we: at best, 
create invalid syntax or at worst, grant all tables and 
plans to the individual.

Our security group is called upon to make these grants all 
the time.  

We have added a global suppression option of the 
dash/underscore-to-blank behavior which is at the root of 
your problem.

To use it, you will need to download:

ftp://www.screensurfer.com/T2_0_10N.zip

Unzip to \screensurfer\bin to replace files there.

Then, start screensurfer, and stop it.

Then, use regedit and change the following entry:

HKEY_LOCAL_MACHINE/Software/Intelligent 
Environments/Screensurfer/Config:RemoveFillChars

Change the value from 1 to 0 (zero).

Now start Screensurfer again and you SQL editing 
functionality should work fine.

That seems to be a lot worse. 

On a normal emulator, the entry field following the READY 
prompt in TSO is displayed on the next line.  Through 
Screen Surfer the entry field is displayed on the same line 
as the prompt. With the RemoveFillChars value set to 0, the 
READY is interpreted as part of the command that I have 
entered.

For example, my attempt to logoff results in


READYlogoff

INVALID COMMAND NAME SYNTAX

Or My attempt to execute a command t results in

READYt

COMMAND READYT NOT FOUND
READY                      

Also, I am now getting most screens coming up with the 
messages similar to the following

"Sorry, your screen submission was in error! The page you 
entered was 7 seconds old, while you should have been 
working with one that is 7 seconds old...

The current screen display follows:

..."
    
This problem (Screen submission error) is independent of 
the RemoveFillChars setting.

You have moved to a test build that was created to work with 
the double -- problem, so we probably need to adjust 
something else.

Can you please run Screensurfer in diagnostic mode, and hit 
one of the TSO screens that is giving you the entry field in 
the wrong place...

Then, edit the file \screensurfer\hostserver\surfdiag.log 
and anywhere you see a password, replace the characters with 
**** (or whatever).

Then, send an email to surfer@ie.com, with the surfdiag.log 
file as an attachment.  We will identify what is going on 
and provide a new build.

Thanks for your patience...

This actually was a regression caused by the fix for the 
dashes-- a blank on the "READY " prompt was causing the 
modified data tag bit to be set on that field (it is 
unprotected) so that it was being sent-in.  That is because 
from the browser, the READY comes-in without the blank, so 
with the logic impaired by the "dash-fix", the field 
appeared to be changed.

Fixed so that even when suppressing dashes and underscores 
from being interpreted as blanks, a blank is still 
differentiated from a null character for leading or trailing 
field characters.

Fix is at:

ftp://www.screensurfer.com/T2_0_10P.zip

Unzip to \screensurfer\bin

That is much better, thanks.
The leading dashes are preserved and the READY prompt does 
not get included with the command entered on the same line.

Now if I could only get rid of that annoying behaviour:

"Sorry, your screen submission was in error! The page you 
entered was 7 seconds old, while you should have been 
working with one that is 7 seconds old...

The current screen display follows:

..."
    
which appears on almost half of the screens.

The sync error should not be occurring--what version of 
browser are you viewing the pages in?  We will take a look 
at your protocol log and check if there is some funnies in 
your TN3270 datastream that would trigger such a near miss.

That message is there to catch when someone uses the 
backbutton and then tries to submit an old screen in default 
pass-through mode (so that the backbutton isn't an "evil" 
thing, but something useful--for review of previously 
visited screens).

Normally, the registry setting synchtype=2 will prevent 
this.

Couldn't find anything that would cause the out-of-sync 
errors in the other log you sent.

Please run Screensurfer in diagnostic mode, and exercise a 
passthrough session until you get the out-of-sync message in 
the browser.

Then, stop using the session (don't exit), zip-up the files 
\screensurfer\hostserver\templates.log and
\screensurfer\hostserver\surfdiag.log

and email to surfer@ie.com with subject=Ticket #583 and 
attach the zip file--we can then figure-out why you got the 
error on the last screen.

This does seem to be browser dependent>
I have experienced this problem consistently using Internet 
Explorer 5.50.4134.0600IC

When I tried Netscape Communicator 4.7 I get very few of 
those messages.  

I note that the IE browser provides a better user 
interface. For example, the focus seems to be on the first 
data entry field when a screen comes up so I can type 
commands in directly whereas with Netscape I have to click 
on the field with my mouse first.  With IE, I can use the 
enter key on my keyboard rather than having to click the 
Emulation Enter button.

Netscape should not have a problem with the focus--it really 
sounds like something odd is happening with the 3270 
datastream such that your output to the HTML pages is 
starting sooner than it should.

We will check the logs you sent and figure it out.

Sorry for the long delay--we were not able to determine the 
cause of the errant sync errors.

We will need to install the exact version of IE you have to 
reproduce, I think...

You probably can get rid of them by turning-off our 
"auto-sync" feature in the registry-- set 
HKEY_LOCAL_MACHINE/Software/Intelligent 
Environments/Screensurfer/Config:Synchtype to 0 (zero).