¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. H390-MVS
  2. Messages
Expanded Topics Messages Polls
Date
Re: ChapGPT

Martin Taylor
 

I seem to remember that STOP RUN had to used in a DOS-VSE program where as GOBACK could be used in MVS code.?
Perhaps other can verify my failing memory ;-)

Regards
Martin.
Re: Trying to migrate TUN networking connection to TAP

 

Hello Harold,

thanks for chiming in!


Am 05.01.2023 um 21:05 schrieb Harold Grovesteen <h.grovsteen@...>:

You are on the right track. Can you look at any stats that show dropped packets? This might tell you how far the response got before it could not make it to the host.
Not sure if something not there can be counted. I think the only option I have is to check at each possible "tap" if things look complete, or not.

Also, it is a little unclear which component you are wanting to respond with the ARP? OMVS or the host based bridge.
Well, only things with an IP address are supposed to "speak" ARP. So it's the TCP/IP stack of OS/390 I suppose to respond. The host based bridge should be transparent, because it's not involved with L3 processing.

That this setup works in general is proven by the same bridge-group including a separate LCS device using SNA. And I do have a working connection to my AS/400 on Ethernet.

Can you get the bridge to do a packet trace?
I have not yet found out. But I can tcpdump on either side of the bridge and the packets I see are the same.

All in all, I've come to the conclusion that I probably have at least one configuration error in the TCPIP profile. Therefore I should read though the TCP/IP manual(s) being available. This is on my (seemingly endless) ToDo-List. :-)

I also should have a closer look about the encapsulation being used: Everybody speaks Ethernet II for IP. But as Grant Taylor pointed out, 802.2 LLC might be involved on the mainframe side.

It does not look like the host is getting any packets from the bridge. Either the bridge is not sending them, or TCPIP or LCS is dropping them.

I, like you, find the two different MAC addresses concerning.
Are they? Ian Shorter once pointed out that a TAP interface is just a L2 "pipe". The host side is an ordinary network interface, and the other (within Hercules) is API calls. You configure the "base" MAC with the ip command and the other side automatically is configured with that MAC + 1. I didn't take my time to find this in the official tuntap documentation. But it makes sense. One can *probably* change the guest side's MAC with an API call from within the guest.

I am back to a packet trace, if you can manage one from something. I would try to get the host and bridge to use the same MAC addresses preferably through configuration (somewhere).
Every switch (aka multiport-bridge) has MAC addresses on each port, because if (for any reason) the bridge must generate a packet by itself, it has a valid "return" address.

So, I'd rather not. If the bridge has a local MAC equal to the "output of the funnel" within Hercules, I bet packets won't be forwarded anymore: The L2 code in the kernel assumes they're addressed to itself. So they clearly must be distinct.

But MAC addresses might not be the problem.
I also thought about MAC addresses once. On a second look, they largely don't matter, because they're not involved in the packet forwarding process at all. Only the endpoints' MAC addresses matter. It's the learning and MAC table which matters. I just looked up the proper command for the Linux bridge: brctl showmacs [bridge]

Purging of inactive ARP cache entries is normal for ARP caches. It is why in some cases a static ARP cache entry is helpful.
I'm aware. :-)

But since I didn't find out how to set a static ARP entry on OS/390, there was no further diagnosing.

Thank you for your input! As said, I need to review the documentation at this point. I'm sure the culprit is either there, or an encapsulation mismatch.

:wq! PoC
Re: 3390/3990-06 I/O Error reported

 

It's not unusual for the system to issue channel commands in the expectation they will fail. It does this to see if particular capabilities are present. You can ignore the error if it does not cause problems for the running system.


On Fri, Jan 6, 2023 at 7:32 AM Jo?o Reginato <jb.reginato@...> wrote:

Hi

?

I¡¯m using Hyperion 4.5 as below

HHC01413I Hercules version 4.5.0.10830-SDL-g58578601????????????????????????????????????? ??????????????????????????????

HHC01414I (C) Copyright 1999-2022 by Roger Bowler, Jan Jaeger, and others??????????????????????????????????????????????

HHC01417I ** The SoftDevLabs version of Hercules **?????????????????????????????????????????????????????? ??????????????

HHC01415I Build date: Nov 26 2022 at 16:25:41??????????????????????????????????????????????????????????????????????????

HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)??????????????????????????????????????????????????

HHC01417I Build type: Windows MSVC AMD64 host architecture build???????????????????????????????????????????????????????

?

All my dasd devices are defined as 3390 with CU=3990-6.

Everything works fine but this message below is always present for all my devices after IPL z/os.

?

HHC01315I 0:2107 CHAN: ccw F760000C 7E84DF58=>18000000 00004100 00000000????????? ............?????????????????????????

HHC01312I 0:2107 CHAN: stat 0E00, count 0000???????????????????????????????????????????????????????????????????????????

HHC01313I 0:2107 CHAN: sense 80000000 00FFFF01 00000000 00000000 00000000 00000000 00000080 0002BF0B???????????????????

HHC01314I 0:2107 CHAN: sense CMDREJ???????????

?

Even using old Hyperion versions the same always occurred.

What is wrong and what can be done to avoid this situation?

?

TIA

Jo?o

?

?


N?o cont¨¦m v¨ªrus.

--
att.
Jo?o



--
Jay Maynard
3390/3990-06 I/O Error reported

 

¿ªÔÆÌåÓý

Hi

?

I¡¯m using Hyperion 4.5 as below

HHC01413I Hercules version 4.5.0.10830-SDL-g58578601????????????????????????????????????? ??????????????????????????????

HHC01414I (C) Copyright 1999-2022 by Roger Bowler, Jan Jaeger, and others??????????????????????????????????????????????

HHC01417I ** The SoftDevLabs version of Hercules **?????????????????????????????????????????????????????? ??????????????

HHC01415I Build date: Nov 26 2022 at 16:25:41??????????????????????????????????????????????????????????????????????????

HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)??????????????????????????????????????????????????

HHC01417I Build type: Windows MSVC AMD64 host architecture build???????????????????????????????????????????????????????

?

All my dasd devices are defined as 3390 with CU=3990-6.

Everything works fine but this message below is always present for all my devices after IPL z/os.

?

HHC01315I 0:2107 CHAN: ccw F760000C 7E84DF58=>18000000 00004100 00000000????????? ............?????????????????????????

HHC01312I 0:2107 CHAN: stat 0E00, count 0000???????????????????????????????????????????????????????????????????????????

HHC01313I 0:2107 CHAN: sense 80000000 00FFFF01 00000000 00000000 00000000 00000000 00000080 0002BF0B???????????????????

