improve documentation for turnkey
This commit is contained in:
parent
a857cc52f0
commit
28a1319bca
@ -320,6 +320,127 @@ herc =====>
|
||||
|
||||
At this point, most of you will be wondering: "Okay. What now?". Well, now you operate your system. That's what. There is a distinction that needs to be made here. It's not like how we "use" microcomputers today. Back in the day, there was an "operator", and there was a "user". The user was the administrator, the programmer, or the accountant, who just used various programs available to him on his terminal device.
|
||||
|
||||
The Operator, however, sat all day long at this console, monitoring system resources, responding to system prompts, mounting tapes, running utility jobs, printing output, and occasionally "IPLing" the system (what we now call 'rebooting').
|
||||
The Operator, however, sat all day long at this console, monitoring system resources, responding to system prompts, mounting tapes, running utility jobs, printing output, and occasionally "IPLing" the system (what we now call 'rebooting'). The following will provide a few simple examples of how you can use the master console to manage your system. For more in-depth details, I will provide links at the bottom to ACTUAL IBM Documentation, that is very similar to what I used when I was being tutored on-the-job, back in 1988.
|
||||
|
||||
To know how to operate the system, you need to know a little something about the system. For starters, how do you enter commands, and what are they showing you? For example, how can you see all the things running on the system? For linux users, there's the `ps` command, or `htop` if you prefer something a little more aesthetically pleasing. It's kind of not like that on MVS.
|
||||
**What's Running?**
|
||||
|
||||
To know how to operate the system, you need to know a little something about the system. For starters, how do you enter commands, and what are they showing you? For example, how can you see all the things running on the system? For linux users, there's the `ps` command, or `htop` if you prefer something a little more aesthetically pleasing. It's kind of not like that on MVS.
|
||||
|
||||
First, you're *technically* not at the master console. You're at the HERCULES prompt which is laying on top of the master console. What is Hercules? Hercules Hyperion is the hardware emulator. It's the software stack that makes MVS **think** it's on an actual S/370. So, to send commands to MVS, you have to prefix your console interactions with a `/`. The forward-slash tells Hercules "this is destined for MVS".
|
||||
|
||||
Second, you need to understand that there are different layers of interaction with MVS. Unprefixed commands (not counting the forward-slash), will get picked up and processed by the MVS kernel itself. Commands that are prefixed with `$` will get intercepted by the Job Entry System, which handles all the work of executing "metered" code on the mainframe. There are other prefixes. But these two are the most important (none, and `$`).
|
||||
|
||||
**MVS Tasks**
|
||||
|
||||
So, to see everything that Linux users might call "daemons" running on the system, you use the MVS `DISPLAY` command. It has the abbreviation `D`. It looks like this:
|
||||
|
||||
<pre class="mvs">
|
||||
HHC00013I '/' input entered for console 0:0009: "d a,l"
|
||||
d a,l
|
||||
/ 0.01.24 IEE102I 00.01.24 25.019 ACTIVITY 455
|
||||
/ 00009 JOBS 00006 INITIATORS
|
||||
/ CMD1 CMD1 CMD1 V=V
|
||||
/ BSPPILOT BSPPILOT C3PO V=V S
|
||||
/ JES2 JES2 IEFPROC V=V
|
||||
/ NET NET IEFPROC V=V
|
||||
/ TP TP TCAM V=V
|
||||
/ MF1 MF1 IEFPROC V=V S
|
||||
/ TSO TSO STEP1 V=V S
|
||||
/ SNASOL SNASOL SOLICIT V=V
|
||||
/ JRP JRP JRP V=V S
|
||||
/ 00000 TIME SHARING USERS
|
||||
/ 00000 ACTIVE 00040 MAX VTAM TSO USERS
|
||||
</pre>
|
||||
|
||||
Note, I endered: `D A,L`. This means "Display All, in List Form". It's like `ls -lA`, but for MVS tasks.
|
||||
|
||||
Notice also, the very first line of the output. This is Herculese telling you that it notice you entered a command, and is acknowledging that the command is destined for the MVS system it is hosting. Then mvs shows you the actual mvs command I entered, followed by the output.
|
||||
|
||||
I'm not going to go over the entire output. For that, you'll have to refer to the IBM documentation. Suffice for this document, to point out just a few important notes:
|
||||
|
||||
1. The first row shows you how many "tasks" are running, and how many "batch" job "initiators" you have available for processing "metered" jobs.
|
||||
2. The first column of the table is the name of each "task" running.
|
||||
3. `CMD1` and `BSPPILOT` are like "TSR" programs. They're long-running scripts that bootstrap the system, and listen for shutdown commands. On a NORMAL MVS system, these will NOT be present. They appear on our Turnkey, because all the manual work of bootstrapping, and shutting down, has been cooked up for us, so we don't have to do it OLD-SKOOL like a real console operator would have to back in the day.
|
||||
4. The first 'system' entry is called `JES2`. That is your Job Entry System. It will ALWAYS be the very first task on a normal MVS system, because it controls the submission of ALL other work on the system.
|
||||
5. `NET` is the task that provides MVS networking capabilities. This includes both SNA and TCPIP architectures.
|
||||
6. I've forgotten what `TP` is, but `MF1` is the "Monitoring Facility". This task keeps track of all the the run statistics of both your base system, and of your "metered" jobs. Technically, you don't need to run this on the Turnkey system, since there's no real need to monitor run statistics, which would normally have been parsed up and sent in batches to IBM, and your accounting department. IBM would get the base statistics for the system. Your accounting department would figure up a cost for each department that matched it's usage of the system, and that cost would be billed to clients.
|
||||
7. `SNASOL` is shorthand for "System Network Architecture Solicitor". In short, it is a task that does nothing more than listen for terminals trying to connect to the system throught `NET`, intercept those connections, and present the terminal display with a logon splash screen, and user entry fields.
|
||||
8. I can't remember what `JRP` is.
|
||||
|
||||
**JES2 Jobs**
|
||||
|
||||
Metered work, such as when a programmer wants to submit a piece of source code to be compiled, or when an accountant wants to submit a program to process a collection of of purchase records, would be done by sending JCL job cards to the card reader we talked about above in the configuration section. In practical terms, those cards would look something like this:
|
||||
|
||||
<pre class="mvs">
|
||||
000001 //@050541 JOB (JCL),'JCL HELLO EXAMPLE',NOTIFY=&SYSUID,
|
||||
000002 // CLASS=A,MSGCLASS=H,
|
||||
000003 // MSGLEVEL=(1,1),
|
||||
000004 // REGION=4M,TIME=1440
|
||||
000005 //HELLO EXEC PGM=IEBGENER
|
||||
000006 //SYSPRINT DD SYSOUT=*
|
||||
000007 //SYSIN DD DUMMY
|
||||
000008 //SYSUT1 DD *
|
||||
000009 HELLO, WORLD!
|
||||
000010 //*
|
||||
000011 //SYSUT2 DD SYSOUT=*
|
||||
000012 //
|
||||
</pre>
|
||||
|
||||
To see all of this work, normally, you'd enter this command: `$da`, with parameters defining filtering and sorting as needed. However, on the Turnkey system, jobs run so quickly (most finish in less than 2 or 3 seconds), that it's just not possible to generate enough workload to demonstrate the command. In any case, here's what it looks like when no jobs are running:
|
||||
|
||||
<pre class="mvs">
|
||||
HHC00013I '/' input entered for console 0:0009: "$da"
|
||||
$da
|
||||
/ 0.40.52 $HASP000 NO ACTIVE JOBS
|
||||
</pre>
|
||||
|
||||
And here is what it looks like on the master console, when I submit the job above. I will do another post explaining how to create jcl, write code, and submit jobs of your own, at another time. Suffice it for this document, to show how to read the master console.
|
||||
|
||||
<pre class="mvs">
|
||||
/ 0.45.29 JOB 150 $HASP100 @050541 ON INTRDR JCL HELLO EXAMPLE
|
||||
/ 0.45.29 JOB 150 $HASP373 @050541 STARTED - INIT 1 - CLASS A - SYS SYSA
|
||||
/ 0.45.29 JOB 150 IEF403I @050541 - STARTED - TIME=00.45.29
|
||||
/ 0.45.29 JOB 150 IEF404I @050541 - ENDED - TIME=00.45.29
|
||||
/ 0.45.29 JOB 150 $HASP395 @050541 ENDED
|
||||
/ 0.45.29 $HASP309 INIT 1 INACTIVE ******** C=A
|
||||
/ 0.45.29 JOB 150 $HASP150 @050541 ON PRINTER1 49 LINES
|
||||
/ 0.45.29 $HASP160 PRINTER1 INACTIVE - CLASS=A
|
||||
/ 0.45.29 JOB 150 $HASP250 @050541 IS PURGED
|
||||
</pre>
|
||||
|
||||
### Reading Console Messages
|
||||
|
||||
The messages above might seem a bit confusing at first. Let's take a simpler example. Here's an example of console messages generated by the Monitoring Facility, which was running a batch job for the first hour of my instance:
|
||||
|
||||
<pre class="mvs">
|
||||
/ 0.12.27 STC 446 $HASP150 MF1 ON PRINTER1 209 LINES
|
||||
/ 0.12.27 STC 446 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING
|
||||
/ 0.12.27 $HASP160 PRINTER1 INACTIVE - CLASS=A
|
||||
/ 0.12.30 $HASP000 OK
|
||||
</pre>
|
||||
|
||||
Reading these lines from left to right: timestamp, STC ("system task"), task number, IBM messageid, "english language message"
|
||||
|
||||
Note that ALL of the IBM message ids you see in these output messages are searchable on Google. EG:
|
||||
|
||||
```text
|
||||
IBM HASP Message
|
||||
The message $HASP150 is related to job processing in IBM’s JES2 (Job Entry Subsystem 2) environment. Here is a summary of the message and its context:
|
||||
|
||||
$HASP150 JOB jij jobname OUTGRP = STC TSU ON devname nnnn (mmmm) LINES nnnn (mmmm) CARDS nnnn (mmmm) PAGES: This message indicates that device devname is beginning to process the output identified in the grpid.joeidl.joeid2 fields for the indicated job. The message includes details such as the number of lines, cards, and pages being processed.
|
||||
This message is informational and does not require any specific action from the operator or programmer. It is part of the system’s logging mechanism to inform about the processing status of jobs in the JES2 environment.
|
||||
```
|
||||
|
||||
### Logging On To System
|
||||
|
||||
Moving on from Console Operator to System User (such as a programmer might be), how would one access the system? This is done through a 3270 terminal attached to an SNA endpoint. In the old days, this was a physical CRT, keyboard, and minimal set of microprocessing hardware needed to communicate on the SNA network.
|
||||
|
||||
TODAY, however, we emulate 3270 in terminal emulation programs, just as we emulate VT100, VT220, and VT232. There are a WHOLE BUNCH of decent 3270 emulation programs out there, but my favortes are `c3270` on Linux terminal for a minimalist approach, and `pw3270` which has a GTK GUI for a more soup-to-nuts terminal console. Either one is fine, or whatever you prefer.
|
||||
|
||||
If you'll recall back at the beginning of the configuration section, there was one entry that was important to this section:
|
||||
|
||||
```text
|
||||
CNSLPORT ${CNSLPORT:=3270}
|
||||
```
|
||||
|
||||
This sets the IP PORT for terminal logins to 3270 (matching the model number, of course). So, if you want to connect with a 3270 emulator to your instance, you'd use the following IP address in your connection settings: `{your.ip.add.ress}:3270`.
|
||||
Loading…
Reference in New Issue
Block a user