¿ªÔÆÌåÓý

  1. H390-Vm
  2. Topics

XNET v1.4.1

 

Mark,
?
I've never tried to run it disconnected, or autologged.? I don't see any reason why you couldn't, except to say that if the CTC's don't connect for some reason you wouldn't know about it.? I suspect that is the problem here.
?
Even if you autologged it and it is running disconnected, you can log on to it later and issue D TASKS and see if the CTCs are connected.
?
You could also start spooling the XNET console log (in its profile exec) so that when it is autologged everything will be recorded; if it fails to work then you can go back and look at that log and see what the messaging says.
?
Regards,
Bob
 

On Sun, Aug 18, 2024 at 07:36 AM, Bob Polmanter wrote:
I've never tried to run it disconnected, or autologged.? I don't see any reason why you couldn't, except to say that if the CTC's don't connect for some reason you wouldn't know about it.? I suspect that is the problem here.
?
I figured running disconnected would be fine, once I got done debugging the connections. The following is the VM370DEV PROFILE EXEC A. I thought it might be helpful to know the status after the program started, but I guess it clears the stack, so the XNET commands are not processed. See console screen results below.
?
FSVIEW: PROFILE EXEC C1 ? ? ? ? ? ? ? ? ?Lines 1-11/11 V80[1-79] ?FSVIEW V1.2.5
&CONTROL OFF
CP SPOOL CONSOLE START CONT TERM TO * CLASS X
CP SET MSG ?ON
CP SET SMSG ON
CP SET EMSG ON
CP SET IMSG ON
CP SET RUN ?ON
&STACK FIFO D TASKS
&STACK FIFO D NODES
&STACK FIFO M VM370P01 We are up and running.
XNET XMASVMCE

The following is the VM370P01 PROFILE EXEC A (I changed the node name and SYSID to not contain special characters):
?
FSVIEW: PROFILE EXEC C1 ? ? ? ? ? ? ? ? ?Lines 1-11/11 V80[1-79] ?FSVIEW V1.2.5
&CONTROL OFF
CP SPOOL CONSOLE START CONT TERM TO * CLASS X
CP SET MSG ?ON
CP SET SMSG ON
CP SET EMSG ON
CP SET IMSG ON
CP SET RUN ?ON
&STACK FIFO D TASKS
&STACK FIFO D NODES
&STACK FIFO M VM370DEV We are up and running.
XNET XMASVMCE
?
VM370DEV Console
?
L XNET
ENTER PASSWORD:
?
DMKLOG090E DEV 09E NOT DEFINED; DEV 09E NOT AVAILABLE
DMKLOG090E DEV 09F NOT DEFINED; DEV 09F NOT AVAILABLE
LOGMSG - 18:48:00 CST SATURDAY 08/17/24
*
* ? ? ? ? ? ?WELCOME TO THE VM/370 DEVELOPMENT (VM370DEV) SYSTEM ? ? ? ? ? *
*
LOGON AT 13:52:43 CST SUNDAY 08/18/24
VM Community Edition V1 R1.2
?
Y (19E) R/O
Segment GCCLIB is not loaded because virtual machine memory is in use.
U (19D) R/O
XNET010 Cross System Net - V1.4.0 ? 07/15/22 10.42
XNET002 XNET using configuration file XMASVMCE CONFIG ? *
XNET020 VM370DEV active
XNET016 CTCA 500 initialization in progress...
XNET017 CTCA 500 is X-side
XNET019 CTCA 500 connected to node VM370P01 (NETID= ?2)
XNET020 VM370P01 active
XNET012 Device 0C8 connected
XNET028 GRAF 0C8 associated with VM370P01 L000
XNET021 LDEV L000 associated with VM370P01 0C8
XNET029 GRAF 0C8 disassociated with VM370P01 L000
XNET013 Device 0C8 disconnected
XNET015 LDEV L000 disassociated with VM370P01 0C8
?
VM370P01 Console
?
L XNET
ENTER PASSWORD:
?
DMKLOG090E DEV 09E NOT DEFINED; DEV 09E NOT AVAILABLE
DMKLOG090E DEV 09F NOT DEFINED; DEV 09F NOT AVAILABLE
LOGMSG - 18:49:48 CST SATURDAY 08/17/24
*
* ? ? ? ? ? ?WELCOME TO THE VM/370 PRODUCTION (VM370P01) SYSTEM ? ? ? ? ? ?*
*
LOGON AT 13:52:39 CST SUNDAY 08/18/24
VM Community Edition V1 R1.2
?
Y (19E) R/O
Segment GCCLIB is not loaded because virtual machine memory is in use.
U (19D) R/O
XNET010 Cross System Net - V1.4.0 ? 07/15/22 10.42
XNET002 XNET using configuration file XMASVMCE CONFIG ? *
XNET020 VM370P01 active
XNET016 CTCA 500 initialization in progress...
XNET017 CTCA 500 is Y-side
XNET019 CTCA 500 connected to node VM370DEV (NETID= ?1)
XNET020 VM370DEV active
XNET012 Device 0C8 connected
XNET021 LDEV L000 associated with VM370DEV 0C8
XNET028 GRAF 0C8 associated with VM370DEV L000
XNET015 LDEV L000 disassociated with VM370DEV 0C8
XNET029 GRAF 0C8 disassociated with VM370DEV L000
XNET013 Device 0C8 disconnected
?
I also decided to make use of LOGMSG so I knew what system I was connecting to.
?
?... Mark S.
 