HHC01314I 0:2107 CHAN: sense CMDREJ???????????

?

Even using old Hyperion versions the same always occurred.

What is wrong and what can be done to avoid this situation?

?

TIA

Jo?o

?

?


N?o cont¨¦m v¨ªrus.

--
att.
Jo?o
Re: ChapGPT

 

Goback exits the program, not any loop within the program. Using stop
run within a subroutine would exit to the operating system and not to
the calling program.

On Fri, Jan 6, 2023 at 2:25 AM Don.isenstadt <don.isenstadt@...> wrote:

Bob,

I used write a complete cobol program¡­ also you can use regenerate and it might add the working storage. I liked the explanation at the end..

Did it write the program or did it ¡°find¡± it? Could not get it to use goback.

So I asked GPT why it does not use goback..


Using "STOP RUN" terminates the entire program and closes all files. "GOBACK" simply exits the current PERFORM or READ loop and returns control to the beginning of the loop. In this case, using "GOBACK" instead of "STOP RUN" would cause the program to continuously loop through the file, reading and printing each record indefinitely. "STOP RUN" is used to end the program after all records have been read and printed.

That is perhaps why it gets away without the working storage flag?


IDENTIFICATION DIVISION.

PROGRAM-ID. READ-AND-PRINT.


ENVIRONMENT DIVISION.

INPUT-OUTPUT SECTION.

FILE-CONTROL.

SELECT INPUT-FILE ASSIGN TO "input.txt"

ORGANIZATION IS SEQUENTIAL.


DATA DIVISION.

FILE SECTION.

FD INPUT-FILE.

01 INPUT-RECORD.

02 INPUT-FIELD PIC X(30).


WORKING-STORAGE SECTION.

01 EOF-FLAG PIC X VALUE 'N'.


PROCEDURE DIVISION.

OPEN INPUT INPUT-FILE

PERFORM UNTIL EOF-FLAG = 'Y'

READ INPUT-FILE

AT END MOVE 'Y' TO EOF-FLAG

END-READ

DISPLAY INPUT-FIELD

END-PERFORM

CLOSE INPUT-FILE

STOP RUN.


Explanation:

The IDENTIFICATION DIVISION and PROGRAM-ID paragraphs are used to identify the program.

The ENVIRONMENT DIVISION contains the INPUT-OUTPUT SECTION, where we specify the input file and its organization (in this case, sequential).

The DATA DIVISION contains the FILE SECTION, where we define the input file and its record layout (in this case, a single field of 30 characters).

The WORKING-STORAGE SECTION is used to define any variables or flags that we need to use in our program. In this case, we define a flag EOF-FLAG to keep track of whether we have reached the end of the file.

In the PROCEDURE DIVISION, we open the input file, then perform a loop until we reach the end of the file. Inside the loop, we read a record from the file and display it. If the end of the file is reached, we set the EOF-FLAG to 'Y' to signal that the loop should terminate. Finally, we close the input file and stop the program.







Air 2

On Jan 6, 2023, at 1:43 AM, Bob Flanders <bob.flanders@...> wrote:

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Re: ChapGPT

 

¿ªÔÆÌåÓý

Bob,

I used write a complete cobol program¡­ also you can use regenerate and it might add the working storage. I liked the explanation at the end..

Did it write the program or did it ¡°find¡± it? Could not get it to use goback.

So I asked GPT why it does not use goback..


Using "STOP RUN" terminates the entire program and closes all files. "GOBACK" simply exits the current PERFORM or READ loop and returns control to the beginning of the loop. In this case, using "GOBACK" instead of "STOP RUN" would cause the program to continuously loop through the file, reading and printing each record indefinitely. "STOP RUN" is used to end the program after all records have been read and printed.

That is perhaps why it gets away without the working storage flag?


IDENTIFICATION DIVISION.

PROGRAM-ID. READ-AND-PRINT.


ENVIRONMENT DIVISION.

INPUT-OUTPUT SECTION.

FILE-CONTROL.

???SELECT INPUT-FILE ASSIGN TO "input.txt"

???ORGANIZATION IS SEQUENTIAL.


DATA DIVISION.

FILE SECTION.

???FD INPUT-FILE.

???01 INPUT-RECORD.

?? ? ??02 INPUT-FIELD PIC X(30).


WORKING-STORAGE SECTION.

???01 EOF-FLAG PIC X VALUE 'N'.


PROCEDURE DIVISION.

???OPEN INPUT INPUT-FILE

???PERFORM UNTIL EOF-FLAG = 'Y'

? ? ??READ INPUT-FILE

?? ? ? ??AT END MOVE 'Y' TO EOF-FLAG

? ? ??END-READ

? ? ??DISPLAY INPUT-FIELD

???END-PERFORM

???CLOSE INPUT-FILE

???STOP RUN.


Explanation:

The IDENTIFICATION DIVISION and PROGRAM-ID paragraphs are used to identify the program.

The ENVIRONMENT DIVISION contains the INPUT-OUTPUT SECTION, where we specify the input file and its organization (in this case, sequential).

The DATA DIVISION contains the FILE SECTION, where we define the input file and its record layout (in this case, a single field of 30 characters).

The WORKING-STORAGE SECTION is used to define any variables or flags that we need to use in our program. In this case, we define a flag?EOF-FLAG?to keep track of whether we have reached the end of the file.

In the PROCEDURE DIVISION, we open the input file, then perform a loop until we reach the end of the file. Inside the loop, we read a record from the file and display it. If the end of the file is reached, we set the?EOF-FLAG?to 'Y' to signal that the loop should terminate. Finally, we close the input file and stop the program.







Air 2

On Jan 6, 2023, at 1:43 AM, Bob Flanders <bob.flanders@...> wrote:
Re: ChapGPT

 

Close. Needs working storage with INREC-EOF value false and at end of
file set it to true. Better to use Goback instead of stop run.

On Fri, Jan 6, 2023 at 12:43 AM Bob Flanders <bob.flanders@...> wrote:

Asked ChapGPT to write a cobol program to read and print a sequential file. Here's what it wrote...

IDENTIFICATION DIVISION.
PROGRAM-ID. READ-SEQ-FILE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INFILE ASSIGN TO 'INPUT.TXT'
ORGANIZATION IS SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD INFILE.
01 INREC.
05 INBUF PIC X(80).
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
MAIN-PROCEDURE.
OPEN INPUT INFILE
PERFORM UNTIL INREC-EOF
READ INFILE INTO INREC
DISPLAY INBUF
END-PERFORM
CLOSE INFILE
STOP RUN.
END PROGRAM READ-SEQ-FILE.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
ChapGPT

 

