¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: A number of questions about MTS.

 

¿ªÔÆÌåÓý

I'll try to answer some of these inline below. Let me know what else you need.

On 22 Jan 2024, at 1:10, Bile Geek wrote:

Hello MTS community! After some moderate reading and light usage of
MTS, I would appreciate if you could answer some of my questions.

1.) Now that archive.michigan-terminal-system.org has been down for
almost a year - though well-archived on Archive.org, and with the
Google Drive links still existing - will this mailing list be the only
home of the MTS community, or will there eventually be another website?

Yes, there will be a new web site. We were just talking about this today.

2.) Obviously not everything can be released for legal/licensing
reasons, and sorting thru it all for D7.0 will take however long it
takes.

But I would like to know: are these files picked out yet but
just not publicly available pre-usable-system, or are most of these
files still being negotiated with rightsholders/programmers/etc? (As
far as I've read many/most of the post-D6.0 redistribution tapes are
still lost, so obviously those can't be sifted through yet.)

All of the so-called "redistribution" tapes were lost. These were informal tapes shared among the MTS sites (sort of like Github without the internet). The rest of the stuff is still being sorted through.

3.) Is it possible to connect a VT52/VT100/Tektronix to the current
D6.0A? Or would that require the networking support in D7.0? (Vol. 4
Appendix B reads to me like UMnet needs to be functioning first.)

This is a complicated question and the answer depends on exactly what you want to do. Connecting a real glass teletype to MTS (i.e. a VT100 or something that emulates one) will be very difficult. However if you run MTS in Hercules you can connect a tn3270 client to MTS right now. Hercules turns a tn3270 connection into a local 3270 which MTS supports. You probably could hack together something that would connect a VT100 emulator to MTS, but I don't think anyone has tried this and I'm not sure how you would do it.

4.) Browsed through CCM 448 [1] about VSS. However, I still have a few
questions:

a.) What version of MVS/370 did support stop at? Can it run
programs for the venerable 3.8j?

Something old. I don't think any particular version was targeted and the emulation was not complete. Mainly it emualted anything needed by a program we wanted to run. It was never meant to be a complete emulation of MVS.

b.) Was there networking support?

No

[1]

5.) I read the previous message about the HIM merge. Is this fork
publicly available?

No, not yet. Soon, I hope.

6.) There were several MTS systems on the BITNET network[1]. Looking
through the bitnet writeup (6.0T5 -1454), MTS BITNET supported
operation over multiple link protocols:

313 The full complement of RSCS link protocols will be
supported.
314 This requirement allows interworking with RSCS emulation
packages
315 which only implement a single protocol.

718 Link protocols (VMB, VMC, NJE, and X.25)

1166 At this writing, only the VMB DSP has been written at the
protocol
1167 layer and the SDA DSP at the physical device layer. In
addition,
1168 a subtasking monitor unit check routine for SDA device type
has
1169 been written.

1367 UBC and SFU have expressed a desire to implement their
Netnorth
1368 link using X.25 and Datapac, because bisync is not
available. It
1369 should be possible to substitute the UBCnet X.25 DSP for
either
1370 the SDA or CTCA DSPs to provide this function, in effect
1371 substituting a full duplex X.25 virtual circuit for a
permanent
1372 bisync line. The VMB or NJE protocols could then operate
over
1373 this link.

You will note that much of this is written in the future tense. At the time of D6 the Resource Manager (RM) was not yet integrated into MTS so none of this is available in D6. The 1996 system has the RM and it works well. I haven't tried BITNET since there is no one for me to talk to and configuring it is a pain. I have however gotten a Postscript printer on my local net to print from MTS using the RM.

Hyperion uses a 2703-lookalike[2] to tunnel NJE over TCP/IP. MTS also
supported the 2703[3], although it was eventually replaced with the
PDP-8 Data Concentrator[4], which was itself replaced with the PDP-11...

-----> The point: did the PDP-11 HIM/NIM/PCP/SCP/whatever support
NJE over a bisync line? Or was it TCP/IP, X.25, and local terminals
only? Would the 2703 be the only way to get BITNET on MTS, or
would an NJE-supporting frontend be the better option, perhaps in
combination with NJE-Bridge[5]? <-----

Your description of the history of terminal support in MTS is mostly correct except that the 2703 wasn't replaced by any of the others, it coexisted with them until the end. I'm not an expert on BITNET by a long shot and BITNET was never more than a bump on the side of MTS. I know we supported EMail via BITNET but I can't recall what other services, if any, were supported over BITNET. What do you want to use BITNET for? Are there any hosts out there still using it?

