Thursday, December 13, 2007

CONSOLE DEFINITION GUIDE – by Senthil.U


Preamble:

The intention of the guide is to give a brief explanation of consoles and how to do the console definition for single LPAR [Not for SYSPLEX].

In this guide I assume that you have some mainframe experience and you can understand the terms like PARMLIB, PROCLIB, IEASYSxx, IPL, and POR etc...


What is console?

Console is a (mostly) display device which can be used to monitor the different activities of the system and interact to the system.


Types of consoles

There are three different types of consoles

1) MCS consoles
2) SMCS consoles
3) System Console


MCS (multiple console support) consoles are channel attached to the processors of the Mainframe e-server.

SMCS (SNA multiple console support) consoles use communication server to interact with ZOS. These consoles are called as Remote consoles.

System console is a primary console which is primarily used to interact with the system. This is called as master console.


Console Limit:

We can have 1-99 of MCS/SMCS consoles and one System console for a single LAPR or in a whole SYSPLEX.




PARMLIB members

This section describes the PARMLIB members that affect the console definition.

CONSOLxx – Main configuration dataset
PFKTABxx - Definition of PF Keys
MPFLSTxx - Message Processing Control
CNGRPxx - Candidate group definition


CONSOLxx Statements:

CONSOLE - used to define the characteristic of console.
DEFAULT – used to define routing codes for unsolicited messages
INIT - used to allocate the buffers for WTO, WTOR etc...

I covered all the necessary parameters of these statements in the following sections.


Sample Defintions:

Content of CONSOLxx member

INIT CMDDELIM(")
          MLIM(3500)
          LOGLIM(2500)
          MONITOR(DSNAME)
          MMS(NO)
          PFK(00)
          RLIM(10)
          UEXIT(N)

DEFAULT ROUTCODE(ALL)

CONSOLE DEVNUM(700)
                   ALTERNATE(701)
                   ROUTCODE(ALL)
                   PFKTAB(PFKTAB1)
                  AUTH(MASTER)
                  UNIT(3277-2)
                  MONITOR(JOBNAMES-T)
                  CON(N)
                  SEG(19)
                  DEL(RD)
                  RNUM(19)
                  RTME(1)
                  MFORM(J,T)
                 AREA(NONE)
Details:

INIT Statement:

CMDDELIM – is used to assign the command delimiter character so that the operators can issue multiple commands at a same time.

MLIM – it is used to specify the maximum no.of buffer limit for WTO messages
1 unit = 352 bytes

LOGLIM – used to specify maximum no of buffer limit for SYSLOG
1 unit = 140 bytes

MONITOR – this is the customization parameter for MOUNT request

MMS – used for message translation service

PFK – used to select PFKTABxx member

RLIM - used to specify maximum no of buffer limit for WTOR messages
1 unit = 96 bytes

DEFAULT Statement:

ROUTECODE – used to assign route codes for unsolicited messages


CONSOLE statement:

DEVNUM - used to specify the console device address which is defined using HCD

ALTERNATE - used to specify the alternative console device address

ROUTCODE - what are messages we want to display in this console

PFKTAB - used to specify the Program function definition table

AUTH(MASTER) – used to specify the authentication level

UNIT(3277-2) - unit type in this case the screen size 24x80

MONITOR(JOBNAMES-T) - determine the depth of messages to be displayed in this case job name with time stamp

CON(N) - decide whether conversational or non conversational mode

SEG(19) - the no of lines to be deleted when you give CONTROL or SEG command

DEL(RD) – decide the deletion mode. In this case the mode is Roll and delete

RNUM(19) – no.of lines to be rolled off for each roll

RTME(1) - no.of seconds between each roll off

MFORM(J,T) – message format j-job,T-with time stamp

AREA(NONE) – out-line-display area the minimum and maximum limit depends on the unit type.



Example of PFKTABxx


PFKTAB TABLE(PFKTAB1)
PFK(01) CMD('K S,DEL=RD,SEG=19,CON=N,RNUM=39,RTME=01,MFORM=J;K A,NONE')
PFK(02) CMD('K E,1 ERASE ONE LINE')
PFK(03) CMD('K E,D ERASE STATUS DISPLAY IN AREA')
PFK(04) CMD('K D,F FRAME DISPLAY FORWARD IN AREA')
PFK(05) CMD('K S,DEL=N HOLD IN-LINE OUTPUT')
PFK(06) CMD('K S,DEL=RD RESUME IN-LINE OUTPUT')
PFK(07) CMD('D A,L LIST ACTIVE JOBS AND TSO USERS')
PFK(08) CMD('D R,L LIST OPERATOR REQUESTS')
PFK(09) CMD('K D,U UPDATE DYNAMIC DISPLAY')
PFK(10) CMD('D C,M MASTER CONSOLE')
PFK(11) CMD('D C,HC HARDCOPY')
PFK(12) CMD('D A;D C COMMANDS')
So from the above contents it obvious to see each PF key is associated with one system command. So if you press any PF key then it will invoke the appropriate command.

Post-amble:

If you want to know further details, you can refer the following Redbooks

1) MVS Initialization and Tuning Reference

