Discussion:
hercules 3.08 unexpected disconnects not handled properly
(too old to reply)
dhdurgee
2013-05-28 15:40:43 UTC
Permalink
I have just downloaded and built hercules 3.08 and am finding that 3270 disconnects are not being handled properly. I am IPLing VM/ESA 1.5 (370 Feature) from my P/370 on hercules. I have configured some 3270 and 3215 ports on it for access. I can logon to VM using x3270 as expected.

Unfortunately it appears that unexpected disconnects are not being handled as expected. If I disconnect x3270, to simulate a line failure, I do get a message on the hercules console:

HHCTE007I 3270 device xxxx client yyy.yyy.yyy.yyy connection closed.

Unfortunately VM does not appear to be receiving the expected signal, as the user remains connected! If I do this on a connection to my P/370 system I get an immediate operator message:

GRAF xxxx DSCONNECT uuuuuuuu USERS = nnn FORCED

Needless to say this error will make recovery from an abnormal disconnect difficult! Hopefully this will be an easy fix.

Dave
dhdurgee
2013-05-28 20:38:40 UTC
Permalink
This is a postscript to the previous post, as there appears to be no way to edit the post after it is entered.

Looking at console.c I see the following after the HHCTE007I message:

return (CSW_ATTN | CSW_UC | CSW_DE);

So it appears that these conditions are being returned to VM/ESA, but are not sufficient to cause VM/ESA to disconnect the user session. Can anyone tell me what would need to be returned for VM/ESA to disconnect the user session and restart the 3270 connection? Is the documented somewhere that I can search it out?

I see several other conditions that could be raised in esa390.h, but I am reluctant to simply keep modifying the source to test the remaining 254 combinations to find one that does cause VM/ESA to disconnect the user session. At this point I would even accept one that left the line disabled or varied off as long as the user session was disconnected.

I guess in the worst case I can attempt to extract that information from my P/370 system via the CPTRAP command, but as I lack the tools to process that output decoding the information is difficult.

Dave
John P. Hartmann
2013-05-28 20:44:46 UTC
Permalink
The status for a local 3270 being powered off is CE UC (possibly with DE)
and sense Intervention Required. But on a real terminal, if memory serves,
the drop comes when the terminal goes ready, that is, presents an
unsolicited device end.
Post by dhdurgee
**
This is a postscript to the previous post, as there appears to be no way
to edit the post after it is entered.
return (CSW_ATTN | CSW_UC | CSW_DE);
So it appears that these conditions are being returned to VM/ESA, but are
not sufficient to cause VM/ESA to disconnect the user session. Can anyone
tell me what would need to be returned for VM/ESA to disconnect the user
session and restart the 3270 connection? Is the documented somewhere that I
can search it out?
I see several other conditions that could be raised in esa390.h, but I am
reluctant to simply keep modifying the source to test the remaining 254
combinations to find one that does cause VM/ESA to disconnect the user
session. At this point I would even accept one that left the line disabled
or varied off as long as the user session was disconnected.
I guess in the worst case I can attempt to extract that information from
my P/370 system via the CPTRAP command, but as I lack the tools to process
that output decoding the information is difficult.
Dave
[Non-text portions of this message have been removed]
dhdurgee
2013-05-28 20:55:26 UTC
Permalink
Post by John P. Hartmann
The status for a local 3270 being powered off is CE UC (possibly with DE)
and sense Intervention Required. But on a real terminal, if memory serves,
the drop comes when the terminal goes ready, that is, presents an
unsolicited device end.
Hmm... in that case perhaps I should add a CSW_CE and see what happens. Thank you for your response.

Dave
John P. Hartmann
2013-05-28 21:13:26 UTC
Permalink
Unit check alone on initial status is also valid. But I don't think
Hercules knows of initial status other than a list of immediate CCW command
codes for each device type.
Post by John P. Hartmann
**
Post by John P. Hartmann
The status for a local 3270 being powered off is CE UC (possibly with DE)
and sense Intervention Required. But on a real terminal, if memory
serves,
Post by John P. Hartmann
the drop comes when the terminal goes ready, that is, presents an
unsolicited device end.
Hmm... in that case perhaps I should add a CSW_CE and see what happens.
Thank you for your response.
Dave
[Non-text portions of this message have been removed]
dhdurgee
2013-05-29 13:47:32 UTC
Permalink
Post by John P. Hartmann
Unit check alone on initial status is also valid. But I don't think
Hercules knows of initial status other than a list of immediate CCW command
codes for each device type.
Post by John P. Hartmann
**
Post by John P. Hartmann
The status for a local 3270 being powered off is CE UC (possibly with DE)
and sense Intervention Required. But on a real terminal, if memory
serves,
Post by John P. Hartmann
the drop comes when the terminal goes ready, that is, presents an
unsolicited device end.
Hmm... in that case perhaps I should add a CSW_CE and see what happens.
Thank you for your response.
Dave
I added CSW_CE but that still does not result in placing the virtual machine in a disconnected state. Is there a principles of operations manual available for channel programming that defines what the expected responses to CSW bits are for VM? For this to work properly the CSW must be set such that VM's response is to disconnect the virtual machine to permit a clean reconnection of the user. If such a CSW also requires a vary on or enable to restore the line to operation that is acceptable as long as the disconnect occurs.

Dave
John P. Hartmann
2013-05-29 13:59:22 UTC
Permalink
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by dhdurgee
**
Unit check alone on initial status is also valid. But I don't think
Hercules knows of initial status other than a list of immediate CCW
command
codes for each device type.
Post by John P. Hartmann
**
Post by John P. Hartmann
The status for a local 3270 being powered off is CE UC (possibly
with DE)
Post by John P. Hartmann
Post by John P. Hartmann
and sense Intervention Required. But on a real terminal, if memory
serves,
Post by John P. Hartmann
the drop comes when the terminal goes ready, that is, presents an
unsolicited device end.
Hmm... in that case perhaps I should add a CSW_CE and see what happens.
Thank you for your response.
Dave
I added CSW_CE but that still does not result in placing the virtual
machine in a disconnected state. Is there a principles of operations manual
available for channel programming that defines what the expected responses
to CSW bits are for VM? For this to work properly the CSW must be set such
that VM's response is to disconnect the virtual machine to permit a clean
reconnection of the user. If such a CSW also requires a vary on or enable
to restore the line to operation that is acceptable as long as the
disconnect occurs.
Dave
[Non-text portions of this message have been removed]
Ivan Warren
2013-05-29 14:13:55 UTC
Permalink
-----Message d'origine-----
De : hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] De
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
À : hercules-390-***@public.gmane.org
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly

An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as not
ready by 1) Attempting to perform an operation 2) by making the device ready
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
dhdurgee
2013-05-29 15:00:27 UTC
Permalink
Post by Ivan Warren
-----Message d'origine-----
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as not
ready by 1) Attempting to perform an operation 2) by making the device ready
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
Perhaps I need to back up and clarify the situation I am attempting to address. I am looking at the case where a tn3270 has been established to hercules and the user has logged into VM, in my case VM/ESA 1.5 (370 feature) in particular. As the user would likely be running APL2 the 3270 session would generally be in VM READ state, thus I would expect a read CCW of some kind has been issued and is awaiting completion.

I need to properly handle the case where the tn3270 connection is disrupted, In this case I am simulating this case by asking the 3270 client to disconnect. This is indeed being detected by hercules, as my console log lists:

HHCTE007I 3270 device xxxx client yyy.yyy.yyy.yyy connection closed.

I would expect this to result in VM placing the virtual machine in disconnected status, as it does when I do this with a session to my P/370 system. At present this does NOT happen, the virtual machine remains connected to the disconnected line.

Currently console.c shows CSW_ATTN | CSW_UC | CSW_DE being returned when the above error is logged. This does not result in VM disconnecting the virtual machine. What do I need to set as the return in this circumstance in order for VM to disconnect the virtual machine so it can be cleanly reconnected later?

As this is in the console.c any changes made will apply specifically to 3270 console devices, not any other devices. I will also need to address a similar situation with 1050/3215 console devices, which are associated with a different error message.

If you need more information to assist me please let me know what you need me to trace or log for you.

Dave
Gregg Levine
2013-05-29 15:13:04 UTC
Permalink
Post by dhdurgee
Post by Ivan Warren
-----Message d'origine-----
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as not
ready by 1) Attempting to perform an operation 2) by making the device ready
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
Perhaps I need to back up and clarify the situation I am attempting to address. I am looking at the case where a tn3270 has been established to hercules and the user has logged into VM, in my case VM/ESA 1.5 (370 feature) in particular. As the user would likely be running APL2 the 3270 session would generally be in VM READ state, thus I would expect a read CCW of some kind has been issued and is awaiting completion.
HHCTE007I 3270 device xxxx client yyy.yyy.yyy.yyy connection closed.
I would expect this to result in VM placing the virtual machine in disconnected status, as it does when I do this with a session to my P/370 system. At present this does NOT happen, the virtual machine remains connected to the disconnected line.
Currently console.c shows CSW_ATTN | CSW_UC | CSW_DE being returned when the above error is logged. This does not result in VM disconnecting the virtual machine. What do I need to set as the return in this circumstance in order for VM to disconnect the virtual machine so it can be cleanly reconnected later?
As this is in the console.c any changes made will apply specifically to 3270 console devices, not any other devices. I will also need to address a similar situation with 1050/3215 console devices, which are associated with a different error message.
If you need more information to assist me please let me know what you need me to trace or log for you.
Dave
Hello!
Dave, are you a member of the H390-VM group? If not you should be.
John I know you are, (or if you aren't I'm thinking of someone else),
Vanya you were last time I looked; I believe we should convene there
to continue this discussion.

And Dave Wade, and you too Vanya, and even you Fish, the problem our
correspondent is relating is no one's fault, not even all of you.
Although I might be tempted to blame a guy named Murphy for all of ten
minutes.
-----
Gregg C Levine gregg.drwho8-***@public.gmane.org
"This signature fought the Time Wars, time and again."
dhdurgee
2013-05-29 15:24:39 UTC
Permalink
Post by Gregg Levine
Post by dhdurgee
Post by Ivan Warren
-----Message d'origine-----
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as not
ready by 1) Attempting to perform an operation 2) by making the device ready
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
Perhaps I need to back up and clarify the situation I am attempting to address. I am looking at the case where a tn3270 has been established to hercules and the user has logged into VM, in my case VM/ESA 1.5 (370 feature) in particular. As the user would likely be running APL2 the 3270 session would generally be in VM READ state, thus I would expect a read CCW of some kind has been issued and is awaiting completion.
HHCTE007I 3270 device xxxx client yyy.yyy.yyy.yyy connection closed.
I would expect this to result in VM placing the virtual machine in disconnected status, as it does when I do this with a session to my P/370 system. At present this does NOT happen, the virtual machine remains connected to the disconnected line.
Currently console.c shows CSW_ATTN | CSW_UC | CSW_DE being returned when the above error is logged. This does not result in VM disconnecting the virtual machine. What do I need to set as the return in this circumstance in order for VM to disconnect the virtual machine so it can be cleanly reconnected later?
As this is in the console.c any changes made will apply specifically to 3270 console devices, not any other devices. I will also need to address a similar situation with 1050/3215 console devices, which are associated with a different error message.
If you need more information to assist me please let me know what you need me to trace or log for you.
Dave
Hello!
Dave, are you a member of the H390-VM group? If not you should be.
John I know you are, (or if you aren't I'm thinking of someone else),
Vanya you were last time I looked; I believe we should convene there
to continue this discussion.
Will be happy to take it there if you feel it more appropriate. I will create a new topic there restating the problem.

Dave
Dave Wade
2013-05-29 18:10:43 UTC
Permalink
Post by dhdurgee
Post by Gregg Levine
Post by dhdurgee
Post by Ivan Warren
-----Message d'origine-----
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as not
ready by 1) Attempting to perform an operation 2) by making the device ready
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
Perhaps I need to back up and clarify the situation I am attempting to address. I am looking at the case where a tn3270 has been established to hercules and the user has logged into VM, in my case VM/ESA 1.5 (370 feature) in particular. As the user would likely be running APL2 the 3270 session would generally be in VM READ state, thus I would expect a read CCW of some kind has been issued and is awaiting completion.
HHCTE007I 3270 device xxxx client yyy.yyy.yyy.yyy connection closed.
I would expect this to result in VM placing the virtual machine in disconnected status, as it does when I do this with a session to my P/370 system. At present this does NOT happen, the virtual machine remains connected to the disconnected line.
Currently console.c shows CSW_ATTN | CSW_UC | CSW_DE being returned when the above error is logged. This does not result in VM disconnecting the virtual machine. What do I need to set as the return in this circumstance in order for VM to disconnect the virtual machine so it can be cleanly reconnected later?
As this is in the console.c any changes made will apply specifically to 3270 console devices, not any other devices. I will also need to address a similar situation with 1050/3215 console devices, which are associated with a different error message.
If you need more information to assist me please let me know what you need me to trace or log for you.
Dave
Hello!
Dave, are you a member of the H390-VM group? If not you should be.
John I know you are, (or if you aren't I'm thinking of someone else),
Vanya you were last time I looked; I believe we should convene there
to continue this discussion.
Will be happy to take it there if you feel it more appropriate. I will create a new topic there restating the problem.
Dave
I don't believe its a VM problem its a Hercules problem. Here should be
fine...
Post by dhdurgee
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Dave Wade G4UGM
Illegitimi Non Carborundum
dhdurgee
2013-05-29 18:45:37 UTC
Permalink
Post by Dave Wade
Post by dhdurgee
Post by Gregg Levine
Post by dhdurgee
Post by Ivan Warren
-----Message d'origine-----
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as not
ready by 1) Attempting to perform an operation 2) by making the device ready
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
Perhaps I need to back up and clarify the situation I am attempting to address. I am looking at the case where a tn3270 has been established to hercules and the user has logged into VM, in my case VM/ESA 1.5 (370 feature) in particular. As the user would likely be running APL2 the 3270 session would generally be in VM READ state, thus I would expect a read CCW of some kind has been issued and is awaiting completion.
HHCTE007I 3270 device xxxx client yyy.yyy.yyy.yyy connection closed.
I would expect this to result in VM placing the virtual machine in disconnected status, as it does when I do this with a session to my P/370 system. At present this does NOT happen, the virtual machine remains connected to the disconnected line.
Currently console.c shows CSW_ATTN | CSW_UC | CSW_DE being returned when the above error is logged. This does not result in VM disconnecting the virtual machine. What do I need to set as the return in this circumstance in order for VM to disconnect the virtual machine so it can be cleanly reconnected later?
As this is in the console.c any changes made will apply specifically to 3270 console devices, not any other devices. I will also need to address a similar situation with 1050/3215 console devices, which are associated with a different error message.
If you need more information to assist me please let me know what you need me to trace or log for you.
Dave
Hello!
Dave, are you a member of the H390-VM group? If not you should be.
John I know you are, (or if you aren't I'm thinking of someone else),
Vanya you were last time I looked; I believe we should convene there
to continue this discussion.
Will be happy to take it there if you feel it more appropriate. I will create a new topic there restating the problem.
Dave
I don't believe its a VM problem its a Hercules problem. Here should be
fine...
It would appear that the H390-VM group agrees with you, as I posted the issue there three hours ago without a response, I likewise thought it a hercules issue else I would have posted there in the first place.

Perhaps it is an issue specifically related to VM/ESA 1.5 as configured to run on a P/370 being run by hercules. If so, the solution might not be of general use. In that case perhaps a configuration switch defaulted the current way could address it.

Dave
dhdurgee
2013-05-29 20:14:28 UTC
Permalink
As I saw no improvement by removing the CSW_DE that had been there I added it back in and then ran make and make install. I tried using device trace on hercules to see what was happening with the following results:

HHCCP049I 0200:Stat=0C00 Count=01E7 CCW=FA5AE0 +
HHCCP048I 0200:CCW=4B000000 60000001=>000C0000 000008E8 00000000 00F7C000 .......Y.....7{.
HHCCP075I 0200:Stat=0C00 Count=0001
HHCCP048I 0200:CCW=01FA4FD0 A0000009=>C211E560 133CE76B 00D6D540 C1E340F1 B.V-..X,.ON AT 1
HHCCP075I 0200:Stat=0C00 Count=0000
HHCCP048I 0200:CCW=08F89328 A0000001=>00F8933D 6000000F 03000000 20000001 .8l.-...........
HHCCP048I 0200:CCW=00F8933D 6000000F=>114C6028 41002842 F7984095 28000040 .<-.....7q n...
HHCCP075I 0200:Stat=0C00 Count=0000
HHCCP048I 0200:CCW=03000000 20000001=>000C0000 000008E8 00000000 00F7C000 .......Y.....7{.
HHCCP075I 0200:Stat=0C00 Count=0001
HHCCP049I 0200:Stat=0C00 Count=0001 CCW=F89338
HHCCP048I 0200:CCW=4B000000 60000001=>000C0000 000008E8 00000000 00F7C000 .......Y.....7{.
HHCCP075I 0200:Stat=0C00 Count=0001
HHCCP048I 0200:CCW=01FA5B3C 6000002D=>C2114DF0 28410028 42F5D6D7 C5D9C1E3 B.(0.....5OPERAT
HHCCP075I 0200:Stat=0C00 Count=0000
HHCCP048I 0200:CCW=03000000 20000001=>000C0000 000008E8 00000000 00F7C000 .......Y.....7{.
HHCCP075I 0200:Stat=0C00 Count=0001
HHCCP049I 0200:Stat=0C00 Count=0001 CCW=FA5B38
HHCCP048I 0200:CCW=4B000000 60000001=>000C0000 000008E8 00000000 00F7C000 .......Y.....7{.
HHCCP075I 0200:Stat=0C00 Count=0001
HHCCP048I 0200:CCW=01FA5B3C 60000028=>C2114F40 28410028 42F4D985 8184A85E B.. .....4Ready;
HHCCP075I 0200:Stat=0C00 Count=0000
HHCCP048I 0200:CCW=03000000 20000001=>000C0000 000008E8 00000000 00F7C000 .......Y.....7{.
HHCCP075I 0200:Stat=0C00 Count=0001
HHCCP049I 0200:Stat=0C00 Count=0001 CCW=FA5B38
HHCTE007I 3270 device 0200 client 192.168.80.14 connection closed
/(0009) q n
15:02:24 4243 - 0200, OPERATOR - 0009
Ready; T=0.01/0.01 15:02:24
/(0009) q 200
15:02:30 GRAF 0200 LOGON AS 4243
Ready; T=0.01/0.01 15:02:30
/(0009) force 4243
Ready; T=0.01/0.01 15:02:41
15:02:42 GRAF 0200 LOGOFF AS 4243 USERS = 001 FORCED
/(0009) q 200
15:02:50 GRAF 0200 ENABLED
Ready; T=0.01/0.01 15:02:50
/(0009) q n
15:05:38 OPERATOR - 0009
Ready; T=0.01/0.01 15:05:38
/(0009) shutdown
HHCCP053I 0200: Halt I/O
HHCCP049I 0200:Stat=0C00 Count=0001 CCW=FA5B38
HHCCP049I 0200:Stat=0C00 Count=0001 CCW=FA5B38


DMKCKP960I SYSTEM WARM START DATA SAVED

DMKCKP961W SYSTEM SHUTDOWN COMPLETE

HHCCP011I CPU0000: Disabled wait state
PSW=000A0000 00000008

I was puzzled to see that the device trace showed nothing after the disconnect of the tn3270 client until system shutdown. Any idea why I am seeing this behavior?

Dave
paoloG
2013-06-01 04:07:01 UTC
Permalink
Hi Dave,

I'll post the answer also in this forum as the problem seems to be Hercules related.

Here's a quick and dirty correction:
in console.c, find the line:

'logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),',

This is the block of code that handles TN3270 disconnections
Insert this line:

device_attention (dev, CSW_DE);

just before the return line:

return (CSW_ATTN | CSW_UC);

Now when I disconnect the TN3270 session the Virtual Machine is forced to disconnect, as it happens in your P/370 environment.

I must confess I don't remember the behaviour of real 3278 when powered off - I hanven't seen one of them for over 20 years ;-)...

Regards.

Paul
snipped<
I was puzzled to see that the device trace showed nothing after the disconnect of the tn3270 client until system shutdown. Any idea why I am seeing this behavior?
Dave
Gerhard Postpischil
2013-06-01 06:56:42 UTC
Permalink
Post by paoloG
I must confess I don't remember the behaviour of real 3278 when powered off - I hanven't seen one of them for over 20 years ;-)...
Local non-SNA CRTs do absolutely nothing when powered off; like other
local devices, they generate a not-ready/ready interrupt when powered
on. I have no idea how VM detects the disconnect (polling?).

I consider the problem due to the Hercules implementation decision of
treating tn3270(e) connections as local non-SNA, rather than supporting
them as BSC or SNA connections. The latter in dial-up mode could provide
detection of disconnects. I would guess that the local non-SNA
implementation was a quick effort, with the advantage of being OS
independent, whereas the remote modes would prove restrictive (e.g., no
TCAM support for SNA). Of course it's not too late to provide additional
connection modes.

Gerhard Postpischil
Bradford, Vermont
Dave
2013-06-01 08:15:41 UTC
Permalink
Post by Gerhard Postpischil
Post by paoloG
I must confess I don't remember the behaviour of real 3278 when powered off - I hanven't seen one of them for over 20 years ;-)...
Local non-SNA CRTs do absolutely nothing when powered off; like other
local devices, they generate a not-ready/ready interrupt when powered
on. I have no idea how VM detects the disconnect (polling?).
I consider the problem due to the Hercules implementation decision of
treating tn3270(e) connections as local non-SNA, rather than supporting
them as BSC or SNA connections.
Some of the OS's we use , such as MTS don't have remote terminal support
included....
Post by Gerhard Postpischil
The latter in dial-up mode could provide
detection of disconnects. I would guess that the local non-SNA
implementation was a quick effort, with the advantage of being OS
independent, whereas the remote modes would prove restrictive (e.g., no
TCAM support for SNA). Of course it's not too late to provide additional
connection modes.
Gerhard Postpischil
Bradford, Vermont
------------------------------------
John P. Hartmann
2013-06-01 08:17:50 UTC
Permalink
Post by Gerhard Postpischil
**
would guess that the local non-SNA
implementation was a quick effort, with the advantage of being OS
independent, whereas the remote modes would
It also has the minor advantage that you can IPL and bring up an XA
operating system.


[Non-text portions of this message have been removed]
Gerhard Postpischil
2013-06-01 14:44:31 UTC
Permalink
Post by John P. Hartmann
It also has the minor advantage that you can IPL and bring up an XA
operating system.
We'll worry about that when we get a legal X/A system <g>
But that's why I called it a "quick" implementation, as it's fine for
static connections.

Gerhard Postpischil
Bradford, Vermont
"Fish" (David B. Trout)
2013-06-01 15:20:58 UTC
Permalink
PEBKAC.

There is no problem in Hercules to be corrected. Hercules is working
correctly.

Unsolicited device attention interrupts are not generated (indeed CANNOT be
generated when you think about it) when a device is powered off.
Unsolicited device attention interrupts can only be generated when the
device is powered ON.

Think about it.

When you're talking to someone on the phone can the connection is dropped,
the only way you can discover it is when you say something to the other
person (asking them a question perhaps) and expect a response and do not get
one:

"So, what do you think Paul? ... Paul? ... Hello? .... Paul? Are you
there? ... Hello?"

You cannot expect the other person to let you know whenever the connection
is severed since, if the connection is severed, how the hell can they tell
you?! There is no connection to "tell you" anything!

The only thing you can do is make note that the connection has been dropped
(Unit Check, Sense = Intervention Required) and then wait for them to call
you back (i.e. wait for them to let you know whenever they've re-established
the connection).

Same with local 3270: powering off does nothing. It does not notify the
program (i.e. the operating system) of ANYTHING. It is only when the device
becomes READY again as a result of powering it ON that an UNSOLICITED(*)
device attention interrupt is generated. Then and only then does the
program learn about the disconnection.

(Except in the previously mentioned case of course where the program tries
communicating to the device after it has been powered off at which point it
gets intervention required. That's the only other way it can learn about a
dropped terminal.)

Bottom line: there is no "Hercules problem" to be "corrected".

I suspect the P/390 likely deviates from normal behavior on purpose and
presents the device attention interrupt whenever the tn3270 client
disconnects. After all, detecting that a TCP/IP network socket connection
has been closed is rather trivial. How you react to the connection being
closed is your business. Hercules logs a message but otherwise does nothing
else. The P/390 probably presents the program with an unsolicited device
attention, which is obviously what you want Hercules to do.

But Hercules is not a P/390 and likely never shall be.

Now if you'd like to ask that we perhaps provide a new 3270 device statement
option to automatically generate the device attention interrupt upon
detection that the connection has been reset, then we might consider such an
option. Maybe. I don't know. Such a thing would have to be discussed with
the other developers.

But to call it a problem with Hercules that needs correcting?

No. Wrong. 100% untrue. :)

p.s. Sorry for the long post.
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
Joe Monk
2013-06-01 18:52:41 UTC
Permalink
When you're talking to someone on the phone can the connection is dropped,
the only way you can discover it is when you say something to the other
person (asking them a question perhaps) and expect a response and do not get
one:

Incorrect. Ever hear of CD (Carrier Detect)? Carrier Detect goes away, then
an unsolicited interrupt is generated... Telling the operator that the line
dropped. Especially for NCP/VTAM with a Sync Modem attached 3270.

And when you are talking on the phone, and the connection is disconnected,
if you hang on the line long enough, you will get the off-hook tone (a loud
screech-screech-screech).

Joe


On Sat, Jun 1, 2013 at 10:20 AM, "Fish" (David B. Trout)
Post by "Fish" (David B. Trout)
PEBKAC.
There is no problem in Hercules to be corrected. Hercules is working
correctly.
Unsolicited device attention interrupts are not generated (indeed CANNOT be
generated when you think about it) when a device is powered off.
Unsolicited device attention interrupts can only be generated when the
device is powered ON.
Think about it.
When you're talking to someone on the phone can the connection is dropped,
the only way you can discover it is when you say something to the other
person (asking them a question perhaps) and expect a response and do not get
"So, what do you think Paul? ... Paul? ... Hello? .... Paul? Are you
there? ... Hello?"
You cannot expect the other person to let you know whenever the connection
is severed since, if the connection is severed, how the hell can they tell
you?! There is no connection to "tell you" anything!
The only thing you can do is make note that the connection has been dropped
(Unit Check, Sense = Intervention Required) and then wait for them to call
you back (i.e. wait for them to let you know whenever they've
re-established
the connection).
Same with local 3270: powering off does nothing. It does not notify the
program (i.e. the operating system) of ANYTHING. It is only when the device
becomes READY again as a result of powering it ON that an UNSOLICITED(*)
device attention interrupt is generated. Then and only then does the
program learn about the disconnection.
(Except in the previously mentioned case of course where the program tries
communicating to the device after it has been powered off at which point it
gets intervention required. That's the only other way it can learn about a
dropped terminal.)
Bottom line: there is no "Hercules problem" to be "corrected".
I suspect the P/390 likely deviates from normal behavior on purpose and
presents the device attention interrupt whenever the tn3270 client
disconnects. After all, detecting that a TCP/IP network socket connection
has been closed is rather trivial. How you react to the connection being
closed is your business. Hercules logs a message but otherwise does nothing
else. The P/390 probably presents the program with an unsolicited device
attention, which is obviously what you want Hercules to do.
But Hercules is not a P/390 and likely never shall be.
Now if you'd like to ask that we perhaps provide a new 3270 device statement
option to automatically generate the device attention interrupt upon
detection that the connection has been reset, then we might consider such an
option. Maybe. I don't know. Such a thing would have to be discussed with
the other developers.
But to call it a problem with Hercules that needs correcting?
No. Wrong. 100% untrue. :)
p.s. Sorry for the long post.
--
"Fish" (David B. Trout)
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
[Non-text portions of this message have been removed]
"Fish" (David B. Trout)
2013-06-01 20:51:52 UTC
Permalink
Joe Monk wrote:

<snip my stuff>
Post by Joe Monk
Incorrect. Ever hear of CD (Carrier Detect)? Carrier Detect
goes away, then an unsolicited interrupt is generated...
Telling the operator that the line dropped. Especially for
NCP/VTAM with a Sync Modem attached 3270. [...]
Oh, for crying out loud... <me: rolls eyes>

So okay, maybe the telephone analogy isn't 100% technically accurate, but it
does serve to illustrate the general idea: you can't ask the other person to
let you know if/when the connection is lost because when the connection is
lost THEY are unable to tell you the connection is lost.

I was trying to be illustrative by explaining things in simple, easy to
understand terms, not to be 100% technically accurate for crying out loud.
Sheesh. :)
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
somitcw
2013-06-01 19:41:41 UTC
Permalink
Post by "Fish" (David B. Trout)
PEBKAC.
There is no problem in Hercules to be corrected.
Hercules is working correctly.
Unsolicited device attention interrupts are not generated
(indeed CANNOT be generated when you think about it) when
a device is powered off. Unsolicited device attention
interrupts can only be generated when the device is powered
ON.
Think about it.
- - - most snipped - - -

I'm too old to think, but here goes the attempt:

Does the 3270 send unsolicited device status when powered
off or when powered on? No it doesn't ever send any
unsolicited status at any time for anything. The control
unit is the one doing the sending and it knows when the CRT
goes up or down. When the CRT is powered up or down, the
control unit normally remains powered up.
Post by "Fish" (David B. Trout)
I suspect the P/390 likely deviates from normal behavior
on purpose and presents the device attention interrupt
whenever the tn3270 client disconnects. After all,
detecting that a TCP/IP network socket connection has
been closed is rather trivial. How you react to the
connection being closed is your business. Hercules logs
a message but otherwise does nothing else. The P/390
probably presents the program with an unsolicited device
attention, which is obviously what you want Hercules to do.
But Hercules is not a P/390 and likely never shall be.
But the P/390 is trying to use a TCP/IP TN3270 telnet
to emulate the same thing that Hercules is. IBM got it
right or at least like it should work to be secure.
Hercules opened a security flaw that someone could drive
a truck through and that if it were IBM code, many
customers would APAR. IBM always accepts APARs for
manufactured security holes.
Post by "Fish" (David B. Trout)
Now if you'd like to ask that we perhaps provide a new
3270 device statement option to automatically generate
the device attention interrupt upon detection that the
connection has been reset, then we might consider such
an option. Maybe. I don't know. Such a thing would
have to be discussed with the other developers.
Did the IBM P/390 code trying to emulate exactly what
Hercules emulates have a TN3270 security enabled/disabled
option? If so, it would be nice to see one for Hercules.
The default of course should be: TN3270-SECURITY ENABLED
with loud messages if anyone selects the un-secure option.
Post by "Fish" (David B. Trout)
But to call it a problem with Hercules that needs
correcting?
No. Wrong. 100% untrue. :)
p.s. Sorry for the long post.
--
"Fish" (David B. Trout)
How do the multiple TCP/IP TN3270 telnet stay-alive
options relate? Perhaps, not at all?
"Fish" (David B. Trout)
2013-06-01 21:12:35 UTC
Permalink
somitcw wrote:

[...]
Post by somitcw
How do the multiple TCP/IP TN3270 telnet stay-alive
options relate? Perhaps, not at all?
TCP/IP keep-alive -- which Hercules does support(*) and is enabled by
default -- detects when the TCP/IP *stack* at the other end of the
connection becomes unresponsive. It does not detect unresponsive clients.

The idea behind TCP/IP keep-alive (Hercules CONKPALV option) is to detect
when, for example, the operating system the client is running on crashes.
(I'm talking about the scenario where the tn3270 session is running on one
host system and Hercules is running on a completely different host system.)

When the TCP/IP connection is established, you basically have two TCP/IP
stacks talking to one another, except that NORMALLY the stacks don't
actually "talk" to one another unless one of the client at either end has
something to say to the other.

With TCP/IP keep-alive however, once the logical TCP/IP connection between
the client and server is established, the two TCP/IP stacks themselves --
NOT the client and server applications -- send "keep-alive" probes to one
another on a periodic basis. The client and server applications may be
completely idle, neither side needing to send any data at all to the other.
The two TCP/IP STACKS however (when keep-alive is enabled), are constantly
sending each other data back and forth in order to detect when the
connection is lost.

This is completely different from a TCP/IP client application simply closing
the logical connection TCP/IP connection with the server at the other end
(which is the original topic under discussion). The CONKPALV option
won't/doesn't help in this situation.
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org

(*) http://www.hercules-390.eu/hercconf.html#CONKPALV




------------------------------------
"Fish" (David B. Trout)
2013-06-01 21:28:30 UTC
Permalink
somitcw wrote:

[...]
Post by somitcw
Does the 3270 send unsolicited device status when
powered off or when powered on?
Powered on.
Post by somitcw
No it doesn't ever send any unsolicited status at any
time for anything. The control unit is the one doing
the sending and it knows when the CRT goes up or down.
Okay, fine. That's technically correct.
Post by somitcw
When the CRT is powered up or down, the control unit
normally remains powered up.
True.


[...]
Post by somitcw
But the P/390 is trying to use a TCP/IP TN3270
telnet to emulate the same thing that Hercules is.
IBM got it right or at least like it should work
to be secure.
No, IBM implemented a stop-gap temporary solution.
Post by somitcw
Hercules opened a security flaw that someone could
drive a truck through and that if it were IBM code,
many customers would APAR. IBM always accepts APARs
for manufactured security holes.
No. Wrong. EMPHATICALLY wrong. Hercules did NOT open ANY security flaw.

It is the guest operating system which is failing to properly deal with the
situation that is the one with the security flaw. Not the hardware
(Hercules). It is not the hardware's responsibility in this particular case
to implement security (to close the described security hole). It is the
operating system's.


[...]
Post by somitcw
Did the IBM P/390 code trying to emulate exactly
what Hercules emulates have a TN3270 security enabled/
/disabled option? If so, it would be nice to see one
for Hercules. The default of course should be: TN3270-
-SECURITY ENABLED with loud messages if anyone selects
the un-secure option.
If you use an insecure guest operating system or one with known security
holes, is it Hercules's (the hardware's) responsibility to implement special
features to close/address said security flaw?

Or is it the operating system's? (that is ultimately responsible for
dealing with the hardware it utilizes in a safe and secure manner)

Hint: it's the latter.
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
Tony Harminc
2013-06-01 23:50:52 UTC
Permalink
Post by somitcw
Hercules opened a security flaw that someone could drive
a truck through and that if it were IBM code, many
customers would APAR. IBM always accepts APARs for
manufactured security holes.
Well, Hercules didn't open it. It became well known when people
started running guest OSs under VM, and used the DIAL facility and/or
VM/PassThrough (PVM). Somewhere around 1984 I tried to APAR the
situation where we moved a system running CICS on MVS to a virtual
machine on a 4341 under VM/SP, and ran into the problem that CICS
users would drop their DIALed connection and someone else would DIAL
and find themselves connected to the first user's session. Turns out
there was (is) a CICS gen option to disconnect on the unsolicited
Device End that we've all been talking about, but it wasn't the
default, and no one in the shop had thought of the situation before.
(This was at a time when it was normal for CICS security to ba based
on terminal ID and there was no logon at all!)
Post by somitcw
Did the IBM P/390 code trying to emulate exactly what
Hercules emulates have a TN3270 security enabled/disabled
option? If so, it would be nice to see one for Hercules.
The default of course should be: TN3270-SECURITY ENABLED
with loud messages if anyone selects the un-secure option.
Of course if you accidently disconnect from your MVS console session,
things aren't going to go too well if you can't reconnect to it.

I think great care needs to be taken before deciding to make Hercules
behaviour differ from that of the real hardware. Not that it should
never be done - clearly hercules isn't real hardware, and there are
some inevitable differences - but it should be well thought through
rather than just being declared a bug and changed incompatibly.

Tony H.
somitcw
2013-06-02 02:18:01 UTC
Permalink
Post by Tony Harminc
Post by somitcw
Hercules opened a security flaw that someone could drive
a truck through and that if it were IBM code, many
customers would APAR. IBM always accepts APARs for
manufactured security holes.
Well, Hercules didn't open it. It became well known when
people started running guest OSs under VM, and used the DIAL
facility and/or VM/PassThrough (PVM). Somewhere around 1984
I tried to APAR the situation where we moved a system running
CICS on MVS to a virtual machine on a 4341 under VM/SP, and
ran into the problem that CICS users would drop their DIALed
connection and someone else would DIAL and find themselves
connected to the first user's session. Turns out there was
(is) a CICS gen option to disconnect on the unsolicited
Device End that we've all been talking about, but it wasn't
the default, and no one in the shop had thought of the
situation before. (This was at a time when it was normal
for CICS security to ba based on terminal ID and there was
no logon at all!)
Post by somitcw
Did the IBM P/390 code trying to emulate exactly what
Hercules emulates have a TN3270 security enabled/disabled
option? If so, it would be nice to see one for Hercules.
The default of course should be: TN3270-SECURITY ENABLED
with loud messages if anyone selects the un-secure option.
Of course if you accidently disconnect from your MVS
console session, things aren't going to go too well if you
can't reconnect to it.
MVS hasn't needed consoles this century. My operator
liked to connect one when shutting down but that was him.
Even MVT-II would run after all consoles were lost until
the WTO buffers filled up. A C.E. replaced our 1052 on
a running MVT-II system about 1973 and then he asked how
we made our operating system recover the console, he
pressed the External Interrupt button that I indicated.
Post by Tony Harminc
I think great care needs to be taken before deciding
to make Hercules behaviour differ from that of the real
hardware. Not that it should never be done - clearly
hercules isn't real hardware, and there are some
inevitable differences - but it should be well thought
through rather than just being declared a bug and
changed incompatibly.
Tony H.
You understand that emulating a hard-wired dumb CRT
into someone's office with a dynamically created and
dropped TCP/IP connections, then the disconnect issue
must be handled. IBM goofed then fixed their issue.
The P/390 came already fixed. Hercules opened a gigantic
security hole that does not exist on hard-wired CRT
terminals. Emulation is not correct.

Hercules could go in the opposite direction than
IBM went but I wouldn't advise it. Hercules could
insure that any tn3270 reconnecting to a terminal
CCCU address is the same IP number, port, and all
else the same as the previous connection. Since that
isn't reasonable, IBM's solution might be better.
"Fish" (David B. Trout)
2013-06-02 09:06:38 UTC
Permalink
somitcw wrote:

[...]
Post by somitcw
You understand that emulating a hard-wired
dumb CRT into someone's office with a dynamically
created and dropped TCP/IP connections, then the
disconnect issue must be handled. IBM goofed
then fixed their issue. The P/390 came already fixed.
Hercules opened a gigantic security hole that does
not exist on hard-wired CRT terminals.
Wrong. Very wrong.

If a user simply turns off (powers off) a REAL hard-wired local 3270
terminal without first logging off, then the next person to come along and
turns on (powers on) that same 3270 terminal is immediately reconnected to
the very same session as the previous person who stupidly turned it off
without logging off first. 3270 terminals have ALWAYS behaved that way.

The security issue is in the operating system and software that USES the
3270 terminals. When the unsolicited device attention interrupt when you
turn on (power on) the terminal occurs, the operating system and/or software
using that terminal should deal with the situation in a secure manner by
logical "disconnecting" the previous user-id's logical session (whether the
logical session is a VM userid or a z/OS VTAM/TSO session or some other
logical software session).

Hercules is correct.

The guest operating system/software is wrong.
Post by somitcw
Emulation is not correct.
Wrong. The emulation is correct.

The guest operating system/software is wrong.
Post by somitcw
Hercules could go in the opposite direction than
IBM went but I wouldn't advise it. Hercules could
insure that any tn3270 reconnecting to a terminal
CCCU address is the same IP number, port, and all
else the same as the previous connection. Since that
isn't reasonable, IBM's solution might be better.
Hercules does support IP numbers and subnet masks in its 3270 device
statement options:

http://www.hercules-390.eu/hercconf.html#3270


This option was created to make it easier to mitigate this very situation
we've been arguing about.

But the bottom line is, Hercules is NOT responsible to ensuring the guest
operating system/software uses 3270 terminals in a safe/secure manner.
Period.
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
Gerhard Postpischil
2013-06-02 02:44:20 UTC
Permalink
Post by Tony Harminc
I think great care needs to be taken before deciding to make Hercules
behaviour differ from that of the real hardware. Not that it should
never be done - clearly hercules isn't real hardware, and there are
some inevitable differences - but it should be well thought through
rather than just being declared a bug and changed incompatibly.
I agree that's its too late to change existing behavior, but it would be
nice to support both fixed and temporary connections.

Hercules supports DASD, tape, and unit record devices natively. The
point that Trout missed is that the original development failed to
provide analogous support for local non-SNA 3270s, but instead adopted
the kludge of supporting permanent links on a transient connection.
Using existing tn3270(e) software was the equivalent of stuffing a round
peg in a square hole.

Gerhard Postpischil
Bradford, Vermont
"Fish" (David B. Trout)
2013-06-02 09:17:38 UTC
Permalink
(partial piggyback)
Post by Tony Harminc
I think great care needs to be taken before deciding
to make Hercules behaviour differ from that of the real
hardware. Not that it should never be done - clearly
hercules isn't real hardware, and there are some inevitable
differences - but it should be well thought through
rather than just being declared a bug and changed incompatibly.
Thank you Tony.


[...]
The point that Trout missed is that the original development
failed to provide analogous support for local non-SNA 3270s,
but instead adopted the kludge of supporting permanent links
on a transient connection.
I respectfully disagree.

The transient connection nature of a tn3270 session is completely analogous
to turning off (powering off) a hard-wired local 3270 terminal. You should
not turn off your terminal (disconnect your tn3270 session) without first
logging off of whatever software product you're using (e.g. VM userid
session, z/OS TSO session, etc).

TCP/IP tn3270 sessions becoming unintentionally/unexpectedly disconnected is
completely analogous to losing power on your hard-wired local 3270 terminal,
and it is the responsibility of the software that is using the device to
deal with "unexpected" session disconnects, NOT the hardware.

Hercules is behaving correctly.

It is the guest operating system and/or software that is misbehaving in an
unsafe/insecure manner.
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org





------------------------------------
John P. Hartmann
2013-06-02 11:31:35 UTC
Permalink
I concur:

HHC01022I 0:03C0 COMM: client 192.168.2.32 devtype 3270: connection closed
by
client

HHC01018I 0:03C0 COMM: client 192.168.2.32 devtype 3270:
connected

11:41:59 GRAF 03C0 DISCONNECT MAINT USERS = 20 FORCED BY SYSTEM

The device end generated by a client being connected to the local 3270
makes VM drop the active session. VM/370 has always behaved this way. So
should VM/ESA 1.5 whatever it is running on.

If the moan is that the P/390 forces the disconnect when it determines that
the TN session has been dropped rather than when a new client connects, the
moaner should cherish his P/390. Nothing else will behave this way,
possibly excepting the IBM 2074, which is the P/390 TN server (I used one
for three years, but don't recall how it behaved with dropped sessions,
perhaps because none ever dropped) in and expensive box with an ESCON
adapter for local attach of 3270s.
Post by "Fish" (David B. Trout)
Hercules is behaving correctly.
[Non-text portions of this message have been removed]
ikj1234i
2013-06-02 17:27:23 UTC
Permalink
Post by "Fish" (David B. Trout)
[...]
The point that Trout missed is that the original development
failed to provide analogous support for local non-SNA 3270s,
but instead adopted the kludge of supporting permanent links
on a transient connection.
I respectfully disagree.
The transient connection nature of a tn3270 session is completely analogous
to turning off (powering off) a hard-wired local 3270 terminal.
A better analogy is a dial-up connection drop. In both dial-up and TN3270 the reconnection appears on a random incoming port and some other means (LU name selection, XID, etc) may be used for identification, and in both the risk exists of undesired "tailgating" (inappropriate connection to a previously-active user session).
Post by "Fish" (David B. Trout)
You should
not turn off your terminal (disconnect your tn3270 session) without first
logging off of whatever software product you're using (e.g. VM userid
session, z/OS TSO session, etc).
You shouldn't? What happens if your tn3270 connection gets zapped due to TCP/IP issues in the network, before you've had a chance to logoff gracefully?
Post by "Fish" (David B. Trout)
TCP/IP tn3270 sessions becoming unintentionally/unexpectedly disconnected is
completely analogous to losing power on your hard-wired local 3270 terminal,
and it is the responsibility of the software that is using the device to
deal with "unexpected" session disconnects, NOT the hardware.
This is true enough, and there are IBM terminal environments that can properly be configured with "switched" lines (IBM-speak) which provide a proper mapping to tn3270 and its "transient" connections (such environments are not common).

However the non-SNA 3270 OS/MVS console is a fantastic example of code that is absolutely notorious for its maximal lack of grace in responding to '"unexpected" session disconnects'! The idea of a "switched" line OS console is .... a joke ...
Post by "Fish" (David B. Trout)
Hercules is behaving correctly.
I would tend to agree with this - it's difficult to imagine this as a "bug" in Hercules. However, it may be an impossible assertion to verify - a proper test would require access to equivalent IBM hardware for test/comparison purposes.
Post by "Fish" (David B. Trout)
It is the guest operating system and/or software that is misbehaving in an
unsafe/insecure manner.
A case could be made that user shouldn't expect this "secure" behaviour from a legacy program for which such a use case was never anticipated. Alternatively, a case could be made that the Hercules user has misconfigured his system when he attaches Hercules tn3270 ports having "switched" semantics to guest OS lines which are wholly "nonswitched"...

Best