[1]
[2]
[3]
[4]
[5]

7.) ASMH is not available due to licensing. More than half the
system is written in Plus[1]. Is it possible to recompile only the
Plus-based portions, plugging in the already-assembled (and/or
manually patched) ASMH portions after the fact? Or is ASMH still
required for the existing build process, absent some heavy
modifications to the build scripts? (Not that I'm capable of any
meaningful modifications, as my programming skills are nascent.)

You should be able to rebuild any module (Plus, ASMH, GOM, or whatever) without affecting any other module. Neither the GOM nor the Plus compiler depends on ASMH.

[1]

Thank you for for taking time to respond to these questions.


A number of questions about MTS.

 

Hello MTS community! After some moderate reading and light usage of
MTS, I would appreciate if you could answer some of my questions.



1.) Now that archive.michigan-terminal-system.org has been down for
almost a year - though well-archived on Archive.org, and with the
Google Drive links still existing - will this mailing list be the only
home of the MTS community, or will there eventually be another website?



2.) Obviously not everything can be released for legal/licensing
reasons, and sorting thru it all for D7.0 will take however long it
takes.

But I would like to know: are these files picked out yet but
just not publicly available pre-usable-system, or are most of these
files still being negotiated with rightsholders/programmers/etc? (As
far as I've read many/most of the post-D6.0 redistribution tapes are
still lost, so obviously those can't be sifted through yet.)



3.) Is it possible to connect a VT52/VT100/Tektronix to the current
D6.0A? Or would that require the networking support in D7.0? (Vol. 4
Appendix B reads to me like UMnet needs to be functioning first.)



4.) Browsed through CCM 448 [1] about VSS. However, I still have a few
questions:

a.) What version of MVS/370 did support stop at? Can it run
programs for the venerable 3.8j?

b.) Was there networking support?

[1]



5.) I read the previous message about the HIM merge. Is this fork
publicly available?



6.) There were several MTS systems on the BITNET network[1]. Looking
through the bitnet writeup (6.0T5 -1454), MTS BITNET supported
operation over multiple link protocols:

313 The full complement of RSCS link protocols will be
supported.
314 This requirement allows interworking with RSCS emulation
packages
315 which only implement a single protocol.


718 Link protocols (VMB, VMC, NJE, and X.25)


1166 At this writing, only the VMB DSP has been written at the
protocol
1167 layer and the SDA DSP at the physical device layer. In
addition,
1168 a subtasking monitor unit check routine for SDA device type
has
1169 been written.


1367 UBC and SFU have expressed a desire to implement their
Netnorth
1368 link using X.25 and Datapac, because bisync is not
available. It
1369 should be possible to substitute the UBCnet X.25 DSP for
either
1370 the SDA or CTCA DSPs to provide this function, in effect
1371 substituting a full duplex X.25 virtual circuit for a
permanent
1372 bisync line. The VMB or NJE protocols could then operate
over
1373 this link.

Hyperion uses a 2703-lookalike[2] to tunnel NJE over TCP/IP. MTS also
supported the 2703[3], although it was eventually replaced with the
PDP-8 Data Concentrator[4], which was itself replaced with the PDP-11...

-----> The point: did the PDP-11 HIM/NIM/PCP/SCP/whatever support
NJE over a bisync line? Or was it TCP/IP, X.25, and local terminals
only? Would the 2703 be the only way to get BITNET on MTS, or
would an NJE-supporting frontend be the better option, perhaps in
combination with NJE-Bridge[5]? <-----

[1]
[2]
[3]
[4]
[5]



7.) ASMH is not available due to licensing. More than half the
system is written in Plus[1]. Is it possible to recompile only the
Plus-based portions, plugging in the already-assembled (and/or
manually patched) ASMH portions after the fact? Or is ASMH still
required for the existing build process, absent some heavy
modifications to the build scripts? (Not that I'm capable of any
meaningful modifications, as my programming skills are nascent.)

[1]



Thank you for for taking time to respond to these questions.


Re: Obtaining a disassembled listing of an object file

 

Pretty sure orl=80 should do the trick.