On Sun, Aug 18, 2024 at 07:36 AM, Bob Polmanter wrote:
Even if you autologged it and it is running disconnected, you can log on to it later and issue D TASKS and see if the CTCs are connected.
With the previously mentioned PROFILE EXECs in place, I disconnected both VMs and then was actually able to DIAL and LOGON to the alternate system!
?
I tried to log on to XNET and was not allowed. This is the same for both VM370DEV and VM370P01.
?
L XNETL XNET
ENTER PASSWORD:
?
DMKLOG066E CANNOT CONNECT TO HOST VIRTUAL MACHINE
ENTER PASSWORD:
?
DMKLOG066E CANNOT CONNECT TO HOST VIRTUAL MACHINE
?
?... Mark S.
?
?
 

On Sun, Aug 18, 2024 at 07:36 AM, Bob Polmanter wrote:
You could also start spooling the XNET console log (in its profile exec) so that when it is autologged everything will be recorded; if it fails to work then you can go back and look at that log and see what the messaging says.
I forced and autologged both VMs. I was able to transfer the console file to MAINT and look at it. This one is from VM370DEV:
?
?--- OK ? ? ? ? ? ? ? ? ?ID=0678 ? ? ? ? ? ? ? ? ? LINE=000001 OF 000022 CASE=U
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
XNET010 Cross System Net - V1.4.0 ? 07/15/22 10.42 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET002 XNET using configuration file XMASVMCE CONFIG ? * ? ? ? ? ? ? ? ? ? ? ??
XNET020 VM370DEV active ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
XNET016 CTCA 500 initialization in progress... ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET017 CTCA 500 is X-side ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET019 CTCA 500 connected to node VM370P01 (NETID= ?2) ? ? ? ? ? ? ? ? ? ? ? ??
XNET020 VM370P01 active ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
XNET012 Device 0C8 connected ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET028 GRAF 0C8 associated with VM370P01 L000 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET021 LDEV L000 associated with VM370P01 0C8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET029 GRAF 0C8 disassociated with VM370P01 L000 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
XNET013 Device 0C8 disconnected ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
XNET015 LDEV L000 disassociated with VM370P01 0C8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
14:08:05 ?MSG FROM MAINT ? : ?D NODES ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
#CP DISCONN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
DISCONNECT AT 14:09:09 CST SUNDAY 08/18/24 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET012 Device 0C8 connected ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET028 GRAF 0C8 associated with VM370P01 L000 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
XNET021 LDEV L000 associated with VM370P01 0C8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
CONNECT= 00:23:05 VIRTCPU= 000:00.22 TOTCPU= 000:00.94 ? ? ? ? ? ? ? ? ? ? ? ? ?
LOGOFF AT 14:15:49 CST SUNDAY 08/18/24 BY SYSTEM ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
* * * ?END OF FILE ?* * * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
?
With the previously shown PROFILE EXEC, and the VM autologged. I could successfully DIAL XNET and log on to the other host!
?
I probably have too many SETs such as SMSG in the EXEC, but I will leave it sit for a bit, and also shutdown and IPL to see how that goes.
?
?... Mark S.
 