Max
Gerhard Postpischil
2013-06-03 05:03:42 UTC
Permalink
Post by "Fish" (David B. Trout)
The transient connection nature of a tn3270 session is completely analogous
to turning off (powering off) a hard-wired local 3270 terminal. You should
not turn off your terminal (disconnect your tn3270 session) without first
logging off of whatever software product you're using (e.g. VM userid
session, z/OS TSO session, etc).
I was going to write a longer response, but Max already beat me to it.
At AMS, I had a 3290, 3279, and 3180 for program development, and an
asynchronous Wyse-50 for program entry (tabs make assembler coding
significantly faster. All of them had the characteristic that cycling
power resulted in them coming up at the same address, with the same
screen geometry.
Post by "Fish" (David B. Trout)
TCP/IP tn3270 sessions becoming unintentionally/unexpectedly disconnected is
completely analogous to losing power on your hard-wired local 3270 terminal,
and it is the responsibility of the software that is using the device to
deal with "unexpected" session disconnects, NOT the hardware.
No. When I lose my tn3270 connections, even if I reconnect in the same
sequence as after startup, I may wind up at a different address, and
with different screen geometry. Some OS and client combinations support
connection to a group or specific address, but not all.
Post by "Fish" (David B. Trout)
Hercules is behaving correctly.
It is the guest operating system and/or software that is misbehaving in an
unsafe/insecure manner.
Hercules may be behaving as designed, but the design is faulty.

Gerhard Postpischil
Bradford, Vermont


------------------------------------
"Fish" (David B. Trout)
2013-06-03 09:13:54 UTC
Permalink
Gerhard Postpischil
[...]
Post by Gerhard Postpischil
Post by "Fish" (David B. Trout)
TCP/IP tn3270 sessions becoming unintentionally/unexpectedly
disconnected is completely analogous to losing power on your
hard-wired local 3270 terminal, and it is the responsibility
of the software that is using the device to deal with
"unexpected" session disconnects, NOT the hardware.
No. When I lose my tn3270 connections, even if I reconnect in
the same sequence as after startup, I may wind up at a different
address, and with different screen geometry. Some OS and client
combinations support connection to a group or specific address,
but not all.
By "software" I did not mean the th3270 client. I meant the guest operating
system software (e.g. z/OS + VTAM, z/VM itself, etc).

As far as not reconnecting to the same device address, Hercules supports the
3270 device statement IP address and mask option (as well as the group name
option) in an attempt to try and mitigate this situation:

http://www.hercules-390.eu/hercconf.html#3270

Otherwise there is no other way for Hercules to "know" at what device
address an incoming tn3270 TCP/IP connection should connect at.

But if the guest operating system and associated software were properly
written to preventing such "tailgating" (GREAT word, that! Describes the
situation to a t!) then the issue you describe becomes moot.
Post by Gerhard Postpischil
Post by "Fish" (David B. Trout)
Hercules is behaving correctly.
It is the guest operating system and/or software that is
misbehaving in an unsafe/insecure manner.
Hercules may be behaving as designed, but the design is faulty.
Oh?! How so?
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
paoloG
2013-06-03 09:46:31 UTC
Permalink
Hi Fish,

surely Hercules management of local 3270 is very close to
a mainframe with local 3274-3174.

IBM chose not to notify the power off of a local 3270; it could be easily accomplished as 3274 knows very well the status of all the terminals connected with the coax cable, as it continuosly polls the terminals.

Probably IBM thought that the local 3274 was an environment stable,
not subjected to unwanted disconessions.

But IBM itself starting with P/370,and then with P/390 and z/PDT ,
modified the management of 3270 (emulated via TN3270), introducing
the notification of the equivalent of '3270 power off'.

IMHO Hercules is much closer to a P/370-P/390 that to a real mainframe
(the DASD and tape management is largely the same - terminal are emulated via TN3270), and z/PDT is even closer (CPU emulated via software).

So I don't see any harm to say that P/370 management of '3270 power off' is better than Hercules' one and avoids various issues, and if IBM is our guide in the darkness, it should be always followed.

Respectfully yours

Paul
Post by Gerhard Postpischil
Gerhard Postpischil
[...]
Post by Gerhard Postpischil
Post by "Fish" (David B. Trout)
TCP/IP tn3270 sessions becoming unintentionally/unexpectedly
disconnected is completely analogous to losing power on your
hard-wired local 3270 terminal, and it is the responsibility
of the software that is using the device to deal with
"unexpected" session disconnects, NOT the hardware.
No. When I lose my tn3270 connections, even if I reconnect in
the same sequence as after startup, I may wind up at a different
address, and with different screen geometry. Some OS and client
combinations support connection to a group or specific address,
but not all.
By "software" I did not mean the th3270 client. I meant the guest operating
system software (e.g. z/OS + VTAM, z/VM itself, etc).
As far as not reconnecting to the same device address, Hercules supports the
3270 device statement IP address and mask option (as well as the group name
http://www.hercules-390.eu/hercconf.html#3270
Otherwise there is no other way for Hercules to "know" at what device
address an incoming tn3270 TCP/IP connection should connect at.
But if the guest operating system and associated software were properly
written to preventing such "tailgating" (GREAT word, that! Describes the
situation to a t!) then the issue you describe becomes moot.
Post by Gerhard Postpischil
Post by "Fish" (David B. Trout)
Hercules is behaving correctly.
It is the guest operating system and/or software that is
misbehaving in an unsafe/insecure manner.
Hercules may be behaving as designed, but the design is faulty.
Oh?! How so?
--
"Fish" (David B. Trout)
au1john
2013-06-03 10:32:07 UTC
Permalink
I think you will also find that IBM has continued this behaviour with first
the 2074 and, with the now current, OSA-ICC.

For those who are not aware they provide a TN3270E client on the LAN/WAN
side and are defined/treated as non-SNA 3270 controllers to the OSes. The
2074 will be getting scarcer now as it was a "PC" (dare I say it, running
OS/2) with ESCON connectivity, the OSA-ICC being installed in the z box.

A case for incorporation of this behaviour in Hercules, chosen as a
configuration option?

John


-----Original Message-----
From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On
Behalf Of paoloG
Sent: Monday, 3 June 2013 19:47
To: hercules-390-***@public.gmane.org
Subject: [hercules-390] Re: hercules 3.08 unexpected disconnects not handled
properly



Hi Fish,

surely Hercules management of local 3270 is very close to a mainframe with
local 3274-3174.

IBM chose not to notify the power off of a local 3270; it could be easily
accomplished as 3274 knows very well the status of all the terminals
connected with the coax cable, as it continuosly polls the terminals.

Probably IBM thought that the local 3274 was an environment stable, not
subjected to unwanted disconessions.

But IBM itself starting with P/370,and then with P/390 and z/PDT , modified
the management of 3270 (emulated via TN3270), introducing the notification
of the equivalent of '3270 power off'.

IMHO Hercules is much closer to a P/370-P/390 that to a real mainframe (the
DASD and tape management is largely the same - terminal are emulated via
TN3270), and z/PDT is even closer (CPU emulated via software).

So I don't see any harm to say that P/370 management of '3270 power off' is
better than Hercules' one and avoids various issues, and if IBM is our guide
in the darkness, it should be always followed.

Respectfully yours

Paul
"Fish" (David B. Trout)
2013-06-03 14:02:51 UTC
Permalink
paoloG wrote:

[...]
Post by paoloG
So I don't see any harm to say that P/370 management
of '3270 power off' is better than Hercules' one and
avoids various issues, and if IBM is our guide in the
darkness, it should be always followed.
You're missing the point Paul. Whether we generate the unsolicited device
attention interrupt when the tn3270 session is disconnected (when the 3270
is "powered off") or whether we generate the unsolicited device attention
interrupt when the/a tn3270 session is (re)connected (when the 3270 is
"powered on"), the described "tailgating" problem is still going to occur
because the guest operating system is not properly handling the situation.
There is nothing Hercules can do to address that fact.

On the other hand however, we now know what the original user was actually
complaining about was in fact NOT the handling of tn3270 connections, but
rather the handling of 1052/3215 console connections.

1052/3215 console devices are not the same as local 3270 devices.

I haven't checked the code (no time right now) but, it's possible we aren't
generating the unsolicited device attention interrupt for those. I don't
know.

If we are generating them however, then we're right back to square one
(right back to where we started): the fact that the guest operating system
is not processing the unsolicited device attention interrupt properly (if it
is indeed processing it at all!).

Sooo... the bottom line in this particular case is, *IF* the guest operating
system in question (VM/ESA in this particular case) DOES handle an
unsolicited device attention interrupt properly for 1052/3215 console
devices (by disconnecting the previous user's session), then *IF* Hercules
is NOT generating said unsolicited device attention interrupt for 1052/3215
console devices, then we should seriously consider providing an option to do
so.

*IF* however, the guest operating system (VM/ESA) does NOT properly handle
unsolicited device attention interrupts for 1052/3215 console devices, then
whether Hercules generates one or not (and whether it generates one at
"power on" (telnet session connection) or at "power off" (telnet session
disconnection)) doesn't matter. Either way the guest o/s is screwed:
tailgating remains possible.

I hope that explains the situation correctly, and invite the original poster
(Dave = dhdurgee-H+***@public.gmane.org) to please let us know if it's not.

Otherwise I would be VERY HAPPY to put this thread to bed. I dislike
beating a dead horse as much as the next person and I believe this thread
has gone on long enough. Methinks it's high time to bring it to a close. :)
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
dhdurgee
2013-06-03 15:30:29 UTC
Permalink
Post by "Fish" (David B. Trout)
[...]
Post by paoloG
So I don't see any harm to say that P/370 management
of '3270 power off' is better than Hercules' one and
avoids various issues, and if IBM is our guide in the
darkness, it should be always followed.
You're missing the point Paul. Whether we generate the unsolicited device
attention interrupt when the tn3270 session is disconnected (when the 3270
is "powered off") or whether we generate the unsolicited device attention
interrupt when the/a tn3270 session is (re)connected (when the 3270 is
"powered on"), the described "tailgating" problem is still going to occur
because the guest operating system is not properly handling the situation.
There is nothing Hercules can do to address that fact.
On the other hand however, we now know what the original user was actually
complaining about was in fact NOT the handling of tn3270 connections, but
rather the handling of 1052/3215 console connections.
1052/3215 console devices are not the same as local 3270 devices.
I haven't checked the code (no time right now) but, it's possible we aren't
generating the unsolicited device attention interrupt for those. I don't
know.
If we are generating them however, then we're right back to square one
(right back to where we started): the fact that the guest operating system
is not processing the unsolicited device attention interrupt properly (if it
is indeed processing it at all!).
Sooo... the bottom line in this particular case is, *IF* the guest operating
system in question (VM/ESA in this particular case) DOES handle an
unsolicited device attention interrupt properly for 1052/3215 console
devices (by disconnecting the previous user's session), then *IF* Hercules
is NOT generating said unsolicited device attention interrupt for 1052/3215
console devices, then we should seriously consider providing an option to do
so.
*IF* however, the guest operating system (VM/ESA) does NOT properly handle
unsolicited device attention interrupts for 1052/3215 console devices, then
whether Hercules generates one or not (and whether it generates one at
"power on" (telnet session connection) or at "power off" (telnet session
tailgating remains possible.
I hope that explains the situation correctly, and invite the original poster
Otherwise I would be VERY HAPPY to put this thread to bed. I dislike
beating a dead horse as much as the next person and I believe this thread
has gone on long enough. Methinks it's high time to bring it to a close. :)
I will concur that if hercules is generating the appropriate unsolicited device attention interrupt that any further issues are the problem of the operating system. I would, however, like to make the argument the generating this at the time of disconnect as opposed to re-connect makes avoiding the tailgating problem much simpler.

As a thought experiment, consider a hercules system with two connected users logged onto the first two 3270 lines in a common pool on a VM system. Assume that the user on the first line logs off cleanly, leaving only the second user logged onto the second line. Assume at this point that the second user's connection is disrupted. The second user, not being finished with his work, reconnects to hercules. Unfortunately he is now connected to the first line and gets an "already logged on xxxx" message, as hercules will not inform the operating system of the situation until a connection to the second line is made. He can work around this by using an additional tn3270 connection, but of course in the general case he could need a large number of additional clients or a way to access a particular line to get reconnected. If hercules were instead to inform the operating system of the disconnect event immediately the user's virtual machine would have been in a disconnected state at the point of his re-connect and he would have been able to resume his work immediately.

I believe this makes a sufficient case to at least make it optional to have hercules generate the unsolicited device attention interrupt at the time of disconnect.

Hopefully someone can inspect the code to determine that hercules is indeed generating the unsolicited device attention interrupt for a 1052/3215 line as well. If it turns out that this is not being done I would appreciate someone providing me the patch to "make it so" on my system. Ideally this would also be handled at the disconnect in order to eliminate the tailgating problem.

Thank you again for all your work on hercules. As it stands it is a great accomplishment and a useful tool. I believe adding this option will make this great tool even more useful to those who want to use it in additional roles.

Dave
somitcw
2013-06-03 16:33:26 UTC
Permalink
--- In hercules-390-***@public.gmane.org,
"dhdurgee" <***@...> wrote:
- - - old notes snipped ---
Post by dhdurgee
I will concur that if hercules is generating the appropriate
unsolicited device attention interrupt that any further issues
are the problem of the operating system. I would, however,
like to make the argument the generating this at the time of
disconnect as opposed to re-connect makes avoiding the
tailgating problem much simpler.
As a thought experiment, consider a hercules system with two
connected users logged onto the first two 3270 lines in a
common pool on a VM system. Assume that the user on the first
line logs off cleanly, leaving only the second user logged onto
the second line. Assume at this point that the second user's
connection is disrupted. The second user, not being finished
with his work, reconnects to hercules. Unfortunately he is
now connected to the first line and gets an "already logged
on xxxx" message, as hercules will not inform the operating
system of the situation until a connection to the second line
is made. He can work around this by using an additional tn3270
connection, but of course in the general case he could need a
large number of additional clients or a way to access a
particular line to get reconnected. If hercules were instead
to inform the operating system of the disconnect event
immediately the user's virtual machine would have been in a
disconnected state at the point of his re-connect and he
would have been able to resume his work immediately.
I believe this makes a sufficient case to at least make it
optional to have hercules generate the unsolicited device
attention interrupt at the time of disconnect.
Hopefully someone can inspect the code to determine that
hercules is indeed generating the unsolicited device
attention interrupt for a 1052/3215 line as well. If it
turns out that this is not being done I would appreciate
someone providing me the patch to "make it so" on my system.
Ideally this would also be handled at the disconnect in order
to eliminate the tailgating problem.
Thank you again for all your work on hercules. As it stands
it is a great accomplishment and a useful tool. I believe
adding this option will make this great tool even more useful
to those who want to use it in additional roles.
Dave
Just to add how MVS 3.8j reacts to Hercules not following
the way that IBM is thought to emulate fixed terminals with
switched terminals:

CRT consoles ripped away are not noticed until a message
attempts to display on them and then a console switch occurs.
If you reconnect to the console port before any message
attempts to display, the console can reconnect with a PA2
with no console screen settings lost.

TSO terminals ripped away are not noticed by MVS.
An attempt to reconnect to the same CCU address
disconnects the TSO user and allows a reconnect.
An attempt to reconnect to a different CCU address says
that the userid is in use. I assume that eventually the
SMF Job-Wait-Time would kill the TSO session instead of
the normal TSO disconnect time limit. JWT is often set to
30 minutes and TSO disconnect is often set to 3 minutes.

Since I don't run Kicks on MVS 3.8j, I know how to handle
consoles, would seldom have a CRT console, know the console
command to cancel a TSO userid, and know how to tell Hercules
how to reconnect to a specific port, all is well with me.
As long as Hercules is my personal main frame, since I have
used VM on real iron for years and have used Hercules for MVS
for years, I could handle VM also.
Rocky Martin
2013-06-03 17:00:36 UTC
Permalink
He can work around this by using an additional tn3270
Post by dhdurgee
connection, but of course in the general case he could need a
large number of additional clients or a way to access a
particular line to get reconnected. If hercules were instead
See previous post - Try using tn3270E and the device address as the name

That will get you to a specific line even though the tn3270e is not
supported -

Works with Vista and one other emulation that I know of.

Roc





[Non-text portions of this message have been removed]
Rocky Martin
2013-06-03 16:33:35 UTC
Permalink
Post by au1john
-----Original Message-----
[...]
Post by paoloG
So I don't see any harm to say that P/370 management of '3270 power
off' is better than Hercules' one and avoids various issues, and if
IBM is our guide in the darkness, it should be always followed.
Paul - It seems to me that Fish summed it up correctly -
If there are issues they are with the guest OS and not with Hercules.

The problem with local non-sna 3270's is that since they are connected
directly to a host address you would want to get the same device address
every time.
With an old COAX connection that is what happened.

In TCPIP, unless you do something special you are going to get the next free
address in the pool.

Now I see some strange behavior from Hercules which sort of corrects that (
We need some input from IVAN as to why) -
I tried using the VISTA emulator that you said that you use and defined the
connection as tn3270E. There I can give a device name

What's strange is I am using a VM/SP5 box which predates TN3270E. But in the
name field I put the address. 020 or 021 or 022 etc. Seems that Ivan is
looking at the name field and trying to connect to the proper address.
If I put 022 then the session only connects to address 022. And my CP fix (
which I posted earlier cleans up after that situation fine).

As soon as you get the interrupt from the connect it disconnects the old
session and returns to the logo screen.

Why tn3270e is completing the negotiation is beyond me, but it works with
Vista and with my old Lognet emulation as well.

So now I get the same address every time - If my session is disconnected (
I cancelled the emulator with task manager, -
Disconnected my internet and even powered off my PC in the middle).

When I reconnected everything worked as expected - Old session disconnects,
and I can reconnect or logon as a different user.

Hercules seems to be doing more than I expect. And properly.
The FIX I posted for SP5 clears up the security issues and prevents hanging
sessions.

Anybody want to try it, I'll give you a userid and password and address - I
have not been able to get it to hang or get the old session back without
logging on. Seems good to me.

Roc
John P. Hartmann
2013-06-03 16:49:14 UTC
Permalink
Post by Rocky Martin
**
With an old COAX connection that is what happened.
Until, that is, some joker replugged one of the patch panels on the way
between the control unit and the screen.


[Non-text portions of this message have been removed]
"Fish" (David B. Trout)
2013-06-04 20:29:48 UTC
Permalink
Rocky Martin wrote:

[...]
Post by Rocky Martin
Hercules seems to be doing more than I expect. And properly.
Yet another confirmation.

Thank you, Roc. :)
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
Gerhard Postpischil
2013-06-05 05:47:18 UTC
Permalink
Post by "Fish" (David B. Trout)
Yet another confirmation.
When I started running turnkey-3 (and couldn't have done it without
HercGUI; thanks), I experienced connectivity problems. My browser and
mail reader would retrieve no data, and the only way to get them back
was to go to the network connection page and deactivate and re-enable my
link. This presented no problem unless I also had Hercules running; then
all my terminals disconnected, but DASD, unit record, and tape continued
just fine. This strongly influences my feelings on the design, which as
I stated original, was kludgy.

Gerhard Postpischil
Bradford, Vermont


------------------------------------
paoloG
2013-06-05 05:09:26 UTC
Permalink
Hi Roc,

I had already performed your tests of disconnection and reconnection (look at VM forum), and I noticed there were some issues(if you disconnect or cancel a TN3270 session (for example at address 021 - user ROCKY) and try to logon on another '3270' (for example a TN3270 session at address 022 already started - with VM LOGON screen), you cannot logon because the user ROCKY is reported to be already connected to the terminal 021.

This is the situation Dhurgee reported in his original post (before talking of 1052 and 3215),as not accettable in his environment, as in P/370 the disconnection of a TN3270 session ended with a disconnession of the logged user.

I suspected (and now I'm certain) that a real mainframe behaved exactly as Hercules does - and it's not a fault of VM - is was the option IBM chose when she decided that 3274 should not notify to the CPU that a 3270 had powered off.

What could the OS do in this situation to detect a power off of a 3270? a polling of all local terminals? Perhaps - or even better the 3274 could notify the terminal power off to the CPU.

In a generous attempt to resolve Dhurgee's issue I found that adding a
line of code in module console.c of Hercules VM behaved as Dave desired, forcing disconnection of the active user when closing a TN3270 session - as P/370 did.

I've made extensive tests of this mod with VM/SP5 and it works very well... with Vista TN3270.

Of course the mod was intended only for VM and could cause issues with other OS (and perhaps it's working only with Vista TN3270).

That's all Roc; it's nice to see you again among us well alive and kicking after your frightening experiences in the Dark Continent ;-).

Now you'll have time to modify you excellent GCIC package in order to use the new DIAG58 support in VM/370 ;-)

Cheers.

Paul
Post by Rocky Martin
Post by au1john
-----Original Message-----
[...]
Post by paoloG
So I don't see any harm to say that P/370 management of '3270 power
off' is better than Hercules' one and avoids various issues, and if
IBM is our guide in the darkness, it should be always followed.
Paul - It seems to me that Fish summed it up correctly -
If there are issues they are with the guest OS and not with Hercules.
The problem with local non-sna 3270's is that since they are connected
directly to a host address you would want to get the same device address
every time.
With an old COAX connection that is what happened.
In TCPIP, unless you do something special you are going to get the next free
address in the pool.
Now I see some strange behavior from Hercules which sort of corrects that (
We need some input from IVAN as to why) -
I tried using the VISTA emulator that you said that you use and defined the
connection as tn3270E. There I can give a device name
What's strange is I am using a VM/SP5 box which predates TN3270E. But in the
name field I put the address. 020 or 021 or 022 etc. Seems that Ivan is
looking at the name field and trying to connect to the proper address.
If I put 022 then the session only connects to address 022. And my CP fix (
which I posted earlier cleans up after that situation fine).
As soon as you get the interrupt from the connect it disconnects the old
session and returns to the logo screen.
Why tn3270e is completing the negotiation is beyond me, but it works with
Vista and with my old Lognet emulation as well.
So now I get the same address every time - If my session is disconnected (
I cancelled the emulator with task manager, -
Disconnected my internet and even powered off my PC in the middle).
When I reconnected everything worked as expected - Old session disconnects,
and I can reconnect or logon as a different user.
Hercules seems to be doing more than I expect. And properly.
The FIX I posted for SP5 clears up the security issues and prevents hanging
sessions.
Anybody want to try it, I'll give you a userid and password and address - I
have not been able to get it to hang or get the old session back without
logging on. Seems good to me.
Roc
Rocky Martin
2013-06-05 09:17:02 UTC
Permalink
Hi Paolo

Nice to hear from you - I do see that you are still busy and posting not a
little to the forum. ---



Yes your example is correct. BUT - did you try the name option in in the
VISTA session.



If you put the device number in the name Field(Define tn3270E - for some
reason it works - Ask Ivan why J )

Then your tn3270 sessions will always connect to the same device and not the
first available device. Try using 023 - Normally you rarely will get that
device.

But if you put it in the name field you will always connect to 023. Then
when you reconnect you first get disconnected by the system an d you can
reconnect.

This little trick seems to simulate an old COAX connection --- If the power
went off say.



Proper protocol would be that you get the Logon Screen and then you can
reconnect. That's what happens with the CP fix I made.



About the console 1050 - I never have any problem reconnecting to the user
console ff the window gets lost, disconnected - I use simple telnet for the
console and it works fine



Roc



From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On
Behalf Of paoloG
Sent: Wednesday, June 05, 2013 8:09 AM
To: hercules-390-***@public.gmane.org
Subject: [hercules-390] Re: hercules 3.08 unexpected disconnects not handled
properly





Hi Roc,

I had already performed your tests of disconnection and reconnection (look
at VM forum), and I noticed there were some issues(if you disconnect or
cancel a TN3270 session (for example at address 021 - user ROCKY) and try to
logon on another '3270' (for example a TN3270 session at address 022 already
started - with VM LOGON screen), you cannot logon because the user ROCKY is
reported to be already connected to the terminal 021.

This is the situation Dhurgee reported in his original post (before talking
of 1052 and 3215),as not accettable in his environment, as in P/370 the
disconnection of a TN3270 session ended with a disconnession of the logged
user.

I suspected (and now I'm certain) that a real mainframe behaved exactly as
Hercules does - and it's not a fault of VM - is was the option IBM chose
when she decided that 3274 should not notify to the CPU that a 3270 had
powered off.

What could the OS do in this situation to detect a power off of a 3270? a
polling of all local terminals? Perhaps - or even better the 3274 could
notify the terminal power off to the CPU.

In a generous attempt to resolve Dhurgee's issue I found that adding a
line of code in module console.c of Hercules VM behaved as Dave desired,
forcing disconnection of the active user when closing a TN3270 session - as
P/370 did.

I've made extensive tests of this mod with VM/SP5 and it works very well...
with Vista TN3270.

Of course the mod was intended only for VM and could cause issues with other
OS (and perhaps it's working only with Vista TN3270).

That's all Roc; it's nice to see you again among us well alive and kicking
after your frightening experiences in the Dark Continent ;-).

Now you'll have time to modify you excellent GCIC package in order to use
the new DIAG58 support in VM/370 ;-)

Cheers.

Paul
Post by Rocky Martin
Post by au1john
-----Original Message-----
[...]
So I don't see any harm to say that P/370 management of '3270 power
off' is better than Hercules' one and avoids various issues, and if
IBM is our guide in the darkness, it should be always followed.
Paul - It seems to me that Fish summed it up correctly -
If there are issues they are with the guest OS and not with Hercules.
The problem with local non-sna 3270's is that since they are connected
directly to a host address you would want to get the same device address
every time.
With an old COAX connection that is what happened.
In TCPIP, unless you do something special you are going to get the next free
address in the pool.
Now I see some strange behavior from Hercules which sort of corrects that
(
Post by Rocky Martin
We need some input from IVAN as to why) -
I tried using the VISTA emulator that you said that you use and defined the
connection as tn3270E. There I can give a device name
What's strange is I am using a VM/SP5 box which predates TN3270E. But in the
name field I put the address. 020 or 021 or 022 etc. Seems that Ivan is
looking at the name field and trying to connect to the proper address.
If I put 022 then the session only connects to address 022. And my CP fix (
which I posted earlier cleans up after that situation fine).
As soon as you get the interrupt from the connect it disconnects the old
session and returns to the logo screen.
Why tn3270e is completing the negotiation is beyond me, but it works with
Vista and with my old Lognet emulation as well.
So now I get the same address every time - If my session is disconnected (
I cancelled the emulator with task manager, -
Disconnected my internet and even powered off my PC in the middle).
When I reconnected everything worked as expected - Old session
disconnects,
Post by Rocky Martin
and I can reconnect or logon as a different user.
Hercules seems to be doing more than I expect. And properly.
The FIX I posted for SP5 clears up the security issues and prevents hanging
sessions.
Anybody want to try it, I'll give you a userid and password and address - I
have not been able to get it to hang or get the old session back without
logging on. Seems good to me.
Roc
[Non-text portions of this message have been removed]
dhdurgee
2013-06-03 17:27:07 UTC
Permalink
--- In hercules-390-***@public.gmane.org, "\"Fish\" \(David B. Trout\)" <***@...> wrote:

[some snipping done]
Post by "Fish" (David B. Trout)
On the other hand however, we now know what the original user was actually
complaining about was in fact NOT the handling of tn3270 connections, but
rather the handling of 1052/3215 console connections.
1052/3215 console devices are not the same as local 3270 devices.
I haven't checked the code (no time right now) but, it's possible we aren't
generating the unsolicited device attention interrupt for those. I don't
know.
If we are generating them however, then we're right back to square one
(right back to where we started): the fact that the guest operating system
is not processing the unsolicited device attention interrupt properly (if it
is indeed processing it at all!).
Sooo... the bottom line in this particular case is, *IF* the guest operating
system in question (VM/ESA in this particular case) DOES handle an
unsolicited device attention interrupt properly for 1052/3215 console
devices (by disconnecting the previous user's session), then *IF* Hercules
is NOT generating said unsolicited device attention interrupt for 1052/3215
console devices, then we should seriously consider providing an option to do
so.
*IF* however, the guest operating system (VM/ESA) does NOT properly handle
unsolicited device attention interrupts for 1052/3215 console devices, then
whether Hercules generates one or not (and whether it generates one at
"power on" (telnet session connection) or at "power off" (telnet session
tailgating remains possible.
I just thought to do some tracing of a 1052/3215 line and try it:

12:43:08 HHCTE008I Device 000A connection closed by client 192.168.80.14
12:43:08 HHCCP075I 000A:Stat=0E00 Count=00FF =>00000000 00000000 00000000 00000000 ................
12:43:08 HHCCP076I 000A:Sense=40000000 00000000 00000000 00000000 00000000 00000000
12:43:08 HHCCP077I 000A:Sense=INTREQ
12:43:08 HHCCP049I 000A:Stat=0E00 Count=00FF CCW=FA5EA0
12:43:08 HHCTE008I Device 000A connection closed by client 192.168.80.14
12:43:08 HHCCP048I 000A:CCW=04F89338 20000020=>00000000 00000000 00000000 00000000 ................
12:43:08 HHCCP075I 000A:Stat=0C00 Count=001F =>40000000 00000000 00000000 00000000 ...............
12:43:08 HHCCP049I 000A:Stat=0C00 Count=001F CCW=F89328
12:43:08 HHCCP048I 000A:CCW=0B000000 20000001=>000C0000 000008E8 00000000 00F7C000 .......Y.....7{.
12:43:08 HHCCP075I 000A:Stat=0200 Count=0001
12:43:08 HHCCP076I 000A:Sense=40000000 00000000 00000000 00000000 00000000 00000000
12:43:08 HHCCP077I 000A:Sense=INTREQ
12:43:08 HHCCP049I 000A:Stat=0200 Count=0001 CCW=00A8A0
12:43:08 HHCCP048I 000A:CCW=04F89338 20000020=>00000000 00000000 00000000 00000000 ................
12:43:08 HHCCP075I 000A:Stat=0C00 Count=001F =>40000000 00000000 00000000 00000000 ...............
12:43:08 HHCCP049I 000A:Stat=0C00 Count=001F CCW=F89328
12:43:11 HHCTE009I Client 192.168.80.14 connected to 3215 device 0:000A
12:43:11 HHCCP066I DEV000A: attention
12:43:11 HHCCP049I 000A:Stat=0400 Count=0000 CCW=000000
12:43:11 HHCCP048I 000A:CCW=0AF88EF8 600000FF=>00000000 00000000 00000000 00000000 ................


If I am interpreting the above correctly the attention is indeed being generated by hercules at the point of re-connection. So there is no way for hercules to address this problem for a 1052/3215 line, it must be corrected in VM/ESA.

Dave
Tony Harminc
2013-06-04 02:04:25 UTC
Permalink
Post by dhdurgee
[some snipping done]
And even more by me...
Really, 1052/3215 are even more extreme than local 3270s, in the sense
that there is no control unit that handles multiple devices, there is
no expectation that such a device will ever be powered off during
normal operation (indeed I don't remember a power switch separate from
the entire mainframe power switch, other than perhaps one for service
mode under the covers).

So in the world of real 1052/3215 hardware, there is no expectation at
all that such a device will ever be disconnected in any sense, and so
no code is needed to handle such a situation.

Obviously since the first days of the VM "dial" command, there have
been disconnectable virtual 1052/3215s, and that's where all the
trouble started. But it's not surprising that these devices are no
more disconnectable from a hardware or protocol point of view than a
1403 printer or a 2501 card reader.

Tony H.
Gerhard Postpischil
2013-06-04 05:17:22 UTC
Permalink
Post by Tony Harminc
Obviously since the first days of the VM "dial" command, there have
been disconnectable virtual 1052/3215s, and that's where all the
trouble started. But it's not surprising that these devices are no
more disconnectable from a hardware or protocol point of view than a
1403 printer or a 2501 card reader.
In the early and mid sixties, I was on the far end of an IBM experiment
with remote computing. I never found out what was on their side (either
a 70x4 or prototype 360?), but the terminal was a 1050, with a manual,
edge-fed card reader (one card at a time), an acoustic modem, and
support for a simple editor and ForTran compile and execute. The system
was so unstable that I never completed entering a non-trivial program.

But technically, it was equivalent to a 1052 with a slightly different
interface that could have offered on S/360 with a 270x as a console.
IIRC there was BTAM support for it.

Gerhard Postpischil
Bradford, Vermont
somitcw
2013-06-04 16:01:08 UTC
Permalink
On 3 June 2013 13:27,
Post by dhdurgee
[some snipping done]
And even more by me...
Post by dhdurgee
I just thought to do some tracing of a 1052/3215 line
Really, 1052/3215 are even more extreme than local 3270s,
in the sense that there is no control unit that handles
multiple devices, there is no expectation that such a
device will ever be powered off during normal operation
(indeed I don't remember a power switch separate from
the entire mainframe power switch, other than perhaps
one for service mode under the covers).
So in the world of real 1052/3215 hardware, there is no
expectation at all that such a device will ever be
disconnected in any sense, and so no code is needed to
handle such a situation.
Obviously since the first days of the VM "dial" command,
there have been disconnectable virtual 1052/3215s, and
that's where all the trouble started. But it's not
surprising that these devices are no more disconnectable
from a hardware or protocol point of view than a
1403 printer or a 2501 card reader.
Tony H.
Channel switches/extenders allowed switching 1403,
2501 and others. We did vary devices offline before
switching.

I think that ours was a copper 3044 but IBM later
had 3088. A later 3044 may have been ESCON?
John P. Hartmann
2013-06-04 16:10:32 UTC
Permalink
There was the 2914 for bus and tag.

Note that these devices switch entire channel paths, not individual devices
(unless you arrange only to have one-device channel segments).

Thus, a 2914 etc could not switch a 3215. as it was directly attached to
the processor.
Post by somitcw
**
Channel switches/extenders allowed switching 1403,
2501 and others. We did vary devices offline before
switching.
I think that ours was a copper 3044 but IBM later
had 3088. A later 3044 may have been ESCON?
[Non-text portions of this message have been removed]
somitcw
2013-06-04 16:39:24 UTC
Permalink
Post by John P. Hartmann
Post by somitcw
**
Channel switches/extenders allowed switching 1403,
2501 and others. We did vary devices offline before
switching.
I think that ours was a copper 3044 but IBM later
had 3088. A later 3044 may have been ESCON?
There was the 2914 for bus and tag.
Note that these devices switch entire channel paths,
not individual devices (unless you arrange only to
have one-device channel segments).
Thus, a 2914 etc could not switch a 3215. as it
was directly attached to the processor.
[Non-text portions of this message have been removed]
The 2914 or 2944 sounds correct.
It's been too long for me to remember.
Tony Harminc
2013-06-04 16:29:57 UTC
Permalink
Post by somitcw
Channel switches/extenders allowed switching 1403,
2501 and others. We did vary devices offline before switching.
Sure - of course there were channel switches. And the B&T protocol
allows a device to be taken offline and powered off, while passing the
signals through.

But nonetheless it was not "normal" for devices like 1052/3215 to be
turned off (the control unit and in some cases channel interface was
built in), and it also remains true that B&T channel cables are not
hot-pluggable.
Post by somitcw
I think that ours was a copper 3044 but IBM later had 3088. A later 3044 may have been ESCON?
That may be, but there was never an ESCON 1052 or 3215.

Tony H.
"Fish" (David B. Trout)
2013-06-04 18:15:28 UTC
Permalink
(piggyback)
Post by Tony Harminc
Post by dhdurgee
[some snipping done]
And even more by me...
Post by dhdurgee
I just thought to do some tracing of a 1052/3215 line
Really, 1052/3215 are even more extreme than local 3270s,
in the sense that there is no control unit that handles
multiple devices, there is no expectation that such a device
will ever be powered off during normal operation (indeed
I don't remember a power switch separate from the entire
mainframe power switch, other than perhaps one for service
mode under the covers).
So in the world of real 1052/3215 hardware, there is no
expectation at all that such a device will ever be disconnected
in any sense, and so no code is needed to handle such a situation.
<snip>

Good point, Tony.

Dave? Have you considered using an integrated 3215 console instead? (i.e.
Hercules device type "3215-C"?):

ccuu 3215-C /

(where "ccuu" is obviously the device address of your VM/ESA console)
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org





------------------------------------
dhdurgee
2013-06-04 20:50:50 UTC
Permalink
Post by "Fish" (David B. Trout)
(piggyback)
Post by Tony Harminc
Post by dhdurgee
[some snipping done]
And even more by me...
Post by dhdurgee
I just thought to do some tracing of a 1052/3215 line
Really, 1052/3215 are even more extreme than local 3270s,
in the sense that there is no control unit that handles
multiple devices, there is no expectation that such a device
will ever be powered off during normal operation (indeed
I don't remember a power switch separate from the entire
mainframe power switch, other than perhaps one for service
mode under the covers).
So in the world of real 1052/3215 hardware, there is no
expectation at all that such a device will ever be disconnected
in any sense, and so no code is needed to handle such a situation.
<snip>
Good point, Tony.
Dave? Have you considered using an integrated 3215 console instead? (i.e.
ccuu 3215-C /
(where "ccuu" is obviously the device address of your VM/ESA console)
--
"Fish" (David B. Trout)
I do use a 3215-C for my operator console. But that does not solve the problem of support for the telnet users of my P/370 system when using hercules in case of a hardware failure.

Per your suggest, I have started a topic in H390-VM to seek out options for this support.

Dave
Harold Grovesteen
2013-06-04 14:41:12 UTC
Permalink
Post by paoloG
But IBM itself starting with P/370,and then with P/390 and z/PDT ,
modified the management of 3270 (emulated via TN3270), introducing
the notification of the equivalent of '3270 power off'.
IMHO Hercules is much closer to a P/370-P/390 that to a real mainframe
(the DASD and tape management is largely the same - terminal are emulated via TN3270), and z/PDT is even closer (CPU emulated via software).
So I don't see any harm to say that P/370 management of '3270 power off' is better than Hercules' one and avoids various issues, and if IBM is our guide in the darkness, it should be always followed.
Respectfully yours
Paul
Paul, I believe the developers would agree that this functionality is
desirable. The real problem, as I see it, is IBM may be a faulty guide,
even if their lead is desirable. Exactly how this "3270 power off"
functionality is implemented within the channel protocol does not appear
to be well documented, if at all.

Someone who could provide some form of channel level trace for this
option in action would be very helpful.

Harold Grovesteen
ikj1234i
2013-06-02 16:52:36 UTC
Permalink
Post by Gerhard Postpischil
I agree that's its too late to change existing behavior, but it would be
nice to support both fixed and temporary connections.
Gerhard, how would you see this working?
Post by Gerhard Postpischil
Hercules supports DASD, tape, and unit record devices natively.
Not sure what this means - the 3350's and 3420's etc. are done using emulation just as much as the 3270's.
Post by Gerhard Postpischil
The
point that Trout missed is that the original development failed to
provide analogous support for local non-SNA 3270s, but instead adopted
the kludge of supporting permanent links on a transient connection.
Would look fwd to seeing details on the non-kludgey alternative....

Best

Max
Gerhard Postpischil
2013-06-03 05:19:49 UTC
Permalink
Post by ikj1234i
Gerhard, how would you see this working?
I think it's too late to change existing behavior, but it would be nice
to add BSC support - I could see a 3275 supported as a tn3270 session,
with simulated dial-up connection, supported by BTAM and TCAM.
I don't remember whether VTAM supported it. For VTAM, it would be nice
to have 3791L, as well as 3174-nnR support.
Post by ikj1234i
Post by Gerhard Postpischil
Hercules supports DASD, tape, and unit record devices natively.
Not sure what this means - the 3350's and 3420's etc. are done using emulation just as much as the 3270's.
By this I mean that one defines DASD and tapes in the configuration
files, and Hercules contains all necessary code to support them. I would
have expected 3270 support to behave the same way, without requiring
additional, third-party software. I use both BlueZone (graphics,
explicit partitions) for development, and Tom Brennan's Vista for
everything else, but for a local terminal, I would expect Hercules to
open a window for each defined CRT, and provide appropriate support.
Post by ikj1234i
Would look fwd to seeing details on the non-kludgey alternative....
Hercules support for 37n5 or NCR/Comten 369n ?

Gerhard Postpischil
Bradford, Vermont
"Fish" (David B. Trout)
2013-06-03 09:21:54 UTC
Permalink
Post by Gerhard Postpischil
Post by ikj1234i
Gerhard, how would you see this working?
[...]
Post by Gerhard Postpischil
but for a local terminal, I would expect Hercules
to open a window for each defined CRT, and provide
appropriate support.
Open a separate window where? On the host running Hercules?

So if you have 16 local 3270 terminals defined in your Hercules
configuration it should open another 16 extra windows?

On the same PERSONAL computer?

So 16 people can take turns using those 16 windows at the same time to get
their work done?

Is that what you're suggesting that Hercules got wrong? :)
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
Gerhard Postpischil
2013-06-04 05:48:18 UTC
Permalink
Post by "Fish" (David B. Trout)
Open a separate window where? On the host running Hercules?
So if you have 16 local 3270 terminals defined in your Hercules
configuration it should open another 16 extra windows?
Yes, I see it as analogous to the integrated 1052/3215 console support.
Most hosts that support windows also support tiling, resizing windows,
and hiding them. For a one-person system, 16 might be extreme, but still
manageable. If more are needed, they could be implemented on other
machines, using network support, and dial-up protocols.
Post by "Fish" (David B. Trout)
Is that what you're suggesting that Hercules got wrong? :)
What I'm suggesting is that the implementation of a permanent connected
terminal via a non-permanent connection is inherently faulty.

However, since we apparently will never agree on this, I concur in
putting this to rest.

Gerhard Postpischil
Bradford, Vermont


------------------------------------
Harold Grovesteen
2013-06-04 14:31:30 UTC
Permalink
<snip>
Post by Gerhard Postpischil
Post by "Fish" (David B. Trout)
Is that what you're suggesting that Hercules got wrong? :)
What I'm suggesting is that the implementation of a permanent connected
terminal via a non-permanent connection is inherently faulty.
Gerhard Postpischil
Bradford, Vermont
Gerhard, you are absolutely correct that there is an inherent
incompatibility when using a non-permanent connection to emulate a
permanent one.

However, I am not convinced that "faulty" is the right way to describe
the choice. Even your succeeding posts on the options are inconclusive
that realistic alternatives exist, particularly for the S/360 and S/370
era systems. At some level Hercules is required to support these
devices in the way the software of that era expects them to operate.

Could alternatives be provided for other situations? Absolutely. So
far, they are yet to materialize. For someone truly interested in them,
I would encourage that development be done. Hercules is after all open
source.

Harold Grovesteen
M. Khalid Khan
2013-06-05 01:00:43 UTC
Permalink
----- Original Message -----
From: "Gerhard Postpischil" <gerhard-sTLh940vhFCsTnJN9+***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Tuesday, June 04, 2013 12:48 AM
Subject: Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
Post by Gerhard Postpischil
Post by "Fish" (David B. Trout)
Open a separate window where? On the host running Hercules?
So if you have 16 local 3270 terminals defined in your Hercules
configuration it should open another 16 extra windows?
Yes, I see it as analogous to the integrated 1052/3215 console support.
Most hosts that support windows also support tiling, resizing windows,
and hiding them. For a one-person system, 16 might be extreme, but still
manageable. If more are needed, they could be implemented on other
machines, using network support, and dial-up protocols.
It doesn't have to start all defined terminals. There could be a flag in the
configuration indicating if a terminal is to be started.

Khalid




------------------------------------
ikj1234i
2013-06-03 16:09:08 UTC
Permalink
Post by Gerhard Postpischil
Post by ikj1234i
Gerhard, how would you see this working?
I think it's too late to change existing behavior, but it would be nice
to add BSC support - I could see a 3275 supported as a tn3270 session,
Yes this would be an interesting addition, virtually all of the code already exists in Hercules in one place or another and would just be a matter of mashing it together, presumably via additions to commadpt.c.

That this is supported by BTAM suggests that the potential exists, at least in theory, to use it as an OS/MVS console. Is this possible?
Post by Gerhard Postpischil
with simulated dial-up connection, supported by BTAM and TCAM.
I don't remember whether VTAM supported it. For VTAM, it would be nice
to have 3791L, as well as 3174-nnR support.
3791L is in 3.08, albeit restricted to one session at a time. What's involved in doing 3174-nnR? - I know they at one time had a token-ring 327x controller/gateway but that had fancier XID requirements than our legacy VTAM could support (IIRC)...
Post by Gerhard Postpischil
Post by ikj1234i
Post by Gerhard Postpischil
Hercules supports DASD, tape, and unit record devices natively.
Not sure what this means - the 3350's and 3420's etc. are done using emulation just as much as the 3270's.
By this I mean that one defines DASD and tapes in the configuration
files, and Hercules contains all necessary code to support them.
Well, say for 3350 disk support Hercules simply makes host OS filesystem calls - Hercules itself actually contains no code to support disks beyond its abstraction layer for IBM mainframe disk devices. One also defines 3270's in the configuration files, just as with DASD and tapes.
Post by Gerhard Postpischil
I would
have expected 3270 support to behave the same way, without requiring
additional, third-party software. I use both BlueZone (graphics,
explicit partitions) for development, and Tom Brennan's Vista for
everything else, but for a local terminal, I would expect Hercules to
open a window for each defined CRT, and provide appropriate support.
The expectation could be less unrealistic in an alternative universe in which window$ / maco$ had good, free 3270 emulation as standard...
Post by Gerhard Postpischil
Post by ikj1234i
Would look fwd to seeing details on the non-kludgey alternative....
Hercules support for 37n5 or NCR/Comten 369n ?
3705 is supported now. Perhaps someone will be motivated someday to enrich it.

Finally, for MVS3.8, how many of the above devices can be used as master 3270 consoles for purposes of IPL?
Post by Gerhard Postpischil
Gerhard Postpischil
Bradford, Vermont
Max
somitcw
2013-06-03 17:01:50 UTC
Permalink
--- In hercules-390-***@public.gmane.org,
"ikj1234i" <***@...> wrote:
- - - almost all snipped - - -
Post by ikj1234i
Finally, for MVS3.8, how many of the above devices can
be used as master 3270 consoles for purposes of IPL?
Max
Way back then, MVS did require a console for IPL.
The console had to be local like a 1052, 3215, or
local model 2 CRT. For VS1 and MVS, we also had a 3066.
3158 console came later at a different location.
3270-2A worked on MVS/SP and MVS/XA.

For MVT-II, we had a couple of 2741 typewriter terminals
hung off of a 2702 but I never tried to use them as the
IPL console. After IPL, we could make either the master
but all of our consoles supported most console commands.
Gerhard Postpischil
2013-06-04 05:04:55 UTC
Permalink
Post by somitcw
Way back then, MVS did require a console for IPL.
The console had to be local like a 1052, 3215, or
local model 2 CRT. For VS1 and MVS, we also had a 3066.
3158 console came later at a different location.
3270-2A worked on MVS/SP and MVS/XA.
All flavors of OS/360 required a local console, as did DOS, SVS, and
MVS. However, your list isn't complete, as OS/360 (don't recall SVS and
MVS options) supported a composite console - you could enter command
responses on a 2540 or other reader, and print messages on a 1403 or
other printer (and woe when the operators forgot to run the stand-alone
UCS load before IPL). The 3066 was also supported under OS/360 (we had
one on a 360/165 running MVT with 4 MiB).

I remember the composite console well. ADR had a policy of assigning any
programmer not on an active contract to the systems groups. One of these
treated our production system as his personal sandbox, and kept making
system changes and applying inappropriate service (before SMP came out).
A colleague of mine got fed up with having to restore the system packs
all the time, and password protected most of the SYS1 data sets. The
password for all was the same - 8 bytes of hex zeroes. The privileged
systems staff had a punch card with reply and multi-punched hex zeroes;
when a SYS1 data set needed updating, we activated the composite
console, duplicated the pattern card with the appropriate reply number,
fed it into the 2540, and deactivated the console.

At one point we had a 360/65, and my boss got some third party with a
console replacement - they hooked something to the CPU, ran a cable from
that to a black box, and established a TTY terminal as a 1052
replacement (with dial-in support). This worked fine until the cable got
disconnected, and the unpolarized plug was reconnected upside down, and
the electronics got fried.
Post by somitcw
For MVT-II, we had a couple of 2741 typewriter terminals
hung off of a 2702 but I never tried to use them as the
IPL console. After IPL, we could make either the master
but all of our consoles supported most console commands.
Perhaps I missed something, but I don't recall any 274x terminal
support; did you have a local mod? Our 2741s were used for ATS, and I
did most of my smaller documentation with them (large manuals were done
with the Type 3 FORMAT program, using a 1403 with TN train).

Gerhard Postpischil
Bradford, Vermont
somitcw
2013-06-04 16:26:57 UTC
Permalink
--- In hercules-390-***@public.gmane.org,
Gerhard Postpischil <***@...> wrote:
- - -most snipped - - -
Post by Gerhard Postpischil
Perhaps I missed something, but I don't recall any 274x
terminal support; did you have a local mod? Our 2741s were
used for ATS, and I did most of my smaller documentation
with them (large manuals were done with the Type 3 FORMAT
program, using a 1403 with TN train).
Gerhard Postpischil
Bradford, Vermont
I don't remember 2741 consoles being anything special.
I currently don't have an MFT-II system running but
suspect that support was added as part of DIDOCS?

MVS 3.8j SYS1.AGENLIB(GENERATE) has comment:
.* MUST DO SVCLIB IF IOGEN W/2740 CONSOLE AND NO BTAM OZ03884

We also had a composite console but seldom used it.
One JOB had an enormous amount of console output that the
programmers insisted we deliver to the application department.
I sent to either a composite or output only 1403 so the JOB
would run quicker.

When we switched to CRT consoles. we kept the 3215 and
2741 consoles for awhile until the operators were happy.
That gave us seven active consoles in one computer room
at one time.

We also had a remote workstation that could enter console
commands. I believe that the remote users could only affect
their own JOBs? When we replied to a message for their JOBs
we had to include the remote name with the reply-id.
Something like: R 00.NY01,'the-reply'
I don't remember if that syntax was for MFT-II or VS1 or both?
We also had to print their forms when their printer was down.
Gerhard Postpischil
2013-06-04 05:40:35 UTC
Permalink
Post by ikj1234i
That this is supported by BTAM suggests that the potential exists, at least in theory, to use it as an OS/MVS console. Is this possible?
I've never used anything other than a local device for a console, and
don't remember any support for remotes. But I'm not sure my memory on
this is reliable. If there ever was support for remotes, it would not
have supported IPL.
Post by ikj1234i
3791L is in 3.08, albeit restricted to one session at a time. What's involved in doing 3174-nnR? - I know they at one time had a token-ring 327x controller/gateway but that had fancier XID requirements than our legacy VTAM could support (IIRC)...
The only dial-up 3174s I have any experience with were SNA versions, and
to the front-end it didn't matter whether they connected terminals with
coax, ethernet or token ring. Makes me wonder whether VTAM would
correctly handle a 3791L that dropped a connection; if not, it would be
interesting to see whether unrestricted software for a 37x5 could be
obtained?
Post by ikj1234i
Well, say for 3350 disk support Hercules simply makes host OS filesystem calls - Hercules itself actually contains no code to support disks beyond its abstraction layer for IBM mainframe disk devices. One also defines 3270's in the configuration files, just as with DASD and tapes.
The expectation could be less unrealistic in an alternative universe in which window$ / maco$ had good, free 3270 emulation as standard...
At least some of the supported systems (esp. Windows, Suse linux)
support windows, so that 3270 support would have been not much more
difficult than DASD or tape support, especially if the first version
supported only a 3272/3277M2 or 3274/3278M2, and left color and other
models for later.
Post by ikj1234i
Finally, for MVS3.8, how many of the above devices can be used as master 3270 consoles for purposes of IPL?
1052/3215, 3277, 3278, 3279, 3180, 3178, 3179, 2540/1403, 3066, 3158.
Not sure about 3290.

Gerhard Postpischil
Bradford, Vermont
Juergen
2013-06-04 14:47:01 UTC
Permalink
Makes me wonder whether VTAM would correctly handle a 3791L
that dropped a connection; if not, it would be interesting to
see whether unrestricted software for a 37x5 could be
obtained?
Hi Gerhard

I just did a quick test on a 3791L emulated through comm3705: LU1 (TTY 3767) as well as LU2 (3270) survive a Telnet disconnect/reconnect without noticing anything. The TSO session remains in the same state as it was before the disconnect, i.e. it doesn't get logically disconnected and consequently doesn't require a logon reconnect command to get reinstated. A CCW trace shows no activity on the 3791L channel address, neither at telnet disconnect nor at reconnect time.

The comm3705 NCP impersonation behaves exactly the same for leased lines (no wonder, as the 3791L is created from the 3705 NCP by just remapping the FID1 and FID2 transmission headers) but schedules of course the regular SNA disconnect sequence for switched lines, causing the TSO session to disconnect logically at telnet _dis_connect time (as opposed to at telnet _re_connect time which can be observed with local non SNA 3270s). This might support the thesis that disconnecting local (hardwired) terminals wasn't considered a serious issue in the old days.

This can of course be a specific behavior of the 3705 NCP/3791L impersonation/emulation, i.e. one cannot conclude whether this fully reflects the behavior of a real 3705 loaded with NCP or a real 3791L upon power off/on of a terminal connected to it.

Anyway: Both don't contain any of the original code for the 37x5, so this cannot be used to conclude much.
From my point of view there is no need to change anything in Hercules' current behavior!
Cheers
Juergen
Gregg Levine
2013-06-04 14:52:04 UTC
Permalink
Post by Juergen
Makes me wonder whether VTAM would correctly handle a 3791L
that dropped a connection; if not, it would be interesting to
see whether unrestricted software for a 37x5 could be
obtained?
Hi Gerhard
I just did a quick test on a 3791L emulated through comm3705: LU1 (TTY 3767) as well as LU2 (3270) survive a Telnet disconnect/reconnect without noticing anything. The TSO session remains in the same state as it was before the disconnect, i.e. it doesn't get logically disconnected and consequently doesn't require a logon reconnect command to get reinstated. A CCW trace shows no activity on the 3791L channel address, neither at telnet disconnect nor at reconnect time.
The comm3705 NCP impersonation behaves exactly the same for leased lines (no wonder, as the 3791L is created from the 3705 NCP by just remapping the FID1 and FID2 transmission headers) but schedules of course the regular SNA disconnect sequence for switched lines, causing the TSO session to disconnect logically at telnet _dis_connect time (as opposed to at telnet _re_connect time which can be observed with local non SNA 3270s). This might support the thesis that disconnecting local (hardwired) terminals wasn't considered a serious issue in the old days.
This can of course be a specific behavior of the 3705 NCP/3791L impersonation/emulation, i.e. one cannot conclude whether this fully reflects the behavior of a real 3705 loaded with NCP or a real 3791L upon power off/on of a terminal connected to it.
Anyway: Both don't contain any of the original code for the 37x5, so this cannot be used to conclude much.
From my point of view there is no need to change anything in Hercules' current behavior!
Cheers
Juergen
Hello!
Juergen would you mind sharing your configuration? I am interested in
your configuration and want to try it. Of course this presupposes I
have here the OS examples that would work with your configuration.
-----
Does anything special need to be done to configure VM/370 Release
number 6 to participate in that arrangement? We have available both
the two disk solution, and the multiple disk solutions.
-----
Gregg C Levine gregg.drwho8-***@public.gmane.org
"This signature fought the Time Wars, time and again."
Juergen
2013-06-04 19:56:30 UTC
Permalink
Post by Gregg Levine
Post by Juergen
Makes me wonder whether VTAM would correctly handle a 3791L
that dropped a connection; if not, it would be interesting to
see whether unrestricted software for a 37x5 could be
obtained?
Hi Gerhard
LU1 (TTY 3767) as well as LU2 (3270) survive a Telnet
disconnect/reconnect without noticing anything.
Hello!
Juergen would you mind sharing your configuration?
I am interested in your configuration and want to try
it. Of course this presupposes I have here the OS
examples that would work with your configuration.
-----
Hi Gregg

Of course I don't mind sharing the configuration. The problem is that it wouldn't be of use for most people here: It is based on my homegrown MVS 3.8j system, which is based on the original TK3 system with additions up to approximately Phil's TK3UPD (I name this system "internally" TK4-).

Besides being my "MVS playground" I designed this system as a showcase for all ways currently available to logon to MVS 3.8 that are available with Hercules:

o Local 3270 non SNA under VTAM
o Local 3270 SNA LU2 under VTAM via 3791L
o Local 3767 SNA LU1 under VTAM via 3791L
o Remote 3270 SNA LU2 under VTAM via 3705 NCP
o Remote 3767 SNA LU1 under VTAM via 3705 NCP
o Local 3270 non SNA under TCAM
o Remote 3270 SNA LU2 under TCAM via 3705 NCP
o Remote 3767 SNA LU1 under TCAM via 3705 NCP
o Remote 3335 non SNA under TCAM via 2703
o Remote 2741 non SNA under TCAM via 2703

To support all the devices needed for these connections the TK4- sysgen differs significantly from the original TK3 or TK3UPD ones, which is one reason why I think that just publishing a few configuration members isn't of much use.

Other reasons are a significant amount of usermods I implemented in the TCAM, TSO/TCAM and TSO/VTAM areas plus quite a bit of automation necessary to get everything to work smoothly. All of this would need a massive documentation effort when being published standalone.

This is why I came to the conclusion to publish the system as a whole, if interest would arise.

I started creating this system about a year ago but put it to sleep back in October 2012 when I started diving into that APL\360 adventure. Now, that I've closed the APL\360 file I'm returning to the TK4- project. Having now implemented a final usermod in the TSO/VTAM field plus enhanced Kermit support for the SNA 3767 connections under VTAM I'm basically at a point, where I could cut of a first version for publication.

This still requires quite a bit of documentation plus some cleanup work on the system. Being off for a business trip in the US for the next two weeks I'll not realistically be able to publish anything before July (after the intensive APL\360 resurrection project I've accumulated a deep red negative time budget anyway).

So, to summarize: Yes, I'm going to make everything available... but I still need some time to do it.
Post by Gregg Levine
Does anything special need to be done to configure
VM/370 Release number 6 to participate in that
arrangement? We have available both the two disk
solution, and the multiple disk solutions.
-----
Up to now I never tried the VM/370 distributions that are available for Hercules. But from my own old VM experiences I remember that there was no native SNA support until the advent of GCS under, I think, VM/XA SP. So, if I'm not totally wrong with this, there is no way to support 3705s (in NCP or PEP mode) or 3791Ls under VM/370 natively.

Cheers
Juergen
Tony Harminc
2013-06-04 20:22:47 UTC
Permalink
Post by Juergen
Up to now I never tried the VM/370 distributions that are available for Hercules. But from my own old VM experiences I remember that there was no native SNA support until the advent of GCS under, I think, VM/XA SP. So, if I'm not totally wrong with this, there is no way to support 3705s (in NCP or PEP mode) or 3791Ls under VM/370 natively.
Yes - IBM's solution up to that point was to run a guest VSE or VS/1
system, which hosted VTAM, which was then able to talk via SNA CCS to
CP. IBM offered some prepackaged such systems for a drop-in
installation.

I don't think the GCS-based VTAM is much more "native" than these; it
is still running an "OS" style VTAM.

And of course none of this is available on VM/370.

Tony H.
ikj1234i
2013-06-04 20:35:29 UTC
Permalink
[snip]
Up to now I never tried the VM/370 distributions that are available for Hercules. But from my own old VM experiences I remember that there was no native SNA support until the advent of GCS under, I think, VM/XA SP. So, if I'm not totally wrong with this, there is no way to support 3705s (in NCP or PEP mode) or 3791Ls under VM/370 natively.
There is some stuff in the VM/370 that we have related to 3705's although it's not clear what it does or how many of the pieces are missing. The ability to generate NCP load modules suitable for loading into a 3705 is missing, of course, as it is in MVS. For VTAM it was necessary to recreate several of the missing pieces (such as IFLOADRN, the MVS 3705 loader) and something similar might be possible with VM, but not sure what you would end up with, or how to go about doing that...

Max
Mike Schwab
2013-06-05 05:32:10 UTC
Permalink
I think this should be included in TK4. Any word on RPF/380?
Post by Juergen
Post by Gregg Levine
Post by Juergen
Makes me wonder whether VTAM would correctly handle a 3791L
that dropped a connection; if not, it would be interesting to
see whether unrestricted software for a 37x5 could be
obtained?
Hi Gerhard
LU1 (TTY 3767) as well as LU2 (3270) survive a Telnet
disconnect/reconnect without noticing anything.
Hello!
Juergen would you mind sharing your configuration?
I am interested in your configuration and want to try
it. Of course this presupposes I have here the OS
examples that would work with your configuration.
-----
Hi Gregg
Of course I don't mind sharing the configuration. The problem is that it wouldn't be of use for most people here: It is based on my homegrown MVS 3.8j system, which is based on the original TK3 system with additions up to approximately Phil's TK3UPD (I name this system "internally" TK4-).
o Local 3270 non SNA under VTAM
o Local 3270 SNA LU2 under VTAM via 3791L
o Local 3767 SNA LU1 under VTAM via 3791L
o Remote 3270 SNA LU2 under VTAM via 3705 NCP
o Remote 3767 SNA LU1 under VTAM via 3705 NCP
o Local 3270 non SNA under TCAM
o Remote 3270 SNA LU2 under TCAM via 3705 NCP
o Remote 3767 SNA LU1 under TCAM via 3705 NCP
o Remote 3335 non SNA under TCAM via 2703
o Remote 2741 non SNA under TCAM via 2703
To support all the devices needed for these connections the TK4- sysgen differs significantly from the original TK3 or TK3UPD ones, which is one reason why I think that just publishing a few configuration members isn't of much use.
Other reasons are a significant amount of usermods I implemented in the TCAM, TSO/TCAM and TSO/VTAM areas plus quite a bit of automation necessary to get everything to work smoothly. All of this would need a massive documentation effort when being published standalone.
This is why I came to the conclusion to publish the system as a whole, if interest would arise.
I started creating this system about a year ago but put it to sleep back in October 2012 when I started diving into that APL\360 adventure. Now, that I've closed the APL\360 file I'm returning to the TK4- project. Having now implemented a final usermod in the TSO/VTAM field plus enhanced Kermit support for the SNA 3767 connections under VTAM I'm basically at a point, where I could cut of a first version for publication.
This still requires quite a bit of documentation plus some cleanup work on the system. Being off for a business trip in the US for the next two weeks I'll not realistically be able to publish anything before July (after the intensive APL\360 resurrection project I've accumulated a deep red negative time budget anyway).
So, to summarize: Yes, I'm going to make everything available... but I still need some time to do it.
Post by Gregg Levine
Does anything special need to be done to configure
VM/370 Release number 6 to participate in that
arrangement? We have available both the two disk
solution, and the multiple disk solutions.
-----
Up to now I never tried the VM/370 distributions that are available for Hercules. But from my own old VM experiences I remember that there was no native SNA support until the advent of GCS under, I think, VM/XA SP. So, if I'm not totally wrong with this, there is no way to support 3705s (in NCP or PEP mode) or 3791Ls under VM/370 natively.
Cheers
Juergen
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Gerhard Postpischil
2013-06-05 05:54:31 UTC
Permalink
Post by Mike Schwab
I think this should be included in TK4. Any word on RPF/380?
It's coming along very, very slowly. I decided to redo all of the screen
I/O, as the original code was faulty (it assumed that the return on a
read was fixed length for most of the pages, as though the author had
never used an Erase EOF key or null fields; it's too easy to lose
several hours worth of changes). As a benefit of the redesign (adapted
from ETPS with many changes), it's easier to support model 2-5 geometry
without a complete redefinition in each module. But it's one step back
for every step forward - model 4 Edit gets 0Cx abends I have not been
able to trace yet; the JCL scan flags correct jobs and fails to find
some errors; etc.

Gerhard Postpischil
Bradford, Vermont
"Fish" (David B. Trout)
2013-06-04 18:17:18 UTC
Permalink
Juergen wrote:

<snip>
From my point of view there is no need to change anything
in Hercules' current behavior!
Thank you, Juergen. That's what I've been saying from the beginning. :)
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
ikj1234i
2013-06-04 20:29:20 UTC
Permalink
Post by Juergen
I just did a quick test on a 3791L emulated through comm3705: LU1 (TTY 3767) as well as LU2 (3270) survive a Telnet disconnect/reconnect without noticing anything. The TSO session remains in the same state as it was before the disconnect, i.e. it doesn't get logically disconnected and consequently doesn't require a logon reconnect command to get reinstated. A CCW trace shows no activity on the 3791L channel address, neither at telnet disconnect nor at reconnect time.
Not sure that this proves anything whatsoever, inasmuch as the fakery that is known as comm3705 makes no pretense of handling these sorts of situations "correctly". Trying to come up with a definition of "correct" behavior in this case (i.e., attempting to map a "transiently" connected tn3270 terminal to an LU connected to a line defined as non-switched to VTAM). You end up I think at exactly the same place as this whole thread has ended up :-)

Max
Rocky Martin
2013-06-02 07:39:20 UTC
Permalink
Yup Tony

I remember that situation very well.

I had an application that used lots of dialed terminals and that became a
real problem.

VM SP/5. I made some fixes to the VM and regenned and I managed to remove
that Problem.

It now goes to the VM logon/Dial screen

I have all the fixes somewhere written more or less properly, so it's easy
to install if you want to see it.

But as I said - VM/SP5

Roc



From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On
Behalf Of Tony Harminc
Sent: Sunday, June 02, 2013 2:51 AM
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
Post by somitcw
Hercules opened a security flaw that someone could drive
a truck through and that if it were IBM code, many
customers would APAR. IBM always accepts APARs for
manufactured security holes.
Well, Hercules didn't open it. It became well known when people
started running guest OSs under VM, and used the DIAL facility and/or
VM/PassThrough (PVM). Somewhere around 1984 I tried to APAR the
situation where we moved a system running CICS on MVS to a virtual
machine on a 4341 under VM/SP, and ran into the problem that CICS
users would drop their DIALed connection and someone else would DIAL
and find themselves connected to the first user's session. Turns out
there was (is) a CICS gen option to disconnect on the unsolicited
Device End that we've all been talking about, but it wasn't the
default, and no one in the shop had thought of the situation before.
(This was at a time when it was normal for CICS security to ba based
on terminal ID and there was no logon at all!)
Post by somitcw
Did the IBM P/390 code trying to emulate exactly what
Hercules emulates have a TN3270 security enabled/disabled
option? If so, it would be nice to see one for Hercules.
The default of course should be: TN3270-SECURITY ENABLED
with loud messages if anyone selects the un-secure option.
Of course if you accidently disconnect from your MVS console session,
things aren't going to go too well if you can't reconnect to it.

I think great care needs to be taken before deciding to make Hercules
behaviour differ from that of the real hardware. Not that it should
never be done - clearly hercules isn't real hardware, and there are
some inevitable differences - but it should be well thought through
rather than just being declared a bug and changed incompatibly.

Tony H.





[Non-text portions of this message have been removed]
"Fish" (David B. Trout)
2013-06-01 15:28:45 UTC
Permalink
[...]
It is only when the device becomes READY again as a result
of powering it ON that an UNSOLICITED(*) device attention
interrupt is generated. [...]
(*) And it is "unsolicited" because the program did not specifically ask the
device for the attention interrupt. How could it? The device is not
responding! It's been powered off! The only way SOLICITED requests can be
made is when a device is powered on and able to respond "Ok!" to a solicited
request for something. Thus, when the device is powered on, the device
attention interrupt that results is classified as "unsolicited".

A device that has been powered off is unable to do much anything. :)

It is only when it is powered ON that it is then able to do something (which
in this case is generate an unsolicited device attention interrupt).
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
dhdurgee
2013-06-02 14:42:55 UTC
Permalink
Post by paoloG
Hi Dave,
I'll post the answer also in this forum as the problem seems to be Hercules related.
'logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),',
This is the block of code that handles TN3270 disconnections
device_attention (dev, CSW_DE);
return (CSW_ATTN | CSW_UC);
Now when I disconnect the TN3270 session the Virtual Machine is forced to disconnect, as it happens in your P/370 environment.
I must confess I don't remember the behaviour of real 3278 when powered off - I hanven't seen one of them for over 20 years ;-)...
Regards.
Paul
I am seeing somewhat different behavior here than you for some reason. Instead of the HHCTE014I I am seeing HHCTE007I with a TN3270 client or a HHCTE008I with a telnet client. I tried inserting the above "device_attention (dev, CSW_DE);" in those sections in hope that it would correct the issue, but it does not. In fact it makes things worse! Adding this not only fails to force the disconnect it results in a hung tn3270/telnet server and an error when attempting to shut down:

HHCCP017I CPU0000: Machine check due to host error: User defined signal 1
PSW=000C1000 000022BC INST=90EFC840 STM 14,15,2112(12) store_multiple
R:00002840:K:06=0000C00A 000003E7 9600E000 00002000 ..{....Xo.\.....
GR00=00000006 GR01=00000200 GR02=00000000 GR03=00000000
GR04=00000002 GR05=0000001E GR06=0007F780 GR07=0007E720
GR08=000003E8 GR09=0007F9C4 GR10=00000000 GR11=0008FF98
GR12=00002000 GR13=00000064 GR14=0000C00C GR15=000003E7



DMKCKP901W SYSTEM RECOVERY FAILURE; MACHINE CHECK


HHCCP011I CPU0000: Disabled wait state
PSW=000A0000 00000007

At this point I had to close the hercules window, as the command prompt hung when I entered "quit" on it. I also found that when I restarted VM it must have run a checkpoint restart, but I never saw the output and the integrated console was acting strange after I logged onto operator issuing prompts for input. This was corrected after a clean shutdown and restart.

Dave
paoloG
2013-06-02 23:25:34 UTC
Permalink
Hi Dave,

perhaps the reason is that I'm using Tom Brennan's Vista TN3270 as TN3270 client; when I disconnect the session I get the Hercules msg:
HHCTE014I (connection reset), and eveything behaves correctly with my modification.

Probably your emulator behaves differently....

Regards.

Paul
Post by dhdurgee
Post by paoloG
Hi Dave,
I'll post the answer also in this forum as the problem seems to be Hercules related.
'logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),',
This is the block of code that handles TN3270 disconnections
device_attention (dev, CSW_DE);
return (CSW_ATTN | CSW_UC);
Now when I disconnect the TN3270 session the Virtual Machine is forced to disconnect, as it happens in your P/370 environment.
I must confess I don't remember the behaviour of real 3278 when powered off - I hanven't seen one of them for over 20 years ;-)...
Regards.
Paul
HHCCP017I CPU0000: Machine check due to host error: User defined signal 1
PSW=000C1000 000022BC INST=90EFC840 STM 14,15,2112(12) store_multiple
R:00002840:K:06=0000C00A 000003E7 9600E000 00002000 ..{....Xo.\.....
GR00=00000006 GR01=00000200 GR02=00000000 GR03=00000000
GR04=00000002 GR05=0000001E GR06=0007F780 GR07=0007E720
GR08=000003E8 GR09=0007F9C4 GR10=00000000 GR11=0008FF98
GR12=00002000 GR13=00000064 GR14=0000C00C GR15=000003E7
DMKCKP901W SYSTEM RECOVERY FAILURE; MACHINE CHECK
HHCCP011I CPU0000: Disabled wait state
PSW=000A0000 00000007
At this point I had to close the hercules window, as the command prompt hung when I entered "quit" on it. I also found that when I restarted VM it must have run a checkpoint restart, but I never saw the output and the integrated console was acting strange after I logged onto operator issuing prompts for input. This was corrected after a clean shutdown and restart.
Dave
dhdurgee
2013-06-05 13:51:36 UTC
Permalink
Post by paoloG
Hi Dave,
HHCTE014I (connection reset), and eveything behaves correctly with my modification.
Probably your emulator behaves differently....
Regards.
Paul
Hmmm. If you have the time, perhaps you could exit your emulator as opposed to disconnecting the session and see if that gives you the HHCTE007I message. If so and you have the time, perhaps you could determine the patch required to accomplish the same thing your other patch does for the HHCTE014I message.

Thanks for your assistance with this issue.

Dave
paoloG
2013-06-05 14:38:39 UTC
Permalink
Post by dhdurgee
Post by paoloG
Hi Dave,
HHCTE014I (connection reset), and eveything behaves correctly with my modification.
Probably your emulator behaves differently....
Regards.
Paul
Hmmm. If you have the time, perhaps you could exit your emulator as opposed to disconnecting the session and see if that gives you the HHCTE007I message. If so and you have the time, perhaps you could determine the patch required to accomplish the same thing your other patch does for the HHCTE014I message.
Thanks for your assistance with this issue.
Dave
Hi Dave,

I tried both disconnecting VISTA TN3270 with the sequence: press FILE button - Disconnect, and killing it with X button or terminating the process with Windows Task Manager.

Both the actions led me to the same message :HHCTE014I, and to the forced disconnection of my VM user:-).

I could try with IBM Personal Communication, that I use sometimes (as it's the only emulator I know to support APL characters), when I'm in the mood of playing a little with APL.

BTW I'm always speaking of Windows, as I only use Linux machines as 'Hercules Mainframes' without X support, and my 3270 emulators are always on Windows computers.

Regards.

Paul
dhdurgee
2013-06-05 16:24:30 UTC
Permalink
Post by paoloG
Post by dhdurgee
Post by paoloG
Hi Dave,
HHCTE014I (connection reset), and eveything behaves correctly with my modification.
Probably your emulator behaves differently....
Regards.
Paul
Hmmm. If you have the time, perhaps you could exit your emulator as opposed to disconnecting the session and see if that gives you the HHCTE007I message. If so and you have the time, perhaps you could determine the patch required to accomplish the same thing your other patch does for the HHCTE014I message.
Thanks for your assistance with this issue.
Dave
Hi Dave,
I tried both disconnecting VISTA TN3270 with the sequence: press FILE button - Disconnect, and killing it with X button or terminating the process with Windows Task Manager.
Both the actions led me to the same message :HHCTE014I, and to the forced disconnection of my VM user:-).
I could try with IBM Personal Communication, that I use sometimes (as it's the only emulator I know to support APL characters), when I'm in the mood of playing a little with APL.
BTW I'm always speaking of Windows, as I only use Linux machines as 'Hercules Mainframes' without X support, and my 3270 emulators are always on Windows computers.
Regards.
Paul
Interesting. Perhaps Windows handles the TCP/IP stack a bit differently than linux. If you see the same behavior with PComm I would guess that it is the Windows TCP/IP stack. In that case, perhaps you could install c3270 on a linux box. As this is a curses based tn3270 client you don't need X to run it.

Interesting that you are another APL'er. That is what we run here on our P/370, which was built for us as an APL2 development system by ISI. If you want another tn3270 client that supports APL characters you can use x3270, which I do here. I have customized a keyboard to match the PComm behavior, which I had also customized a bit. I should note that x3270 is the client I am using with hercules as well.

Dave
dhdurgee
2013-06-05 20:12:48 UTC
Permalink
A short follow-up.

I can confirm that c3270 will work from a linux full screen console by testing. I started hercules in an x-terminal window on my x console and the switched to a text console via Ctl-Alt-F1 on which I logged on and then used c3270 to connect to the hercules running in the x-terminal window. I saw the same HCTE007I when I disconnected c3270 by quitting it while connected that I see with x3270.

Given this I believe you should be able to duplicate this on your linux system without x running.

Dave
paoloG
2013-06-05 22:28:27 UTC
Permalink
Post by dhdurgee
Post by paoloG
Post by dhdurgee
Post by paoloG
Hi Dave,
HHCTE014I (connection reset), and eveything behaves correctly with my modification.
Probably your emulator behaves differently....
Regards.
Paul
Hmmm. If you have the time, perhaps you could exit your emulator as opposed to disconnecting the session and see if that gives you the HHCTE007I message. If so and you have the time, perhaps you could determine the patch required to accomplish the same thing your other patch does for the HHCTE014I message.
Thanks for your assistance with this issue.
Dave
Hi Dave,
I tried both disconnecting VISTA TN3270 with the sequence: press FILE button - Disconnect, and killing it with X button or terminating the process with Windows Task Manager.
Both the actions led me to the same message :HHCTE014I, and to the forced disconnection of my VM user:-).
I could try with IBM Personal Communication, that I use sometimes (as it's the only emulator I know to support APL characters), when I'm in the mood of playing a little with APL.
BTW I'm always speaking of Windows, as I only use Linux machines as 'Hercules Mainframes' without X support, and my 3270 emulators are always on Windows computers.
Regards.
Paul
Interesting. Perhaps Windows handles the TCP/IP stack a bit differently than linux. If you see the same behavior with PComm I would guess that it is the Windows TCP/IP stack. In that case, perhaps you could install c3270 on a linux box. As this is a curses based tn3270 client you don't need X to run it.
Interesting that you are another APL'er. That is what we run here on our P/370, which was built for us as an APL2 development system by ISI. If you want another tn3270 client that supports APL characters you can use x3270, which I do here. I have customized a keyboard to match the PComm behavior, which I had also customized a bit. I should note that x3270 is the client I am using with hercules as well.
Dave
Hi Dave,

with IBM PComm when I disconnect or kill the TN3270 session I get the msg HHCTE007I (the same you are getting), so my guess that it depended on the TN3270 emulator was correct.

Now in Italy it's a bit late - tomorrow I'll do some try to patch console.c.

See you

Paul
paoloG
2013-06-06 06:56:07 UTC
Permalink
Post by dhdurgee
Post by paoloG
Post by dhdurgee
Post by paoloG
Hi Dave,
HHCTE014I (connection reset), and eveything behaves correctly with my modification.
Probably your emulator behaves differently....
Regards.
Paul
Hmmm. If you have the time, perhaps you could exit your emulator as opposed to disconnecting the session and see if that gives you the HHCTE007I message. If so and you have the time, perhaps you could determine the patch required to accomplish the same thing your other patch does for the HHCTE014I message.
Thanks for your assistance with this issue.
Dave
Hi Dave,
I tried both disconnecting VISTA TN3270 with the sequence: press FILE button - Disconnect, and killing it with X button or terminating the process with Windows Task Manager.
Both the actions led me to the same message :HHCTE014I, and to the forced disconnection of my VM user:-).
I could try with IBM Personal Communication, that I use sometimes (as it's the only emulator I know to support APL characters), when I'm in the mood of playing a little with APL.
BTW I'm always speaking of Windows, as I only use Linux machines as 'Hercules Mainframes' without X support, and my 3270 emulators are always on Windows computers.
Regards.
Paul
Interesting. Perhaps Windows handles the TCP/IP stack a bit differently than linux. If you see the same behavior with PComm I would guess that it is the Windows TCP/IP stack. In that case, perhaps you could install c3270 on a linux box. As this is a curses based tn3270 client you don't need X to run it.
Interesting that you are another APL'er. That is what we run here on our P/370, which was built for us as an APL2 development system by ISI. If you want another tn3270 client that supports APL characters you can use x3270, which I do here. I have customized a keyboard to match the PComm behavior, which I had also customized a bit. I should note that x3270 is the client I am using with hercules as well.
Dave
Hi Dave,

so far this is the situation:

Hercules manages VISTA TN3270 and IBM PComm disconnection or killing
in a different way, giving two different messages (HHTCE007I and HHTCE014I).

So I did another even quick and dirty mod, that causes both emulators
to use the same Hercules connection reset routine.

Here is the final result (Console.c - Hercules 3.08.1):
----------------------------------------------------------
if (rc <= 0) { <-------------
if ( HSO_ECONNRESET == HSO_errno )
logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),
dev->devtype, dev->devnum, inet_ntoa(dev->ipaddr) );
else
TNSERROR("console: DBG023: recv: %s\n", strerror(HSO_errno));
dev->sense[0] = SENSE_EC;
device_attention (dev, CSW_DE); <-------------
return (CSW_ATTN | CSW_UC);
------------------------------------------------------------
there is a modified statement (the first pointed by <-------), and a new one (the second pointed by <--------)

For me it works very well with VISTA TN3270 and IBM PComm - VM/SP5 on the host side.

Regards.

Paul
dhdurgee
2013-06-06 16:37:43 UTC
Permalink
Post by paoloG
Post by dhdurgee
Post by paoloG
Post by dhdurgee
Post by paoloG
Hi Dave,
HHCTE014I (connection reset), and eveything behaves correctly with my modification.
Probably your emulator behaves differently....
Regards.
Paul
Hmmm. If you have the time, perhaps you could exit your emulator as opposed to disconnecting the session and see if that gives you the HHCTE007I message. If so and you have the time, perhaps you could determine the patch required to accomplish the same thing your other patch does for the HHCTE014I message.
Thanks for your assistance with this issue.
Dave
Hi Dave,
I tried both disconnecting VISTA TN3270 with the sequence: press FILE button - Disconnect, and killing it with X button or terminating the process with Windows Task Manager.
Both the actions led me to the same message :HHCTE014I, and to the forced disconnection of my VM user:-).
I could try with IBM Personal Communication, that I use sometimes (as it's the only emulator I know to support APL characters), when I'm in the mood of playing a little with APL.
BTW I'm always speaking of Windows, as I only use Linux machines as 'Hercules Mainframes' without X support, and my 3270 emulators are always on Windows computers.
Regards.
Paul
Interesting. Perhaps Windows handles the TCP/IP stack a bit differently than linux. If you see the same behavior with PComm I would guess that it is the Windows TCP/IP stack. In that case, perhaps you could install c3270 on a linux box. As this is a curses based tn3270 client you don't need X to run it.
Interesting that you are another APL'er. That is what we run here on our P/370, which was built for us as an APL2 development system by ISI. If you want another tn3270 client that supports APL characters you can use x3270, which I do here. I have customized a keyboard to match the PComm behavior, which I had also customized a bit. I should note that x3270 is the client I am using with hercules as well.
Dave
Hi Dave,
Hercules manages VISTA TN3270 and IBM PComm disconnection or killing
in a different way, giving two different messages (HHTCE007I and HHTCE014I).
So I did another even quick and dirty mod, that causes both emulators
to use the same Hercules connection reset routine.
----------------------------------------------------------
if (rc <= 0) { <-------------
if ( HSO_ECONNRESET == HSO_errno )
logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),
dev->devtype, dev->devnum, inet_ntoa(dev->ipaddr) );
else
TNSERROR("console: DBG023: recv: %s\n", strerror(HSO_errno));
dev->sense[0] = SENSE_EC;
device_attention (dev, CSW_DE); <-------------
return (CSW_ATTN | CSW_UC);
------------------------------------------------------------
there is a modified statement (the first pointed by <-------), and a new one (the second pointed by <--------)
For me it works very well with VISTA TN3270 and IBM PComm - VM/SP5 on the host side.
I attempted this here and have problems. Here is that section:

---------------------------------------------------------------
if (rc <= 0) { /* dhd - modified from < */
if ( HSO_ECONNRESET == HSO_errno )
logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),
dev->devtype, dev->devnum, inet_ntoa(dev->ipaddr) );
else
TNSERROR("console: DBG023: recv: %s\n", strerror(HSO_errno));
dev->sense[0] = SENSE_EC;
device_attention (dev, CSW_DE); /* dhd - added action */
return (CSW_ATTN | CSW_UC);
----------------------------------------------------------------

This looks functionally identical to me, but here are the results from my hercules log:

----------------------------------------------------------------
Ready; T=0.03/0.09 09:41:17
/(0009) q n
09:41:21 OPERATOR - 0009
Ready; T=0.01/0.01 09:41:21
HHCTE009I Client 127.0.0.1 connected to 3270 device 0:0200
09:41:54 GRAF 0200 LOGON AS 4243 USERS = 002
console: DBG023: recv: Interrupted system call
/(0009) q n
09:42:24 4243 - 0200, OPERATOR - 0009
Ready; T=0.01/0.01 09:42:24
/(0009) force 4243
Ready; T=0.01/0.01 09:43:15
09:43:16 GRAF 0200 LOGOFF AS 4243 USERS = 001 FORCED
/(0009) q n
09:43:18 OPERATOR - 0009
Ready; T=0.01/0.01 09:43:18
/(0009) shutdown
HHCCP017I CPU0000: Machine check due to host error: User defined signal 1
PSW=000C1000 000022BC INST=90EFC840 STM 14,15,2112(12) store_multiple
R:00002840:K:06=0000C00A 000003E7 9600E000 00002000 ..{....Xo.\.....
GR00=00000006 GR01=00000200 GR02=00000000 GR03=00000000
GR04=00000002 GR05=0000001E GR06=0007F780 GR07=0007E720
GR08=000003E8 GR09=0007F9C4 GR10=00000000 GR11=0008FF98
GR12=00002000 GR13=00000064 GR14=0000C00C GR15=000003E7



DMKCKP901W SYSTEM RECOVERY FAILURE; MACHINE CHECK


HHCCP011I CPU0000: Disabled wait state
PSW=000A0000 00000007
HHCAO001I Hercules Automatic Operator thread started;
tid=7F01ABCFC700, pri=0, pid=19620
--------------------------------------------------------------------

I do not understand the reason I am seeing different behavior, unless it relates to elsewhere in the source. I am working with the 3.08 base code, does the "3.08.1" you note above refer to a later release or did you bump the version to reflect your above change? If this IS a later release, how do I obtain that source to work with?

Dave
paoloG
2013-06-06 18:43:54 UTC
Permalink
Post by dhdurgee
Post by paoloG
Post by dhdurgee
Post by paoloG
Post by dhdurgee
Post by paoloG
Hi Dave,
HHCTE014I (connection reset), and eveything behaves correctly with my modification.
Probably your emulator behaves differently....
Regards.
Paul
Hmmm. If you have the time, perhaps you could exit your emulator as opposed to disconnecting the session and see if that gives you the HHCTE007I message. If so and you have the time, perhaps you could determine the patch required to accomplish the same thing your other patch does for the HHCTE014I message.
Thanks for your assistance with this issue.
Dave
Hi Dave,
I tried both disconnecting VISTA TN3270 with the sequence: press FILE button - Disconnect, and killing it with X button or terminating the process with Windows Task Manager.
Both the actions led me to the same message :HHCTE014I, and to the forced disconnection of my VM user:-).
I could try with IBM Personal Communication, that I use sometimes (as it's the only emulator I know to support APL characters), when I'm in the mood of playing a little with APL.
BTW I'm always speaking of Windows, as I only use Linux machines as 'Hercules Mainframes' without X support, and my 3270 emulators are always on Windows computers.
Regards.
Paul
Interesting. Perhaps Windows handles the TCP/IP stack a bit differently than linux. If you see the same behavior with PComm I would guess that it is the Windows TCP/IP stack. In that case, perhaps you could install c3270 on a linux box. As this is a curses based tn3270 client you don't need X to run it.
Interesting that you are another APL'er. That is what we run here on our P/370, which was built for us as an APL2 development system by ISI. If you want another tn3270 client that supports APL characters you can use x3270, which I do here. I have customized a keyboard to match the PComm behavior, which I had also customized a bit. I should note that x3270 is the client I am using with hercules as well.
Dave
Hi Dave,
Hercules manages VISTA TN3270 and IBM PComm disconnection or killing
in a different way, giving two different messages (HHTCE007I and HHTCE014I).
So I did another even quick and dirty mod, that causes both emulators
to use the same Hercules connection reset routine.
----------------------------------------------------------
if (rc <= 0) { <-------------
if ( HSO_ECONNRESET == HSO_errno )
logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),
dev->devtype, dev->devnum, inet_ntoa(dev->ipaddr) );
else
TNSERROR("console: DBG023: recv: %s\n", strerror(HSO_errno));
dev->sense[0] = SENSE_EC;
device_attention (dev, CSW_DE); <-------------
return (CSW_ATTN | CSW_UC);
------------------------------------------------------------
there is a modified statement (the first pointed by <-------), and a new one (the second pointed by <--------)
For me it works very well with VISTA TN3270 and IBM PComm - VM/SP5 on the host side.
---------------------------------------------------------------
if (rc <= 0) { /* dhd - modified from < */
if ( HSO_ECONNRESET == HSO_errno )
logmsg( _( "HHCTE014I %4.4X device %4.4X client %s connection reset\n" ),
dev->devtype, dev->devnum, inet_ntoa(dev->ipaddr) );
else
TNSERROR("console: DBG023: recv: %s\n", strerror(HSO_errno));
dev->sense[0] = SENSE_EC;
device_attention (dev, CSW_DE); /* dhd - added action */
return (CSW_ATTN | CSW_UC);
----------------------------------------------------------------
----------------------------------------------------------------
Ready; T=0.03/0.09 09:41:17
/(0009) q n
09:41:21 OPERATOR - 0009
Ready; T=0.01/0.01 09:41:21
HHCTE009I Client 127.0.0.1 connected to 3270 device 0:0200
09:41:54 GRAF 0200 LOGON AS 4243 USERS = 002
console: DBG023: recv: Interrupted system call
/(0009) q n
09:42:24 4243 - 0200, OPERATOR - 0009
Ready; T=0.01/0.01 09:42:24
/(0009) force 4243
Ready; T=0.01/0.01 09:43:15
09:43:16 GRAF 0200 LOGOFF AS 4243 USERS = 001 FORCED
/(0009) q n
09:43:18 OPERATOR - 0009
Ready; T=0.01/0.01 09:43:18
/(0009) shutdown
HHCCP017I CPU0000: Machine check due to host error: User defined signal 1
PSW=000C1000 000022BC INST=90EFC840 STM 14,15,2112(12) store_multiple
R:00002840:K:06=0000C00A 000003E7 9600E000 00002000 ..{....Xo.\.....
GR00=00000006 GR01=00000200 GR02=00000000 GR03=00000000
GR04=00000002 GR05=0000001E GR06=0007F780 GR07=0007E720
GR08=000003E8 GR09=0007F9C4 GR10=00000000 GR11=0008FF98
GR12=00002000 GR13=00000064 GR14=0000C00C GR15=000003E7
DMKCKP901W SYSTEM RECOVERY FAILURE; MACHINE CHECK
HHCCP011I CPU0000: Disabled wait state
PSW=000A0000 00000007
HHCAO001I Hercules Automatic Operator thread started;
tid=7F01ABCFC700, pri=0, pid=19620
--------------------------------------------------------------------
I do not understand the reason I am seeing different behavior, unless it relates to elsewhere in the source. I am working with the 3.08 base code, does the "3.08.1" you note above refer to a later release or did you bump the version to reflect your above change? If this IS a later release, how do I obtain that source to work with?
Dave
Hi Dave,

the Hercules 3.08.1 IS a later release; look at

https://github.com/s390guy/hercules-390

After TN3270 disconnection,your message is:
'console: DBG023: recv: Interrupted system call'
and doesn't look very encouraging;-)

while I get this message:
'console: DBG023: recv: No error'
that looks somehow harmless:)

the error description comes from ' strerror(HSO_errno)',
so HSO_errno is different using IBM PComm and your emulator.

Could you try with VISTA TN3270 or IBM PComm?

Regards.

Paul

John P. Hartmann
2013-05-29 15:59:05 UTC
Permalink
Post by dhdurgee
**
Post by Ivan Warren
-----Message d'origine-----
De
Post by Ivan Warren
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as
not
Post by Ivan Warren
ready by 1) Attempting to perform an operation 2) by making the device
ready
Post by Ivan Warren
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
Perhaps I need to back up and clarify the situation I am attempting to
address. I am looking at the case where a tn3270 has been established to
hercules and the user has logged into VM, in my case VM/ESA 1.5 (370
feature) in particular. As the user would likely be running APL2 the 3270
session would generally be in VM READ state, thus I would expect a read CCW
of some kind has been issued and is awaiting completion.
Wrong assumption. There is no active channel program when the terminal
sits in a VM READ. VM READ means that a 1052 would have the keyboard
open. (And so does CP READ).
Post by dhdurgee
I need to properly handle the case where the tn3270 connection is
disrupted, In this case I am simulating this case by asking the 3270 client
to disconnect. This is indeed being detected by hercules, as my console log
HHCTE007I 3270 device xxxx client yyy.yyy.yyy.yyy connection closed.
I would expect this to result in VM placing the virtual machine in
disconnected status, as it does when I do this with a session to my P/370
system. At present this does NOT happen, the virtual machine remains
connected to the disconnected line.
Currently console.c shows CSW_ATTN | CSW_UC | CSW_DE being returned when
the above error is logged. This does not result in VM disconnecting the
virtual machine. What do I need to set as the return in this circumstance
in order for VM to disconnect the virtual machine so it can be cleanly
reconnected later?
Your (whoever's?) code is merging too many status bits here. You need to
present ATTN + UNIT check. Then subsequently the asynchronous DE.
Post by dhdurgee
As this is in the console.c any changes made will apply specifically to
3270 console devices, not any other devices. I will also need to address a
similar situation with 1050/3215 console devices, which are associated with
a different error message.
If you need more information to assist me please let me know what you need
me to trace or log for you.
Dave
[Non-text portions of this message have been removed]
Ivan Warren
2013-05-29 16:17:16 UTC
Permalink
-----Message d'origine-----
De : hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] De
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 17:59
À : hercules-390-***@public.gmane.org
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly

Your (whoever's?) code is merging too many status bits here. You need to
present ATTN + UNIT check. Then subsequently the asynchronous DE.

********

Actually, ATTN+CU only and no DE (since this would imply that the Control
Unit detected an error and the device subsequently became ready again).

It's possible that the 3174 emulation on the P370 does differently (and you
would be the one to really know about this John). A *real* 3174 would never
issue any unsolicited status in response to a terminal being turned off or
disconnected from the CU... Maybe the AWS version (and possible the ICCS
version) react differently..

There is *SOME* provision for some error being reported with ATTN+UC - but
not for the case when the terminal connection is lost (but then again..
ATTN+UC with an Int Req sense *could* work).

See :

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7A7003/3.1.3.2.
3?SHELF=EZ2HW125&DT=19941103140433&CASE=

Last row.

PS : IMHO, this is not a VM issue, but purely an emulation issue (although
it is causing grief for a VM user - but that's secondary).

--Ivan
Mike Alexander
2013-05-29 16:44:15 UTC
Permalink
Post by Ivan Warren
PS : IMHO, this is not a VM issue, but purely an emulation issue (although
it is causing grief for a VM user - but that's secondary).
I'm not sure this can easily be fixed without changing the host software. If I understand what you're talking about, the same issue affects MTS too. When a remote TN3270 session disconnects from an emulated local 3270 session MTS doesn't sign the user off. If you think back to real 3274's this isn't surprising. A given channel address was connected to a specific 3270 and it was something of a big deal to change this. If a 3270 got turned off and back on again, it was still the same 3270 in the same person's office. MTS probably never noticed that it was off (unless it tried to update the screen while it was off) so when it was turned back on the session continued as if nothing had happened. This is very much what the user wanted. VM may be doing much the same thing. Since this isn'
t the behavior you want when the 3270's are actually remote sessions instead of hard wired local terminals, I've thought about changing MTS's behavior, but haven't done anything about it.

Mike


[Non-text portions of this message have been removed]
dhdurgee
2013-05-29 17:18:09 UTC
Permalink
Post by Ivan Warren
PS : IMHO, this is not a VM issue, but purely an emulation issue (although
it is causing grief for a VM user - but that's secondary).
I'm not sure this can easily be fixed without changing the host software. If I understand what you're talking about, the same issue affects MTS too. When a remote TN3270 session disconnects from an emulated local 3270 session MTS doesn't sign the user off. If you think back to real 3274's this isn't surprising. A given channel address was connected to a specific 3270 and it was something of a big deal to change this. If a 3270 got turned off and back on again, it was still the same 3270 in the same person's office. MTS probably never noticed that it was off (unless it tried to update the screen while it was off) so when it was turned back on the session continued as if nothing had happened. This is very much what the user wanted. VM may be doing much the same thing. Since this isn't the behavior you want when the 3270's are actually remote sessions instead of hard wired local terminals, I've thought about changing MTS's behavior, but haven't done anything about it.
Mike
As I noted, I am running VM/ESA 1.5 as configured to run on a P/370, so I would imagine that any host changes were incorporated when VM/ESA 1.5 was generated. I am attaching my 3270 consoles to the same lines that are being used for this purpose on the P/370, so I would think that were the same information presented by hercules to VM/ESA as the P/370 devices present that the same behavior would be obtained.

I can, with some difficulty, obtain CPTRAP information from the P/370 if that will be necessary to determine what is being seen by VM. My problem is that I lack the software to interpret the CTRAP captured data and must do so by hand after dumping the spool file to tape.

If indeed this would require something special be done for a 3270 console attached to hercules to work as it does with a P/370 perhaps we could add a configuration file option to activate it as opposed to the default behavior. I imagine I might need a similar modification to address any 1052/3215 connected consoles to handle a disconnect properly.

Dave
Mike Schwab
2013-05-29 20:27:31 UTC
Permalink
Last time I used a IBM 3278 (1988) with MVS 3.8 or XA, if we lost
connection we had to hit Attn and Sys Req to get our screen going
again.
Post by Ivan Warren
PS : IMHO, this is not a VM issue, but purely an emulation issue (although
it is causing grief for a VM user - but that's secondary).
I'm not sure this can easily be fixed without changing the host software. If I understand what you're talking about, the same issue affects MTS too. When a remote TN3270 session disconnects from an emulated local 3270 session MTS doesn't sign the user off. If you think back to real 3274's this isn't surprising. A given channel address was connected to a specific 3270 and it was something of a big deal to change this. If a 3270 got turned off and back on again, it was still the same 3270 in the same person's office. MTS probably never noticed that it was off (unless it tried to update the screen while it was off) so when it was turned back on the session continued as if nothing had happened. This is very much what the user wanted. VM may be doing much the same thing. Since this isn't the behavior you want when the 3270's are actually remote sessions instead of hard wired local terminals, I've thought about changing MTS's behavior, but haven't done anything about it.
Mike
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
John P. Hartmann
2013-05-29 20:43:32 UTC
Permalink
That's VTAM unformatted services. VM doesn't do that.
Post by Mike Schwab
**
Last time I used a IBM 3278 (1988) with MVS 3.8 or XA, if we lost
connection we had to hit Attn and Sys Req to get our screen going
again.
[Non-text portions of this message have been removed]
dhdurgee
2013-05-29 17:02:53 UTC
Permalink
Post by Ivan Warren
-----Message d'origine-----
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 17:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
Your (whoever's?) code is merging too many status bits here. You need to
present ATTN + UNIT check. Then subsequently the asynchronous DE.
********
Actually, ATTN+CU only and no DE (since this would imply that the Control
Unit detected an error and the device subsequently became ready again).
It's possible that the 3174 emulation on the P370 does differently (and you
would be the one to really know about this John). A *real* 3174 would never
issue any unsolicited status in response to a terminal being turned off or
disconnected from the CU... Maybe the AWS version (and possible the ICCS
version) react differently..
There is *SOME* provision for some error being reported with ATTN+UC - but
not for the case when the terminal connection is lost (but then again..
ATTN+UC with an Int Req sense *could* work).
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7A7003/3.1.3.2.
3?SHELF=EZ2HW125&DT=19941103140433&CASE=
Last row.
PS : IMHO, this is not a VM issue, but purely an emulation issue (although
it is causing grief for a VM user - but that's secondary).
--Ivan
Per the above I edited console.c to remove the CSW_DE from the return, but this is still not resulting in a disconnected virtual machine. I should perhaps also note that prior to the return I see:

dev->sense[0] = SENSE_IR;

So it does appear the Int Req sense is set here.

What additional information or tests can I do for you?

Dave
John P. Hartmann
2013-05-29 17:19:07 UTC
Permalink
I think we are getting two scenarios mixed up here. One is the VM TCP/IP
TN3270 server's handling of a lost connexion.

The other, which is what this thread is supposed to be about, is the TN3270
server in Hercules.

Right now with the end of April sandhawk I get this when I close the
emulated terminal without disconnecting:

HHC01022I 0:03C1 COMM: client 192.168.2.32 devtype 3270: connection closed
by
client

HHC00160I SCP command: q
john2

q
john2

18:09:01 JOHN2 -
03C1

Ready; T=0.01/0.01 18:09:01

To recover from this, I usually log on HERE to reconnect to the session. I
don't recall it ever being different, but memory is fading.
Post by Ivan Warren
**
Post by Ivan Warren
-----Message d'origine-----
De
Post by Ivan Warren
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 17:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
Your (whoever's?) code is merging too many status bits here. You need to
present ATTN + UNIT check. Then subsequently the asynchronous DE.
********
Actually, ATTN+CU only and no DE (since this would imply that the Control
Unit detected an error and the device subsequently became ready again).
It's possible that the 3174 emulation on the P370 does differently (and
you
Post by Ivan Warren
would be the one to really know about this John). A *real* 3174 would
never
Post by Ivan Warren
issue any unsolicited status in response to a terminal being turned off
or
Post by Ivan Warren
disconnected from the CU... Maybe the AWS version (and possible the ICCS
version) react differently..
There is *SOME* provision for some error being reported with ATTN+UC -
but
Post by Ivan Warren
not for the case when the terminal connection is lost (but then again..
ATTN+UC with an Int Req sense *could* work).
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7A7003/3.1.3.2.
Post by Ivan Warren
3?SHELF=EZ2HW125&DT=19941103140433&CASE=
Last row.
PS : IMHO, this is not a VM issue, but purely an emulation issue
(although
Post by Ivan Warren
it is causing grief for a VM user - but that's secondary).
--Ivan
Per the above I edited console.c to remove the CSW_DE from the return, but
this is still not resulting in a disconnected virtual machine. I should
dev->sense[0] = SENSE_IR;
So it does appear the Int Req sense is set here.
What additional information or tests can I do for you?
Dave
[Non-text portions of this message have been removed]
dhdurgee
2013-05-29 17:37:58 UTC
Permalink
Post by John P. Hartmann
I think we are getting two scenarios mixed up here. One is the VM TCP/IP
TN3270 server's handling of a lost connexion.
The other, which is what this thread is supposed to be about, is the TN3270
server in Hercules.
Right now with the end of April sandhawk I get this when I close the
HHC01022I 0:03C1 COMM: client 192.168.2.32 devtype 3270: connection closed
by
client
HHC00160I SCP command: q
john2
q
john2
18:09:01 JOHN2 -
03C1
Ready; T=0.01/0.01 18:09:01
To recover from this, I usually log on HERE to reconnect to the session. I
don't recall it ever being different, but memory is fading.
Post by Ivan Warren
**
Post by Ivan Warren
-----Message d'origine-----
De
Post by Ivan Warren
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 17:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
Your (whoever's?) code is merging too many status bits here. You need to
present ATTN + UNIT check. Then subsequently the asynchronous DE.
********
Actually, ATTN+CU only and no DE (since this would imply that the Control
Unit detected an error and the device subsequently became ready again).
It's possible that the 3174 emulation on the P370 does differently (and
you
Post by Ivan Warren
would be the one to really know about this John). A *real* 3174 would
never
Post by Ivan Warren
issue any unsolicited status in response to a terminal being turned off
or
Post by Ivan Warren
disconnected from the CU... Maybe the AWS version (and possible the ICCS
version) react differently..
There is *SOME* provision for some error being reported with ATTN+UC -
but
Post by Ivan Warren
not for the case when the terminal connection is lost (but then again..
ATTN+UC with an Int Req sense *could* work).
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7A7003/3.1.3.2.
Post by Ivan Warren
3?SHELF=EZ2HW125&DT=19941103140433&CASE=
Last row.
PS : IMHO, this is not a VM issue, but purely an emulation issue
(although
Post by Ivan Warren
it is causing grief for a VM user - but that's secondary).
--Ivan
Per the above I edited console.c to remove the CSW_DE from the return, but
this is still not resulting in a disconnected virtual machine. I should
dev->sense[0] = SENSE_IR;
So it does appear the Int Req sense is set here.
What additional information or tests can I do for you?
Dave
I am here comparing the tn3270 server support in hercules with that of my P/370 and the differing behavior I see. I do not have VM TCP/IP as part of my VM/ESA 1.5 system. I have an entry in my hercules.cnf of:

0200.4 3270

which defines 4 3270 lines at a location so configured in VM/ESA. In my DMKRIO.ASM I see:

RDEVICE ADDRESS=(200,16),DEVTYPE=3278,MODEL=2

So I could have defined additional 3270 devices but have not at this point as four should be enough to test things out.

As noted in earlier posts, VM/ESA on the P/370 places the user's virtual machine in disconnected state if the tn3270 client connection is closed. At this point, VM/ESA on hercules leaves the user's virtual machine connected to a closed line.

Dave
John P. Hartmann
2013-05-29 15:54:53 UTC
Permalink
Ivan, I'm speaking of how CP determines that the terminal has gone ready
and drops the currently dialed/logged user. A 3270 does not to my
knowledge present asynchronous unit check to alert the host that it has
gone offline.

If CP does an I/O to a not ready terminal, depending on the control unit,
it may even see control unit busy before the unit check.
Post by Ivan Warren
**
-----Message d'origine-----
la part de John P. Hartmann
Envoyé : mercredi 29 mai 2013 15:59
Objet : Re: [hercules-390] Re: hercules 3.08 unexpected disconnects not
handled properly
An unsolicited device end is all it takes on a local GRAF. I don't recall
a 3272 sending an unsolicited unit check when you power off a screen.
Post by Ivan Warren
Yuck ! That NEVER happens ! The device can only be detected as not
ready by 1) Attempting to perform an operation 2) by making the device ready
again 3) when the device becomes not ready during or because of an I/O
operation (for example Rewind Unload always returns UC - amongst other
things depending on the control unit & tape drive)... *PLEASE* people !
Don't break this perfectly working portion of Hercules !
Post by Ivan Warren
--Ivan
[Non-text portions of this message have been removed]



------------------------------------
Ivan Warren
2013-05-29 14:10:10 UTC
Permalink
No no...

The proper response from a control unit receiving a CCW (except for sense
and sense-ID) for a device that is NOT Ready unit is to respond with UC
*ONLY* (no CE, no DE).. This is because the CCW is rejected during
initiation. The CE would indicate the I/O was initiated.

See : (for a general consideration regarding unit check for a not ready
device)

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR110/2.6.9?SH
ELF=EZ2HW125&DT=19920904110920

And : for the 3174 in particular

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7A7003/3.1.3.2.
2?SHELF=EZ2HW125&DT=19941103140433&CASE=

(Table 5-6, 7th row)

--Ivan


-----Message d'origine-----
De : hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] De
la part de dhdurgee
Envoyé : mercredi 29 mai 2013 15:48
À : hercules-390-***@public.gmane.org
Objet : [hercules-390] Re: hercules 3.08 unexpected disconnects not handled
properly
Post by John P. Hartmann
Unit check alone on initial status is also valid. But I don't think
Hercules knows of initial status other than a list of immediate CCW command
codes for each device type.
Post by John P. Hartmann
**
Post by John P. Hartmann
The status for a local 3270 being powered off is CE UC (possibly with DE)
and sense Intervention Required. But on a real terminal, if memory
serves,
Post by John P. Hartmann
the drop comes when the terminal goes ready, that is, presents an
unsolicited device end.
Hmm... in that case perhaps I should add a CSW_CE and see what happens.
Thank you for your response.
Dave
I added CSW_CE but that still does not result in placing the virtual machine
in a disconnected state. Is there a principles of operations manual
available for channel programming that defines what the expected responses
to CSW bits are for VM? For this to work properly the CSW must be set such
that VM's response is to disconnect the virtual machine to permit a clean
reconnection of the user. If such a CSW also requires a vary on or enable
to restore the line to operation that is acceptable as long as the
disconnect occurs.

Dave



------------------------------------

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}

#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}

#ygrp-mkp #ads {
margin-bottom: 10px;
}

#ygrp-mkp .ad {
padding: 0 0;
}

#ygrp-mkp .ad p {
margin: 0;
}

#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}

#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}

#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}

#activity span {
font-weight: 700;
}

#activity span:first-child {
text-transform: uppercase;
}