# copy unsp:disasm -x
# run *objutil scards=-x 0=-y par=orl=80
# 11:12:08
  OBJUTIL VERSION(CT311) 11:12:09 01-17-24
  ADDED:
   PASS0    WORKAREA SYS13    PASS1    CARD     PAB      PA       LCF
   FTXTA    RFTXT    COFST    TXT      END      ENDA     NTXT     PASS4
   ADA      COTR     PASS3    PASS5    EXIT     ESD      ESD0     PROGN
   NPROG    ESD1     NENT     ESD2     NEXT     SCNE     ESD5     LCOM
   RLD      NBR      RR       RX       RS       SI       SS       ARL
   COMF     SBCZ     CONST    FTXT     CRLD     ARLDS    CF       AXN
   MEN      ADDR     SAVA     NAST     AST      USING    BCV      FXPT
   FLPT     PR       CXN      CDN      ART      AST4     BSC      NAVBS
   PRINT    READ     PRINTA   PDOFF    LCT      READA    SPPR     PLCB
   DS       TIME#    COUNT    MENC     DECOMP   PUNCH    CSNOOP   SNOOP
   RCALL    ADROF    IADROF   MOVEC

  CPU time = 0.08 seconds.
# 11:12:09  T=0.083  $0.03
# f -x maxlen
  -X                MaxLen=3364
# f -y maxlen
  -Y                MaxLen=80
#

   Thomas Valerio


Re: Obtaining a disassembled listing of an object file

 

Pretty sure orl=80 should do the trick.

# copy unsp:disasm -x
# run *objutil scards=-x 0=-y par=orl=80
# 11:12:08
OBJUTIL VERSION(CT311) 11:12:09 01-17-24
ADDED:
PASS0 WORKAREA SYS13 PASS1 CARD PAB PA LCF
FTXTA RFTXT COFST TXT END ENDA NTXT PASS4
ADA COTR PASS3 PASS5 EXIT ESD ESD0 PROGN
NPROG ESD1 NENT ESD2 NEXT SCNE ESD5 LCOM
RLD NBR RR RX RS SI SS ARL
COMF SBCZ CONST FTXT CRLD ARLDS CF AXN
MEN ADDR SAVA NAST AST USING BCV FXPT
FLPT PR CXN CDN ART AST4 BSC NAVBS
PRINT READ PRINTA PDOFF LCT READA SPPR PLCB
DS TIME# COUNT MENC DECOMP PUNCH CSNOOP SNOOP
RCALL ADROF IADROF MOVEC

CPU time = 0.08 seconds.
# 11:12:09 T=0.083 $0.03
# f -x maxlen
-X MaxLen=3364
# f -y maxlen
-Y MaxLen=80
#

Thomas Valerio

I cannot use. UNSP:DISASM. because the. APL. object
file uses. CSI. records which are code/data records of
up to 32767 bytes in length. DISASM only disassembles
TXT records of 80 bytes of length at a time. ( Same as
CSI records but only 80 bytes in length). There is a
way, using OBJUTIL, to modify all of the CSI records
to TXT records but I haven't figured out how.

-- William Gallant

On Monday, January 15, 2024, rvjansen@... <rvjansen@...>
wrote:

Hi William,

you might know this already but in case you do not, it might come in
handy
in your endeavor: the source for APL\360 is downloadable at


best regards,

Ren??.

On 15 Jan 2024, at 15:33, William Gallant <sigma.research@...>
wrote:

Hi. My name is William Gallant.
I am new to MTS. I hardly know any MTS commands
or how to find my way around the OS or use files, etc...
I am looking for a way to get a disassembled listing of
the APL object file on tape d5.0t1.aws
I tried the OBJLIST program with options "ALL" selected
but only got a complete detailed cross-reference of
symbols and hex dumps of CSI records ( code mixed with data )
some which are 32767 bytes long.
Question - Is there a way, using the program OBJUTIL instead of
OBJLIST to obtain a disassemble listing ( even if piece by piece )?

-- William Gallant


Re: Obtaining a disassembled listing of an object file

 

I cannot use. UNSP:DISASM. because the. APL. object
file uses. CSI. records which are code/data records of
up to 32767 bytes in length.? DISASM only disassembles
TXT records of 80 bytes of length at a time. ( Same as
CSI records but only 80 bytes in length). There is a
way, using OBJUTIL, to modify all of the CSI records
to TXT records but I haven't figured out how.

--? William Gallant


On Monday, January 15, 2024, rvjansen@... <rvjansen@...> wrote:
Hi William,

you might know this already but in case you do not, it might come in handy in your endeavor: the source for APL\360 is downloadable at?

best regards,

¸é±ð²Ô¨¦.

On 15 Jan 2024, at 15:33, William Gallant <sigma.research@...> wrote:

Hi. My name is William Gallant.
I am new to MTS. I hardly know?any MTS commands
or how to find my way around the OS or use files, etc...
I am looking for a way to get a disassembled listing of
the APL object file on tape? ?d5.0t1.aws? ?
I tried the OBJLIST program with options "ALL" selected
but only got a complete detailed cross-reference of
symbols and hex dumps of CSI records ( code mixed with data )
some which are 32767 bytes long.
Question - Is there a way, using the program OBJUTIL instead of
OBJLIST to obtain a disassemble listing ( even if piece by piece )?

--? William Gallant


Re: Obtaining a disassembled listing of an object file

 

¿ªÔÆÌåÓý

Hi William,

you might know this already but in case you do not, it might come in handy in your endeavor: the source for APL\360 is downloadable at?

best regards,

¸é±ð²Ô¨¦.

On 15 Jan 2024, at 15:33, William Gallant <sigma.research@...> wrote:

Hi. My name is William Gallant.
I am new to MTS. I hardly know?any MTS commands
or how to find my way around the OS or use files, etc...
I am looking for a way to get a disassembled listing of
the APL object file on tape? ?d5.0t1.aws? ?
I tried the OBJLIST program with options "ALL" selected
but only got a complete detailed cross-reference of
symbols and hex dumps of CSI records ( code mixed with data )
some which are 32767 bytes long.
Question - Is there a way, using the program OBJUTIL instead of
OBJLIST to obtain a disassemble listing ( even if piece by piece )?

--? William Gallant


Re: Obtaining a disassembled listing of an object file

 

On Mon, Jan 15, 2024 at 02:03 PM, William Gallant wrote:
Hi. My name is William Gallant.
I am new to MTS. I hardly know?any MTS commands
or how to find my way around the OS or use files, etc...
I am looking for a way to get a disassembled listing of
the APL object file on tape? ?d5.0t1.aws? ?
I tried the OBJLIST program with options "ALL" selected
but only got a complete detailed cross-reference of
symbols and hex dumps of CSI records ( code mixed with data )
some which are 32767 bytes long.
Question - Is there a way, using the program OBJUTIL instead of
OBJLIST to obtain a disassemble listing ( even if piece by piece )?

--? William Gallant
Have you tried UNSP:DISASM? That usually works for me


Obtaining a disassembled listing of an object file

 

Hi. My name is William Gallant.
I am new to MTS. I hardly know?any MTS commands
or how to find my way around the OS or use files, etc...
I am looking for a way to get a disassembled listing of
the APL object file on tape? ?d5.0t1.aws? ?
I tried the OBJLIST program with options "ALL" selected
but only got a complete detailed cross-reference of
symbols and hex dumps of CSI records ( code mixed with data )
some which are 32767 bytes long.
Question - Is there a way, using the program OBJUTIL instead of
OBJLIST to obtain a disassemble listing ( even if piece by piece )?

--? William Gallant


Re: CBELL

 

On Wed, Jan 10, 2024 at 05:53 PM, Mike Alexander wrote:
On 10 Jan 2024, at 10:22, Ron Frederick wrote:

I remember writing C code on MTS before before I left RPI (graduated
in 1989) and I thought I used *C89, but it¡¯s possible it was *C87 or
even possibly CBell. I haven¡¯t had a chance to fire up my MTS
installer here to see what was included in d6.0a, but I found an old
thread
at??which
mentioned that C89 was present but didn¡¯t work yet. I think some of
the reason for that might be a dependency on ASMH.
CBell uses ASMH but C89 does not. I don't think C87 does either, but
I'm not quite sure.

Mike
*C87 isn't in d6.0 but there are several files like *C87INCLUDE and *C87LIB


Re: CBELL

 

On 10 Jan 2024, at 10:22, Ron Frederick wrote:

I remember writing C code on MTS before before I left RPI (graduated in 1989) and I thought I used *C89, but it¡¯s possible it was *C87 or even possibly CBell. I haven¡¯t had a chance to fire up my MTS installer here to see what was included in d6.0a, but I found an old thread at? mentioned that C89 was present but didn¡¯t work yet. I think some of the reason for that might be a dependency on ASMH.

CBell uses ASMH but C89 does not. I don't think C87 does either, but I'm not quite sure.

Mike


Re: CBELL

 

¿ªÔÆÌåÓý

