Quick verification of communication between CISCO 2911 router and my laptop

 PURPOSE OF THE LINK

The ethernet connection between my laptop and the fast ethernet port of the Cisco 2911 will be used by the DLSW encapsulation function of the router to contact the 'other router' to carry the SDLC traffic between the serial port on the router, hooked to my IBM 3174 terminal controller, and a mainframe system. 

The other router is really code built into the 3705 emulation function of Hercules which strips the SDLC from the link and processes it as if a serial line were configured between a real 3705 communications controller and the remote 3174. Thus the mainframe emulated by Hercules thinks it has a 3705 using a leased line to talk to the 3174. 

IBM and Cisco developed the DLSW encapsulation as a way of transporting the serial traffic over a TCP/IP network instead of Telco leased lines. The 3174 on one side and the 3705 on the mainframe data center side both have serial port connectors, but instead of those being cabled to modems, they hook to serial interfaces on Cisco routers. The routers carry the serial traffic inside TCP/IP. 

TESTING SETUP

I hooked up an ethernet cable between the laptop and the router. I set up the fast ethernet port of the 2911 as 192.168.0.1 and configured my laptop's ethernet port as 192.168.0.2. I then booted up the router making use of a USB serial link for the console port of the router and the command processor of Windows on the laptop side.

VERIFICATION

I did some pings to see that the packets were sent both ways over the ethernet cable, then started a telnet client on windows and pointed it at the router address. This opened and I had the logon prompt that I could use to connect to the router's IOS environment. This ensure that I have a good link on this end. 

NEXT STEPS

Once the outdoor environment is healthy I will hook the serial port of the router to my 3174 and cable the ethernet to the laptop. After I boot the router and start Hercules, I am IML the 3174 controller. If all goes well, the serial link will be established between 3174 and 2911, then I can start DLSW and IPL the MVS 3.8J image under Hercules.

Side project while waiting for outdoor air to become fit for human life - restore a Power Designs 2005P Power Supply - Part I

 CALIFORNIA FIRES AND AIR QUALITY

The many wildfires, most started by lightning during one day of thunderstorms, have been joined by fires up north of California and a few new blazes started later, to produce staggering amounts of smoke and ash. While I am safely away from any fire danger, the air quality has had very large quantities of 2.5 micron or finer particles that are quite unhealthy. 

TERMINAL PROJECT WORK REQUIRES OUTSIDE EXPOSURE

I have set up tables with the various 317x terminals, the 3174 controller and the other components for my main project driving the green and color screens from MVS running on PC based Hercules and a P390 mainframe. The bad air has been an impediment to further testing, thus I have been spending my time in alternate projects and reading.

RESTORATION OF POWER DESIGNS 2005P POWER SUPPLY

I had bought a 2005P power supply from eBay because it is a highly accurate supply with an internal oven to ensure excellent regulation and accuracy of the voltage produced. The model I bought is remotely programmed, which simply means that an external resistance is used to set the voltage. It produces 1V for every 1000 ohms of resistance across its 'programming' terminals.

I have a resistance substitution board that produces essentially any resistance I want from 1 ohm to 11.1 MOhm by setting switches, which when connected to the power supply programming terminals will let me produce voltages from .001 to the full 20V capability of the supply. It also supports current regulation, thus will be a good lab tool when used for experiments where controlled targeted voltages are important. 

There are some adjustments that I can't make with the extreme range of the calibrating pots, but that I something I can deal with by adjusting some internal resistances and pots. The more serious issue I detected is that the oven is not heating up. Any time the supply is plugged in, even if the switch is off, it should warm the oven and maintain its  temperature. 

The amplification and regulation components are set inside an oven can where a heater is thermostatically operated to establish a narrow range of fixed temperatures for the remaining parts. Operation of the heater is shown with a neon indicator bulb on the supply faceplate, but it remained dark.

Further, I checked the terminals on the oven that feed the heater inside and found zero voltage on the pins. Checking the pins for the thermostat, I found it stuck open when it should be closed at room temperature. I therefore have to disassemble the oven, find the thermostat and attempt to fix it. If I can't fix it I will need to replace it with a comparable unit. 

Oven with components inside

Oven desoldered and removed from the main turret board

