Recently, I've been struck with the crisis that all software developers get bit with at some point in their career where they long to work with their hands. For me, this desire manifested itself as a desire to build things with wood. The challenge of this is that I live in a relatively small 2 BR apartment in Brooklyn, NY, which means I barely have enough space to live, much less to create life-size pieces of furniture.

While researching, I had stumbled upon some other fine woodworkers, like this gentleman, who seems to have built a presence woodworking in their apartment; however, even their setup seems far more elaborate than anything I could reasonably have access to. Alternatively, I had the option of using a shared Makerspace, like Makeville, but their membership, which seemed on the affordable side, still seems excessive for an already steeply priced hobby.

Basically, I concluded that the best way to learn woodworking would be to do it at my apartment (which I luckily have roof access to). I prefer to spend my money on tools and supplies rather than lessons in an attempt to save as much as I can. Also, since so many woodworkers generously put free lessons on YouTube, I didn't feel like I was missing out on all too much. I was also gifted a set of Japanese ryoba saws and chisels which further lessened the barrier of entry for this expensive, expensive hobby.

I basically settled on a set of constraints for apartment woodworking that I feel are reasonable (in no real order):

1. Minimal noise. I want to be a good neighbor! Sadly, this means, no hammering (which by extension limits my ability to chisel).
2. No fine wood dust. My understanding is that without good airflow or a shop vaccuum, fine wood dust is quite dangerous for your health. If I do need to do something that produces fine wood dust, like sanding, I have the option of using my roof to minimize the amount that gets dispersed indoors.
3. No big power tools. I simply don't have the space, and they produce too much fine dust to safely use in a living space.
4. Buy wood cut-to-size. There are a few places around me that are accessible by public transit that will cut wood to size. Unfortunately, they aren't extremely precise, but they seemed fine for my first big project (a medium-sized workbench). I also know a good place in Sunset Park that only cuts plywood that is extremely precise. If I can minimize the amount of cutting I need to do myself, it will save me from the mess at home. Plus, big 8' pieces of lumber are just hard to transport without a car!

With those constraints in mind, it's not an exaggeration to say that I am severly limited in what I can and can't do. But, I'm hoping that those limitations can be overcome with a little bit creativity! This blog will document my journey (among other things) with figuring out my way around woodworking in a small NYC apartment. I don't think I'll produce fine-woodworking quality stuff, but it will be fine (in the other sense of the word).

Increasingly, I've been working with legacy systems that are dependent on COBOL. One major thing that a large organization like CMS is trying to do is migrate a decades old systems into the Cloud. Being a part of an undertaking like this unfortunately requires being able to read and understand some COBOL.

From my research, it seems like CMS has experimented with a few different approaches to begin this migration. Probably the most ambitious one seems to have been an effort to translate their decades old codebase from COBOL to Java. Unsurprisingly, a one-size-fits-all approach like this just doesn't work (and it didn't). The largest flaw was that it seemed like there were some minute differences from doing calculations with high-precision floats that ended up compounding downstream. These differences were ultimately caused by foundational differences in how Java and COBOL store highly-precise numeric values.

Of course, there are other issues with doing a simple COBOL to Java conversion. The primary one is that converting a codebase from one language to another does not promise to change the STRUCTURE of that codebase. You ultimately just end up with another codebase that inherits the same bugs, quirks, and issues with maintainability as the old one. IMO, this effort was doomed to fail.

I am not suggesting that I have a better solution, but a clear learning from this is that you can't simply wave a wand and end up with a shiny new modern codebase. One approach that I would like to experiment with is combining GnuCOBOL and FFIs (Foreign Function Interfaces) to create a programming layer between COBOL and a modern programming language (ideally Rust). GnuCOBOL is able to compile a COBOL program to a C library that can be linked to, and most applications offer FFIs to interface with C.

Once a reliable layer exists, you can create connective tissue to restructure the legacy codebase and eventually just replace the FFI components with new reimplementations. Of course, I'm making this sound far easier than it is. Ultimately. this process requires a deep understanding of how disparate parts of the legacy code relate to one another. This is an extremely daunting task given the fact that these systems have been developed across decades, by developers who undoubtedly had varying perspectives about how to manage complex systems.

Alas, all programming journies begin with "Hello World", so let's try just that!

Let's say I have this COBOL program:

IDENTIFICATION DIVISION.
PROGRAM-ID.    TESTCOBC.
AUTHOR.        Ferris Tseng.

ENVIRONMENT DIVISION.

DATA DIVISION.

LINKAGE SECTION.
01 L-FNAME PIC X(10).

PROCEDURE DIVISION USING L-FNAME.
    DISPLAY 'Hello World! Hello 'L-FNAME.
    GOBACK.

So, what's going on here?

A COBOL application is structured into a series of divisions, each with a distinct purpose. The first, the IDENTIFICATION DIVISION simply stores some metadata about the program, like an application name and author. The ENVIRONMENT DIVISION stores some info about the environment the application is running on. The DATA DIVISION stores, well data like local variables, and the PROCEDURE DIVSION stores instructions.

Some important things to call out:

1. The LINKAGE SECTION declares inputs into the program, so for this application, we have one alphanumeric string with 10 bytes. When compiling this to C, GNUCobol creates an entrypoint function with 1 argument.
2. The end of the PROCEDURE DIVISION has a GOBACK. directive which transfers control back to the parent (kind of like a return).

Then, you can compile it to some C source files:

$ cobc -C -o out/test.c test.cob

Then, calling it from C is as easy as importing it and initializing the COBOL runtime!

#include "out/test.c"
#include <libcob.h>
#include <stdio.h>

int main(void) {
  cob_init(0, NULL);

  printf("Hello World from C!\n");
  TESTCOBC("SHEN NONG ");
  printf("After\n");

  cob_stop_run(0);
}

$ cobc -x testc.c -o out/main && ./out/main
Hello World from C!
Hello World! Hello SHEN NONG
After

Welcome to my new blog! I've blogged before (without much consistency), but with the collapse of Reddit and Twitter, I guess it feels right to try this again. In the interest of "owning" my data, I'm keeping this stuff off of a platform like Blogger or Tumblr. So, what are you going to find here? Some personal stuff, some technical stuff, project updates, recipes, reviews, etc. Feel free to shoot me an email at ferristseng(at)fastmail.com if you have any comments.