2) Z/OS MVS Planning: Operations.



Best of luck.

Wednesday, December 12, 2007

REXX – How to write a hello world program

REXX – Restructured Extended Executer

What is REXX?

REXX is a scripting language like Perl, UNIX shell scripts and developed by IBM. You can use REXX to simplify the admin tasks like creating bulk no.of users, creating bulk datasets, recalling bulk datasets etc…and also it can be used in Panel programming.

If you don’t have any idea about script language, you can assume REXX is used to execute the collection of system commands according to our logic. This logic can be coded using control constructs like IF..THEN..END,DO..END etc..

So REXX will ease the work of administrator, With out REXX it will be very difficult to perform any large or repetitive tasks.

If you already know any programming languages then REXX will be very easy to learn.


Steps to create REXX program

1) Create a sequential dataset with RECFM=FB, LRECL=80 or it can be a member of any PDS with these attributes

2) Code the following

Line1:  /*REXX*/ 
Line2:  
CLEAR  
Line3:  
SAY ‘Welcome to rexx coding’  

Notes:

/* */ - any statement with in this will be considered as comment.
Line1:The first line of the any REXX script must contain the word 'REXX'
Line2: to clear the screen
Line3: to display the string 

3) Save it

4) You can execute it by the following ways

Assumes you have the coding in the dataset ‘HLQ.NAME.EXEC(FIRST)’

Then

• From TSO ready prompt you can type EXEC ‘HLQ.NAME.EXEC(FIRST)’ EXEC [Explicit Execution]
• Or you can first concate your PDS to SYSEXEC DD and type %FIRST in TSO ready prompt.[Implicit Execution]
• Or typing EX at DSLIST(Option 3.4) line command area




Note:

To concate the PDS to SYSEXEC DD use the following command

CONCAT DD (SYSEXEC) DS (‘HLQ.NAME.EXEC(FIRST)’)


Basic way of coding REXX

Normally we code the REXX in the following way

1) Execute some system commands by using REXX
2) Collect the Output of that commands to the Stem* variables
3) Process the data which we have collected in stem variable according to our logic or execute some other system commands

*Stem variable – you can assume it as a array variable


For example if your aim is to find the Name of a particular userid then

1) You have to identify the required system commands.In this case you can use
RACF command LU

2) The output of the command will contain the name field which contains the name information of the person. So to not displaying all the info in the screen you will use
Outtrap REXX command to capture the output of the command to a stem variable.

3) Then you will extract only name info from the stem variable and display it on the screen.


Final Words

By using REXX you can do a lot of stuff like panel progrmming etc.. REXX will save a lot of time and efforts of the SYSPROG.So it is a good idea to learn REXX.

The purpose of this article is just to give you a basic idea of REXX. So don’t worry if you couldn’t understand any topics.

If you are interested in REXX, I suggest you to refer REXX user guide from IBM Redbooks.

Your comments are always welcome.

Best of luck.

Mainframe -Evolution

Mainframes - Evolution

This article discusses IBM’s evolution over the last few years, and introduces its newest mainframe, the System z9 109. If you don’t recognize the names above, you will by the end of this article!