Mark,
?
So, are you saying it is working while disconnected after all?? It sure looks like it from the console messages.
?
Regards,
Bob
 

Mark,
?
I tried to log on to XNET and was not allowed. This is the same for both VM370DEV and VM370P01.
?
L XNETL XNET
ENTER PASSWORD:
?
DMKLOG066E CANNOT CONNECT TO HOST VIRTUAL MACHINE
ENTER PASSWORD:
?
DMKLOG066E CANNOT CONNECT TO HOST VIRTUAL MACHINE
?
?
You can't logon to the virtual machine that is hosting the logical devices.? Thus, you cannot logon to XNET from an XNET created logical device session.? This is not an XNET restriction, this is the rules of LDF (the logical device facility).
?
Regards,
Bob
?
 

On Sun, Aug 18, 2024 at 04:06 PM, Bob Polmanter wrote:
You can't logon to the virtual machine that is hosting the logical devices.? Thus, you cannot logon to XNET from an XNET created logical device session.? This is not an XNET restriction, this is the rules of LDF (the logical device facility).
I can't read or type, it seems. XNETL is not XNET.? I went back and was able to log on from a CUU device.
?
?... Mark S.
 

On Sun, Aug 18, 2024 at 04:04 PM, Bob Polmanter wrote:
So, are you saying it is working while disconnected after all?? It sure looks like it from the console messages.
With the PROFILE EXEC i altered (see prior email), I can autolog XNET and it behaves properly.
?
?... Mark S.
 

On Sat, Aug 17, 2024 at 07:11 PM, Gregg Levine wrote:
I see that Mark. There's a good reason waiting for it. What say that
when all of this is settled, and you've got the two systems seeing
each other, can you present all of this as a good example of
documentation?
I've started the documentation. It will be uploaded to the Files section. It is not complete, but I'd like to know if I'm doing too much/not enough/just right.
?
?... Mark S.
 

On Sun, Sep 8, 2024 at 01:06 PM, Mark A. Stevens wrote:
I've started the documentation. It will be uploaded to the Files section. It is not complete, but I'd like to know if I'm doing too much/not enough/just right.
/g/h390-vm/files/How_to_Configure_XNET_for%20_Two_Systems.txt
?
?... Mark S.
 

On Thu, Aug 15, 2024 at 07:50 AM, Bob Polmanter wrote:
For example, you have port 30880 on the CTCE at 500 and at 600.? They need to be different ports, on both sides of the CTCE definition.? So, I'd suggest using 30880 for address 500 and something like 30890 for address 600.? This isnt XNET's rules; rather, this is required by CTCE to function properly.
Bob,
?
A follow up question concerning use of channels/CTCE for XNET vs. other applications, say RSCS.
?
I remember your documentation saying, I should only use XNET on a channel once, so 500, but not 501, ... Is it "safe" to use 501 for RSCS, or other products, or does XNET keep the whole channel too busy, when it is in use?
?
Thanks!
?
?... Mark S.
 

¿ªÔÆÌåÓý

The channel does not actually exist in Hercules.? It started out as an ESA/390 emulator so initially the channel subsystem was implemented for subchannel I/O.? Later, support for S/370 was added and the channel I/O commands were added as a wrapper to the already existing channel subsystem.? The channel subsystem does not report the channel busy.

There was an effort to emulate channels, but that did not make it into Hercules.

