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

 REVERSE ENGINEERED CIRCUIT FOR PROGRAMMING CONSTANT ADJUSTMENT

I went through the power supply, tracing out, beeping and and measuring components to determine what was different between this 2005P supply and its cousin the 2005 for which I had schematics. In fact it was a very minor set of changes. 

I took the schematic for the 2005 and erased the extraneous gear and made the corrections. Now I have a schematic of my unit. I posted this as the prior blog post for anyone who has this unit and is looking for the drawing.

Portion of 2005P schematic covering adjustment

As is shown above, the Programming Constant trim pot is R21 and it is wired to deliver 0 to 200 ohms of resistance from one end of the range to the other. Above it, there is a parallel set of resistors, one fixed at 5200 ohms and the other (R CAL) chosen to make the effective resistance correct for operation.

In my unit, the value of R CAL is 100K such that the equivalent value of the parallel resistors is 4,925K. Since the circuit when adjusted all the way to one end of the Programming Constant trimmer pot, where the resistance is 200 ohms, is insufficient to make the output low enough, the equivalent resistance of this pair is too low. 

STRATEGY FOR CORRECTING TRIM POT RANGE

I will snip out R CAL and test the resulting output voltage. Based on where the output voltage is with the trimmer pot halfway, I will determine an appropriate parallel or series resistor to make the output of the supply match the external resistor in K ohms by adjusting the Programming Constant pot. 

FINAL ADJUSTMENTS

I set up my resistance board for as close to exactly 20,000 ohms as I could get and wired it into the supply rear terminals as the programming resistance. After cutting out the R CAL resistor, I was able to adjust to 20.000 volts with the Programming Constant trim pot somewhere in the middle of its range.

I did have to recheck and readjust the Zero Trim pot, then finesse the Programming Constant but once that was done, I could set up my resistance board to any value I wanted between 0 and 20K and I would see a voltage equal to 1/1000 of the resistance. This project is complete. 

CROSS CHECKING WITH OTHER MEASUREMENT INSTRUMENTS

My 2005P power supply is only adjusted as accurately as the resistance I hooked up and as accurately as my VOM could measure. When I am next in a lab with multiple higher quality instruments, I will recheck the resistance and output voltage but that will be a matter of a minor adjustment of the trim pot.

Power supply with 'programming' resistance board on top

Power Designs 2005P power supply schematic

 This is a schematic I created by correcting the model 2005 version for the differences found in the 2005P, since there seem to be no extant schematics for the latter model.

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

The wine country fires have dumped large amounts of ash and smoke into the air, with that particle laden air wafting down to my area. Air quality is Unhealthy and will likely remain until those fires die down or the wind patterns change. I continued working on the side project for now.

First step was to drill the holes in the top cap, just to the side of the slot where the inner circuit board juts out. Then the wire will bend 90 degrees to exit sideways from the top of the red outer can. As you can see from the pictures below, it has extra room above the top cap to permit the wires to fit.

Top cap on left, outer can on right

I used a small drill bit and a handheld drill on the outer can because of its cylindrical shape, but was able to use the same drill bit in a drill press for the top cap as its bottom would sit flat. With holes drilled and a test made for the wire clearance, I began to think about assembly.

The thermostat wires are too short for the run from inside the oven, out the top cap, along the entire length of the outer can before it is slid down over the oven and still have the wire come out the side holes. Therefore I need to extend the wires by soldering new lengths to the ends and insulating. These new segments should be rated at least the same 105 C as the thermostat existing wires. 

Holes drilled and wire fit tested

The last safety check was to ensure that the shrink wrap tubing that would insulate the solder joints was also capable of safe operation up to 105 C, the same limit as my wiring. I found that the materials used were intended for operation at levels from 125 C up to more than 220 C depending on the particular type, thus making these suitable for my project. 

With the new thermostat installed, I stuffed the insides of the oven with the glass wool and replaced the can covers. I then routed the external wires down the side of the oven can and to the terminals underneath where the thermostat circuit is connected.

Oven back in place ready for rewiring

The next task was to solder all the connections back on the oven terminals. Several of them had 3 or more leads, but most were single wire per terminal. I found for the multi-lead ones I had to completely clean the terminal, clean up the wires and wrap each around the terminal lug ends before I could reliably solder them.

One final check shows connectivity of the thermostat contacts and of the heater, but no shorts, so I tidied up and applied line voltage to verify that this heats up then cycles to maintain target temperature. According to the manual it should take about 10 minutes to reach working temperature after which the thermostat will open and then cycle to maintain the target 70 C.  

I found it was only about 4 1/2 minutes until the oven light extinguished. Since the ambient temperature was about 38 C and the can had been in full sunlight before I put on the cover and started, that is a reasonable warm-up interval. I suspect the manual assumes an air conditioned lab and has some padding in the estimate to ensure the 

Now that the oven is working properly, I have to turn my attention to the process of calibrating the unit. There are meter adjustments, zero voltage adjustments and a 'programming' linearity that ensures that with a perfect 20K ohm resistor attached, the unit will deliver 20V with a variation of no more than 7 millivolts. 

The procedure to adjust the output accurately covers the situation I faced, where the trim pot doesn't get all the way to the desired value when turned to its extreme. There are a set of resistors in a division network on the board, on which you solder jumpers until you get the zero voltage point with the trimmer pot set about midway through its rotation. In other words this is a normal part of adjusting the unit. 