#activity span a {
color: #5085b6;
text-decoration: none;
}

#activity span span {
color: #ff7900;
}

#activity span .underline {
text-decoration: underline;
}

.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}

.attach div a {
text-decoration: none;
}

.attach img {
border: none;
padding-right: 5px;
}

.attach label {
display: block;
margin-bottom: 5px;
}

.attach label a {
text-decoration: none;
}

blockquote {
margin: 0 0 0 4px;
}

.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}

.bold a {
text-decoration: none;
}

dd.last p a {
font-family: Verdana;
font-weight: 700;
}

dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}

dd.last p span.yshortcuts {
margin-right: 0;
}

div.attach-table div div a {
text-decoration: none;
}

div.attach-table {
width: 400px;
}

div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none;
}

div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited {
text-decoration: none;
}

div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}

.green {
color: #628c2a;
}

.MsoNormal {
margin: 0 0 0 0;
}

o {
font-size: 0;
}

#photos div {
float: left;
width: 72px;
}

#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}

#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}

#reco-category {
font-size: 77%;
}

#reco-desc {
font-size: 77%;
}

.replbq {
margin: 4px;
}

#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}

#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}

#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}

#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}

#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}

#ygrp-mlmsg * {
line-height: 1.22em;
}

#ygrp-mlmsg #logo {
padding-bottom: 10px;
}


