"Config files? What are those? To change the system configuration, use these assembler macros, reassemble this module, relink the operating system and then reIPL it". So, systems programmer, because knowing assembler was part of the job description.
Plus, at mainframe sites in the 1960s/1970s, it was common for sysprogs to write custom code to hook into the operating system and change its behaviour (user exits), or even to actually patch the operating system code (SYSMOD) – and assembler was the language used to do all that
If we are talking about IBM mainframes specifically, by the 1970s, a lot of the operating system was written in a high level language (a PL/I dialect), but although they shipped customers the source code, they didn't ship them any compiler for the special PL/I dialect, so customers couldn't modify it by changing the source, only by disassembling the binary, modifying the assembly, then reassembling it. Plus, commonly, IBM shipped only source for the initial release, not later patches, so the customer copy of the source would gradually get out of sync with the binary. Some other mainframe vendors weren't quite so primitive, and so there was significantly less use of assembler by customers for OS customisation (e.g. I think, Burroughs, Multics)
Formerly systems programmer, or sysprog for short
"Config files? What are those? To change the system configuration, use these assembler macros, reassemble this module, relink the operating system and then reIPL it". So, systems programmer, because knowing assembler was part of the job description.
Plus, at mainframe sites in the 1960s/1970s, it was common for sysprogs to write custom code to hook into the operating system and change its behaviour (user exits), or even to actually patch the operating system code (SYSMOD) – and assembler was the language used to do all that
If we are talking about IBM mainframes specifically, by the 1970s, a lot of the operating system was written in a high level language (a PL/I dialect), but although they shipped customers the source code, they didn't ship them any compiler for the special PL/I dialect, so customers couldn't modify it by changing the source, only by disassembling the binary, modifying the assembly, then reassembling it. Plus, commonly, IBM shipped only source for the initial release, not later patches, so the customer copy of the source would gradually get out of sync with the binary. Some other mainframe vendors weren't quite so primitive, and so there was significantly less use of assembler by customers for OS customisation (e.g. I think, Burroughs, Multics)