As you've probably put together by now, a program can invoke many subroutines or subprograms. Some of those subprograms will use dynamic linkage through the supervisor routines in the operating system. Linkage is simply the techniques required to make separate pieces of code all work together. The four supervisor routines involved are LINK, LOAD, ATTACH, and XCTL, that's transfer control. I know I had to look it up to. These names are also the names of the assembler macro instructions which are used for such dynamic linkage. In this visual here, the word find means more than just search. It means including the building control blocks which describe the program. If the program is not already in storage, it will be loaded into storage. When the system goes to find a program for you, the search order is incredibly important. First, it's going to look in the places where you keep your programs, and that starts in your address space, then in your library, that's job live and step live. Then it will look in the system program starting with programs already in storage, that's LPA and ELPA, and then in the system libraries, mainly LINKLST. This area gets deep, like way deeper than you want to hear me try and explain. LINKLST is definitely something you'll be looking into in greater depth after this video. I know I keep saying that, but more on that later on. One more concept I want to make sure you're aware of, AMODE and RMODE. I'm doing my best not to talk about the olden days, but z/Architecture addressing is 64 bits today. It used to be 31 bits, and before that it was 24 bits. As you may have heard, backwards compatibility is a big deal. There needs to be a way to indicate just what type of memory addressing we're talking about. You'll hear references to the line, which is the limit of 24-bit addressing, 16 megabytes. Then you'll hear references to the bar, which is the limit of 31-bit addressing, which happens at two gigabytes. AMODE refers to the addressing mode, A stands for addressing, which indicates which hardware addressing mode is active when a program executes. Those addressing modes are 24-bit, 31-bit, ANY meaning 24 or 31-bit, 64 meaning just 64, and MIN request that the binder assign an AMODE value to the program module and it will select the most restrictive AMODE of all control section. You assign a residence mode or RMODE, the R stands for residence, to specify where the modules must be loaded in virtual storage. Program modules must be addressable using 131-bit address. They cannot be loaded beyond the two gigabyte bar or in an address space. Those residence modes are 24, that's 24-bit addressable virtual storage or 16 megabytes, ANY, where it can be anywhere above or below the 16 megabyte virtual storage line. Split, which means the module is split into two class segments, one below and one above, and RMODE 64 is treated as RMODE ANY for module loading and execution with the exception of data class CWSA64, which can be loaded above the two gigabyte bar. Presented one more way PSW bit 12 is always set to one in ESA mode. In z/Architecture mode, it's always set to 0, the PSW bits 31 and 32 describe the addressing mode. Moving forward once more, let's talk about serializing resources. Hey, look, it's that chart again. What is serialization? There's a lot of work happening on an IBM Z system, and a lot of resources to make sure that happens. There's a lot of orchestration involved in making sure that the resources get to the applications that need them. You can imagine in the case of something like this, I'm assuming a banking application, there's a lot of actions which might want to work on this data. Serialization isn't something you just turn on or enable, it's a concept that needs to be done and done correctly. Now, these are some of the functions used to manage access to resources. Many of these are reserved for system code and some authorized programs. But they're listed here for your reference. ENQ, DEQ, that's E-N-Q, D-E-Q, it's clever, is the only standard user interface. Those are also used by system components, but locks are used extensively in z/OS to serialize system control blocks. The latch manager functions are callable service for all high level languages. Even if you can't get in at a lower level, the latch manager functions are certainly something that can be of use. Serialization doesn't get much bigger than GRS, that's global resource serialization. GRS is a z/OS component which provides the serialization for access to resources. It is required in a cyst plex, even if another product is used for resource serialization. It works by communicating between all systems in the GRS complex. It gets invoked through the ENQ, DEQ, and RESERVE macros. Those ENQ, DEQ functions are used by the system every time a job is run, they get triggered by the DD statements. This is what lets multiple systems operate in a cyst plex environment without constantly stepping on each other's toes. The way this works is whenever GRS detects a resource is being requested for use, it scans the RNL or the resource name list. For the resource and the scope, entries in an RNL can be specified or they can spell out the resource by partial name or by pattern. There are different scopes and modification actions which can be spelled out in the RNL. If you think about application development and what a hassle it can be to get multiple instances of an application sharing storage without causing timeouts or data integrity issues, the ability to control access and usage at this level is really something special. You can see why it's a core part of the z/Architecture. In our next section, we'll talk about SVCs and program authorization.