My zero point delivered about 4 mv at its lowest on my VOM, not zero, with the zero trimmer set to its extreme end of the range. To eliminate errors from the alligator clip jumper resistance and the VOM accuracy, I put in a good solid conductor jumper for the resistance and made use of my oscilloscope for the voltage measurement. The results were consistent - I need to change the resistance to achieve a real zero setting with the trimmer pot.

Jumpers on resistors thus only 16.2K (R9) is in circuit now

The four resistors from left to right are R40 (4.32K), R13 (8.25K), R9 (16.2K) and R41 (32.4K) thus they can be set for resistances for 4.32K up to 61.17K in approximately 4.32K increments. These resistors feed one side of the comparator in the oven to match against the target resistance connected to the programming terminal. 

I will cut the existing jumpers and use alligator clip jumpers to experiment, then solder in new jumpers to the desired resistor value I select based on the outcome. The correct combination in circuit were R40 and R13 for a combined resistance of 12.58K ohms. I was able to set the zero point with the trim pot and the unit was very stable within the precision limits of my VOM. 

Setting the zero point with short on programming input terminals

With the zero point properly set, I attached my resistor board and set it up for 10K ohms. My VOM shows the resistance at 9.9K within the precision of my unit. Then I attempted to set the linearity to achieve 9.9 volts where it is between 9.893 and 9.907 on the voltage measurement, again subject to the precision and accuracy of my VOM, in order to meet the specifications for this unit of +/- a millivolt. I could not. At one extreme of the programming constant trim pot, it was still over 10.3V output. 

Unfortunately, the schematics I own are all for the regular 2005 unit, not the 2005P that is programmed by external resistance. In the regular units, high precision resistors are wired onto the setting switches and necessary adjustments are made internally, but on my unit there is a trimmer pot to make sure that 1000 ohms produces exactly 1V +/- 7 mv. 

To finalize the restoration of this unit, I will need to reverse engineer the circuit portion that includes the trim pot to see where I might be able to adjust other values so that the trim pot can set the target somewhere near the middle of its adjustment range. Stay tuned for part III of this project.

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. 

Loading code into the SyncDongle

 SYNCDONGLE BLUE PILL STM-32 CODE LOADED OVER JTAG

I wired up the ST-Link adapter to the JTAG connector on the Blue Pill board. JTAG is a programming interface useful for loading flash memory contents or initializing processors and FPGA hardware. The ST-Link adapter plugged into my laptop through a USB port.

The code written by Mattis Lind is a mix of Arduino mainline code and some C library functions. I set up the Arduino development environment to handle the ARM cores on the Blue Pill, compiled everything and loaded it over the ST-Link to the SyncDongle board. It was now ready for use, once I provided power to the board and connected its two serial connections to the 3174 and a USB serial cable respectively.

Building the MVS version to support BSC links to my 3174 using SyncDongle - second time is the charm

 INVESTIGATION OF THE USER CATALOG ISSUE

Once I looked closely at the issue, the problem was pretty simple. Somehow I had been interrupted yesterday and had to reIPL the mvs image. The configuration file didn't mount the four new disk packs onto which we were doing the sysgen, one of which held the user catalog in question.

EASY FIX AND THEN COMPLETING THE SYSGEN

A quick modification of the configuration file, a restart of Hercules and an IPL allowed me to start the sysgen jobstream. All ran successfully, a few hours of submitting jobs, checking completion codes and saving the 'printout' files for later review. 

There was a minor roadblock, so typical of the intrusive Windows environment, where I had to fight to get netcat (a utility that takes pipelined input and writes it out on a TCP/IP socket, thus used to copy files to a network address). Both Google Chrome and Norton Antivirus seemed intent to block every attempt to download and use this tool, because some have used it for hacking. Guilt by association.

NMAP had a version (ncat.exe) that I could download without the gestapo marching in to remove it, then a simple rename to nc.exe and a modification of Jay's submit.bat file to remove options (-w1) that make no sense to this netcat program, and I could continue adding languages, third party programs and other enhancements. 

I ended up with a customized MVS 3.8J system that was ready for me to apply a few modifications to support the BSC (binary synchronous communications) protocol link over TCP/IP. 

Constructing an MVS 3.8 with 2703 controller and TCAM configuration for my remote 3174 - try 1

 OVERVIEW

In order to bring up MVS and have it communicate with the SyncDongle and my 3174 controller, I need to set up the OS to use a 2703 communications controller (emulated) having a BSC socket. The network and TSO system needs a TCAM message control program that defines my remote terminals and attempts to contact them using the 2703. 

The existing turnkey MVS 3.8J system I have does NOT have 2703 devices generated into it, thus I will need to do a sysgen (systems generation) to configure the device first. That is a lengthy process that I will attempt using Jay Moseley's process based on the starter system and distribution tapes. 

Once that system comes up, I need to generate the appropriate TCAM files and message control program that will know how to start a TSO session on my remote terminals. Finally, the startup process needs to vary those new terminals online in order for them to accept logons.

DOWNLOADING THE START SYSTEM, DISTRIBUTION TAPES AND JAY'S SUPPORT TOOLS

After I downloaded the various tape files and support tools, I stepped through the process from the very start, as if I had only the tapes and some uninitialized hardware in a data center. I could have worked within the existing turnkey system I had but I decided to begin at step zero for nostalgia. I had worked with MVS systems a long time ago and this walked me through a realistic scenario. 

