Top 10 reasons why we joined IT

Top 10 reasons why we joined IT...
1) I hated sleep.
2) I had enjoyed my life enough.
3) I couldn’t live without tension.
4) I wanted to pay for my sins.
5) I believed in Bhagwad Geeta: Work but don’t expect results out of it...
6) Everything in life has a reason; I wanted to prove it wrong.
7) I wanted to take revenge on myself.
8) I liked doing politics between people
9) I always wanted to curse other peoples on whatever things they do (Even if it is correct).
10) I don’t want to give exercise to my body and want to sit at the same place.

Confidence-Trust-Hope

One line definitions for Confidence, Trust and Hope.
CONFIDENCE
Once, all village people decided to pray for rain. On the day of prayer all people gathered and only one boy came with an umbrella.
That's Confidence

TRUST
Trust should be like the feeling of a one year old baby when you throw him in the air, he laughs......because he knows you will catch him.
That's Trust

HOPE
Every night we go to bed, we have no assurance to get up alive in the next morning but still you have plans for the coming day.
That's Hope

HAVE CONFIDENCE,
TRUST OTHERS &
NEVER LOSE HOPE.
In Life do the ordinary, GOD will do extra ordinary,
Do the natural, GOD will do supernatural
Do the possible, GOD will do impossible.

The aging mainframer

A continuing, lingering perception that the mainframe is dead persists in some parts of the IT industry. It seems that we constantly hear that big IT shops are getting rid of their mainframes. But rarely do we ever hear about it after the fact. No, it is usually reported right when someone thinks that it is a good idea.
Now don't get me wrong. I'm sure there are some shops that have removed their mainframe. But I'm also sure that there are many more that thought about it but couldn't do it -- as well as those who wouldn't even consider it.
A bigger problem for the mainframe than the misguided notion that it is more costly than other computing platforms is the aging of the mainframe workforce. This is a reality. If you don't believe me, go to a SHARE conference and fix your eyeballs on some of the dinosaurs attending mainframe sessions there (myself included).
Basically, the problem is that mainframe experts are getting older and slowly retiring. And who will replace them? Most young IT professionals do not choose to work on mainframe systems, instead choosing to concentrate on the latest technology bandwagons -- things like Windows and Linux, open source and so on. Put one of these newbies in front of a terminal and introduce them to the joys of JCL, ISPF and COBOL, then watch them scream out the door yelling "I want my Java!"
But that is probably an inaccurate perception. You see, mainframe no longer means ugly old green screens. Today's mainframe environment is quite different from the mainframe of yesteryear. That hulking, water-cooled beast you may remember has been replaced with chip-based, CMOS, air-cooled systems. Today's mainframes are easier to hook together using Parallel Sysplex technology. And all of the "modern" technology used on Windows and Linux platforms works on the mainframe, too. Yes, that means XML, Transmission Control Protocol/Internet Protocol, Java and so on are all mainframe technologies, too.
Nowadays, the biggest mainframe "problems" are training and PR. Let's focus on training first. Mainframe technology is not taught by most universities these days; this really needs to change. What is needed is a comprehensive educational program delivered through major universities, as well as IT-focused institutions like DeVry and NorthFace universities. The program should be sponsored by major mainframe vendors like IBM and Computer Associates International, which could provide hardware and software, as well as a conduit for hiring graduates. Doing so would help to further promote and extend the mainframe -- a platform that benefits vendors' bottom lines.
And why would universities be interested in such a program? Employability of their graduates! As the current crop of mainframe experts retire, companies will have to replace them. I'd venture to guess that five to 10 years down the line, it will be easier for an IMS DBA, for example, to get a job offer than an Oracle DBA. The demand will be greater for the IMS talent because the supply is so low.
The publicity component is a bit more difficult. So much has been written and implied about the mainframe being dead that a lot folks believe it. But the mainframe continues to be a robust, viable component of today's IT infrastructure. Organizations continue to add more MIPS, deploy more applications and run their most important, mission-critical applications on mainframe computers. Until this aspect of the mainframe is publicized more, the existing perception is likely to linger.
Or maybe we should just give the mainframe a new name and pretend that it is a new technology with better availability, scalability and performance than the existing platforms.
Craig Mullins is president and principle consultant of Mullins Consulting Inc., in Sugar Land, Texas. He is the author of the DB2 Developer's Guide and Database Administration: The Complete Guide to Practices and Procedures, and has published several hundred articles on database technology.

Create a New member using JCL