In 2000, IBM made an audacious change. The industry had enjoyed more than 35 years of mainframe evolution, from System/360 through S/370 to S/390. (The missing link—what should have been called System/380—was instead named System/370 Extended Architecture, or S/370-XA. This anomaly may have resulted simply due to marketing choices, but may also have occurred in part because of the System/38. Released in 1978, the System/38 was descended from IBM’s Future Systems project, which would have replaced the System/370 with a revolutionary but incompatible architecture, and was almost named System/380.)

In a sweeping move, IBM in 2000 renamed all its processor lines as “eServers.” Netfinity PCs became eServer xSeries; RS/6000 RISC machines become pSeries; the AS/400 became iSeries; and the S/390 became zSeries.

The move was more than cosmetic. Historically, the different product lines were developed and sold by different parts of IBM. This led to fragmentation and confusion: The site that needed a medium-size system might be wooed by both a mainframe and an AS/400 sales representative, each claiming their product was superior, even though both were from the same company!

At times, this internal rivalry caused IBM itself difficulty making rational decisions. For example, the IBM PC Server S/390, or P/390, was a PC workstation that contained a special card that provided S/390 processing capability. Introduced in the mid-90s, the P/390 almost didn’t make it to market because the RS/6000 organization within IBM fought against it. Their premise was that the mid-size companies the P/390 would appeal to were their territory, and how dare the mainframe folks poach their customers! Of course, the reality was that companies that needed a smaller mainframe were unlikely to even consider an RS/6000. If forced to migrate to another platform, they’d suddenly find a plethora of choices available, including Sun, HP, and DEC, all of which had successful Unix architectures competing with the RS/6000.

The historical separation across hardware lines also meant that different divisions were solving the same problems with little interoperability: Peripherals such as tape drives were rarely interchangeable, and the machines shared little visual commonality. Since the reorganization, hardware cross-pollination has resulted in iSeries and pSeries machines sharing underlying Power processors; both integrated and outboard xSeries co-processors for iSeries enabling tightly coupled Intel-based computing within an iSeries chassis; and all four families sharing storage, via the TotalStorage “Shark” arrays.

The shift to all-black chassis, echoing the successful tradition of the ThinkPad laptops, also provided a visual family tie. And the rumored “eClipz” project will use multiple common components for machines from embedded systems to future mainframes. The processors and microcode will vary, but the rest of the machine—I/O subsystem, memory, hardware console, power, packaging and cooling—will be shared.

With the eServer re-branding, the IBM server sales teams were also integrated. Instead of selling four different lines, IBM now sold eServers. The move wasn’t without risk. Many thought re-branding was a real gamble and could lead to a dilution of the overall IBM brand, loss of “mind-share” and market share.

Coupled with new, sexier designs and a concurrent push for Linux on all platforms, the eServer consolidation was a success. IBM has led the server market for the last five years. They even created the first ever television advertisements for mainframes!

During this period, the zSeries name became a recognized synonym for mainframe, and four zSeries lines were released: the original z900, followed by its little brother, the z800, and then the z990 and z890.

Operating systems for zSeries share the letter designation: z/OS, z/VM, z/VSE and, most recently, z/TPF. (The slash in the operating system names has been a source of confusion. The rule is actually simple: Software gets a slash; hardware doesn’t. The only tricky part of this is that the architecture is considered software, and is thus“z/Architecture.”)

On July 27, 2005, IBM announced a re-branding and a new family of z/Architecture mainframe processors. The eServer zSeries z990 was replaced by the System z9 109. The short name for these new machines is “z9-109.” This renaming may seem minor, but from a marketing perspective, it represents another significant shift. IBM is once again selling systems rather than servers.

This change from eServer zSeries to System z9 mirrors similar re-branding of iSeries, pSeries and TotalStorage, which are now System i5, System p5 and System Storage respectively. Curiously, xSeries and iSeries machines are still branded as eServer.

IBM taxonomy and marketing theology are complex but worth understanding. Prior to this announcement, the mainframe brand was IBM eServer; the family was zSeries; and the model was 900, 800, 890, or 990. Now, the brand is IBM; the family is System z9; and the model is 109. Additionally, there are five configuration models available: S08, S18, S28, S38, and S54.

