REXEC between zVM and zVSE

[darmstadt]

Here's a good one...I recently built and installed a VTS (virtual tape server) and a customer (they make convertible cars and camper vans) which is based on SuSE Linux. This is connected to the mainframe running zVM and zVSE via ESCON channels. In order to do tape mounts you need to send commands to the emulation software running on Linux. I tried a tool called BSIMOUNT which works but we can't create the proper directory structure under Linux with that.

Using REXEC from zVM and zVSE is fine, I created a REXX program on these systems which performs the REXEC command and that then runs a couple of REXX programs under Linux to do various actions. From zVM we have no problems but from zVSE there is a slight problem. It makes the connection but then waits 30 seconds before returning any data to zVSE. What is interesting is that doing it to AIX from zVSE the data is returned automatically. Also what is interesting is that the REXECD on Linux normally uses port 512 but this returning data from port 113 which is INETD (or XINETD in this case.) I was wondering if INETD is doing some kind of authentication as the TCPIP stack in zVSE is slightly different to other stacks.

Any ideas as I have to somehow get rid of this 30 second delay?

[scotspine]

ah, now this *is* interesting. the solution is however clear. what is happening is that, as you rightly suspect, under zvse, the tcpip stack is leaking into the system heap and so your rexx exes are corrupting the registers. you can write a rexx against the bsimount api, which will regain control of the port inputs and so stop the loss of data from the output. this requires an install of cantmount [note, this will only run after a sucessful stack flush and reboot, and will probably also mean that the tcpip stack will need to be reset. you can do this by running xvertmystck with the correct arguments, which you can obtain from reading the register contents immediately before the stack flush]. after this, check to see that inetd is running with full admin permissions against the escon channels, which will of course need to be secured against abstraction by zvm. if this is seen to be happening, rebuild tcpip stack, clear the heap and check that no running processes are locked [if any are, you will need to restart this process i'm afraid]. then, and only then, check that the reset stack has not been corrupted by manually inspecting its contents. some editing might be required here. that should be enough to get you started.
alternatively, wipe suse, install windows, hit the start button and select 'do my tape mounts'.
hth

[darmstadt]

Just because I talk about real computers

I'll take your second option, install Windows as I'll get more money for callout then

But which version 3.11 or Windows for Workgroups and should I install Microsoft's own TCPIP stack?

[DimPrawn]

It's pretty clear that 30 seconds is approx the time it takes a single pentode vacuum tube to warm up.

HTH

PS. I would suggest you try .NET 3.5 beta 2 running on Windows Server 2008 beta 3 instead. Works for Milan.