This begins with standalone utilities to initialize blank disk drives, then restoration of various tape images to create a starter system, in this case MVS 3.7. The system maintenance program SMP needed to be created at the proper level of functionality and there were similar small issues to address, but from that point forward we build up the distribution libraries for all the software functionality.

These many libraries are read from the tape and imported by SMP to create the code base, following which a slew of bug fixes (PTFs) had to be applied. Various catalog entries, files and other content were built, culminating in the point where the system is generated by defining many macros that list devices and options to be handled by our new OS. 

I was well along, having completed the first stage with my macros and was ready to have the customized OS modules placed in the proper locations on the production disks. At this point, I realized something was wrong as the temporary (user) catalog that was created for the sysgen was no longer discoverable by the starter OS. 

I have to either find the existing user catalog (SYS1.VSAM.MASTER.CATALOG) and link it back or recreate that catalog and every single file and PDS that was managed by it. I have a lot of investigating and sorting out to accomplish, so I will call it a night and begin fresh tomorrow.

Building a Hercules version known to work with BSC and the SyncDongle

 WHY NOT JUST USE THE SOFTDEVLAB VERSION OF HERCULES

Mattis Lind, who created the SyncDongle and has tested it with Hercules, has found reliability issues trying to get the SoftDevLab Hyperion version of Hercules to work. The BSC support in that version appears suited for batch remote job entry devices (remote card readers and printers) but less so for terminal connections using BSC.

I therefore believe it better to have a second version of Hercules for the BSC tests, one known to work well with Mattis' solution. I have set up my laptop so that I can swap Hercules versions between the original distribution, SoftDevLab and Spinhawk

FINDING, DOWNLOADING AND TESTING SPINHAWK AS RECOMMENDED BY MATTIS

I did locate and download the code, then successfully built the 64 bit version which I can use with my BSC system. That was exactly as expected, a very pleasant change from my early experience fighting the MS development environment.

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.

Adding in ZLIB and other support functions to Hercules

 FINALLY, SOMETHING EASY AND STRAIGHTFORWARD

All I needed to do was download the three zip files with the binary versions of ZLIB1, BZIP2 and PCRE which are used for functions like compressed disk images and automated console operations. Three environmental variables were added to my system, pointing to the folders containing those utilities, after which a REBUILD seamlessly included them in Hercules.

Although I planned to stop for the evening, this looked easy so I completed the rebuild and moved the files into my turnkey MVS 3.8 area. It was time to validate whether this appeared to work properly.

SUCCESSFUL OPERATION OF MVS 3.8 WITH THE NEW HERCULES

The process of IPLing MVS is pretty simple. A Command Prompt is opened, set to the directory for the MVS 3.8 turnkey system. There is a batch file startmvs.bat that brings up Hercules. I fired up Vista TN, a 3270 terminal emulator and connected to Hercules. The command window showed me a successful connect and the terminal emulator window displayed a Hercules splash screen.

Entering the command ipl 148 is the equivalent of spinning the load unit dials to 148 and pushing the LOAD button on the mainframe console. It fetched the first record on that disk drive, which had been formatted as the system residence volume thus containing boot code at the beginning. 

MVS, in its startup, locates the first ready console, which was the virtual 3270 that I had connected from the terminal emulator. It displayed the MVS startup prompt, to which I replied r 00,CLPA which is a very traditional way to bring up MVS. Messages began flashing on the console and rather quickly, then MVS and its spooling program JES2 were up and running.

It appears I have a fully functional Hercules and can proceed, once the smoke clears a bit and breathing gets healthier outside, to fire up the Cisco router, my 3174 and terminals then attempt to connect them to Hercules. It may be a few days yet so my next steps will focus on building a BSC version of Hercules. 

Done building Hercules for SDLC, readying it for use

BRICK WALL AFTER BRICK WALL, INFINITE LOOP EDITION

The cause ended up being simple. This library is part of the windows SDK beginning with version 6.1 but my VS 2008 install gave me 6.0a that does NOT support 64 bit fully. The solution took a while to sort out. 

When I installed Service Pack 1 onto my VS 2008, I found that it did not give me 6.1 but did enhance things a bit in the SDK. That, however, did not include bcrypt.lib so I had to look elsewhere. Microsoft does not provide older SDK like this one online and I had the hardest time hunting down a copy that I could install. I have to fault the SoftDevLabs build instructions for Hercules on Windows as they do NOT describe this as a pre-requisite but it definitely is. 

I decided to leapfrog to the Windows 10 SDK and install it on my system, then provide the path to VS2008 in the desperate hope that it would allow a build to complete and then have a version of Hercules that works properly. Like all other Windows products, this bloatware took an eternity to install. 

I then had to modify the search path for lib files in VS2008 for my project and try once again. Fail! After searching there is no bcrypt.lib in the Windows 10 SDK. More hunting on the web, where I found a hint that it is instead included in the Windows Driver Kit (WDK). Grrrrrrrr. I located and downloaded WDK 7.1.0 - another heap (860MB) of bloatware chewing up bandwidth, disk space and precious time.

The damned file wasn't there! Recycled that and hunted some more. I found a github project that had the file as part of it, inside its win32 section which probably means that this is the 32 bit not the 64 bit version, but I nonetheless downloaded it and stuck it in the project folder.

