Hi there. It's me again. In this course, we're going to take a closer look at some system programmer concepts. What's a system programmer? I'm so glad you asked. That's exactly what we're going to cover here. The role of a system programmer basically comes down to describing the person who installs, customizes, and maintains the operating system. Now, in reality, it's a bit more fuzzy than that. Your typical system programmer or SysProg, became SysProg by having a whole lot of experiences in a number of areas all around the operating system. So what is expected of a SysProg, and what a SysProg does on a day-to-day basis, will differ greatly from one business to the next. However, it's defined, the SysProg plays a central role in just about everything that has to do with the mainframe. A system programmer needs to have knowledge of hardware, processors, system libraries and datasets, storage, software, security, networking. The system programmer may not be the one who actually, hands on keyboard, makes those changes but, they do need to understand the changes, so they can help plan them and minimizing impact to production workloads. They typically handle building and maintaining IODF configurations, architecting the connections to storage devices and, other mainframes. They know the system backwards and forwards, physically and logically. Some typical situations a SysProg needs to be able to handle might include the selecting a performance management strategy to best optimize the mainframe performance, determining when and how to expand the system. It's not always in the budget or the production schedule to be upgrading to the latest and greatest all the time. A system programmer needs to be able to determine when they should roll in that new mainframe. They need to establish a baseline for performance and track that performance over time, so problems with customers waiting too long or transactions timing out don't sneak up on them. A lot of what a SysProg does is making sure that a system is prepared for anticipated workloads. Some of this involves working with the business side of things. For example, imagine a retail business is planning on having a huge sale in the middle of the summer that's going to drive massive amounts of shoppers to their website. The SysProg needs to know about that, and they have to have the system ready to handle that anticipated load of all those new people. Perhaps, most importantly, a SysProg needs to maintain a list of procedures for how certain situations should be handled on their mainframe systems. Now, I'm talking about actual written out procedures for when you see this type of problem, look for these Indicators, and based on conditions A, B, and C, perform actions D, E, or F. Let me put it another way. You ever hit a problem on your computer and you search for the error you get on the Internet and you find somebody else describing exactly the same problem. Instead of describing how they fix it, they just up and disappear or maybe they came back and their only update is, "Never mind, I fixed it." Procedures aren't always the most fun thing in the world to write, but when you run into an issue and seconds count, a well-written procedure that perfectly describes what you're seeing and what you have to do is a beautiful thing. A SysProg may not directly handle security aspects of operations, they might have a dedicated security administrator for that. But the SysProg still needs to have a firm handle on who should and shouldn't have access to various system resources. The reason the system programmer needs to be involved in all of these areas is that there is a high expectation when it comes to enterprise systems. These are not something went wrong, try again situations. In many cases, the expectation is 24 by seven operation, and often, is the case that there is a contract in place guaranteeing a certain level of performance and availability. So being reliable and performing isn't just a nice thing, it's the business. For that reason, change control is an extremely important aspect of working in an enterprise environment. Making changes will often require discussing what you want to do with a team of others, to make sure that it won't affect them or that they can anticipate them and work around those changes. Even something that seems very simple and could do no harm like upgrading a piece of software, may introduce changes that affect other users. Software, operating system, and hardware changes are often planned out weeks, if not months in advance. As a system programmer, this is your system. You know it best, you know what it's capable of, what might put business objectives at risk, and how to handle certain situations that come up. It's a tough job, but I'm pretty sure you're up to it.
