Successfully configuring Hercules for the SDLC links to the terminals

 SETTING UP HERCULES TO PROVIDE A DLSw SOCKET

I need a modified version of Hercules with the DLSw code inserted in the 3705 emulation module. I used Matt Burk's code from Github to produce that version of Hercules. It has the inherent capability but will require a change to the configuration file to indicate that an emulated 3705 should create a socket to send and receive DLSw traffic. 

Before the device we configured to Hercules can be used, I have to modify the MVS 3.8 turnkey image to make use of terminals remotely attached via the 3705, whereas the usual terminals set up in the image are locally attached 3270s (e.g. through a channel attached 3274 or similar control unit). VTAM definitions and procedures are modified and assembled to invoke my new terminals.

SNAG NUMBER 1 - CURRENT MVS IMAGE HAS NO 3705 IN THE OPERATING SYSTEM

The MVS 3.8J image I have downloaded and used is not the TK4- turnkey version used by Matt Burk for his SDLC work. The nucleus was generated with only local 3270 terminals, no 3705 devices were implemented. That would require me to do a system generation (sysgen) to add in the devices, then configure VTAM from scratch.

On the other hand, the TK4- system already has 3705 devices included and only needs some VTAM work to make it functional. I therefore downloaded and installed this version of MVS for use with my modified Hercules. A minor update to the configuration file gave one of the 3705 devices the DLSw functionality.

UPDATE TO VTAM FILES IMPLEMENTED IN THE TK4- SYSTEM ON MY LAPTOP

I had to brush the cobwebs away from my memories of using ISPF to edit MVS files, in order to use the freeware product RPF under TSO of the turnkey MVS. It involved editing two members of a partitioned data set SYS1.VTAMLST in order to define the three terminals I wanted and change a blocksize limit for the three terminals I will support via my DLSw link. I then had to edit the startup procedure STARTSTD in SYS1.PARMLIB to vary online the additional terminals I defined. 

A utility function let me delete the two members of SYS1.VTAMOBJ which holds precompiled versions of the members in SYS1.VTAMLST - compiled for speed during execution. I killed the two members S3705 and N13, thus causing VTAM to compile them at the next startup.

REBOOT OF MVS 3.8 TO VERIFY THAT I DIDN'T MESS UP THE VTAM CHANGES

The system came right up and everything appeared to be working properly. I then opened the two log files, one is a hardcopy of every MVS message during the operation and the other is the Hercules log. I could see the vary commands turning on my three new terminals, so the MVS side seemed good. The Hercules side, however, listed an error "unrecognized parameter DLSW" which means somehow I don't have the correct 3705 emulation code operating. 

WEIRDNESS - I CLONED THE GITHUB PROJECT BUT NOT THE DLSW BRANCH

I had the branch visible on the github website but when I did the clone by launching the desktop github app, it pulled the main not the branch. I detected this by comparing the comm3705.c files on my laptop with the ones on the branch online. Sheesh. 

I downloaded a zip file of the branch, which in fact had the proper updates to comm3705.c and other files. At some point I will need to investigate why the desktop application messed this up, but for now I have the files and can go back and build this version of Hercules. 

RETEST NOW THAT I HAVE THE PROPER DLSW VERSION OF HERCULES

I updated the Hercules executable folder of the tk4- (and my older mvs38j) turnkey MVS systems and did a test IPL of tk4- to see whether it recognized the parameter and seemed to come up. The Hercules log looked very good as I could see it start up the support and listen for my router to connect:

13:24:35 DLSw thread starting for dev 1634

13:24:35 HHC00100I Thread id 000031c4, prio 4, name '3705 device(1:0662) thread' started

13:24:35 DLSw: create server socket

13:24:35 DLSw: setsocketopt()

13:24:35 DLSw: bind()

13:24:35 DLSw: listen()

I then looked at the MVS log to make sure that all seemed good for the VTAM use of the 3705 and the various terminals going online. That too looks good:

13:25:33 HHC01062D 0:0662 COMM: WR: 1F00 6000 0800 0001 000C 6B8000 110255 ACTPU

13:25:33 WARNING: DLSw packet lost, requestp[2] = 0x60, requestp[3] = 0x0

13:25:33 HHC01062D 0:0662 COMM: RD: 1F00 0800 6000 0001 000D EB8000 1102D5 ACTPU

13:25:33 HHC01062D 0:0662 COMM: WR: 1F00 6000 0800 0002 0004 6B8000 A0     SDT

13:25:33 WARNING: DLSw packet lost, requestp[2] = 0x60, requestp[3] = 0x0

 We can see above that VTAM is trying to communicate with the 3174 using the DLSW link but of course since I don't have the router connected and active, the packets are not getting a response. However, it did attempt steadily to connect to the remote 3174 until I had shut down MVS.