I once again tried to point VS 2008 at the library section and complete the build. I got much further but failed with unresolved references to BCryptGenRandom, BCryptOpenAlgorithmProvider and BCryptCloseAlgorithmProvider which are all functions in the bedamned bcrypt.lib file but clearly not in the version I downloaded.

Time to massively capitulate and install an even more bloated product  (2GB or more, more than 320 packages) - VS 2019 Community - in the increasingly desperate hope that I can find a workable bcrypt.lib file for 64 bit code.

More tomfoolery. I try to build the project but immediately receive an alert that I need to install SDK 7.1a first. Another search, another download and install. What fun. Included an iterative error that I needed a new .NET 4 Framework before I could add the SDK before I could use VS2019. Another 137MB of crap. Another delay. 

Found that I had installed the developer framework, but that wasn't what the SDK wanted. It wanted the run time version. Delete, search, download, install. Complains that .NET 4 is installed already. Delete it but still get the error. Reboot f**king windows.

SDK installer fails to work because it sets up an invalid path for install - superficially looks okay but not valid. Overrode it and it still failed to load ANYTHING. I am not the only one to find this Keystone Kops comedic behavior, but the solutions involve things like Registry key overrides after swapping permissions. Can't Microsoft do anything right? Sheesh. 

Once I gave myself ownership and full control to the registry key entries, I modified the .NET framework version to the single value that the SDK installer believes is valid - 4.0.30319 - and then ran the installation successfully. Once done I had to reset the versions to the proper 4.8.03752 version and unwind the permission changes. Still failed to install anything. 

I hunted down the SoftDevLabs web pages where they discussed how to get Hercules to build using VS 2019. They point me to an optional installation feature in VS 2019 that creates the win32.mak file that the older code needs, without having to run the SDK installer at all. Thanks Microsoft. 

In fact, this did install SDK 7.1A although it is labeled as a deprecated support for Windows XP on the VS 2019 installation option list. I find that it has everything I need - bcrypt.lib in both 32 and 64 bit versions, as well as the win32.mak file that nmake needs. I have finally been taught the secret magic spell that solves the problem, I think. 

There are a couple of environmental variables that had to be added and a configuration choice changed in VS2009, but once those are done it is rumored that I can build Hercules at last. The environmental variables were easy, but the two property sheets weren't found. 

I suspect that the compiler somehow wasn't installed, so back to the VS 2019 installer once again. I found a subtle optional feature along the lines of C lang support which was not selected in spite of my having picked the major choice of C++ Desktop Development. I don't see how you can do that without a compiler. Added the compiler in, since it only tied up another 830MB of space and burned 40 minutes.

Still no property sheets. I searched everywhere for them on my disk. Must be another 'optional' feature that I need to select, so back to the installer once again. I never did find those property sheets either by name nor in the directories they specified, but I found a way to update the include path in VS2019 itself. 

I brought up VS 2019 and attempted, yet again, to build Hercules. This time it ran to successful completion. Finally! I I fired it up and verified that it appears to work properly. Now it is time to move it over to work with my MVS 3.8J system. 

REPLACING MY CURRENT HERCULES WITH THIS VERSION

When I downloaded the turnkey MVS 3.8 image it came with a copy of Hercules installed in its folder tree. I had to figure out what to disentangle, store the old version safely elsewhere and put the newly built Hercules in the turnkey folder location. 

I copied the original folder elsewhere, then moved the executable files from my build into the Hercules spot in the MVS 3.8J turnkey site. I fired up Hercules and it seemed to work okay. It was now time to run a more complete test to be sure that I didn't foul up something in the build. 

VERIFYING HERCULES OPERATION USING TERMINAL EMULATOR SOFTWARE

Up came the system, I connected by Vista TN terminal emulator software to Hercules successfully, and attempted an IPL of drive x148 which is the SYSRES volume of MVS. It failed, but for a legitimate reason - the disk volumes are compressed using ZLIB but I didn't configure that into my build. 

Therefore my next task is to build or grab ZLIB, then do a rebuild of Hercules. I will attempt this tomorrow, as I have burned the entire day and more fighting with Visual Studio in its several guises. I consider this a successful stopping point for tonight. 

GOING TO HAVE TO GRAB A VERSION OF HERCULES WITH THE BSC 2703 CODE 

Since I have learned that the SoftDevLabs version of Hercules doesn't work well with the SyncDongle designed by Mattis Lind, I can't use the code I created for the SDLC link. Instead, I have to secure a Hercules image for the BSC link, one whose 2703 emulation code works properly for BSC.

California fires, horrible air quality and terminal workbench outside of my home - not making much progress

 The fires started by the thunderstorms of last week are still quite active in the foothills between me and the pacific ocean. The smoke is blown inland and has made time outdoors challenging since the air quality is very unhealthy. Eyes burn and the sun is a reddish orb for most of the day while the wind comes inland from the water. 

The fires are about 27 miles away from me and shouldn't pose any direct threats to us in Silicon Valley other than the air being worst than Beijing at its worse or the bad old days in Los Angeles before emissions standards were set. 

Since my 3174 and the terminals are not inside the house, I have to go outdoors to spend time working on them. I am not able to spend the time to continue the projects, delaying them until the air clears up.

Looking into the overly dim 3179 monitors

 3179 WITH EXCESSIVELY DIM TUBE

