I purposely don't say Vista emulates any particular real terminal, and
there's no option to specify you want to look like a 3278 vs. a 3279 or
whatever. That helps keep me out of trouble when it comes to details
like this :)
But in addition, I took some poetic-license with certain things that
bothered me about a real terminal. For example, I seem to remember some
programs that would initially fill an input area with nulls, and if you
moved the cursor out to the right and started typing, the host would
remove the nulls abd scoot your typing to the left. Not what I wanted,
so there's a Vista option (on by default) that replaces those nulls to
the left with real spaces. I don't think that's involved with this
problem though.
There's another option to convert nulls to blanks when sending them to
the host (off by default), in case anybody needs that. But that causes
enough trouble that when you try to set that option in Vista, you get a
warning window telling you that you probably don't want to do that.
I need to find Skip's original post and see if I can reproduce the error
and perhaps understand it a bit better, or at least see if it could be
an emulator issue or not.
I typically use an old PCOMM version I have to determine what a real
terminal would do, since I'll probably never see another real one except
at a museum. My theory was the old PCOMM was programmed using logic
obtained directly from the ROM in a real terminal, maybe even ported.
So I would expect PCOMM to be the gold-standard when any questions come up.
If that SDSF screen is the one I'm thinking of, it's a couple of
separate fields with a jump to the second line. If you have a long
command in your clipboard, you might try the PasteByTyping function
which simulates typing each character and does the jump. Menu:
Edit/Paste-Functions/Paste-By-Typing. But yeah, it might be a stretch
to expect an emulator to do inserts and deletes as if it was one line.
Oops... Sorry. Long post.
On 12/1/2020 1:50 PM, Charles Mills wrote:
Tom Brennan's Vista conforms: if a field runs to the right edge of the screen
and continues on the next line, then Ins mode pushes characters from one line
to the next. I recall no relevant experience with any other emulators.
The problem with SDSF /+ is that its "Full Screen" is only 80 characters wide,
so if your display is wide -- mine is 132 wide FWIW -- the field does not really
continue. SDSF thinks it continues, and you know it continues, and I know it continues,
but an emulator has no way of knowing.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Paul Gilmartin
Sent: Tuesday, December 1, 2020 10:36 AM
To: [email protected]
Subject: Re: Extraneous blanks in SDSF issued command
On Tue, 1 Dec 2020 17:39:58 +0000, Seymour J Metz wrote:
"The INS MODE (3275/3277) or ~ (3276/3278/3279) key allows characters to be inserted
into a field, while all characters following the point of insertion are shifted to the
right."
"If a field is a large one and covers more than one line, and if the situation calls
for it, during the insert operation, characters will shift from the end of one line to
the beginning of the next."
Clear enough. Thanks. Citation needed.
So Rob's terminal is nonconforming. But if that's the modal behavior
among current emulators, it avails suppliers little to count on the
"standard" behavior. Is it optional?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