So from Hercules stand point, it does not matter.

From the perspective of the guest operating system running in Hercules, VM, it might care.

Harold Grovesteen

On 9/12/24 15:10, Mark A. Stevens via groups.io wrote:

On Thu, Aug 15, 2024 at 07:50 AM, Bob Polmanter wrote:
For example, you have port 30880 on the CTCE at 500 and at 600.? They need to be different ports, on both sides of the CTCE definition.? So, I'd suggest using 30880 for address 500 and something like 30890 for address 600.? This isnt XNET's rules; rather, this is required by CTCE to function properly.
Bob,
?
A follow up question concerning use of channels/CTCE for XNET vs. other applications, say RSCS.
?
I remember your documentation saying, I should only use XNET on a channel once, so 500, but not 501, ... Is it "safe" to use 501 for RSCS, or other products, or does XNET keep the whole channel too busy, when it is in use?
?
Thanks!
?
?... Mark S.
 

Mark,
?
It is not just XNET, it is the nature of the beast.? When a CTC device has an i/o in progress, the entire channel is busy; if there are other devices on the channel, whether they are other CTCs or any other device, they will be unable to do i/o or receive interruptions during the CTC i/o.
?
So if you are using 500 for XNET, then I would recommend you put RSCS's CTC on 600 or some other channel.? But if you are aware of the possible reduction in throughput on a CTC channel, then yes you could also put RSCS's CTC on channel 5.
?
The other thing is that our systems are small and generally just single user, so the number of i/os issued by XNET across the channel isn't going to be much of an impact.? XNET doesnt do any "heartbeat" i/o, so if you are not doing anything at your 3270 terminal dialed to XNET, then there is no idle-time CTC i/o.
?
Regards,
Bob
?
 

¿ªÔÆÌåÓý

See below,

Harold Grovesteen

On 9/12/24 17:45, Bob Polmanter wrote:
Mark,
?
It is not just XNET, it is the nature of the beast.?
When a CTC device has an i/o in progress, the entire channel is busy; if there are other devices on the channel, whether they are other CTCs or any other device, they will be unable to do i/o or receive interruptions during the CTC i/o.

That is interesting.? I have never worked with a CTC at this level.? Was unaware that is how the CTC works.? I would of course expect the software to work that way.? As I said, though, I doubt Hercules will ever have the channel appear busy.? Putting CTC's on different channels might keep the software from getting confused in some way.

Thanks for the insight!

?
So if you are using 500 for XNET, then I would recommend you put RSCS's CTC on 600 or some other channel.? But if you are aware of the possible reduction in throughput on a CTC channel, then yes you could also put RSCS's CTC on channel 5.
?
The other thing is that our systems are small and generally just single user, so the number of i/os issued by XNET across the channel isn't going to be much of an impact.? XNET doesnt do any "heartbeat" i/o, so if you are not doing anything at your 3270 terminal dialed to XNET, then there is no idle-time CTC i/o.
?
Regards,
Bob
?
 

On Thu, Sep 12, 2024 at 05:45 PM, Bob Polmanter wrote:
The other thing is that our systems are small and generally just single user, so the number of i/os issued by XNET across the channel isn't going to be much of an impact.? XNET doesnt do any "heartbeat" i/o, so if you are not doing anything at your 3270 terminal dialed to XNET, then there is no idle-time CTC i/o.
Does the lack of a "heartbeat" help or hinder? I don't know. I have kept my two KVMs up and running for 8 days, and sessions dialed to/through each XNET, and it doesn't drop.
?
What I did discover, is if one VM system goes down, planned or otherwise, you can not reestablish the XNET connections without re-IPLing the XNET on the surviving machine.
?
I tried to use the V cuu ACT/INACT to reestablish the connections, but that didn't work. Is it supposed to?
?
I would ask, for consideration the following:
?
0. Don't clear the stack, but read it, so when you IPL XNET you could stack D NODES and D TASKS to show up in your spooled console?
?
1. SMSG capability, so I could SMSG D NODES and get the response back.
2. A restart capability, via SMSG? to reconnect systems when a failure happens.
?
Thanks for providing this utility!
?
?... Mark S.
 