//MANIMA JOB (020406),'MANI/941-2',
// MSGLEVEL=1,MSGCLASS=O,NOTIFY=MANIM,
// CLASS=A
//STEP010 EXEC PGM=IEBUPDTE,PARM=NEW
//*
//SYSUT1 DD DUMMY
//SYSUT2 DD DSN=MANIM.TEST.JCL,DISP=SHR
//SYSPRINT DD SYSOUT=X
//*
//SYSIN DD DATA,DLM='><'
./ ADD NAME=SAMPLE,LIST=ALL
/* REXX */
/* SAMPLE */
/***********************************************************/
SAY 'MANI'
EXIT
./ ENDUP
><
//*

Renaming VSAM Datasets

Here's a quick and easy way to rename VSAM datasets and components in ISPF without having to retype all or part of the new name. It's especially useful if you have multiple datasets to rename:

1) Display the datasets you need to rename using option 3.4 or DSLIST.

2) Enter SHOWCMD ON on the command line. This will allow you to modify commands entered on the Dataset List panel before they're executed.

3) Tab down to the line with the dataset you want to rename, type the following and press Enter:
ALTER / NEWNM(/) Example:
------------------------------------------------------------------DSLIST - Data Sets Matching VTSUL.VTCMHCommand ===>
Command - Enter "/" to select action Message
------------------------------------------------------------------
alter / newnm(/) CMH.VT1001CT.NEWTICKT.MSTR VTSUL.VTCMH.VT1001CT.NEWTICKT.MSTR.DATA VTSUL.VTCMH.VT1001CT.NEWTICKT.MSTR.INDEX
------------------------------------------------------------------

4) When the expanded command is displayed, overtype the new dataset name in the NEWNM parameter field with your changes, and press Enter to execute the ALTER command. Example:
------------------------------------------------------------------
Data Set Name. : VTSUL.VTCMH.VT1001CT.NEWTICKT.MSTR
Command before expansion: ALTER / NEWNM(/)

Command after expansion:===>
ALTER 'VTSUL.VTCMH.VT1001CT.NEWTICKT.MSTR' NEWNM('VTSUL.VTCMH.VT1001CT.NEWICKT.MSTR')
----------------------
Remember, each component of a VSAM Cluster (DATA, INDEX, etc.) must be renamed individually.

5) Repeat the command for the remaining datasets and/or components using the '=' command.
This handy trick could also be used to perform other similar tasks... just use your imagination!

Tips for Success

1. Reward yourself. Treat yourself when you hit milestones on the way to your goals. A magazine subscription, a night on the town or just time for yourself to dream are great ways to celebrate.

2. Keep track. Record your daily progress. Something as simple as a daily checkmark will keep your goals top of mind.

3. Talk it up. Share your goals with your friends and family, by telling others you increase your accountability.

4. Be detailed. Write down precisely what you want to achieve. "Reduce bodyfat to 13% by March." Is much more powerful than "Get in shape."

5.Visualize. Imagine what it will be like to achieve your goal. Better yet, picture yourself doing what it takes to realize your dream.

Ten Commandments of ego less programming

1. Understand and accept that you will make mistakes. The point is to find mistakes early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We aren't surgeons; we can learn, laugh, and move on.

2. You are not your code. Remember, the entire point of a review is to find problems and problems will be found. Don't take it personally when a problem is uncovered.

3. No matter how much karate you know, someone else will always know more. This fact kept the Samurai from indiscriminately attacking people in Imperial Japan. In our less violent times, the individual who knows more can teach you some new moves if you ask. There will always be people who know more than you. Seek and accept input from others, even when you think it's not needed.

4. Don't rewrite other programmers' code without consultation. There's a fine line between "fixing other programmers' code" and "rewriting other programmers' code." The former implies that a bug or other functionality problem exists and needs to be fixed; it can also refer to correcting gross readability problems. The latter, however, refers to changes made to code for the sake of style. Programmers fresh from college are often guilty of this. Things like renaming variables, the use of a different construct, re-commenting, or gratuitous reformatting of white space fall into this category. Such activities, even with the purest of motives, are high hubris and detrimental to team mentality.

5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Becoming angry only reinforces this perception and teaches people to avoid asking questions. This can only harm your work in the long run.

6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

7. The only true authority stems from knowledge, not from position.Knowledge engenders authority, and authority engenders respect so if you want respect in an egoless environment, cultivate knowledge.

8. Fight for what you believe but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.

9. Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

10. Criticize code instead of people; be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance etc.