For your comprehensive comparison of STCs vs UNIX daemons, thank you. This is one of the most helpful and constructive replies (there are many others, but also plenty of 'go away and read this manual cover to cover' replies out there) I've seen in quite a long time.
Original Message:
Sent: Mon February 17, 2025 10:34 AM
From: J Robert Garrett
Subject: Some rookie doubts :-)
Hey Saul, >long time< mainframe guy here so I'll attempt to answer all your questions. Fair warning: I tend to get carried away so let me apologize in advance for that.
1) : "How do you install servers under z/OS..."
I'm guessing from the way you worded your question that you have at least some background/experience with "small systems" like Windows and/or Linux, and you're referring to what would normally be called a "Service" in Windows or a "Daemon" in Linux, correct? There are equivalents under z/OS that behave the same way. One is called a "Started Task" or "STC" for short. These are indeed 'defined' via a type of JCL (called a stored JCL procedure) that will previously have been placed into the System Procedure Library (System PROCLIB) (There will always be at least one: named SYS1.PROCLIB, and 99.99% of the time there will be additional libraries 'concatenated' to this one as part of the Job Entry Subsystem (JES - usually JES2) configuration. The 'system programmers' who maintain z/OS itself are in control of this, and the names and number of libraries can and do vary from shop to shop). Started Tasks (STC's) are started via an operator command: "START xxxxx" where xxxxx is the name of a JCL procedure that has been stored in the System Proclib. The command is either entered by an operator, or by various forms of 'automation' that can masquerade as a human operator. That's one way to start a 'server/service' on z/OS. Another way is to submit a plain old vanilla 'batch job' with JCL that runs a program that BEHAVES like a service/server - in other words, once it starts, it continues to run until some outside action (such as a STOP command) tells it to stop. There are some minor distinctions between the two, but for our purposes an operator initiated STC and a batch job that BEHAVES like an STC are the same as far as z/OS is concerned. They both continue to run until some outside 'force' makes them stop. A third way is to start a process in USS (Unix System Services) that also behaves like a service - it runs until something makes it stop.
At this point, I think it's important to understand something about OMVS/USS on z/OS. It's not -really- Unix/Linux. It's just a "shell" - in the same way that running a bash shell on Linux, or a command/powershell prompt on Windows is really just a human interface into the underlying operating system. All the different Linux shells on 'real' Linux systems (bash, korn, c-chell, etc) have slightly different behaviors, and of course working with a Windows command prompt is quite a bit different than using powershell, but all of those still are interfacing with 'the same' underlying operating system, right? Windows is still Windows, Linux is still Linux. When you're working with USS on z/OS, you're not using a 'real' Unix/Linux (the new container service on z/OS 3.1 notwithstanding, but that's a different topic). Instead you're using a shell that presents a Unix-like (actually POSIX) "face" to you the user, but underneath it's still talking to the same z/OS, using the same API's and services, that 'normal' z/OS STC's, batch jobs, TSO users, etc. are working with plus making the POSIX API set available as well (which it 'translates' into the base z/OS API's). The 'files' and 'filesystems' you see in USS are in reality, just plain old VSAM linear datasets that the USS subsystem is using to mimic/implement/provide an experience similar to what you see on a 'real' Linux system. OMVS/USS makes it LOOK LIKE you're using a Linux system but you're really not - underneath it's still just z/OS. So if you 'peel back' all the layers, if you "start a daemon" under USS, bottom line it's still just a long-running program running on z/OS that, because of how it was started, has all of the USS (POSIX) API's available to it.
Getting back to your questions: (I did warn you..)
2) "To use Python do you have to create a JCL that invokes it or is it enough with a command?"
Short answer, Yes - either or both. At the time I'm writing this answer, as far as I know Python on z/OS is only available under/through USS because it needs the USS (POSIX) API's to work. So, you can invoke a Python program from inside your interactive TSO OMVS/USS session, AND/OR there are ways to start/invoke OMVS/USS commands and services (including 'shell scripts') using JCL submitted as a batch job. Your choice.
3). "If a folder/file is created from OMVS using Unix commands... In order to access the resource from ISPF, are these files/folders automatically converted to Data Set or cannot be viewed from ISPF?"
There is no "conversion" needed, other than perhaps code page conversion (between ASCII and EBCDIC) depending on what's in the file(s) and how you're accessing them. Remember I said above that underneath it all, everything is still just z/OS and OMVS/USS is simply "putting a face" on it that looks like Linux? Files, directories, and filesystems under OMVS/USS are really backed by VSAM linear datasets. These VSAM linear datasets are created and initialized using the very same IDCAMS utility program that's used to create and manage any other VSAM dataset. In fact, until those linear datasets are initially formatted as zFS filesystems AND mounted on USS mount points, z/OS has no idea that they're any different from any other VSAM dataset. (The previous assertions that files in USS are not datasets is incorrect. They are - they're just being accessed though an API that makes them seem not to be.) If you're in an OMVS/USS interactive session under TSO, then you interact with those items "just like you would" on Linux. But you're not limited to using only that interface. You can also access them using "plain old" TSO/ISPF and even a "plain old" z/OS batch job via ::gasp:: JCL. If you have access to TSO/ISPF, try it. Go into (what is usually) ISPF option 3.4 where you work with 'regular' z/OS datasets, but instead of typing in a dataset name or dataset name pattern, type in this: /etc it'll bring up a display of everything that's in the USS "/etc" directory just like it would if you were to do "cd /etc" then "ls -al" inside your OMVS/USS session. If you want to 'drill down' into a directory, just type an 'l' to the left of it. This all works because ISPF is 'smart enough' to see that you've entered a USS path in the 3.4 entry panel and therefore it knows it needs to invoke the USS API's to 'do what it does'. Batch JCL. There are operands for the 'plain old' DD statement that are used to access OMVS/USS paths and files. Here's an example of a batch step that prints a USS file:
//GENER EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD PATH='/u/beargfr/cicsts61.readme.txt',
// PATHOPTS=(ORDONLY)
//SYSUT2 DD SYSOUT=*
The presence of the PATH= parameter on the DD statement "tells" JES2 that the input file is on USS, so JES2 "knows" it's going to have to 'include' the POSIX API's as part of the job step. PATHOPTS=(ORDONLY) in this case tells the system that the file is to be accessed in 'read only' mode.
Key concept is knowing/remembering that everything is still done by z/OS. All OMVS/USS is doing is providing a different 'look' to things along with some POSIX API's to make things look familiar to people who are more accustomed to working on what I playfully call "toy computers". ::grin::
Contin
------------------------------
J Robert Garrett
Original Message:
Sent: Sun February 16, 2025 10:57 AM
From: SAUL MAURICIO CHAGOLLA HERREJON
Subject: Some rookie doubts :-)
Nice day!!!
I am relatively new to IBM, I passed 3 z/OS courses ("Basic Path") but there are no in-depth topics there. For this reason, I have some basic doubts.
1.- How do you install servers under z/OS (through an executable type such as a "special" JCL or through commands to call some type of IBM repository, etc.)?
2.- To use Python do you have to create a JCL that invokes it or is it enough with a command?
3.- If a folder/file is created from OMVS using Unix commands... In order to access the resource from ISPF, are these files/folders automatically converted to Data Set or cannot be viewed from ISPF?
Thanks for replying :-)
------------------------------
SAUL MAURICIO CHAGOLLA HERREJON
------------------------------