To make things more complex, each IBM product has a name, such as “System z9 109,” as well as one or more product numbers. A product number consists of a four-digit number, called a machine type, followed by a dash and a three-character model, which is the same as the configuration model listed above.

Like its zSeries predecessors, the z9-109 is available as a single machine type (2094). The five models are built on the z990 “book” concept of modules containing multiple CPUs, only some of which need be enabled, and continue the IBM mainframe tradition of upgradeability across the line, ranging from a single 600 MIPS engine to a 54-way, offering a staggering 18,000 MIPS.

The model scheme is simple. Each adds one “book” to the previous model, and for all, the numeric portion indicates the maximum number of CPUs available on that machine. The exception is the S54, which is a four-book machine like the S38, but with extra CPUs enabled on each book. With the eight System Assist Processors (SAPs) and two spares, the 64 physical processors in an S54 leave 54 available for configuration as CPs (normal z9 CPUs), IFLs (full-speed processors that can run Linux only on zSeries or z/VM, thus reducing license fees for z/OS shops), zAAPs (Java engines), or additional SAPs.

Figure 1 shows how you can configure five models ranging from the S8 to S54. Suffice it to say this mid-life kicker to the existing hardware architecture provides more, better, faster mainframe processing than ever before. With ever-increasing processing demands, particularly in the growth of Linux on zSeries, the z9-109 offers uch-needed relief for high-end shops.

Beyond just “feeds and speeds,” IBM is touting the z9-109 as an example of “holistic balanced system design.” This somewhat touchy-feely sounding phrase is relevant, as it expresses what mainframers have long recognized: Clock speed isn’t everything. Even the fastest Intel processor can be easily brought to its knees by a single application (try burning a DVD and doing almost anything else simultaneously!), whereas mainframes have for decades supported many hundred simultaneous users, with 100 percent CPU utilization, thousands of devices active, and good response time. This isn’t just due to operating system design; it’s also due to an architecture that emphasizes these traits. Intel hardware spent 20-plus years focusing on clock speed. For much ofthat time, PC I/O architecture made relatively minor advances, and most machines can be easily bottlenecked by I/O limitations.

IBM believes a key feature is balancing I/O capability, MIPS (clock speed), n-way multi-processing, and main storage. The System z9 machines exemplify that philosophy. Figure 2 shows the evolution, from the G5 and G6 9672s, through the zSeries machines, to the z9-109, which is the most evenly balanced machine yet.

Most of the readers will recognize Freeway, Raptor, Ptero, and T-Rex as the fairly public IBM codenames for the z900, z800, z990, and z890, respectively. These names are interesting because they reflect the evolution of the technology. Freeway was the “big road” to the future—the first 64-bit machine, replacing the 31-bit machines that were becoming too small. Raptor, T-Rex, and Ptero (short for Pterodactyl) were dinosaurs. That generation of naming reflected the perception that mainframes were huge, powerful—and from the past. IBM has clearly re-thought that approach; mainframes have proven their staying power, rather than becoming extinct.

Thus with the z9-109, IBM has gone from dinosaurs to gods. Danu is the Irish/Celtic Earth Goddess, matriarch of the Tuatha D_ Danann (“People of the Goddess Danu”), and mother of many Irish Gods, including the Dagda, God of the Earth and treaties and ruler over life and death (who is also sometimes listed as her father); Dian Cecht, God of healing; Ogma, God of speech, said to lead his followers around by chains of gold and amber, leading from his tongue to their ears; Lir, God of the sea; and Lugh, the “Shining One,” God of the sun. Danu’s Welsh equivalent is the goddess Don.

The wealth of possibilities for naming, using this new scheme, promises a rich future for the IBM mainframe. It seems only appropriate that the most powerful general-purpose computers on Earth are named after a deity!


References:

www.zjournal.com

Welcome to my blog

Hi welcome to all,I am working as a System programmer and having limited experience.I have decided to create a blog where i can share my knowldge about mainframes and my experiences.

Here i will discuss about ZOS,DB2,CICS,IMS,REXX,ASSEMBLY,USS,TSO/E and Mainframe H/W.
Since I am a System Programmer, Mostly i wil focus on  Z/Os,USS,REXX,ASSEMBLY.

I hope it will be very useful to you all.

Best of Luck.

Thank you.