The first color terminal I bought, a 3179, came with the monitor and logic element but was missing a keyboard. When I power it up, I can barely see the dim line and error symbol that declares the keyboard is missing, but only at nighttime when it is dark.

There are a number of reasons this may be so dim, but the most difficult to solve is if the cathode surface is oxidized inside the CRT such that the electron emission rate is very low. However, there may be issues with the voltages on the anode and various grids of the tube, which would be far easier to repair. 

I have schematics for the 3179 so that I know the pins to check and the expected voltages for the various tube elements. The anode is charged to 25,000V, the focus grid is at a max of 8,500V, and grid 2 is at approximately 1,500V. Deflection is done magnetically. The tube actually has one heater but three independent cathodes, one for each of the primary colors. 

The existence of three different cathodes would like mean that once I can generate other colors besides the blue that is displayed sans keyboard, I may find variations in brightness of the three colors. It is unlikely that all three cathodes would oxidize at exactly the same rate, making the likelihood higher that the problem lays in the grid or anode voltages. 

EXPERIENCE WITH SECOND 3179 TUBE

My second 3179 is similarly dim, maybe a bit brighter, and after I hooked it to the logic base and provided a keyboard, I found that all three colors were equally dim. Two tubes in a row, I guess a bit unlikely that the issue is six independent cathodes oxidized but it is certainly possible.

To account for both of these having almost identical characteristics I would need to identify some component(s) that would have failed with age. The monitor is too old to have been afflicted with the 'capacitor plague', where capacitors from the turn of the century had a bad electrolyte formula and widely failed after a few years of operation. 

CHALLENGE - MEASURING EXTREMELY HIGH VOLTAGES 

I have a Vacuum Tube Voltmeter (VTVM) with a long insulated probe for checking high voltages. The meter itself, a Heathkit V7A, can measure DC voltages up to 1.5KV which is far less than the levels I must verify. 

Heathkit V7A VTVM

Fortunately, I also have the companion high voltage probe for this VTVM, which is a long wand of plastic and has internal resistance that divides the voltage being measured by 100. That means that the 25KV anode voltage will read 250V on the meter. 

High voltage probe

Fighting to compile SDL Hercules

ATTEMPTING RESOLUTION OF THE ISSUES COMPILING HERCULES

Out of desperation, I decided to remove Visual Studio and reinstall it, without applying the service pack afterwards. I had originally believed that my problems stemmed from the lack of the SP, but it might have contributed to the odd issues I faced.

1. The Hyperion build files use an option that doesn't exist in Visual Studio 2008 in spite of the readme file instructing me to buy this. 
2. Some step that should fill in the version parameters before invoking the build process is not taking place, or failing, because I end up with empty or malformed parameters that cause the compilation to terminate.
3. Using another of the routes suggested in the Hyperion readme file causes my VS 2008 system to try to run the x64 compiler which tries in vain to open bcrypt.dll. I searched my system and found it inside system32 but the compiler wasn't finding it.

Long long process to remove since VS 2008 installs dozens of components individually, but eventually I had it cleaned up and then installed again. I then ran into problem #2 again. After digging through dozens of makefile files and related objects, I saw that the version information is build by a windows script _dynamic_version.cmd but that didn't seem to be invoked properly by the nmake process. I ran it myself and then the data was available to complete those version flags properly.

Now, when the makefile is attempting to link code, it looks for but can't open bcrypt.lib causing a fatal error. I will have to dig through all the files again to see where and how this is requested. It isn't installed anywhere on my laptop. 

I decided to try to build the 32 bit version instead, hoping that would be more successful. It was up to a point, compiling and linking until it failed as it couldn't find legacy_stdio_definitions.lib file.

Various internet hints suggested that I add this to the dependencies, so I first had to search for the file to be sure I knew where it was and how to get it included. Some web postings suggest that it was added in VS 2015 so it definitely shouldn't be requested and it isn't on my system.

I am essentially stuck with either bcrypt.lib or legacy_stdio_definitions.lib errors. I have tried every version that SDL describes for building this (nmake commands, VS solution file or makefile.bat execution), but can't get through a build. 

If I did development on Windows and was familiar with VS I might know how to proceed, but at this point I have to set it aside and see if I can find an alternate route to building Hercules with the 3705 SDLC modifications.

Images from IBM 3179 terminal in operation

 

Putting 3179 in online test mode

Test menu brought up by PF12

Test 0 to verify basic terminal functionality

Comparing to 3178 green screen terminal

Terminal built-in hardware test (colors shifted by camera)

Building the cable and preparing to test the SDLC link from 3174 to Hercules via SDLC

CHECKING MY SDLC VERSION OF THE 3174 CONTROL DISKETTE 

I did an IML of the controller with the new Control diskette configured for SDLC, using the EIA cable with the switches set to TEST for wrap of the RS232 signals. It did boot up giving me two status messages. 

Initially it reported 501 status with a sub status of 0111. This says that SDLC is waiting for a host (mainframe) to connect to it. After a short while, I got the 532 on the operator panel and on the status line of the terminal, with a sub status of 0311. This is a timeout of the SDLC link to the remote end, appropriate because we have a wrap of signals and not an actual device on the far end of the cable.

BUILDING THE CABLE

