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. 

Restored floppy drive, made diskette copies of my images, IMLed the 3174 from floppy

 RESTORING THE 1.2MB 5.25" FLOPPY DRIVE FROM MY 3174

The Hitachi floppy drive used in my 3174 controller is installed in a plastic enclosure that in turn is bolted into the drive frame in the controller. I removed the drive, then opened up the enclosure to remove the drive mechanism.

Hitachi 1.2MB drive in IBM plastic enclosure

I carefully inspected the mechanism and the PCBs for signs of wear or damage. I applied +5 and +12V carefully to check for issues with the power supply, regulators or other circuitry. Everything looked good. I next used alcohol wipes to carefully clean the heads, as well as verifying smooth movement of the head assembly from track 00 to 79. 

Bottom of the drive

Top of the drive mechanism

At this point I checked for correct operation when a diskette was inserted - permitting the lever to rotate and pushing the drive clamp and heads onto the magnetic surface. That too worked well so it was time to place the mechanism in the plastic enclosure and mount that back into the 3174

Testing the mechanism with media inserted

BUYING APPROPRIATE MEDIA FOR THE DRIVE

The 1.2MB drives require a specific floppy media - double sided high density - in order to achieve the data density. I found some New-Old-Stock (NOS) media on eBay and had it ready to write diskette images onto. 

Polaroid NOS media

USING UTILITIES TO COPY THE GOTEK IMAGE TO THE PHYSICAL DRIVE

I had the real floppy drive cabled into the drive 1 position and one of the Gotek emulators cabled as drive 2. I set the Gotek to mount the Utility diskette image and IMLed from drive 2. This gave me the utilities menu.

Choice 3 is the Copy utility, which supports a range of copy activities include a fully disk to disk copy which is what I wanted. It will format a diskette as it writes, so no prep was needed for my new media. I told it to copy from drive 2 to drive 1, changed the Gotek to mount the Control image and let it rip.

The copy utility started at track 79 and worked its way down to 00 rather quickly and silently. In the picture above you can see the Gotek LCD peeking out in the upper slot, where it showed the track being accessed. The physical drive is lit as it has just read a track from the Gotek and was writing its contents to the same track number on the new media.

Copy utility doing full copy, currently on track 62

TESTING IML FROM THE FLOPPY DRIVE

After having copied the Control diskette image to one of my new floppies, I started a new copy and wrote the Utility diskette image to a second floppy. These sit in the tray on the controller in between the positions for floppy drives 1 and 2. 

I hit the IML button on the controller, which causes it to attempt to IML from images starting with drive 1, then drive 2, then the hard drive if it exists. Since the Control floppy was mounted in drive 1, that began reading and the controller completed its boot sequence and self tests, ending about two and a quarter minutes after it began with the magic status number 3174 displayed on the front panel.

This is a video of the 3174 doing an IML from the floppy, continuing through all its configuration and self test before it becomes fully operational, which is indicated by the code 3174 displayed on the front operator panel. You can see a 3178 terminal attached to the controller running the online test here. 

Terminal miscellany

 NEW 3179 TERMINAL ARRIVED

My first 3179 terminal is so extremely dim that I have to sit outside at night in the darkness to see the image. I hope to rejuvenate the CRT to increase its brightness, but I found another 3179 monitor which arrived yesterday. It is indeed brighter - both it and my best 3178 are hard to read in sunlight but in normal room light the 3179, like the 3178, should be suitable. 

KEYBOARD FOR 3179 ORDERED

My two 3179 terminals came without keyboards. The logic element checks for the keyboard and won't complete its initialization, therefore I can't work with the terminal until I have a keyboard attached. The part numbers listed in the manuals are very hard to find but a fellow hobbyist, Guy Sotomayor, has working 3179 terminals that he equipped with keyboards originally used with different terminal types.

Guy shared the part numbers of the keyboards he has successfully used, which allowed me to find one on eBay yesterday. I bought the keyboard and am awaiting its arrival so that I can bring up the terminal fully and test it out.

BALUNS TO REPLACE COAX WITH ETHERNET CABLES

The cabling between the terminals and the 3174 controller are coaxial with 93 ohm impedance. An alternative was developed to make use of twisted pair Ethernet cables between terminals and the controller. I was given several pairs and tested out one pair successfully. This will allow me to connect multiple terminals without having to buy 93 ohm coax cables.

The coaxial cable has an active center lead surrounding by an insulator and an outer cylinder of conducting shield. The shield is connected to ground while the signal travels on the one inner conductor. These are unbalanced transmission lines.

Twisted pair makes use of differential signal, which helps reject induced noise because the spurious signal injected on one wire of the pair is almost completely counterbalanced by a reverse direction signal on the other wire. Therefore twisted pair are balanced transmission lines. 

The devices I have are Baluns, an adapter that converts between unbalanced and balanced transmission lines. One side has a coax connector, which is installed on the terminal or 3174 controller. The other side is an RJ-45 jack where the ethernet cable is inserted. 

Starting to put together the BSC approach based on Mattis Lind's SyncDongle

THE SYNCDONGLE

This PCB converts synchronous serial messages in IBM's Binary Synchronous Communications protocol, routing the messages over a normal async serial line. It allows connection to the IBM 3174 adapter in BSC mode, but doesn't require the other side to have to deal with all complications of sync serial mode and the BSC protocol. 

 ORDERED PCB AND COMPONENTS TO BUILD A SYNCDONGLE

KiCad design for PCB

I opened the KiCad design files, produced the Gerber and drill files, then sent them off to JLCPCB.com to build five of them for $2 after which I splurged on express shipment. Mouser.com had the various components to mount on the board except for the STM32 Blue Pill board which I bought from Amazon.com

Mattis' picture of bare PCB and assembled board

I began reading Mattis' code that runs in the Blue Pill, called BSCbridge, when I realized that he worked out a very clever way to use the processor to handle sync serial without the start bits that are normally required to achieve character framing. He uses an SPI link and interrupts to receive an undifferentiated stream of clocked bits, which he can frame based on receipt of SYN characters. Very clever idea, wished it had occurred to me. 

He coded an Arduino sketch for the main routine that establishes the SPI link (and the normal serial link), then added some C++ library routines to handle framing, buffers and other protocol details. Since this board runs a 72Mhz ARM Cortex processor it definitely can keep up with reasonable speed BSC links.