Asked ChapGPT to write a cobol program to read and print a sequential file. Here's what it wrote...

? ?IDENTIFICATION DIVISION.
? ?PROGRAM-ID. READ-SEQ-FILE.
? ?ENVIRONMENT DIVISION.
? ?INPUT-OUTPUT SECTION.
? ?FILE-CONTROL.
? ? ? ?SELECT INFILE ASSIGN TO 'INPUT.TXT'
? ? ? ? ? ?ORGANIZATION IS SEQUENTIAL.
? ?DATA DIVISION.
? ?FILE SECTION.
? ?FD INFILE.
? ?01 INREC.
? ? ? ?05 INBUF ? ? ?PIC X(80).
? ?WORKING-STORAGE SECTION.
? ?PROCEDURE DIVISION.
? ?MAIN-PROCEDURE.
? ? ? ?OPEN INPUT INFILE
? ? ? ?PERFORM UNTIL INREC-EOF
? ? ? ? ? ?READ INFILE INTO INREC
? ? ? ? ? ?DISPLAY INBUF
? ? ? ?END-PERFORM
? ? ? ?CLOSE INFILE
? ? ? ?STOP RUN.
? ?END PROGRAM READ-SEQ-FILE.
Re: Trying to migrate TUN networking connection to TAP

 

¿ªÔÆÌåÓý

Fish said:

"A packet trace would probably help. I use Wireshark myself on Windows. I have no idea what you would use on Linux."

Wireshark of course...? ?Unix + Wireshark where the magic started!

Regards,
Gary


Sent from whatever device I am using.


-------- Original message --------
From: Fish Fish <david.b.trout@...>
Date: 1/5/23 4:37 PM (GMT-05:00)
Subject: Re: [H390-MVS] Trying to migrate TUN networking connection to TAP

Harold Grovesteen wrote:

> Fish, you are the guru of the LCS interface.

I am?! When did this happen? Seriously! I know a little bit about LCS, sure, but I would hardly classify myself as a "guru"! (Especially not for Linux!!)


> Hope you see this post.
> You may have some insight for troubleshooting this.
>
> You are on the right track.

I am?! How can that be?! I never responded to Patrik's post!

And the reason I didn't respond was because whatever his problem is completely out of my league. I know virtually NOTHING about Linux networking. (His use of "IUTSAMEH" in his guest's TCPIP profile is also something I'm unfamiliar with.)


> Can you look at any stats that show dropped packets?? This might
> tell you how far the response got before it could not make it to
> the host.

You must be talking to Patrik and not me! Yes?


> Also, it is a little unclear which component you are wanting to
> respond with the ARP?? OMVS or the host based bridge.
>
> Can you get the bridge to do a packet trace?? Or the TCP/IP trace
> at the Layer-2 level?? This might be informative about who is
> responding (or not).

A packet trace would probably help. I use Wireshark myself on Windows. I have no idea what you would use on Linux.

Sorry I can't offer more, but as I said, Linux networking issues are *completely* out of my league!