I took the loop cable I bought, which has Smart Serial plugs on both end, one wired as DTE and the other as DCE, then cut it in the middle. I now have a DCE and a DTE cable with individual wires at the other ends. The connectors are internally wired to define the type of serial protocol and whether it is DTE or DCE, so I just had to select the correct side. 

The Smart Serial cables tell the Cisco router the type of connection they are making by grounding certain pins, the pattern encoding which kind of serial connection and whether this is acting as DTE or DCE. In my case, pins 22 and 23 were connected to pin 26 in the cable, thus asserting this as an EIA DCE link. 

Beeping out the wires gave me the wire color of each active pin from the Smart Serial end - then I soldered it to the DB25 pin that corresponds to that signal. The result is the same as the Cisco cable CAB-SS-232FC which provides EIA (RS232) as DCE to connect to the cable from the 3174 which is EIA DTE. 

Test cable based on diagrams

I did some verification testing of the connector wiring and found a non-obvious short. There appeared to be an air gap between the adjacent pins but the multimeter insisted that electrons flowed between them. I took a picture and zoomed in closely, where I observed some wire whiskers that formed a wee jumper between the pins. Each enough to cut away so the connector wiring is correct. 

Cross jumper formed by wire whiskers

CHALLENGES GETTING THE 2811 ROUTER CONFIGURED AND CONTROLLABLE

The eBay seller from whom I bought my 2811 router provides a CF card with all the key configurations and software needed by students working on their Cisco networking certifications, however they failed to clear the nonvolatile ram image before sending the box to me.

This means that the box was still configured for its role doing IP telephony at a bank, along with all the passwords still set but not disclosed to me. I have no experience doing Cisco administration nor using the command line interface to manage such a box, but had to learn quickly. 

I figured out how to bypass the passwords then replace them all - after five or six partial attempts that still left the box unable to be fully managed.  I turned off a number of functions that had been used by the prior owner before setting up the DLSw and Serial interface settings. 

Building Hercules with the DLSw 3705 and BSC 2703 modifications

 GETTING SOURCE CODE FOR MODIFIED HERCULES

Matt Burk set up a fork of the Hercules SoftDevLabs code base which included his modification to the 3705 comm controller emulation to provide a socket that acts like a DLSw router, allowing me to connect from the Cisco 2811 that is attached to my IBM 3174. 

I cloned this on my desktop and did some investigating to see if it included the BSC socket in the 2703 comm controller emulation that is used by Mattis Lind's SyncDongle via the socat filter. If not, it would be necessary to retrieve any modifications made by Mattis and back fit them into this Hercules distribution.

The good news is that there are no code changes to Hercules, only configuration file adjustments and some changes to the MVS TCAM system. That means that this version of Hercules will support both BSC and SDLC connection to my terminals attached to my IBM 3174. 

BUILDING THE CODE - NEED VISUAL STUDIO 2008

The instructions and setup to build Hercules from the code I cloned requires Microsoft Visual Studio 2008. Although the Readme file asserts that you can use a free 45 day trial download, I couldn't find any evidence that Microsoft now allows download of this old and unsupported product.

Fortunately, I found a decent deal with a reseller and have an official copy of Visual Studio 2008 Professional that I will use. What I received was an ISO image to burn to DVD - but I couldn't locate my USB DVD drive anywhere. I thought I had to order another and wait a day before I could burn the DVD image to begin the install. 

However, I discovered that I can virtually mount the ISO image, just like in MacOS, so that I could run the setup without needing a physical DVD. The process ran smoothly and I soon has VS 2008 Pro installed on my laptop. 

MAKING THE HERCULES BINARIES

Overall it should be a straightforward matter of issuing nmake commands through a command line interface and letting VS 2008 do its thing. That didn't turn out to be the case.

Minor hiccups. 

I did the nmake and on the first compile, I was given a fatal error:

        Rc /r /nologo /D _MSVC_ /D MAX_CPU_ENGINES=8 -D VERSION=\"\" -D VERS_MAJ= -D VERS_INT= -D VERS_MIN= -D VERS_BLD= -DWIN32 -D_WIN32 -DWINVER=0x0600  -fo msvc.dllmod.obj\hercprod.res hercprod.rc

fatal error RC1106: invalid option: -ologo

I found some web dialog that makes it seem like this option, nologo, was added to 2008 and is probably in the service pack 1 that I haven't yet applied. Instead, the RC.exe sees this as the /n option about newline characters and then some random option text 'ologo'. I headed off to update VS 2008 before I tried again. That involved a 831 MB download from MS of another ISO image.

Sadly, that didn't correct this. The makefiles have the false option /nologo, which I had to remove. I then hit the next error in what I now expect to be a long chain of incompatibilities and errors.

        Rc /r /D _MSVC_ /D MAX_CPU_ENGINES=8 -D VERSION=\"\" -D VERS_MAJ= -D VERS_INT= -D VERS_MIN= -D VERS_BLD= -DWIN32 -D_WIN32 -DWINVER=0x0600  -fo msvc.dllmod.obj\hercprod.res hercprod.rc

hercver.rc2(45) : error RC2127 : version WORDs separated by commas expected

The substitutions to show the versions is going wrong. I decided to end this method suggested in the readme.md file (the command line method) and moved to method 2, using the solution file from VS 2008 itself.

