BASIC ELEMENTS OF Z/OS

BASE ELEMENTSBASE ELEMENTS OPTIONAL CHARGED OPTIONAL CHARGED ELEMENTSELEMENTS

JES2JES2 BOOK MANAGER READBOOK MANAGER READ

DFSMSDFSMS DFSMSdss / DFSMSrmmDFSMSdss / DFSMSrmm

TSO/ETSO/E RMFRMF

MVS/ESAMVS/ESA SDSFSDSF

ISPFISPF FIREWALLFIREWALL

SMP/ESMP/E LDAP SERVERLDAP SERVER

ESCON DIRECTOR ESCON DIRECTOR SUPPORT / HCDSUPPORT / HCD

DFSORTDFSORT

LANGUAGE LANGUAGE ENVIRONMENTSENVIRONMENTS

HCMHCM

Z/OS COMMUNICATIONS Z/OS COMMUNICATIONS SERVERSERVER

RACFRACF

IBM HTTP SERVERIBM HTTP SERVER HLASM TOLLKITHLASM TOLLKIT

CICSCICS

IMSIMS

COBOLCOBOL

FORTRAN / PLIFORTRAN / PLI

IBM COMMUNICATIONS SECURITY IBM COMMUNICATIONS SECURITY SERVER 3SERVER 3

GDDM-REXX FREATUREGDDM-REXX FREATURE

DB2 QMF HOSTDB2 QMF HOST

OPTIONAL ELEMENTS

SUBSYSTEMS OF MAINFRAME

RACF(RESOURCE ACCESS CONTROL FACILITY)

COMPREHENSIVE SECURITY MANAGER FOR CONTROLLING ALL COMPREHENSIVE SECURITY MANAGER FOR CONTROLLING ALL ACCESS RIGHTSACCESS RIGHTS

MAINTAINS IT’S OWN SECURITY DATABASEMAINTAINS IT’S OWN SECURITY DATABASE

USERS BELONG TO GROUPS, AND HAVE INDIVIDUAL AS WELL AS USERS BELONG TO GROUPS, AND HAVE INDIVIDUAL AS WELL AS GROUP RIGHTSGROUP RIGHTS

RESOURCES - DASDS, DATASETS, DATASET GROUPS, JOB RESOURCES - DASDS, DATASETS, DATASET GROUPS, JOB OUTPUTS ETC. ARE CONTROLLED BY PROFILESOUTPUTS ETC. ARE CONTROLLED BY PROFILES

RACF CAN ALSO CONTROL LOGGING ON TO ALL SUB-RACF CAN ALSO CONTROL LOGGING ON TO ALL SUB-SYSTEMS. ONCE AN USER LOGS IN (INCLUDING LOGON AND SYSTEMS. ONCE AN USER LOGS IN (INCLUDING LOGON AND LOGOFF PROCEDURE) LOGOFF PROCEDURE)

WHATEVER HE DOES IN THE MAINFRAME IS MANAGED BY WHATEVER HE DOES IN THE MAINFRAME IS MANAGED BY THIS SECURITY PRODUCT .THIS SECURITY PRODUCT .

WHENEVER AN USER LOGS INTO THE MAINFRAME HE IS WHENEVER AN USER LOGS INTO THE MAINFRAME HE IS ASKED FOR AN USER ID (HIGH LEVEL QUALIFIER) AND THEN A ASKED FOR AN USER ID (HIGH LEVEL QUALIFIER) AND THEN A PASSWORD PASSWORD

WHEN THE USER ID IS TYPED BY THE RACF CHECKS FOR THE WHEN THE USER ID IS TYPED BY THE RACF CHECKS FOR THE USER’S AVAILABILITY IN IT’S DATABASE ,IF THE USER IS USER’S AVAILABILITY IN IT’S DATABASE ,IF THE USER IS PRESENT ONLY THEN IT ALLOWS ACCESS TO THE MAINFRAME PRESENT ONLY THEN IT ALLOWS ACCESS TO THE MAINFRAME ENVIRONMENTENVIRONMENT