#ygrp-msg p a {
font-family: Verdana;
}

#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}

#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}

#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}

#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}

#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}

#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}

#ygrp-text {
font-family: Georgia;
}

#ygrp-text p {
margin: 0 0 1em 0;
}

#ygrp-text tt {
font-size: 120%;
}

#ygrp-vital ul li:last-child {
border-right: none !important;
}
-->
</style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
Rocky
2013-06-02 16:01:00 UTC
Permalink
Post by dhdurgee
I have just downloaded and built hercules 3.08 and am finding that 3270 disconnects are not being handled properly. I am IPLing VM/ESA 1.5 (370 Feature) from my P/370 on hercules. I have configured some 3270 and 3215 ports on it for access. I can logon to VM using x3270 as expected.
Ok - I don't think that this is a Hercules Issue -

It's more of TCPIP/Application/Emulator issue.

If you have an unexpected disconnect - or if you shut your PC off exactly what mechanism is going to cause an interrupt to Hercules.

Remember Hercules needs to get some TCPIP signal to cause an interrupt.

As someone pointed out before there were some bugs in the old IBM code which could cause a security issue when a new session attempted to connect to an old "hanging" session. I remember that problem well.
Users were getting connected to the middle of someone elses session.
Lots of security noise.


I made a small fix to DMKGRF which resolved that issue and if I remember correctly also greatly reduced the Hanging terminal issue, or at least simplified the cleanup.