On Sat, Aug 17, 2024 at 07:11 PM, Gregg Levine wrote:
I see that Mark. There's a good reason waiting for it. What say that
when all of this is settled, and you've got the two systems seeing
each other, can you present all of this as a good example of
documentation?
I've written down my experiences as a How-To. I will post that in the Files section.
?
?... Mark S.
 

Mark,
?
Does the lack of a "heartbeat" help or hinder? I don't know. I have kept my two KVMs up and running for 8 days, and sessions dialed to/through each XNET, and it doesn't drop.
?
What I did discover, is if one VM system goes down, planned or otherwise, you can not reestablish the XNET connections without re-IPLing the XNET on the surviving machine.
?
I tried to use the V cuu ACT/INACT to reestablish the connections, but that didn't work. Is it supposed to?
Having a heartbeat really wouldn't help matters much for detecting that a system on the other side has gone away.? The main problem is really the nature of CTCE devices on Hercules.? When one side goes down and Hercules is stopped and restarted, the state of the CTCE device is lost.? XNET on the side that remained up doesn't understand the state of the CTC as it sees it; it thinks it was left the way it was last used.? Understand that if this were a real CTC device on real S/370 hardware back in the day, this would be basically channel cables between two separate CPUs and a small bit of controller hardware logic.? If one CPU crashes, the state of the CTC remains unchanged.? What Hercules/CTCE does when it goes down is essentially the same as disconnecting the channel cables from the real CTC and powering down the CTC control logic, and restarting/reconnecting later.? The original state of the device was lost.? That does not typically happen with real CTCs; they were physically connected 24/7.
?
If you know that you are going to shut down one side deliberately, you should issue a V cuu,INACT on the side that will be remaining active.? Then shut down the intended system.? Once the shut down system is restarted and XNET is started, you should be able to issue V cuu,ACT on the side that stayed up.? None of this helps for an unplanned shutdown however.
?
I suppose a new command is needed to force reinitialization of the CTC and the connection for these situations, because V? INACT/ACT won't work in such cases.
?
Regarding your other suggestions:
?
0. Don't clear the stack, but read it, so when you IPL XNET you could stack D NODES and D TASKS to show up in your spooled console?
XNET doesn't run under CMS; it takes over the virtual machine and runs natively immediately after launching.? How about instead if the XNET CONFIG file allowed commands to be placed there that would be executed upon start up?? Note that there wouldn't be much shown or revealed by these commands if the CTCs are not yet connected and no one has yet DIALed to XNET.
?
?
1. SMSG capability, so I could SMSG D NODES and get the response back.
2. A restart capability, via SMSG? to reconnect systems when a failure happens.
Interesting ideas; I hadn't thought about the SMSG feature.? I'll look into these solutions for winter projects.
?
Regards,
Bob


?
?
 

On Sun, Sep 22, 2024 at 05:39 PM, Bob Polmanter wrote:
0. Don't clear the stack, but read it, so when you IPL XNET you could stack D NODES and D TASKS to show up in your spooled console?
XNET doesn't run under CMS; it takes over the virtual machine and runs natively immediately after launching.? How about instead if the XNET CONFIG file allowed commands to be placed there that would be executed upon start up?? Note that there wouldn't be much shown or revealed by these commands if the CTCs are not yet connected and no one has yet DIALed to XNET.
?
?
1. SMSG capability, so I could SMSG D NODES and get the response back.
2. A restart capability, via SMSG? to reconnect systems when a failure happens.
Interesting ideas; I hadn't thought about the SMSG feature.? I'll look into these solutions for winter projects.
?
If you tackle the SMSG, then we wouldn't need commands in the CONFIG, as AUTOLOG1 or OPERATOR or ... could just SMSG the command to get the results, especially if there was a SLEEP to allow time for connections to stabilize.
?
?... Mark S.

21 - 38 of 38