Sorry!? :(

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: fish@...
Re: Trying to migrate TUN networking connection to TAP

 

Harold Grovesteen wrote:

Fish, you are the guru of the LCS interface.
I am?! When did this happen? Seriously! I know a little bit about LCS, sure, but I would hardly classify myself as a "guru"! (Especially not for Linux!!)


Hope you see this post.
You may have some insight for troubleshooting this.

You are on the right track.
I am?! How can that be?! I never responded to Patrik's post!

And the reason I didn't respond was because whatever his problem is completely out of my league. I know virtually NOTHING about Linux networking. (His use of "IUTSAMEH" in his guest's TCPIP profile is also something I'm unfamiliar with.)


Can you look at any stats that show dropped packets? This might
tell you how far the response got before it could not make it to
the host.
You must be talking to Patrik and not me! Yes?


Also, it is a little unclear which component you are wanting to
respond with the ARP? OMVS or the host based bridge.

Can you get the bridge to do a packet trace? Or the TCP/IP trace
at the Layer-2 level? This might be informative about who is
responding (or not).
A packet trace would probably help. I use Wireshark myself on Windows. I have no idea what you would use on Linux.

Sorry I can't offer more, but as I said, Linux networking issues are *completely* out of my league!

Sorry! :(

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

mail: fish@...
Re: Trying to migrate TUN networking connection to TAP

 

Fish, you are the guru of the LCS interface. Hope you see this post.
You may have some insight for troubleshooting this.

You are on the right track. Can you look at any stats that show
dropped packets? This might tell you how far the response got before
it could not make it to the host.

Also, it is a little unclear which component you are wanting to respond
with the ARP? OMVS or the host based bridge.

Can you get the bridge to do a packet trace? Or the TCP/IP trace at
the Layer-2 level? This might be informative about who is responding
(or not).

Packet counts might be useful in determining who is sending and who is
receiving if anyone.

Scroll down to the show mac address-table output...

Harold Grovesteen

On Sun, 2022-12-25 at 18:09 +0100, Patrik Schindler wrote:
Hello,

merry xmas to you all. I hope you can enjoy some stressless days with
your loved ones.

I'm using the days off work to do some cleanup work here and there.
One of that is that I want to migrate my routed (tun) network
connection of an OS/390 instance running in Hercules 4.4.1.0-SDL, in
turn running on a Linux Debian 11 machine, to tap. I want to spare
multiple intermediate routing networks but have the machine appear at
the local LAN with its designated MAC address.

The very same instance runs SNA 802.2 DLC on a bridged interface
without issue.

Hercules runs as root, but I prefer preconfigured interfaces for
Hercules to use.

I don't use the fancy new Network Manager, but stock
/etc/network/interfaces configuration:
- Eth1 is the physical port connected to the LAN switch (works),
- Tap0 is the bridged interface for SNA (works),
- Tap1 is the bridged interface for IP (doesn't work).


---8<--- /etc/network/interfaces ---8<---

auto eth1 tap0 tap1 br0

# Hercules OS/390: Port LAN Port
iface eth1 inet manual
????????up /sbin/ip link set dev $IFACE up

# Hercules OS/390: TAPs for Bridging.
iface tap0 inet manual
????????pre-up /sbin/ip tuntap add mode tap
????????up /sbin/ip link set dev $IFACE address 02:00:FE:DF:00:42
????????up /sbin/ip link set dev $IFACE up
????????post-down /sbin/ip link del dev $IFACE

iface tap1 inet manual
????????pre-up /sbin/ip tuntap add mode tap
????????up /sbin/ip link set dev $IFACE address 02:00:FE:DF:01:42
????????up /sbin/ip link set dev $IFACE up
????????post-down /sbin/ip link del dev $IFACE

# Bridge everything together and assign an IP address to the bridge.
iface br0 inet static
????????address 192.168.59.12
????????netmask 255.255.255.128
????????gateway 192.168.59.1
????????bridge_ports tap0 tap1 eth1

---8<---


Hercules configuration excerpt:

---8<---

0E40??? LCS? -e SNA tap0
0E42.2? LCS? tap1

---8<---


Relevant configuration excerpts from TCPIP.PROFILE.TCPIP:

---8<---

; Required for EE
DEVICE IUTSAMEH MPCPTP
LINK?? LSAMEH?? MPCPTP IUTSAMEH

DEVICE LCS1?? LCS?????????? E42
LINK?? TAP1? ETHERNET? 1? LCS1


HOME
?? 192.168.59.89? TAP1


PRIMARYINTERFACE TAP1


GATEWAY
;
; Direct Routes - Routes that are directly connected to my
interfaces.
;
; Network??? First Hop?? Link??? Pkt????? Subnet Mask??? Subnet Value
; Class????? Hop???????? Name??? Size???? (excl. Class!) (Remainder)

;The next commented line gives us an error:
;17.10.00 STC00043? EZZ0312I THE SUBNET MASK ON LINE 230 CONTAINS AN
INCORRECT VALUE 0.0
;192.168?????? =???????? TAP1??? 1492???? 0.0.255.128??? 0.0.59.0
?192.168.59??? =???????? TAP1??? 1492???? 0


DEFAULTNET 192.168.59.1? TAP1??? 1492 0


START LCS1
START IUTSAMEH

---8<---

Link starts without error:

17.55.46 STC00052? EZZ4314I INITIALIZATION COMPLETE FOR DEVICE LCS1,
LINK TAP1


I can see the MAC addresses of all three bridged devices on the
switch port:

sw-keller-1g#show mac address-table | incl Gi0/2$
?? 1??? 0200.fedf.0043??? DYNAMIC???? Gi0/2
?? 1??? 0200.fedf.0143??? DYNAMIC???? Gi0/2
?? 1??? 7efc.3ef5.66ca??? DYNAMIC???? Gi0/2

Note that the TAP code automatically increments the MAC address given
while configuring the interface by one. So, the host-local side of
the TAP has 02:00:fe:df:01:42, but the guest-local side uses
02:00:fe:df:01:43!
It does not look like the host is getting any packets from the bridge.
Either the bridge is not sending them, or TCPIP or LCS is dropping
them.

I, like you, find the two different MAC addresses concerning.

I am back to a packet trace, if you can manage one from something. I
would try to get the host and bridge to use the same MAC addresses
preferably through configuration (somewhere). But MAC addresses might
not be the problem.


But I can't ping.


When "S TCPIP" is run from the master console, the TCP/IP code seems
to check for IP address collisions:

18:01:13.178327 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: Request who-has 192.168.59.89 tell
192.168.59.89, length 46

Then it does a lookup because I've configured a DNS server
(192.168.59.10):

18:01:13.784330 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: Request who-has 192.168.59.10 tell
192.168.59.89, length 46
18:01:13.784723 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP
(0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8,
length 46
18:01:14.811173 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: Request who-has 192.168.59.10 tell
192.168.59.89, length 46
18:01:14.811627 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP
(0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8,
length 46
This clearly says the host IP stack is sending an ARP response. As you
say the guest never sees it.

Back to packet counts. Hopefully these will reveal where the hole
exists.

This happens 11 times. Apparently, the ARP answer doesn't make it
back to OS/390, because it tries multiple times?


Looking at 192.168.59.10's local ARP table, I see that the MAC
address from tap1 is visible after S TCPIP but is purged after a
while:
Purging of inactive ARP cache entries is normal for ARP caches. It is
why in some cases a static ARP cache entry is helpful.

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at 02:00:fe:df:01:43 [ether] on ens160

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at <incomplete> on ens160

Now setting a static ARP entry on 192.168.59.10¡­? but I still can't
ping.


Looking at the local ARP cache of OS/390 via OMVS netstat -R ALL
command shows that it only knows about its own MAC address and
nothing else:

MVS TCP/IP onetstat CS V2R10?????? TCPIP Name: TCPIP
Querying ARP cache for address 192.168.59.89
Link: TAP1????????????? ETHERNET: 0200FEDF0143


Unfortunately, I can't find out how to set a static ARP entry from
OMVS. There seems to be no related command in ls
/usr/lpp/tcpip/[s]?bin/


Browsing SG24-5227-01 (OS/390 eNetwork Communications Server V2R7
TCP/IP Implementation Guide
Volume 1: Configuration and Routing) there are some commands
mentioned which aren't there in V2R10 ADCD, such as oeifconfig (PDF
Page 506). The document can be obtained here:



Questions:
- How can I set a static arp entry in OS390 V2R10 ADCD?
- Is my GATEWAY configuration correct (sans assuming a /24 network
instead of a /25)?
- Has anybody successfully established TCP/IP-Networking in a bridged
environment as described above?

Thank you!

:wq! PoC
Trying to migrate TUN networking connection to TAP

 

Hello,

merry xmas to you all. I hope you can enjoy some stressless days with your loved ones.

I'm using the days off work to do some cleanup work here and there. One of that is that I want to migrate my routed (tun) network connection of an OS/390 instance running in Hercules 4.4.1.0-SDL, in turn running on a Linux Debian 11 machine, to tap. I want to spare multiple intermediate routing networks but have the machine appear at the local LAN with its designated MAC address.

The very same instance runs SNA 802.2 DLC on a bridged interface without issue.

Hercules runs as root, but I prefer preconfigured interfaces for Hercules to use.

I don't use the fancy new Network Manager, but stock /etc/network/interfaces configuration:
- Eth1 is the physical port connected to the LAN switch (works),
- Tap0 is the bridged interface for SNA (works),
- Tap1 is the bridged interface for IP (doesn't work).


---8<--- /etc/network/interfaces ---8<---

auto eth1 tap0 tap1 br0

# Hercules OS/390: Port LAN Port
iface eth1 inet manual
up /sbin/ip link set dev $IFACE up

# Hercules OS/390: TAPs for Bridging.
iface tap0 inet manual
pre-up /sbin/ip tuntap add mode tap
up /sbin/ip link set dev $IFACE address 02:00:FE:DF:00:42
up /sbin/ip link set dev $IFACE up
post-down /sbin/ip link del dev $IFACE

iface tap1 inet manual
pre-up /sbin/ip tuntap add mode tap
up /sbin/ip link set dev $IFACE address 02:00:FE:DF:01:42
up /sbin/ip link set dev $IFACE up
post-down /sbin/ip link del dev $IFACE

# Bridge everything together and assign an IP address to the bridge.
iface br0 inet static
address 192.168.59.12
netmask 255.255.255.128
gateway 192.168.59.1
bridge_ports tap0 tap1 eth1

---8<---


Hercules configuration excerpt:

---8<---

0E40 LCS -e SNA tap0
0E42.2 LCS tap1

---8<---


Relevant configuration excerpts from TCPIP.PROFILE.TCPIP:

---8<---

; Required for EE
DEVICE IUTSAMEH MPCPTP
LINK LSAMEH MPCPTP IUTSAMEH

DEVICE LCS1 LCS E42
LINK TAP1 ETHERNET 1 LCS1


HOME
192.168.59.89 TAP1


PRIMARYINTERFACE TAP1


GATEWAY
;
; Direct Routes - Routes that are directly connected to my interfaces.
;
; Network First Hop Link Pkt Subnet Mask Subnet Value
; Class Hop Name Size (excl. Class!) (Remainder)

;The next commented line gives us an error:
;17.10.00 STC00043 EZZ0312I THE SUBNET MASK ON LINE 230 CONTAINS AN INCORRECT VALUE 0.0
;192.168 = TAP1 1492 0.0.255.128 0.0.59.0
192.168.59 = TAP1 1492 0


DEFAULTNET 192.168.59.1 TAP1 1492 0


START LCS1
START IUTSAMEH

---8<---

Link starts without error:

17.55.46 STC00052 EZZ4314I INITIALIZATION COMPLETE FOR DEVICE LCS1, LINK TAP1


I can see the MAC addresses of all three bridged devices on the switch port:

sw-keller-1g#show mac address-table | incl Gi0/2$
1 0200.fedf.0043 DYNAMIC Gi0/2
1 0200.fedf.0143 DYNAMIC Gi0/2
1 7efc.3ef5.66ca DYNAMIC Gi0/2

Note that the TAP code automatically increments the MAC address given while configuring the interface by one. So, the host-local side of the TAP has 02:00:fe:df:01:42, but the guest-local side uses 02:00:fe:df:01:43!


But I can't ping.


When "S TCPIP" is run from the master console, the TCP/IP code seems to check for IP address collisions:

18:01:13.178327 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.59.89 tell 192.168.59.89, length 46

Then it does a lookup because I've configured a DNS server (192.168.59.10):

18:01:13.784330 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.59.10 tell 192.168.59.89, length 46
18:01:13.784723 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP (0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8, length 46
18:01:14.811173 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.59.10 tell 192.168.59.89, length 46
18:01:14.811627 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP (0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8, length 46

This happens 11 times. Apparently, the ARP answer doesn't make it back to OS/390, because it tries multiple times?


Looking at 192.168.59.10's local ARP table, I see that the MAC address from tap1 is visible after S TCPIP but is purged after a while:

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at 02:00:fe:df:01:43 [ether] on ens160

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at <incomplete> on ens160

Now setting a static ARP entry on 192.168.59.10¡­ but I still can't ping.


Looking at the local ARP cache of OS/390 via OMVS netstat -R ALL command shows that it only knows about its own MAC address and nothing else:

MVS TCP/IP onetstat CS V2R10 TCPIP Name: TCPIP
Querying ARP cache for address 192.168.59.89
Link: TAP1 ETHERNET: 0200FEDF0143


Unfortunately, I can't find out how to set a static ARP entry from OMVS. There seems to be no related command in ls /usr/lpp/tcpip/[s]?bin/


Browsing SG24-5227-01 (OS/390 eNetwork Communications Server V2R7 TCP/IP Implementation Guide
Volume 1: Configuration and Routing) there are some commands mentioned which aren't there in V2R10 ADCD, such as oeifconfig (PDF Page 506). The document can be obtained here:


Questions:
- How can I set a static arp entry in OS390 V2R10 ADCD?
- Is my GATEWAY configuration correct (sans assuming a /24 network instead of a /25)?
- Has anybody successfully established TCP/IP-Networking in a bridged environment as described above?

Thank you!

:wq! PoC
Re: How to wait indefinitely for a read on CTC device?

 

Hi Joe,

On 11.25.2022 18:33, Joe Monk wrote:
So i've been following this thread with some curiosity ... Looking at the
CTCA for S/370 (the one that would've been used with MVS 3.8J) ...

[image: image.png]
It seems you need to do an SIO on the receiving side (channel Y) to clear
the mandatory attention interrupt generated by the first command from the
sending (channel X) side. Also, have a look at "operation sequences" on pp
7-8... They seem to indicated synchronous operation of the adapter (write
on channel x must be accompanied by read on channel Y)...
Yep... as for the SIO, that's taken care of my MVS itself. I can't
exactly run an SIO instruction directly from a problem state program,
but I'm successfully communicating over the CTCA from my code by running
channel programs with EXCP.

And yes, the operations do need to be "in sync" on both sides or things
go downhill very quickly.

Until I get the interruption-detection stuff working, I'm faking it with
my SENSE+delay loop. The SENSE command is one command you can run on the
CTCA *without* a matching command on the other side of the link, BUT if
the other side of the link sends a CONTROL command, the SENSE command
ends up satisfying it. So you can end up doing either a simple "CONTROL
+ WRITE" with a SENSE on the other side to detect when to read, or
"CONTROL + READ" if you want to SENSE on the other side to determine
when to do your write. The SENSE command is special in that it doesn't
affect the CTCA state unless there's a command pending for it to read.

Yep the old doc from '72 has been critical. The Hercules source code
also references a newer CTC Adapter doc that I was able to find in
BookManager format that has more details about the state of the adapters
on each end of a connection (section 2.13 in SA22-7203-00 or section
2.13 in SA22-7203-00).

Thanks,
Matthew
Re: How to wait indefinitely for a read on CTC device?

 

So i've been following this thread with some curiosity ... Looking at the CTCA for S/370 (the one that would've been used with MVS 3.8J) ...

image.png
It seems you need to do an SIO on the receiving side (channel Y) to clear the mandatory attention interrupt generated by the first command from the sending (channel X) side. Also, have a look at "operation sequences" on pp 7-8...? They seem to indicated synchronous operation of the adapter (write on channel x must be accompanied by read on channel Y)...



Joe

On Fri, Nov 25, 2022 at 4:32 PM Matthew Wilson <mwilson@...> wrote:
Hi Bob,

Thank you for your extensive reply.

On 11.25.2022 12:42, Bob Polmanter wrote:
>I originally posted the MVS-based CTC program on the H390-MVS group
>when it was still under the control of Yahoo Groups.? It was in the
>file section and it had a name like CTCASAMP.TXT or CTCAMVS.TXT or
>something like that.? For some reason, that post did not get migrated
>over here to in this forum or in the other MVS Turnkey
>forum.? Further, I cannot seem to find it here on my TK4 system.? I
>honestly don't know what happened to it.? Actually, I think I did this
>when I was still using TK3 long ago and so it might be there, if I
>still have that stuff.? It has been a long while.

Off-list, Rene Ferland sent me a file he found from one of the old Yahoo
files sections, CTCAMAIN.VS1.txt. I'm not sure if this was your code,
but from what I can see from a brief scroll through it, it does match
much of what you describe from your notes.

>First of all, you don't want to issue a READ command and have it
>pending. Instead, you just want to have the device's DCB opened and
>everything initialized and ready to go, then just WAIT.? The ECB isn't
>tied to the device or the DCB; this is just one of your own ECBs. ?
>When the other side writes to the CTC, an attention interruption will
>be raised on the opposite side.? This attention will drive an interrupt
>handler and then it can post the WAIT.

Yes, I think waiting for the attention interruption is the correct
approach. Alas, I couldn't find a way for programs running under MVS to
easily wait for an attention on a device...

>Ok with all of that laid out, here is the ugly part.? MVS? (and VS1
>before it), do not present the attention to the application program.?
>Even though you have a DCB opened to the DDNAME with UNIT=xxx for the
>CTCA device, MVS won't give you the attention.

...and it sounds like I couldn't find a way because MVS doesn't make it
easy!

>? So what to do?? Turns out, you must establish the attention routine
>yourself.? I don't know if there is some official "MVS-way" of doing
>this, such as with IO appendages or some system macro that I don't know
>about (but I doubt it), so what I did was set up the attention routine
>myself.
>
>The attention routine should be treated like an asynchronous exit.? It
>needs to be in page-fixed storage.? The exit gets control directly from
>the system i/o interrupt handler and it is treated as a subroutine of
>the interrupt handler.? You set up a base register quickly, examine the
>CSW in the IOB if you need to, and POST your ECB.? Then exit using BR
>14.

This definitely gets into areas I haven't touched before... lots of
quality time reading through more PDFs on Bitsavers looks to be in my
future. I think you've given me the information I need to navigate
through learning all the right pieces to accomplish what I want.

>I hope this helps you get started.? If there is way to access the old
>Yahoo group files that might be an option.? Feel free to ask questions
>if needed.? Good luck.

The code you provided from your notes looks similar to code in the file
Rene found (attached to this message), so I think it should give me a
good example.

Thank you again for your extensive reply. I'll have to leave my
delay/sense-polling in place for now while I learn enough to make sense
of some of these details, but this does appear to be the answer.

Thanks,
Matthew
Re: How to wait indefinitely for a read on CTC device?

 

Hi Bob,

On 11.25.2022 15:12, Bob Polmanter wrote:
Yes, this is the program!?? Thanks Rene for locating it and making it
available.?? I sure thought it was an MVS version though.? Still, odds
are this would run on MVS with little to no changes.

After reviewing the code, some things you should know.? This was run on
VS1 running as a guest of VM/370.? Hence the DIAG08 subroutine and the
CP commands that it issues; you can ignore all that stuff.
Yep, I saw the DIAG08 and thought... aha! This must have been VS1
running under VM!

You should also know that the "other side" of this program was a
virtual machine running CMS.? The CMS application would communicate
with this CTCA code via a 'virtual CTCA'.? If you're not familiar with
VM, a virtual CTCA is a software implementation of real CTCA hardware,
and it acts and functions just like a real one and you drive it exactly
the same way.
In a way, that's somewhat like what I'm prototyping. While I've done
MVS<->MVS/Hercules<->Hercules to do some initial programming to make
sure I understand the basics of writing CTCA code, the project I'm
working on is MVS in Hercules on one side, but an application I'm
running on my host system on the other side. I've read through Hercules'
CTC implementation enough to piece together the struct that's serialized
and sent over the wire, the handshake protocol in Spinhawk-and-later,
etc., so I have a program written in Go running on my computer which
sends a command to my program running under MVS and receives data back
from the MVS program and displays it. Same approach that Shelby's MVSDDT
tool (which of course has been invaluable in debugging my usually-broken
assembler code!) uses from what I can tell, but using the "CTCE" support
instead of the original CTCT. Working to demonstrate the possibilities
of client/server programming against servers running inside MVS that
work all the way back with Hercules 3.13 that's included as a binary
package in some Linux distros (although 3.13 and Spinhawk-and-later made
changes/improvements to the CTC code, so I have accounted for the
differences on my side to support 3.13 through SDL-Hyperion).

I still feel like I have an MVS CTCA program around somewhere; if I
find it I'll be sure to make it available.
If you happen to find it I'm sure it'd be helpful, but otherwise you've
given me plenty to try to find a path through. Thanks!

-Matthew
Re: How to wait indefinitely for a read on CTC device?

 

Hi Matthew,

Yes, this is the program!?? Thanks Rene for locating it and making it available.?? I sure thought it was an MVS version though.? Still, odds are this would run on MVS with little to no changes.

After reviewing the code, some things you should know.? This was run on VS1 running as a guest of VM/370.? Hence the DIAG08 subroutine and the CP commands that it issues; you can ignore all that stuff.? I did recall correctly about the system providing the SCB data, the command code byte that was issued by the other side.? It is in the UCB, and I can see this code checking to see if the other side issued a read or a write CCW.? This version doesn't answer the question of the type of POST; in the VS1 code I cheated by turning off the wait bit in the RB.? I don't that that would fly in MVS.

You should also know that the "other side" of this program was a virtual machine running CMS.? The CMS application would communicate with this CTCA code via a 'virtual CTCA'.? If you're not familiar with VM, a virtual CTCA is a software implementation of real CTCA hardware, and it acts and functions just like a real one and you drive it exactly the same way.

This code was a prototype for an idea to enable a CMS user to read a PDS or delete a dataset or issue a message to the console; the request would be sent over CTC to VS1 and the actual work was done on the VS1 side.? Unfortunately, all of that extra stuff muddies the waters for want you really want in order to pick out the CTC portions of the code.

I still feel like I have an MVS CTCA program around somewhere; if I find it I'll be sure to make it available.

Regards,
Bob
Re: How to wait indefinitely for a read on CTC device?

 

Hi Bob,

Thank you for your extensive reply.

On 11.25.2022 12:42, Bob Polmanter wrote:
I originally posted the MVS-based CTC program on the H390-MVS group
when it was still under the control of Yahoo Groups.? It was in the
file section and it had a name like CTCASAMP.TXT or CTCAMVS.TXT or
something like that.? For some reason, that post did not get migrated
over here to groups.io in this forum or in the other MVS Turnkey
forum.? Further, I cannot seem to find it here on my TK4 system.? I
honestly don't know what happened to it.? Actually, I think I did this
when I was still using TK3 long ago and so it might be there, if I
still have that stuff.? It has been a long while.
Off-list, Rene Ferland sent me a file he found from one of the old Yahoo
files sections, CTCAMAIN.VS1.txt. I'm not sure if this was your code,
but from what I can see from a brief scroll through it, it does match
much of what you describe from your notes.

First of all, you don't want to issue a READ command and have it
pending. Instead, you just want to have the device's DCB opened and
everything initialized and ready to go, then just WAIT.? The ECB isn't
tied to the device or the DCB; this is just one of your own ECBs. ?
When the other side writes to the CTC, an attention interruption will
be raised on the opposite side.? This attention will drive an interrupt
handler and then it can post the WAIT.
Yes, I think waiting for the attention interruption is the correct
approach. Alas, I couldn't find a way for programs running under MVS to
easily wait for an attention on a device...

Ok with all of that laid out, here is the ugly part.? MVS? (and VS1
before it), do not present the attention to the application program.?
Even though you have a DCB opened to the DDNAME with UNIT=xxx for the
CTCA device, MVS won't give you the attention.
...and it sounds like I couldn't find a way because MVS doesn't make it
easy!

? So what to do?? Turns out, you must establish the attention routine
yourself.? I don't know if there is some official "MVS-way" of doing
this, such as with IO appendages or some system macro that I don't know
about (but I doubt it), so what I did was set up the attention routine
myself.

The attention routine should be treated like an asynchronous exit.? It
needs to be in page-fixed storage.? The exit gets control directly from
the system i/o interrupt handler and it is treated as a subroutine of
the interrupt handler.? You set up a base register quickly, examine the
CSW in the IOB if you need to, and POST your ECB.? Then exit using BR
14.
This definitely gets into areas I haven't touched before... lots of
quality time reading through more PDFs on Bitsavers looks to be in my
future. I think you've given me the information I need to navigate
through learning all the right pieces to accomplish what I want.

I hope this helps you get started.? If there is way to access the old
Yahoo group files that might be an option.? Feel free to ask questions
if needed.? Good luck.
The code you provided from your notes looks similar to code in the file
Rene found (attached to this message), so I think it should give me a
good example.

Thank you again for your extensive reply. I'll have to leave my
delay/sense-polling in place for now while I learn enough to make sense
of some of these details, but this does appear to be the answer.

Thanks,
Matthew

CTCAMAIN.VS1.txt
CTCAMAIN.VS1.txt

Re: How to wait indefinitely for a read on CTC device?

 

On 11.25.2022 08:09, Martin Taylor via groups.io wrote:
Many years ago I contacted Shelby Beach who uses CTC in their DDT debug
tool. In the reader part of the tool a CCW is issued using a C3 command
code with a data length of 1. No sure what this does but it may be a
solution to your problem, or just a red herring :-) ?FYI Have you a
copy of the CTC manual *IBM System/370 Special Feature* *Description:
Channel-to-Channel Adapter* which can be found on bitsavers.
Ah, interesting. C3 is a no-op, but it has a side-effect of disabling
compatibility mode on the adapter, putting it into extended mode.
Extended mode, among other things, looks like it enables some additional
status bits and generates -- and requires handling of -- an attention
interrupt when a command is first received from the other side.

The attention interrupt is interesting in that it sounds like that
aligns with Bob's message about waiting on the interrupt...

Thanks,
Matthew
Re: How to wait indefinitely for a read on CTC device?

 

When doing communications, I used to use a Twait or Waitt macro. I don't remember which. Either way it waited on multiple ecb's. That way of I wanted to end the program I just post the correct ecb and it did clean up and went to EOJ.

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Matthew Wilson
Sent: Friday, November 25, 2022 4:13 AM
To: [email protected]
Subject: [H390-MVS] How to wait indefinitely for a read on CTC device?

Hello,

I am on MVS 3.8, writing assembler code that reads from a CTC adapter. I will be running a "server" started task that should wait indefinitely for a command from the "client" program on the other end of the CTC link.

I'm having trouble finding the right way to wait indefinitely for the other side to send data.

I'm using the EXCP macro to execute my channel program (just a simple read command) on the CTC device. I do the EXCP, then I use the WAIT macro on the associated ECB.

When the sender doesn't send anything, the WAIT ends after 1 minute and the completion code in the high order byte of the ECB is 0x41. If I run EXCP and WAIT again, the WAIT *immediately* returns and the high order byte of the ECB is 0x48.

See the attached CTCREAD.0.txt for a job that demonstrates this.

That's not the behavior I want. Ideally I could WAIT, hit the 1 minute timeout waiting for data, then just issue the READ again and WAIT another minute. (Or just not timeout at all, in a perfect world.) I can loop until I get a non-timeout completion. (Although...I suspect this isn't quite right; I get an "IEA000I 502,IOE,02,9000,..." message on the console for the timeout, which I wouldn't want accumulating every minute over time.)

Alternatively, if I close the CTC DCB and open it again before the next EXCP/WAIT, there's another one minute pause before timing out again.
This is closer to the desired behavior... but I feel like CLOSEing and OPENing the CTC device each time through the "wait indefinitely for the other side to send data" loop is wrong. (And I also suspect that the read side sending the "read" command state to the other side of the link every time when it's not actually issuing corresponding writes each time will lead to problems.)

See the attached CTCREAD.1.txt for a job that demonstrates this close/open approach. This suggests to me that there's some state I should be able to clear to get the EXCP to really wait another minute before timing out, without actually having to close and re-open the CTC DCB.

The best approach I've been able to come up with so far is to not do a READ in my "wait" loop, but to do a SENSE CCW on the CTC adapter. On the sending side, I issue a CONTROL command through the CTC adapter before doing the WRITE. On my receiving side, I put the EXCP that runs the SENSE CCW in a loop with a 250ms pause (using STIMER macro). So if the SENSE doesn't see the CONTROL command from the other side, I sleep for 250ms and check again. Once the SENSE gets the CONTROL command from the other side, I can run the READ CCW and get data back.

This, so far, is the closest I've come to an ideal solution because it doesn't cause any IO exceptions, either in my program or on the MVS console.

However, I don't quite like it because I want to be able to use the WAIT macro on an ECB list that include the CTC "read" wait along with some other events. And with the 250ms spin loop, if the other side of the link writes data 50ms into the loop iteration, it's unfortunate to delay activity the remaining 200ms, and seeing the CPU time of the job slowly increase over time while doing nothing due to the loop is...not aesthetically pleasing.

SO... MY QUESTION... what is the correct way in MVS 3.8 to wait on reading data from a CTC adapter that may come right away or may not come for hours? Especially in the context of wanting that to be one of several ECBs I'm waiting on with the WAIT ECBLIST=... form of the WAIT macro?

Thank you,
Matthew
Re: How to wait indefinitely for a read on CTC device?

 

¿ªÔÆÌåÓý

Bob,

I have copies of the files from most of the MVS groups but I won¡¯t be able to access them for a week.

Dave

?

From: [email protected] <[email protected]> On Behalf Of Bob Polmanter
Sent: 25 November 2022 20:42
To: [email protected]
Subject: Re: [H390-MVS] How to wait indefinitely for a read on CTC device?

?

Hi Matthew,

I've done a lot of CCW programming of CTC devices over the years but unfortunately for this case the vast majority of it was in a VM environment.? In a virtual machine, I could write my own interrupt handlers and issue the CCWs using SIO and have 100% control over the device.? However, I did do some work with CTC adapters under MVS and VS1, using EXCP and WAIT but it wasn't anything meaningful; its sole purpose was to prove that I could get it to work.? And I did.

I originally posted the MVS-based CTC program on the H390-MVS group when it was still under the control of Yahoo Groups.? It was in the file section and it had a name like CTCASAMP.TXT or CTCAMVS.TXT or something like that.? For some reason, that post did not get migrated over here to groups.io in this forum or in the other MVS Turnkey forum.? Further, I cannot seem to find it here on my TK4 system.? I honestly don't know what happened to it.? Actually, I think I did this when I was still using TK3 long ago and so it might be there, if I still have that stuff.? It has been a long while.

However, I did find some 'CTC Notes' in my files, and I do recall some things that I discovered while trying to get those adapters to work on MVS, and combined with what I know of how CTCAs work in general, I think I can get you pointed in the right direction.

First of all, you don't want to issue a READ command and have it pending. Instead, you just want to have the device's DCB opened and everything initialized and ready to go, then just WAIT.? The ECB isn't tied to the device or the DCB; this is just one of your own ECBs. ? When the other side writes to the CTC, an attention interruption will be raised on the opposite side.? This attention will drive an interrupt handler and then it can post the WAIT.

After the WAIT is posted, your code can now issue the READ. It should be completed very quickly and you'll get a CSW with CE+DE if you chain the READ CCW with a NO-OP? X'03' CCW.? After that operation is completed you are free to go back and wait again, or attempt to write something to send back.? The other side would also be waiting for the next action and if you did write something back then the other side would also receive an attention and do a post and then issue READ.? I hope that makes sense.? But the main point is, you don't issue a read until you get an attention.

After receiving an attention, you could (optionally) issue a "Sense Command Byte" CCW (X'14'), to see what command the other side used to initiate the attention.? It could have issued a write.? Or it could have issued a Control CCW.? You can use the results of sense command byte (SCB) to determine how you want to handle the attention.? But something tickles my memory that in MVS the SCB value is placed into the UCB and you can examine that after the attention, thereby avoiding the extra hassle of issuing another EXCP to do the Sense Command Byte operation.? See below in the notes about UCB+23.

Ok with all of that laid out, here is the ugly part.? MVS? (and VS1 before it), do not present the attention to the application program.? Even though you have a DCB opened to the DDNAME with UNIT=xxx for the CTCA device, MVS won't give you the attention.? So what to do?? Turns out, you must establish the attention routine yourself.? I don't know if there is some official "MVS-way" of doing this, such as with IO appendages or some system macro that I don't know about (but I doubt it), so what I did was set up the attention routine myself.

The attention routine should be treated like an asynchronous exit.? It needs to be in page-fixed storage.? The exit gets control directly from the system i/o interrupt handler and it is treated as a subroutine of the interrupt handler.? You set up a base register quickly, examine the CSW in the IOB if you need to, and POST your ECB.? Then exit using BR 14.

What I can't remember is if I did a regular POST or if I did a 'branch entry to POST'.? I think it was branch entry though, because I doubt the system interruption handler would tolerate an SVC execution due to a regular POST.

To page-fix the storage for the exit, you could GETMAIN some storage in subpool 245 and move your exit code into that storage area.? What I did (because this wasnt anything serious) was just use ADDRSPC=REAL on the EXEC PGM=? JCL statement along with a small REGION size like 64K or whatever to make the program? run in fixed real storage that way.

Now there is one other problem to solve and this is where my notes come in.? The system doesn't know about your exit routine or how to locate it.? You have to tell it, manually.? Basically, you stuff the address of of a one word parameter list that contains the address of the entry point of your exit directly into the CTC's UCB.? To do all of this (to set the parm list exit address in the UCB and to use SP 245 storage) you need to be APF-authorized and both of these functions need storage key 0 access.? Here is what my notes say about getting the exit address set into the UCB:

???????? OPEN? (CTCA)
*
???????? MODESET KEY=ZERO,MODE=SUP
???????? LA??? R5,CTCAATTN????????? POINT TO ATTN EXIT PARM LIST
???????? L???? R6,CTCA+44????????????? GET DEB ADDRESS FROM DCB
???????? L???? R6,32(,R6)????????????? GET UCB ADDR FOR CTCA FROM DEB
???????? LA??? R6,0(,R6)?????????????? CLEAR THE HIGH ORDER BYTE R6
???????? ST??? R5,24(,R6)????????????? PUT PARM LIST ADDR IN UCB
CTCA???? DCB?? DDNAME=CTCA500,MACRF=(E),DSORG=PS
CTCAATTN DC? A(ATTNRTN)???? PARMLIST POINTS TO ATTN EXIT
.
.
ATTNRTN? DS? 0H
????????????????? BALR? R3,0
????????????????? USING *,R3
* UCB addr is in R7, can examine CSW or sense data in UCB
* UCB sense command code is at UCB+23
* UCB CSW status is at UCB+28
?????????????????? BR?? R14


I hope this helps you get started.? If there is way to access the old Yahoo group files that might be an option.? Feel free to ask questions if needed.? Good luck.

Regards,
Bob

2081 - 2100 of 5260