I then discovered that my installation of VS 2008 didn't bother to include x64 support, only 32 bit support, so I had to go back and update it. I then loaded the solution file, set it to x64 and release, starting the build. Next problem - couldn't open bcrypt.dll - which is some other kind of configuration or pre-requisite issue with my VS 2008 environment. 

Nothing obvious is found with various Google searches, so this is going to take a bit of investigation before I can figure out what failed to install the DLL. My working guess is that this comes with the .NET prerequisite that was installed as part of my VS 2008 product. I will table this effort while I do some research. 

Keyboard arrives and my 3179 color terminal is working!

 EBAY KEYBOARD ARRIVES TODAY, GETS PLUGGED IN, AND TERMINAL WORKS

A fellow hobbyist, Guy Sotomayor, gave me the product number of a keyboard that he successfully uses with his 3179 terminals. I found one on eBay and it arrived today. It was in good condition and ready to be hooked up. I plugged the round DIN connector into the logic element and powered on my terminal.

Without the keyboard, the terminal would stop partway through initialization and give an error 3 that indicated the keyboard was not working. With this connected it sailed through startup and went into test mode. It is still pretty dim, a bit brighter than the first one I bought, but I can see the image (barely) even in sunlight. 

DOING ONLINE TESTS WITH THIS HOOKED TO MY 3174 CONTROLLER

I routed a cable between my 3174 controller and the terminal, then IMLed the controller. It saw the terminal just fine and I was able to hit the ALT-TEST key combination to start up the online tests, then using the PA2 key I saw the main menu light up. Finally, I requested test 0, which puts some test text on the screen to allow basic functional verification. All is good!

Setting up my DLSw link with a Cisco 2811 router and the IBM 3174 controller

 ROUTER ARRIVED AND INSPECTED

The Cisco 2811 router arrived on Friday, a refurbished unit I bought on eBay. It seems that units like this come with a set of configurations and software that allow the user to work through the Cisco networking certifications. 

I, on the other hand, only want this to speak synchronous serial to the IBM 3174 and encapsulate SDLC from that link so that it can be routed over TCP/IP. The Hercules mainframe emulator has a 3705 communications controller emulation that implements DLSw with a TCP/IP socket on the PC running the mainframe software. 

I had separately purchased a serial interface module (WIC-2T) that I installed in a slot on the rear of the 2811 router. This has a compact 26 pin connector (two actually, since it hosts up to two serial links) into which I would plug a Cisco Smart Serial cable. 

The router appeared to be in good condition and it started up reasonably, booting from the CF card onboard and eventually going into its active and ready state. Since I hadn't hooked up to the console port, I had no way to check the condition beyond the evidence of the green color on the System indicator LED. 

I found that I needed to communicate to an RJ45 serial port at 9600 baud to use the console port, but didn't have the right kind of adapters on hand. I thus had to order an RJ45 to USB serial cable through Amazon for arrival on Saturday.

CONFIGURATION CABLE ARRIVED AND SETUP BEGINS

Plugging in the serial USB cable to my laptop and the other end to the router, I opened a terminal program on the laptop and powered on my router. The console demanded a username and password, but didn't accept the defaults for these routers. The seller did not provide any note with the credentials either.

There is a set of procedures to recover the password (actually to set a new one since the old is encrypted). The first didn't work but the second, involving removal of the configuration Compact Flash (CF) card and some commands reset the box, let me reinsert the CF to copy its configuration file while I had supervisor level access, then define the username and password I wanted. 

After that procedure and a reboot, I received a command prompt from the router, at which point I could begin to configure the DLSw for the SDLC line. I checked over the status and hardware elements of the box - it did see my two serial links from the module I added in, as well as the core hardware and adequate RAM. 

I had to configure the ethernet port as a private address range (e.g. starting with 192.168) with a fixed IP address that would allow me to connect to another fixed address on the PC running Hercules, the mainframe emulator.

I set up the configuration along the lines of this example from Matt Burk's DLSw page on 9track.net 

dlsw local-peer peer-id 192.168.0.95    ! Local interface for DLSw
                                        !
dlsw remote-peer 0 tcp 192.168.0.44     ! Remote system running Hercules
                                        !
interface FastEthernet0/0               ! Ethernet interface to Hercules
 ip address 192.168.0.95 255.255.255.0
                                        !
interface Serial0/0/0                   ! Serial interface to SDLC target
 encapsulation sdlc
 clock rate 64000                       ! 64 Kbit/s baud rate
 sdlc role primary                      ! Router is primary SDLC device
 sdlc vmac 4000.0999.0100               ! Virtual MAC address associated with
                                        !   the SDLC target. This is an
                                        !   arbitrary value but the last two
                                        !   digits should be 00
 sdlc address C1                        ! SDLC addess of SDLC target
                                        !   on the serial link
 sdlc xid C1 01700018                   ! XID to report to DLSw peers for
                                        !   the SDLC target
 sdlc partner 4000.1020.1000 C1         ! The MAC address of the remote SDLC
                                        !   partner (within Hercules).
                                        !   Currently this is unused so any
                                        !   value can be input however it
                                        !   may be used for selecting between
                                        !   NCPs in the future
 sdlc dlsw C1    

Essentially this is defining the serial interface number 0 as a link carrying SDLC from the 3174, which is wrapped in DLSw and routed over TCP/IP to the IP address and port of the Hercules instance on my laptop. Hercules, via its 3705 controller emulation and some code added by Matt, will strip off the DLSw and deliver the SDLC into the mainframe to MVS.  

