AS/400: Libraries

2022/02/05

This is post no. 76 for Kev Quirk's #100DaysToOffload challenge. The point is to write many things, not to write good ones. Please adjust quality expectations accordingly :)

As mentioned in our intro post, AS/400 systems have a lot of weird things that seem impressively pointless on first sight. Just to start with one:

there are files. They're grouped in libraries. But: you can't put libraries in other libraries.

a library with some files in it

... like, seriously??? haven't we invented directory trees in, like, the 70s? UNIX had them pretty much right away?

It does makes sense though!

There is this thing called the library list, for each running job.

as/400 screen with a list of libraries to search

It works like $PATH for UNIX systems (... or, for that matter, the schema search path for Postgres): if you refer to a file without any other paths added, the system will try finding it in the order specified in the library list. However, it works not just for binaries to run but also database tables! (... which files are fairly similar to on AS/400).

So... you can just replace the production tables with test ones for when you're testing code, without any additional configuration on the code side; it'll just find the right table right away. Likewise, you can add your own binaries to the system and use those by default, without affecting anyone else on the system (... the latter might be familiar from UNIX though).

Some more weirdness with files

... actually, there is one more level, sometimes. On AS/400, files can have members, which... are... um... well, for source files, your actual source files are the members, not the file itself. So that's one more level of hierarchy for you.

Overall though... apparently, it's possible to get away without a lot of hierarchy for an entire OS.

Do we need trees?

It's somewhat interesting though to think about how much hierarchy we really need. After all, even on UNIX systems, once you get down to 4-5 levels, things start getting really messy. Also, the one thing I remember as a cautionary example is Visual Studio's "c:\Program Files\Microsoft\Visual Studio\versions\9.0\Contents\Compiler\9.0\Bin\" (most of the example was just made up, but... it does have some pointlessly nested directories in there). Do we really need all of this?

AS/400 seems to take the opposite approach: just specify a couple of levels that you can use as, basically, namespaces, and make everything a lot more flat. Maybe... if you're using the file system as a database... you can also use an actual database instead?

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.