I remember writing C code on MTS before before I left RPI (graduated in 1989) and I thought I used *C89, but it¡¯s possible it was *C87 or even possibly CBell. I haven¡¯t had a chance to fire up my MTS installer here to see what was included in d6.0a, but I found an old thread at??which mentioned that C89 was present but didn¡¯t work yet. I think some of the reason for that might be a dependency on ASMH.

On Jan 9, 2024, at 9:16?PM, Mike Alexander <mta@...> wrote:
If you look at the comments for component 934 in the D6 driver file you'll see that much of CBell was not distributed due to licensing restrictions. I don't know if we still have it and whether the licensing restriction still apply. CVell also calls ASMH to assemble the compiled program so it won't run on D6 as is. It could perhaps be patched to run ASMG, but that's moot if it's not there at all.

At the time of D6 support for C in MTS was not very good. By 1996 there were (or had been) three C compilers in MTS: CBell, C87, and C89. C89 was pretty good and passed most of the language verification tests. CBell had been retired and C87 was in limbo. Unfortunately I don't think any of these are on D6, either because they didn't exist or due to licensing restrictions.

Mike

On 9 Jan 2024, at 12:55, Tom Chandler wrote:

Already looked at that.?
CBELL is not even listed.??

However in VOL 2 MTS Documentation there is about
two pages discussing it.? All I can find....

/cheers
/tom c


On Tue, Jan 9, 2024 at 11:52?AM Joe Monk <joemonk64@...> wrote:


Joe

On Tue, Jan 9, 2024 at 10:34?AM Tom Chandler <tchandler48@...> wrote:
I am trying to compile a "C" program under MITS 6.0a.? Trying to use
the CBELL compiler.? Not having any success.

As anyone be able to compile "C" using this compiler.

Thank You
Tom c

--?
Ron Frederick
ronf@...




Re: CBELL

 

Mike,
Thank you for closing this out for me.? I was hoping that CBELL was included.

Now to plan B, whatever that is....

/cheers
/tom c


On Tue, Jan 9, 2024 at 11:16?PM Mike Alexander <mta@...> wrote:

If you look at the comments for component 934 in the D6 driver file you'll see that much of CBell was not distributed due to licensing restrictions. I don't know if we still have it and whether the licensing restriction still apply. CVell also calls ASMH to assemble the compiled program so it won't run on D6 as is. It could perhaps be patched to run ASMG, but that's moot if it's not there at all.

At the time of D6 support for C in MTS was not very good. By 1996 there were (or had been) three C compilers in MTS: CBell, C87, and C89. C89 was pretty good and passed most of the language verification tests. CBell had been retired and C87 was in limbo. Unfortunately I don't think any of these are on D6, either because they didn't exist or due to licensing restrictions.

Mike

On 9 Jan 2024, at 12:55, Tom Chandler wrote:

Already looked at that.?
CBELL is not even listed.??

However in VOL 2 MTS Documentation there is about
two pages discussing it.? All I can find....

/cheers
/tom c


On Tue, Jan 9, 2024 at 11:52?AM Joe Monk <joemonk64@...> wrote:


Joe

On Tue, Jan 9, 2024 at 10:34?AM Tom Chandler <tchandler48@...> wrote:
I am trying to compile a "C" program under MITS 6.0a.? Trying to use
the CBELL compiler.? Not having any success.

As anyone be able to compile "C" using this compiler.

Thank You
Tom c


Re: CBELL

 

¿ªÔÆÌåÓý

If you look at the comments for component 934 in the D6 driver file you'll see that much of CBell was not distributed due to licensing restrictions. I don't know if we still have it and whether the licensing restriction still apply. CVell also calls ASMH to assemble the compiled program so it won't run on D6 as is. It could perhaps be patched to run ASMG, but that's moot if it's not there at all.

At the time of D6 support for C in MTS was not very good. By 1996 there were (or had been) three C compilers in MTS: CBell, C87, and C89. C89 was pretty good and passed most of the language verification tests. CBell had been retired and C87 was in limbo. Unfortunately I don't think any of these are on D6, either because they didn't exist or due to licensing restrictions.

Mike

On 9 Jan 2024, at 12:55, Tom Chandler wrote:

Already looked at that.?
CBELL is not even listed.??

However in VOL 2 MTS Documentation there is about
two pages discussing it.? All I can find....

/cheers
/tom c


On Tue, Jan 9, 2024 at 11:52?AM Joe Monk <joemonk64@...> wrote:


Joe

On Tue, Jan 9, 2024 at 10:34?AM Tom Chandler <tchandler48@...> wrote:
I am trying to compile a "C" program under MITS 6.0a.? Trying to use
the CBELL compiler.? Not having any success.