RACF(RESOURCE ACCESS CONTROL FACILITY)(CONTD…..)

RMF(RESOURCE MANAGEMENT FACILITY)

• MANY DIFFERENT ACTIVITIES KEEP THE MAINFRAME RUNNING SMOOTHLY,RMF IS A TOOL THAT HELPS THE OPERATOR,THE SYSADMIN,SERVICE ADMIN TO DO THIS TASK .

• RMF GATHERS DATA USING THREE MONITORS

•SHORT TERM- MONITOR 3

•SNAPSHOT-MONITOR 2

•LONG TERM-MONITOR 1

• DATA IS GATHERED FOR A SPECIFIC CYCLE TIME AND DATA ARE WRITTEN IN SPECIFIC INTERVAL TIME

SMP/E (SYSTEM MODIFICATION PROGRAM EXTENDED

• SMP/E IS A TOOL DESIGNED TO MANAGE THE INSTALLATION OF THE SOFTWARE PRODUCTS ON THE MAINFRAME’S MVS SYSTEMS

•THE SYSTEM PROGRAMMER HAS TO TAKE CAR OF THE INSTALLATION AND MODIFICATION OF THE PRODUCTS SUCH THAT THESE CAN WORK AT A PROPER LEVEL

•SMP/E IS ALSO USED TO TRACK THE MODIFICATIONS MADE TO THE PRODUCT

•THE Z/OS APPEARS TO BE ABIG BLOCK OF CODE RUNNING THE CPU. EACH SYSTEM FUNCTION IS COMPOSED OF ONE OR MORE LOAD MODULES.

•THE LOAD MODULES REPRESENT BASIC UNIT OF MACHINE READABLE LANGUAGE

SMP/E (SYSTEM MODIFICATION PROGRAM EXTENDED) (CONTD….)

DFSMS(DATA FACILITY STORAGE MANAGEMENT SUBSYSTEMS)

• DFSMS/MVS PERFORMS THE ESSENTIAL DATA,STORAGE,PROGRAM AND DEVICE MANAGEMENT FUNCTIONS OF THE SYSTEMS

• DFSMS/MVS IS THE CENTRAL COMPONENT OF BOTH SYSTEM AND NON-SYSTEM MANAGED STORAGE ENVIRONMENTS

•MVS SUPPORTS BOTH 24-BIT AND 31-BIT ADDRESSING USED BY DFSMS/MVS

•DFSMS/MVS CONSISTS OF A SET OF SOFTWARE AND HARDWARE PRODUCTS THAT TOGETHER PROVIDE A SYSTEM MANAGED STORAGE SOLUTIONS .

DFSMS(DATA FACILITY STORAGE MANAGEMENT SUBSYSTEMS)(CONTD…)

• THE COMPONENETS OF DFSMS/MVS AUTOMATE AND CENTRALIZE STORAGE MANAGEMENT BASED ON INSTALLATION DEFINED POLICIES

• THE ISMF(INTERACTIVE STORAGE MANAGEMENT FACILITY) PROVIDES THE USER INTERFACE FOR DEFINING AND MAINTAINING THE POLICIES

• DFSMS FUNCTIONAL COMPONENTSDFSMS IS COMPRISED OF DFSMSdfp, AN

ELEMENT OF OS/390, AND DFSMSdss , DFSMShsm, AND DFSMSrmm FEATURES OF OS/390.

(SMF)SYSTEM MANAGEMENT FACILITIES

SYSTEM MANAGEMENT FACILITIES (SMF) COLLECTS AND RECORDS SYSTEM AND JOB-RELATED INFORMATION THAT YOUR INSTALLATION CAN USE IN:

BILLING USERS. REPORTING RELIABILITY. ANALYZING THE CONFIGURATION. SCHEDULING JOBS. SUMMARIZING DIRECT ACCESS VOLUME

ACTIVITY. EVALUATING DATA SET ACTIVITY. PROFILING SYSTEM RESOURCE USE. MAINTAINING SYSTEM SECURITY.

SMF FORMATS THE INFORMATION THAT IT GATHERS INTO SYSTEM-RELATED RECORDS (OR JOB-RELATED RECORDS).

SYSTEM-RELATED SMF RECORDS INCLUDE INFORMATION ABOUT THE CONFIGURATION, PAGING ACTIVITY, AND WORKLOAD.

JOB-RELATED RECORDS INCLUDE INFORMATION ON THE CPU TIME, SYSOUT ACTIVITY, AND DATA SET ACTIVITY OF EACH JOB STEP, JOB, APPC/MVS TRANSACTION PROGRAM, AND TSO/E SESSION

IT IS A SET OF SERVICES THAT IS USED TO IMPROVE THE RESPONSE TIME OF APPLICATIONS THAT MUST RETRIEVE A SET OF DATA FOR MANY USERS

VLF CREATES AND MANAGES A DATA SPACE TO STORE APPLICATION’S MOST FREQUENTLY USED DATA.

WHEN THE APPLICATION REQUESTS FOR DATA THEN VLF CHECKS ITS DATASPACE TO SEE IF THE DATA IS PRESENT. IF PRESENT THEN VLF CAN RAPIDLY RETRIEVE DATA WITHOUT REQUESTING I/O OR DASD

AN APPLICATION MUST IDENTIFY DATA IT NEEDS TO PERFORM THE TASK

THE DATA IS KNOWN AS THE DATA OBJECT

THE DATA OBJECTS SHOULD BE SMALL TO MODERATE IN SIZE AND NAMED ACCORDING TO VLF NAMING CONVENTIONS

VLF IS INTENDED TO BE USED FOR MAJOR APPLICATIONS

CONVERTS THE JCL INTO EXECUTABLE TEXT

INITIATES THE JOB BASED ON THE INPUT CLASS, PRIORITY ETC.

ALLOCATES DATA SETS AND OTHER RESOURCES

SPOOLS OUTPUTS TO DISK

RELEASES RESOURCES AFTER COMPLETION OF THE JOB

THUS THE JES IS RESPONSIBLE FOR WHATEVER JOB A USER SUBMITS

JES2- FOR A MONOPLEX ENVIRONMENT

JES3-USED IN A MULTISYSTEM ENVIRONMENT

IMS (INFORMATION MANAGEMENT SYSTEM)

◦ HIERARCHICAL DATABASE MANAGEMENT SYSTEM◦ OLD DATABASE MANAGEMENT SYSTEM

◦ HAS IT’S OWN COMMUNICATION COMPONENT - IMS/DC

◦ LIMITED FACILITIES

RELATIONAL E.G.. DB2◦ SUPPORTS STRUCTURED QUERY LANGUAGE (SQL)

◦ DATABASES ORGANIZED AS TABLESPACES

TABLES ROWS AND COLUMNS

◦ SUPPORTS REFERENTIAL INTEGRITY

◦ SQL CALLS CAN BE EMBEDDED IN ANY HIGH LEVEL LANGUAGE

CICS (Customer Information Control System)◦ FULLY ON-LINE TRANSACTION PROCESSOR

◦ SEPARATE SUB-SYSTEM

◦ COMPLETELY TRANSACTION DRIVEN, AND MAP BASED

◦ MORE LIKE A MINI O/S BY ITSELF DATASET ACCESS PROVIDED (INCLUDING VSAM) PROGRAM CONTROL FACILITIES DB ACCESS CALLS SUPPORTED

VTAM provides a method by which application programs can communicate with telecommunication devices and their users.

VTAM was the first IBM program to allow programmers to deal with devices as “logical units” without having to understand the details of line protocols and device operation.

Prior to VTAM, programmers used IBM¢s Basic Telecommunications Access Method (BTAM) to communicate with devices that used the binary synchronous (BSC) and start-stop line protocols.

TRANSFER CONTROL PROTOCOL / INTERNET PROTOCOL

TCP/IP IS A SET OF PROTOCOLS AND APPLICATIONS

IT ALLOWS YOU TO PERFORM CERTAIN COMPUTER FUNCTIONS IN A SIMILAR MANNER INDEPENDENT OF THE TYPES OF COMPUTERS OR NETWORKS BEING USED.

WHEN YOU USE TCP/IP, YOU ARE USING A NETWORK OF COMPUTERS

TO COMMUNICATE WITH OTHER USERS, SHARE DATA WITH EACH OTHER, AND SHARE THE PROCESSING RESOURCES OF THE COMPUTERS

CONNECTED TO THE TCP/IP NETWORK.

THE TCP/IP COMPONENT OF e-NETWORK COMMUNICATIONS SERVER SUPPORTS THE FOLLOWING FUNCTIONS:

LOG ON TO A REMOTE HOST TRANSFER DATA SETS SEND AND RECEIVE ELECTRONIC MAIL PRINT ON REMOTE PRINTERS AUTHENTICATE NETWORK USERS DISPLAY IBM GDDM/MVS GRAPHICS ON X WINDOW SYSTEM

WORKSTATIONS RUN A COMMAND ON ANOTHER HOST MONITOR THE NETWORK QUERY NAME SERVERS MANAGE NETWORK RESOURCES

As a z/OS system programmer, you must be aware of the following:

• Storage concepts• Virtual storage and address spaces concepts • Device I/O configurations• Processor configurations• Console definitions• System libraries where the software is placed• System data sets and their placement• Customization parameters that are used to define your z/OS configuration

Responsibilities System Installation Problem Diagnosis and Resolution System Modifications Hardware Configuration Housekeeping Evaluating software packages Dealing with software suppliers Performance monitoring and tuning Be a Professional Project management Change Management Testing Documentation

Systems programmer, like the whole Operations department, plays essentially a service role

It is your job to make sure the system works when it is needed, performs adequately,and provides the function required by the applications the business wishes to use.

On the other hand, you need to be a businessperson - you need to understand the impact of what you do on the organization you work for, you need to think about how you can contribute to its goals and policies.

Understanding where you fit in and what is expected of you, is to ensure that those around you understand you! “ That means explaining to them what you are doing and why , consulting them when appropriate, and letting them see that you are a professional, with a professional attitude and professional methods”.

“Systems Programmer” is very misleading – “Programming” is only one small aspect of the modern systems programmer's job.

Heart of the job is to install, maintain, and enhance the system software which provides the environment in which the applications required by the organization can run.

Systems programmers spend 65% of their time installing, upgrading, and maintaining software.

Other responsibilities, however, vary considerably from organization to organization, depending on the size and type of the organization.

Systems programmer is responsible for creating all the datasets, load modules, catalogs and catalog entries, parameters, and procedures required to get the MVS system up and running.

CBIPO is a set of tapes which include not only all the modules you need to install your system.

CBIPO is Tailoring process to easily correct the JCL for your site requirements, and a set of documentation including step-by-step instructions on how to generate your MVS system.

You need to have an operating system installed already, to run the CBIPO jobs, IBM supplies very basic pre-generated and pre-configured versions of MVS, which give you enough function to build a proper system from your CBIPO tapes.

You will have to bring up your new system in place of the old one, migrate your real users onto it, then “ Sit back and wait for the problems! ”

When problems occurs, the MVS systems programmer will generally be the

‘Expert of last resort' for the entire installation.

If the problem is caused by a bug in a piece of IBM or third party software, you

will have to contact the supplier, obtain a 'fix', install it on your testing system,

check that it doesn't introduce more problems than it solves and migrate it

onto your production system.

You may also be required to install 'preventative' maintenance on a regular basis.

Decide how devices such as disks, printers, and tape drives should be attached to

the mainframe - on which channels, control units.

Generate the control blocks which both the processor hardware and the operating

system use to identify which devices are attached to which channels and protocols

to use.

Tools you will use to generate these are known as the “ IOCP” and the MVSCP

respectively (or HCD on MVS Version 4).

You may also get involved in configuring ports on local communications cluster

controllers, and other more 'hardware' oriented work, depending on the lines of

demarcation between the systems programming and other operations support

groups.

MVS generates large amounts of diagnostic and informational data, such as

system logs, dumps, hardware error records, accounting and event-monitoring

records.

It is the systems programmer's job to set up and maintain processes to collect,

report on, and archive this information as required.

Furthermore, it is also your job to set up the processes required to remedy this

deficiency like to delete uncataloged datasets from DASD, defragment DASD

packs, and reorganize catalogs with CI-splits and CA-splits.

Systems programmers have to look after ( i.e. install, upgrade, maintain, and sometimes even administer) varies enormously from site to site. For example, you may have to look after:

IBM program products (many of which may come on your CBIPO tape),

including compilers, utilities, communications software, and system

management products;

Third party system software such as storage management packages,

security packages, tape management systems, scheduling packages, and

many others;

Major subsystems such as CICS, IMS, or DB2.

Possibly even application software packages bought in from external

suppliers, particularly when the sort of expertise required to install.

Apart from raising problems with suppliers' technical staff and negotiating with

their salesman for deals on new products, you will probably have to deal with

suppliers on many other occasions.

Try to be polite, at the very least - they may actually come up with exactly what

you need one day! Salespeople from companies you already deal with deserve more

consideration again, as they may often be able to give you useful information about

new releases with new functions, add-on products, market trends, and competitors'

products.

You may also be able to squeeze them for useful 'goodies' such as free training or

manuals!

In many organizations there is a separate team dealing with performance, but in others you may have the opportunity to work in these area.

As an MVS systems programmer is an essential prerequisite for the task of tuning a system - you can't tune a system well unless you know how it works in the first place.

However, performance monitoring and tuning is a very large area.

As a technical guru, you may often be invited to give advice and assistance to those working in a wide range of other areas - particularly where those areas potentially overlap with your own.

Disaster recovery Capacity planning Applications development Automated operations Hardware strategy and purchasing decisions Security policy

Professional Attitude Professional's attitude to their work can be summed up in two simple

words - Taking Responsibility. Those simple words mean a thousand different things in a thousand different situations, but here's a few examples:

“Owning the problem” - When someone brings a problem to you, you make sure that it is solved and even if you need to ask someone else to solve it.

“Admitting mistakes” - Putting them right as far as you can, and implementing measures to stop them happening again

Ensuring that anyone who might be adversely affected by what you are doing is consulted or at least informed - what they are doing might be a lot more important to the organization than what you are doing!

Ensuring that you use methods which maximize the quality of your work and minimize any adverse consequences for your users.

Systems programmers seem to think that project management is only for “Applications projects”

They're wrong - and they're depriving themselves of a vital technique for ensuring that they deliver high quality work and deliver it on time.

Go for a slow start - many studies have shown that if you spend more time planning a project at the beginning, the total time taken to complete it (including the planning time) is reduced.

Check the proposed schedule with everyone involved, including managers with potentially contending responsibilities

When a task is completed, check it - ask the person who did it to show you the results

Chase people who are behind schedule and get them to commit to complete by a specific date

If you realize you are going to miss a deadline, start talking to the people who will be affected straight away, and negotiate a new one, or increased resources.

Generally change control systems will require you to

Record what it is you want to do, when, and what effect it will have on the production environment and online users;

Explain what testing will be done and what provision will be made to back out the change if it goes wrong.

This is a vital one for systems programmers - because when your changes go wrong you are often in danger of having corrupted the very systems you need to use to put them right.

Obtain the approval of certain managers to the change and its timing.

Inform any users who may be affected by the change - this gives you an opportunity to point out how the changes will benefit them and so improve your image too!

Every change which goes wrong is a blot on your reputation, and you will probably need five to ten changes to go right to cancel out the effect of the one that went wrong! So minimize the danger:

Back up anything you might conceivably corrupt before you start changing it, and plan how to recover from every possible disaster (within reason) BEFORE you start making changes - this is the secret of turning disasters into minor delays

Get someone to check your commands or JCL before you submit them if you are in any danger of causing a disaster should you have mistyped - and always check them against the manual if you are less than 100% confident of what you are doing

Ensure users can't access test systems or live systems you are in the process of changing

Draw up a comprehensive test plan - consider what options need to be tested,

and the possible things that could go wrong, consult users and specialists in

the area you are dealing with, and prepare testing JCL or commands before

your test session

Run through your test plan on the live system to see what the results ought to

be before testing in earnest

Create whatever testing environment is enquired to enable you to test the new

software without disrupting the users of the current version

Test from the plan!

Check the results carefully

Document your work internally as you go - so every piece of JCL, assembler code, clist, etc, contains comments explaining what it is for, when it is used, and any peculiarities relating to it - unusual techniques, for example, or important things to check before you use it.

Keep all your work in places where it will be easy to find - usually libraries with library names that follow a sensible standard and member names which are self-explanatory.

Create and keep up to date a high-level system manual. This should include summary documentation of key features of your system, including in-house modifications, with pointers to datasets where more detailed documentation can be found, and explanations of the naming standards which will allow someone new to find your detailed work easily.

Document should be easily accessible to all systems programmers, there should only be one copy of it, it should be kept and updated in machine-readable form, and whenever it is changed the entire document should be reprinted, the old hard copy thrown away, and the new one inserted in its place.

Training all members of the team to deal with the commoner types of problem in all areas for which the team is responsible;

Maintaining an 'on call' Rota so that each systems programmer carries a pager out of working hours and is responsible for dealing with any problems during those hours - but only for their week on the Rota.

Maintaining a 'problem duty' Rota to handle problems during working hours in exactly the same way - junior staff can go onto this one earlier than the 'on call' Rota to help them learn the ropes, but with more experienced staff available to provide a safety net.

This sort of Rota is vastly preferable to the alternatives of (a) directing all problems to the person in whose area they lie - this means everyone's project work is constantly disrupted, and the opportunity to spread basic problem resolution skills around the team is lost; or (b) having one or more members of staff dedicated full-time to problem resolution - the sort of mind-numbing job which drives away high-quality staff.

Dataset names should include a high-level-qualifier related to the application or user which owns them, so that rules for allowing access to them and for accounting for the space they use can be extremely simple, depending in 90% of cases only on the HLQ;

System dataset names should also follow simple rules - e.g. one HLQ could be allocated for installation JCL datasets, another for IBM program products, another for CICS datasets, another for third party system software;

When amending members of system libraries, follow a simple rule for naming backup copies - e.g. always make a backup copy with a name the same as the original, except replacing the suffix with your initials - and ensure that all members of the team follow the same convention

Never code tables of variable information into system programs (such as valid account codes, public holidays, etc) - put them in an easily maintained file instead or you will constantly have to modify and reassemble the program itself

Make a rule about the use of SMP/E - i.e. always use it when possible - and about what products go in which CSI's - e.g don't put third party products in your MVS CSI or you won't be able to throw it away when you install a new CBIPO.

If your site or section doesn't have effective standards, push for them! And remember the golden rule - a standard is only a standard if it is enforced. One of the best and commonest reasons for writing system exits is to enforce standards.