The fixes were to VMSP5 and I retrofitted them on Hercules and they worked fine.

This is the code: (very small 29 lines)
DMKGRF O31070RM C1 F 80 3 BLKS 8/10/29 LINE 1 O
===>
./ * PREREQ: VM30180
./ * CO-REQ: NONE
./ * IF-REQ: NONE
./ I 04165000 $ 4166000 100
* -------------------------------------------------------- @HERC001
* USE R8 AS A SWITCH FOR SPECIAL LOGO CASE 10/15/08 @HERC001
N R8,=X'7FFFFFFF' SET OFF HIGH BIT 10/15/08 @HERC001
* -------------------------------------------------------- @HERC001
./ R 06970000 $ 6970100 100
* -------------------------------------------------------- @HERC001
* IF USER IS CP THEN CONTINUE ELSE SET SWITCH 10/15/08 @HERC001
* AND GO TO CONLOGOF SWITCH WILL CAUSE ROUTINE TO RE-ENTER @HERC001
* SO THAT USER WILL GET THE LOGON SCREEN AFTER THE FORCE @HERC001
* BNE CONLOGOF REMOVED 10/15/08 @HERC001
BE HERC0 10/15/08 @HERC001
O R8,=X'80000000' SETON HIGH BIT 10/15/08 @HERC001
B CONLOGOF WE STILL GO TO CONLOGOF 10/15/08 @HERC001
* SWITCH IS SET TO FORCE REENTRY TO 10/15/08 @HERC001
* ROUTINE A SECOND TIME AND LOGO WILL 10/15/08 @HERC001
* BE SENT ON THE SECOND TRY 10/15/08 @HERC001
HERC0 EQU * 10/15/08 @HERC001
* ------------------------------------------------------- @HERC001
./ I 19250000 $ 19251000 100
* ------------------------------------------------------- @HERC001
* USE HIGH ORDER BIT OF R8 AS THE SWITCH 10/15/08 @HERC001
LTR R8,R8 IF SWITCH IS ON GO RETRY THE 10/15/08 @HERC001
BC 4,GRFRSTRT 10/15/08 @HERC001
* -------------------------------------------------------- @HERC001
* * * END OF FILE * * *

and this was the descriptor I used -

O31070RM 514-RM FIX OF NO LOGO SCREEN WHEN USER IS FORCED

Not sure if you can retrofit them to other versions of CP

iF ANYBODY IS INTERESTED i CAN SUPPLY MORE INFORMATION - This pretty much resolved the issues as I remember

roc
Loading...