As anyone be able to compile "C" using this compiler.

Thank You
Tom c


Re: CBELL

 

Already looked at that.?
CBELL is not even listed.??

However in VOL 2 MTS Documentation there is about
two pages discussing it.? All I can find....

/cheers
/tom c


On Tue, Jan 9, 2024 at 11:52?AM Joe Monk <joemonk64@...> wrote:


Joe

On Tue, Jan 9, 2024 at 10:34?AM Tom Chandler <tchandler48@...> wrote:
I am trying to compile a "C" program under MITS 6.0a.? Trying to use
the CBELL compiler.? Not having any success.

As anyone be able to compile "C" using this compiler.

Thank You
Tom c


Re: CBELL

 



Joe

On Tue, Jan 9, 2024 at 10:34?AM Tom Chandler <tchandler48@...> wrote:
I am trying to compile a "C" program under MITS 6.0a.? Trying to use
the CBELL compiler.? Not having any success.

As anyone be able to compile "C" using this compiler.

Thank You
Tom c


CBELL

 

I am trying to compile a "C" program under MITS 6.0a.? Trying to use
the CBELL compiler.? Not having any success.

As anyone be able to compile "C" using this compiler.

Thank You
Tom c


Re: How's the HIM merge into Hercules coming along?

 

On 12 Oct 2023, at 19:29, John Palmer wrote:

Just wondering how the HIM code merge into Hercules is coming.? I know there was a flurry of activity last month, but some issues popped up.

I've been otherwise occupied for the last couple of months, but I'm anxious to get back on this.

Mike


How's the HIM merge into Hercules coming along?

 

Just wondering how the HIM code merge into Hercules is coming.? I know there was a flurry of activity last month, but some issues popped up.


Re: Issues Running MTS on SDL Hercules (Hyperion) 4.x - Summary of Trials

 

Fascinating story about bug swatting.

May I suggest the MTS guys (especially Rupert Lane, if he is here) to just add a note to try-mts.com telling people to either avoid Vista or to be careful when using 4.x?

All the best

Marco


Re: Issues Running MTS on SDL Hercules (Hyperion) 4.x - Summary of Trials

 

(ATTACHMENTS)

Fish wrote:
John Palmer wrote:

There is no mode in which using Vista 3270 as the master
console works without causing a superdump in the early
stages of IPL of MTS when running Hercules 4.x.
Educate me: what is a "superdump"? And how can I tell it has occurred?

Because I finally got around to trying MTS for myself, and it seems to work just fine for me on Windows with Vista 3270. The *only* thing that doesn't work is a 3270 model-5-E (27x132), which causes Vista to complain about an invalid buffer address (see attached).

But that's not Vista's problem. That's MTS causing that!

And the same thing occurs when I use Hercules 3.13 too!

As long as I stick with a model-4-E (43x80) or a model-3-E (32x80) or a model-2-E (24x80) however, then it seems to work just fine on both Herculeses. (Herculi?)

Are you *SURE* you're connecting your Vista 3270 session to MTS's 3270 display terminal address 0001 as a 3270 model 2 or 3 or 4? (i.e. NOT as a model 5?) (see attached)

Can we see a screen shot of Vista's connect dialog? As well as Hercules's logfile where it reports the connection? (e.g. "HHC02914I 0:0001 COMM: client 0 negotiations complete; ttype = 'IBM-3278-4-E'")


Note, this is not the case for Hercules 3.x (3.06, 3.13). They
don't exhibit this behavior.
For me, using a 3270 model-5-E (27x132) *always* causes problems, even for Hercules 3.x (3.13), whereas using any other model (e.g. 2, 3 or 4) works beautifully, just as it does with SDL Hyperion 4.6 too. <shrug>


Then it certainly sounds like there is a bug in SDL Hercules
which needs to be investigated!
Which I now suspect MIGHT not be the case!

It all depends on:

1. What a "superdump" is.

2. Whether you're using a model-5 or a model-4, 3 or 2.

3. Whether you're using NetBSD or not.

4. Whether your Hercules is running natively or in virtual machine (e.g. VMware on Windows, VirtualBox on Linux, or some other virtual machine running elsewhere, such as the AWS you mentioned before).


I will see about opening a ticket in order to help diagnose the problem.
Thank you. I would appreciate that very much.
Yes! PLEASE! We need to get to the bottom of this!

There is something very unusual with whatever system/environment you're trying to run SDL Hyperion + MTS on!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...