Following the instructions got me to the point where I can see the board with all the amplifier components mounted on it but when I grab it and try to pull it out it isn't moving. Moreover, the diagrams of the board don't have the thermostat (or heater) on them so they may be embedded inside the base of this can. I did have to pick out quite a bit of glass wool that is the insulation inside. 

Amplifier components on small turret board inside overn

I suspect the thermostat is inaccessibly embedded in this nylon base

While there is no definitive spec for the temperature inside the can, several others who have restored these units report that it activates at 70C. Some have chosen a lower set point of 50C, claiming the regulation is just as good and they believe the lifetime of the components would be enhanced. 

I shopped for a 70C thermostat. There must be room inside to mount it and a way to connect the wires to the pin on the base, or a way to route the wires out without compromising the heat seal of the oven. Putting it inside the can won't be a problem, I believe, but the wiring is challenging. 

70C Thermostat

My plan was to drill two small holes in the base for a snug fit and epoxy the thermostat wires in place. The body of my new thermostat is metal thus I had to ensure that it was fully insulated from the components on the small turret board. Fortunately it comes with a plastic cover.

Drilling from the bottom was too risky, since I can't see inside the nylon base. My plan B is to drill holes in the top metal cap to allow the thermostat wires to protrude, then bend them 90 degrees and route them out a hole in the top of the outer metal can. This won't be ideal cosmetically but should minimize additional heat loss and most importantly, work properly. 

Setting up laptop for private ethernet link to Cisco router

 CONNECTING CISCO 2811 TO LAPTOP FOR HERCULES SDLC LINK TO MVS

The SDLC (VTAM) version of the project is to connect my IBM 3174 and its attached 3178 and 3179 terminals to MVS running under Hercules on my laptop. This uses an IP encapsulation protocol DLSw implemented by Cisco that will wrap SDLC packets inside an IP protocol. This was used to route links to remote 3270 terminals using IP networks, with both endpoints stripping the DLSw and implementing SDLC links to mainframe and 3174 ends. 

The Hercules project implemented a DLSw socket on its 3705 communications controller emulation function, which strips the outer protocol and pretends that there was a native SDLC link hooked to the 3705. The other end of the DLSw link is the CISCO 2811 router, which believes it is talking to another Cisco router rather than Hercules. 

The serial connection on the Cisco router is hooked to my 3174 cable and speaks SDLC. My IBM 3174 thinks it is talking pure SDLC over telecom lines to a physical 3705 controller on a mainframe. 

STATIC IP ADDRESS CONFIGURATION FOR THE DIRECT LINK

I configured my laptop's ethernet port with a static address. It is 192.168.69.2 and it uses 192.168.69.1 as the default gateway for routing. Of course, the Cisco router is configured so its ethernet is 192.168.69.1 and its default gateway is my laptop's address. 

VERIFYING CONNECTIVITY

To bring this up, I have to boot up the Cisco router and attach an ethernet cable from it to my laptop. Pings from both the router console and from my laptop will show whether the IP connection exists. The DLSw link itself uses TCP port 2065 on both end, but that will be tested once I bring up the entire test setup. 

RPF working well now

 COMPARING MOSELEY AND TK4- MVS SYSTEMS HIGHLIGHTED DIFFERENCES

There were quite a few differences but I first zeroed in on the variations that I suspected might have caused the observed symptoms. Some I ignored because they didn't seem likely to account for the misbehavior - for example, the good system has RPF V1R5M3 while the bad system was running a newer V1R8M0.

I began to narrow down my investigation to the parameters and procedures that start up TSO under TCAM. In the parameter library SYS1.PARMLIB, the primary member that controls TSO is IJKPRM00 but there is also a member TSOKEY00 to consider. Nothing in the SYS1.PROCLIB procedure that starts timesharing looked meaningful, nor did the CLISTs executed at login. 

IKJPRM00 member of SYS1.PARMLIB

I carried the entries from the TK4- system back to the Moseley MVS 3.8J and updated IKJPRM00 and TSOKEY00 there. When I then logged into TCAM TSO and ran RPF, it worked perfectly! The likely causes are the buffer size and quantities specified in IKJPRM00. While I could do a binary search changing individual lines in the file, that isn't important to me. What matters is having full RPF use. 

Digging into the TCAM TSO problem running RPF correctly

 CLUES TO PURSUE

