Sujet : zos
-
Automating z/OS through z/OSMF: the jobs, datasets, and files REST APIs
z/OSMF exposes z/OS jobs, datasets, and z/OS UNIX files as ordinary HTTPS/REST resources, which makes it the most agent-friendly interface to the system; requests need the X-CSRF-ZOSMF-HEADER custom header (state-changing ones are rejected without it), and responses use standard HTTP status codes rather than 3270 message text.
-
z/OS orientation: address spaces, datasets, catalogs, JES2, and what SSH into USS can see
z/OS organizes work into address spaces rather than a flat process table, stores data in cataloged datasets rather than a single filesystem tree, and queues batch work through JES2; an SSH session into z/OS UNIX System Services (USS) is one more address space with its own view, not a window onto the whole system.
-
JCL and batch basics: JOB/EXEC/DD statements, return codes, submitting from USS, and reading output
A JCL job is a JOB statement, one or more EXEC steps each naming a program, and DD statements binding files/datasets to that program's I/O; each step ends with a return code where 0 is clean and higher values signal warnings or errors, and a job can be submitted from the USS shell with submit and its output read through SDSF or the z/OSMF jobs REST API.
-
z/OS security with RACF: user, group, and dataset profiles, and why agents need least privilege
RACF is the resource manager most z/OS installations use behind the System Authorization Facility (SAF) interface, protecting users, groups, and datasets through profiles queried with LISTUSER/LISTDSD and granted with PERMIT; an automation agent should run under a narrowly scoped user ID rather than one carrying broad access, and should not treat command output as a stable programmatic interface.
-
z/OS system operations basics: console commands, SYSLOG/OPERLOG, and what an IPL is
Console commands like D A,L (list active jobs) and D IPLINFO (display IPL information) are the read-only starting point for understanding what a z/OS system is doing; SYSLOG and OPERLOG are where system messages accumulate, and an IPL (Initial Program Load) is the mainframe's equivalent of a full system boot, not something to trigger outside a planned change window.
-
Reaching z/OS datasets from the UNIX shell: the //'HLQ.NAME' notation, tsocmd, and encoding tags
From a z/OS UNIX shell, classic datasets are addressed with the //'HLQ.DATA.SET' notation understood by cp and other USS utilities, or by running a TSO command directly with tsocmd; text files crossing between EBCDIC datasets and ASCII USS files need explicit tagging with chtag or the _BPXK_AUTOCVT setting, or they arrive corrupted rather than merely wrong-looking.
Lisible par machine : JSON