WIRING THE CABLE BETWEEN THE ROUTER AND THE 3174

The cable I bought had Smart Serial plugs on both ends, but what I need is to connect Smart Serial to a female DB25 with the right signals on appropriate pins to communicate with my 3174. I do have documentation of the signals that must be routed to the various DB25 pins and the location on the Smart Serial cable for each of those. 

Thus, I cut the cable in half, giving me two cables with a Smart Serial plug on one side. I have several DB25 female connectors thus I will be able to create the cable I need fairly easily. Using a multimeter I determined the purpose of each wire in the cable and soldered them as needed to the DB25 connector.

CONFIGURING THE 3174 FOR SDLC

First I had to configure my 3174 controller for SDLC. It is currently configured for BSC protocol, but I can create a second Control diskette and using the Utility diskette, set it up as needed. I have no prior experience with administering VTAM/SDLC so I had to fumble around a bit to figure this out. Actually, I have no Cisco router administration experience either, doubling the fun or learning experience of this project.

Working through the planning guide and configuration worksheets, plus the Hercules side definition of the controller, I put together the options I believe are correct. After copying the Control diskette, I did a customize on the new Control image to implement the SDLC parameters.  Now I can choose the Control diskette to use the 3174 with either SDLC via the router or BSC through Mattis Lind's SyncDongle. 

Adjusting the repaired 3178 terminal monitor - now have three viewable monochrome monitors

 SCREEN FACE COATED WITH GUNK

The glass covering of the CRT face was dirty, with a layer of grime that made the image even worse. I used soap, water and alcohol wipes until I had it clean. That contributed to a better image but still not bright enough.

OBSERVED THAT VERTICAL RANGE WAS NOT ADJUSTED PROPERLY

In the images from the last post you can see that the height of the image is compressed, the top line should be higher on the tube face and the bottom status line closer to the bottom edge. That can contribute to character legibility problems.

I found the vertical height adjustment potentiometer and rotated it until the image was properly sized. I was pleased with the results.

WORK ON FOCUS ISSUE

There are two potentiometers on the board that adjust the focus - a larger main focus pot and a small 'dynamic focus' trimmer. Rotating the main pot to either end had very little effect on the image, which led me to check the resistance readings of this pot. It seems fine and the image is marginally better at one extreme. 

The dynamic focus circuit compensates for differences in beam distance at edges versus the center; since I don't see any discernable difference in focus across the tube face, I declare this pot to be set correctly. 

There is a potentiometer labeled Sub-Bright that is in line with the brightness control and seems to limit current flow. I cranked this fully out of circuit and saw a bit of green glow across the entire screen, but with just a tiny rotation back it gave me acceptably bright images. 

If I had a schematic with voltages noted, I could check the correctness of all the HV for the various grids and anode. Since I don't, all I know is that a sticker declares the anode to be at 14KV. I could at least check that voltage. If the anode is too low it would affect tube brightness and potentially focus. 

Some internet posts suggested that this monitor is identical to the IBM 5151 used with the original 5150 PC. The circuit is similar but the parts numbers differ enough that it can't be used directly. It does show me the voltages to expect at various points related to the CRT pins, which is enough for me to do some voltage tests.  

I checked the ends of the Focus pot and saw about 600V on one end and about 100V on the other - this is reasonable given the types of focus voltage that a CRT like this would receive. If it were easy I would test the anode voltage, given as 13.2KV in the 5151 schematic and 14K listed inside the monitor, but the anode connection has a rubber cap that I can't slip the probe underneath. 

Methods exist to deal with the cap, but since the adjustment of the Sub Bright pot, the display is the equal of my best 3178. I applied the same adjustment to the remaining 3178, thus I have three monitors at about the same (acceptable) brightness. 

ALMOST THREE COMPLETE WORKING 3178 TERMINALS

I have three keyboards and three monitors, but only two logic elements (the base that connects the other parts and the 3174 controller.) If I ever needed to complete the third, logic elements can be had for about $50 including shipping. At the present, my supply of two fully functional 3178 and the soon to be working 3179 exceeds my known requirements. I don't feel the need to buy another keyboard for my second 3179 nor a logic element for the third 3178. 

Terminal monitor electrical inspection and repair work

 3178 WITH MISSING CAP, NO VERTICAL DEFLECTION

I originally received three 3178 terminals, each with its monitor, keyboard and logic element. Number one is in service now with a decent brightness, number two is quite dim but works and the third had no vertical deflection. In that last monitor I found an electrolytic capacitor that had committed suicide and part of the PCB trace connected to it was damaged.

I bought a replacement capacitor and opened the monitor to make the repair. I used jumper wire to bridge the bad traces. The reason I am doing this is because the trace is acceptably bright, unlike the very dim terminal number two that is otherwise functional. I had a good monitor PCB to compare to be sure I repaired the burned trace properly.

Reference board

Board with damaged trace

I installed the new capacitor and a bridge wire to restore continuity for the circuit. 

Repair made

I then fired up the monitor to compare it to terminal One that works well. The good news is that I restored the vertical deflection. However, the image looks terrible. I suspect that I have to adjust focus and do a bit of cleaning in the hope that this will sharpen up acceptably.

Monitor with replaced cap and repair

Good monitor for reference

Will download the manual for adjustments and see whether I can get a decent image or this terminal goes on the recycle list.