Some times that RPF would want to clear the screen, it does not happen. The impact of this is screen residue including attribute bytes protecting fields that should no longer exist. On the other hand, when the cursor gets to the bottom of the screen in line mode, it clears just fine to present the next 'screenful'. 

The terminal is only in line mode. That is, when you hit enter the cursor is moved down a line and periodically when the bottom of the screen is reached, three asterisks are shown to cue the user that lines weren't written because the screen is 'full'. PF24 is supposed to toggle TCAM between line and full screen modes, but it does nothing. The terminal only operates in line mode.

EXPERIMENTATION TO UNDERSTAND THE ISSUE

The only software that appears to malfunction is RPF. RPE, another full screen tool, works fine. All the line oriented applications and commands work well. I began looking through the source code of RPF and making small changes to see if I could localize the problem. 

RPF worked partially. Some menus were displayed, others were not.

• The initial splash screen at startup is not displayed
• The main menu is not displayed. This offers 11 choices, 0-9 and X
• Choice 0 will display its own menu, as do choices 3, 7, 8, and 9. X ends RPF
• Choices 1, 2, 4, 5, and 6 do not display their menus
• Within choice 0's submenu, there are 5 choices plus exit. Only two display menus

I first looked at the streams being written and the code in the module producing it, to see if there was an obvious common element or code being executed. Nothing obvious as far as I could tell. I then moved the screen write (TPUT write to TCAM) earlier in the modules to see if bypassing some code would clear the problem. Nothing changed in this case either.

I then slightly modified the TPUT call. There are three types of TPUT - ASIS, FULLSCR and NOEDIT - and RPF was almost exclusively using NOEDIT. I changed the startup code to ASIS and the splash screen appeared! 

This had a deleterious effect on operation under VTAM, as it converted the splash screen into a line oriented rather than full screen write, so I had the three asterisks that mark a continuation at the bottom of a screen. It did not behave that way under TCAM. 

I went into the code that produced the main menu to change the TPUT statements to ASIS. This did put up the menu but oddly, in sections with the line continuation characters between each group. ASIS supposedly passes the message directly through TCAM to the terminal, while FULLSCR and NOEDIT make some dynamic translations including decisions about line mode versus full screen. 

About this time, I came across the release notes of newer versions of RPF which mentioned changes dealing with the NOEDIT version of TPUT and correcting behavior under TCAM. That seemed to match my symptoms thus I proceeded to download and install the latest release V1R8M3 to see what it did. 

Alas, while it improved the behavior of some screens it still didn't show the splash screen, main menu or several of the choices from the main menu. Where it did display the menus in the past, residual characters were left on the screen from prior writes. With this new release, those menus that did display correctly erased the screen first so at least we had progress.

COMPARING TK4- AND MOSELEY 3.8J VERSIONS FOR RPF EXECUTION

RPF is said to work properly under TCAM in the TK4- version of MVS 3.8J while it obviously does not work in the version of 3.8J I just built from the Jay Moseley site. I had Tk4- installed and will first verify that it works well, then start examining the two systems to look for differences that might explain this divergence.

In particular, I will look for:

1. Differences in parameters in library members and procedures related to RPF, TSO, TCAM
2. Different APARS and local modifications applied to the two versions of MVS
3. Any modifications applied to RPF

Investigating issue with TSO operation under TCAM, showcased by failure of RPF to display menus

 RUNNING DUAL TSO ENVIRONMENT, TCAM AND VTAM

While I am testing the BSC link to my 3174, I must use TCAM to support the TSO sessions. With SDLC connections, only VTAM is needed and that is how my MVS turnkey system was configured. To be sure that still have the ability to use TSO while fumbling with TCAM, I have both available.

If I issue a S NET command on the operator console, it brings up VTAM and that starts TSO. On the other hand, if I issue a S TP command, it starts my procedure to bring up TCAM. There are a set of local 3270 terminals assigned to VTAM and another set assigned to TCAM, in addition to the remote 3174 that will be handled by TCAM. I can have both running simultaneously, useful to do comparison commands.

FAILURES EXPERIENCED WITH TSO/TCAM LOCALLY (BUT WORKS FOR TSO/VTAM)

The differences I see when running TSO under TCAM versus the VTAM version:

1. No splash screen for logon
2. TSO does not know how to clear the screen before Logon request message
3. Running commands like Operator and RPF don't produce initial output
4. These commands above are operating, as they respond to input
5. RPF in particular does not produce splash screen nor initial menu

I found that if I blindly typed an input of 0 after starting RPF, which with the initial menu would select the session defaults option, I do see the menu for that choice displayed. However, the screen was not cleared before this leaving residue from prior contents anywhere that wasn't written by this menu.

I could pick a few of the choices within that session defaults menu and have them work properly. Choices 0 and 2 did display the expected output although once again without clearing the screen beforehand. Choice 1 did nothing. 

FIRST THOUGHTS

Whatever is wrong, it isn't very major since much behaves properly. TSO operation depends upon a ballet of procedure library entries, parameter library entries and CLIST entries to execute in order to set up the session properly. 

Whatever is malfunctioning seems to be more basic than just RPF, even though that program shows the most problems. The lack of screen clearing at logon indicates an issue at a fundamental level. 

I don't have access to all the proper manuals at the MVS 3.8J level and therefore I am interpolating from material of earlier (MVT 21.8) and later (zOS) which has its challenges and dangers. Still, I do have a working VTAM TSO environment to make comparisons with. 

It is time to collect as much data as I can about what is occurring both for basic login and for RPF execution, starting with MVS logs and moving on to various diagnostic methods I can establish. Hopefully the clues will build until I have a clear culprit, after which I can take corrective action.

Changing the TCAM configuration and MCP to support the BSC link to the SyncDongle

 OVERVIEW OF CHANGES NEEDED

The TCAM message control program (MCP) that will be used by TSO needs to be built to reference remote 3270s connected via a 2703 control unit. The MCP startup procedure needs to specify the address of the 2703 in addition to the local 3270 devices. Finally, Hercules must define the 2703 and invoke the BSC socket at a given port number. 

The system I just generated had entries to define several 2703 communications controllers thus the OS already will support this. I chose to use device x604, the same one selected by Mattis Lind in his project.

POINTING HERCULES AT THE 2703

All that is needed is an entry in the mvs.cnf configuration file used by Hercules to define my virtual data center where I will IPL MVS. The existing configuration file doesn't define the 2703 devices but I need to add one at x604 so that TCAM can try to reach the remote 3174 controller using BSC protocol. 

0604    2703    lport=32701 lnctl=BSC dial=IN

The line above tells Hercules to emulate a 2703 at address x604, using the BSC capability, opening a TCP socket at port 32701 which will be connected to by socat, a tool similar to netcat but taking serial in one side and bidirectionally transferring messages to a TCP destination on the other side. The serial side of socat is connected to my SyncDongle, which has the 3174 cable hooked to its other end. 

BUILDING A TCAM MCP

Creating a TCAM message control program is a two stage process. High level macros are created by the system programmer to define the terminals and other features needed. When these are assembled they produce a stage two jobstream that assembles data areas and hooks them together (link edits) with existing TCAM modules to create our MCP. 

SET UP A START PROCEDURE FOR OUR MCP

In order to bring up TSO, we have to start our MCP. A procedure is installed on the system to start this code and point it at our communications controller at address x604. This procedure is invoked as a command by the operator to start up TSO. This MCP will only handle the remote terminals, so I plan to make adjustments to add in the local 3270 terminals. 

TEST IPL OF MVS WITH THESE CHANGES

I had first tested IPLing the system with the 2703 added but without the MCP set up. It was in fact listening on 32701 for our connection. I used a telnet program to connect just to see what will be emitted, but the BSC code didn't like what it saw and dropped the call. I then used netcat as suggested by Mattis and did see the poll attempts:

7@@@@-7@@@@-7@@@@-7@@@@-7@@@@-

When I broke the network connection the console was flooded with intervention required messages, quickly flooding the WTO (write to operator) buffers. The system was uncontrollable at this point so I tried shutting down things in the blind and then dropped Hercules. 

NEXT STEPS

I want my TCAM MCP to handle both local and remote terminals, thus I have a bit of work to do enabling this. 

It will be time to hook up the SyncDongle and attempt to make this all work. Before that step, however, I need to get a socat equivalent utility installed as that must establish a flow of messages between the async serial port of SyncDongle and the network port 32701 in Hercules that is the 2703 comm controller.