Re: Testing System Programmer Capabilities
Arthur wrote: I've seen users accidentally bring a system to its knees Back in the 90's someone that was logging on to a system using a TPX type product, kept on taking VTAM down. The command she was supposed to enter was logon applid=tso instead she typed logon applis=tso... and when she claimed that she caused it, The senior sysprog told her that she could not possibly have the authority in the system to do such a thing, she was adamant, called him over and showed him... Sadly she got a bit of a brushing over that... to this day, I still cannot imagine what on earth could have been the cause of this problem with VTAM on OS390 1.3 Regards Herbie Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Tue, 26 Jun 2007 19:44:52 -0500 Kenneth E Tomiak [EMAIL PROTECTED] wrote: :On Tue, 26 Jun 2007 15:15:15 -0500, Patrick O'Keefe :[EMAIL PROTECTED] wrote: :I not only agree, I get a very uncomfortable feeling just hearing :about the excercise. I know I'm more paranoid than most, but if :I really wanted to hose over a system I might pretend to be from a :consulting firm and ask a bunch of system programmers for a list of :hacks that would stretch the abilities of other system programmers. :That's probably not at all what's involved here, but I don't like thefeel :of it. Then they wouldn't be asking for hacks requiring special authority. :If this company being asked to test the SysProgs is legit, they could always :corrupt their own system, then back up the dump to tape and ask the :SysProg to shoot the bug they caused by doing unnatural acts. Maybe they want to do the test under pressure? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On 6/27/07, Kenneth E Tomiak [EMAIL PROTECTED] wrote: If this company being asked to test the SysProgs is legit, they could always corrupt their own system, then back up the dump to tape and ask the SysProg to shoot the bug they caused by doing unnatural acts. Those things get much less disruptive when you can use z/VM for it. I was recently talking to a z/OS customer who considered running z/OS systems under z/VM for training. You could certainly extend that to break a system on purpose. Back when we were using RVA, I had a setup that allowed for a clone of the production system to test recovery procedures. With z/VM you can do that during office hours (or from home in the evening) and you can leave it for a while when more urgent matters show up. That does not have the pressure of a real crisis, but I don't think you train fire fighters by burning down a house with folks inside... We used to have a collection of such things folks could take to hone their skills when they had a few hours to spare. Like debugging a nice dump, or get hold of a system with a broken RACF database, set up a network with a few subareas, etc. But ran out of folks wanting to learn and/or have hours to spare... Rob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
In [EMAIL PROTECTED], on 06/25/2007 at 03:29 AM, Eric Sun [EMAIL PROTECTED] said: Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. Why of course? Don't you have a test LPAR? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Mon, 25 Jun 2007 16:07:16 +0800 Charokee Sun [EMAIL PROTECTED] wrote: :Our company recently had been given a task by our client to test the :responsiveness and capabilities of their systems programmer in their test :environment. Our tasks assigned include to hack their system to :cause/simulate system and application outage, of course not to the extent of :hanging/re-IPLing the whole system. :Just want to know whether anyone out there have done any similar test before :and willing to share what they have tested. Btw, we will be provided with :powerful TSO user IDs but won't be allowed to touch any system module and :probably just to change some control blocks in memory. Somehow, it seems :easy to think what you can do in CICS and DB/2 but it's easier said than :done in MVS. :The systems programmers will be given at least 1-1/2 hour limit to resolve :the problem. Altering some CICS options in memory seems easy enough. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Mon, 25 Jun 2007 14:43:38 -0400 Tim Hare [EMAIL PROTECTED] wrote: :Question: how do we know that your organization is not just asking us to :provide a way to disrupt mainframe systems? No offense intended, at all; :it's just a basic security question. If he has the powerful ID, he has the ability anyway. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
well I just had some fun and games, we have a large ISPF panel library which is a merge of ISPF and other product panel ibraries. the dataset is LLA/VLF managed. and during a change, it got emptied. very. very soon after a refresh no one could use ISPF! (problem restricted to a development system with approx 500 TSO users active) took me a little while, with the help of a RACF security administrator, to fix the problem. maybe this is the sort of test of friend is asking for. the young guys here were impressed:- 1. How to break out of the auto-allocate exec process. (very needed as there is an automatic LOGOFF stacked after ISPF) 2. How to allocate alternative panel library concatenation. To access ISPF. 3. How to get access to re-load the empty dataset. 4. How to get acess to refresh LLA. 5. Validating that the re-load and refresh all worked correctly. (normally, the access to load the dataset and refresh LLA is tied to running a package through the change management system.) much fun! :-D Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Tue, 2007-06-26 at 04:35 -0500, Bruce Hewson wrote: the young guys here were impressed:- 1. How to break out of the auto-allocate exec process. (very needed as there is an automatic LOGOFF stacked after ISPF) 2. How to allocate alternative panel library concatenation. To access ISPF. Tsk, tsk Bruce - you don't have a minimal proc to enable a panic logon ???. Shame on you ... ;0) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Doc Farmer Okay, I'll give it a shot: [ snip ] 2) The CIO, a big-iron neophyte, wants an explanation why you need an upgrade from a z890 to a z900, with an addition of 6 new CPUs and 256GB of main memory, as well as an appropriate number of shark spindles. What do you do? A) Explain the business need as outlined by overall production growth over the past four years. B) Provide RMF charts to show the past 2 years of increased use and the next two years of upgrade capacity. C) Go into a deep technical explanation of hardware and software requirements, explaining in hex wherever possible. D) Bore the CIO into the coma mentioned in Question 1, so that you won't catch seven kinds of hell when you apply that APAR on production until s/he regains consciousness. E) Explain why a z900 would be a *downgrade* from a z890. (Perhaps you meant upgrade to a z9?) [ snip ] -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
In me own defense, m'lud, I did write that while under the influence of cold medication and a 102.7 fever. You're right, I did mean z9. I see, however, that you found no fault with the donut question... :D On Tue, 26 Jun 2007 06:55:50 -0500, Chase, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Doc Farmer Okay, I'll give it a shot: [ snip ] 2) The CIO, a big-iron neophyte, wants an explanation why you need an upgrade from a z890 to a z900, with an addition of 6 new CPUs and 256GB of main memory, as well as an appropriate number of shark spindles. What do you do? A) Explain the business need as outlined by overall production growth over the past four years. B) Provide RMF charts to show the past 2 years of increased use and the next two years of upgrade capacity. C) Go into a deep technical explanation of hardware and software requirements, explaining in hex wherever possible. D) Bore the CIO into the coma mentioned in Question 1, so that you won't catch seven kinds of hell when you apply that APAR on production until s/he regains consciousness. E) Explain why a z900 would be a *downgrade* from a z890. (Perhaps you meant upgrade to a z9?) [ snip ] -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Tue, 26 Jun 2007 06:55:50 -0500, Chase, John wrote: E) Explain why a z900 would be a *downgrade* from a z890. Sure, the z900 is a bit older technology, but how do you figure that it would be a downgrade? Especially with the addition of 6 new CPUs? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant On Tue, 26 Jun 2007 06:55:50 -0500, Chase, John wrote: E) Explain why a z900 would be a *downgrade* from a z890. Sure, the z900 is a bit older technology, but how do you figure that it would be a downgrade? Especially with the addition of 6 new CPUs? General principle is that replacing newer technology with older is by definition a downgrade. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Mon, 25 Jun 2007 22:31:27 -0400, Doc Farmer [EMAIL PROTECTED] wrote: funny stuff mostly snipped LOL 2) The CIO, a big-iron neophyte, wants an explanation why you need an upgrade from a z890 to a z900 That would probably be a downgrade. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On 6/26/2007 3:13 AM, Binyamin Dissen wrote: On Mon, 25 Jun 2007 16:07:16 +0800 Charokee Sun [EMAIL PROTECTED] wrote: :Our company recently had been given a task by our client to test the :responsiveness and capabilities of their systems programmer in their test :environment. Our tasks assigned include to hack their system to :cause/simulate system and application outage, of course not to the extent of :hanging/re-IPLing the whole system. :Just want to know whether anyone out there have done any similar test before :and willing to share what they have tested. Btw, we will be provided with :powerful TSO user IDs but won't be allowed to touch any system module and :probably just to change some control blocks in memory. Somehow, it seems :easy to think what you can do in CICS and DB/2 but it's easier said than :done in MVS. :The systems programmers will be given at least 1-1/2 hour limit to resolve :the problem. Altering some CICS options in memory seems easy enough. Probably true, but I don't think I would consider that a meaningful test. What should we expect the system programmer to do other than (a) recognize that CICS had a problem; and (b) tell operations to restart it. CICS does allow changing of some options via commands, and I suppose one might expect the system programmer to recognize that and correct the problem by issuing the appropriate commands. But if the hacker needed to change bits in control blocks in storage to cause the problem, I would not expect the system programmer to figure out which bits and write a program to fix them. In that situation I would expect a simple restart of the region. And I would not expect it to take 1.5 hours to figure this out and get it restarted. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
Sure, the z900 is a bit older technology, but how do you figure that it would be a downgrade? Especially with the addition of 6 new CPUs? 1. IIRC, z890 - z900 was NEVER a valid path. 2. IBM stopped marketting, shipping, and supporting them over a year ago (if not longer). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On 6/25/07, Arthur T. [EMAIL PROTECTED] wrote: snip However, in terms of testing a sysprog: A much better test than being able to hack a system is being able to undo the results of such a hack. I've seen users accidentally bring a system to its knees, and a sysprog's job is to get the system going again without an IPL, and with minimal impact on schedules and people. snip Agreed! In 25 years of Sysprog work I've always tried to fix problems, not create them. -- Mark Pace Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Tue, 26 Jun 2007 09:17:25 -0400 Walt Farrell [EMAIL PROTECTED] wrote: :On 6/26/2007 3:13 AM, Binyamin Dissen wrote: : On Mon, 25 Jun 2007 16:07:16 +0800 Charokee Sun [EMAIL PROTECTED] : wrote: : :Our company recently had been given a task by our client to test the : :responsiveness and capabilities of their systems programmer in their test : :environment. Our tasks assigned include to hack their system to : :cause/simulate system and application outage, of course not to the extent of : :hanging/re-IPLing the whole system. : :Just want to know whether anyone out there have done any similar test before : :and willing to share what they have tested. Btw, we will be provided with : :powerful TSO user IDs but won't be allowed to touch any system module and : :probably just to change some control blocks in memory. Somehow, it seems : :easy to think what you can do in CICS and DB/2 but it's easier said than : :done in MVS. : :The systems programmers will be given at least 1-1/2 hour limit to resolve : :the problem. : Altering some CICS options in memory seems easy enough. :Probably true, but I don't think I would consider that a meaningful :test. What should we expect the system programmer to do other than :(a) recognize that CICS had a problem; and :(b) tell operations to restart it. It has been a while since I was a SP in a real shop, but if CICS was only partially dysfunctional would it really be - immediately - restarted? Inform all active users to terminate their sessions? I remember that we used to take some efforts to repair things before taking the drastic step. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Tue, 26 Jun 2007 09:56:15 -0400, Mark Pace [EMAIL PROTECTED] wrote: ... Agreed! In 25 years of Sysprog work I've always tried to fix problems, not create them. ... I not only agree, I get a very uncomfortable feeling just hearing about the excercise. I know I'm more paranoid than most, but if I really wanted to hose over a system I might pretend to be from a consulting firm and ask a bunch of system programmers for a list of hacks that would stretch the abilities of other system programmers. That's probably not at all what's involved here, but I don't like thefeel of it. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Tue, 26 Jun 2007 15:15:15 -0500, Patrick O'Keefe [EMAIL PROTECTED] wrote: I not only agree, I get a very uncomfortable feeling just hearing about the excercise. I know I'm more paranoid than most, but if I really wanted to hose over a system I might pretend to be from a consulting firm and ask a bunch of system programmers for a list of hacks that would stretch the abilities of other system programmers. That's probably not at all what's involved here, but I don't like thefeel of it. Pat O'Keefe If this company being asked to test the SysProgs is legit, they could always corrupt their own system, then back up the dump to tape and ask the SysProg to shoot the bug they caused by doing unnatural acts. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Mon, 25 Jun 2007 03:29:44 -0500, Eric Sun [EMAIL PROTECTED] wrote: HI, all Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. Just want to know whether anyone out there have done any similar test before and willing to share what they have tested. Btw, we will be provided with powerful TSO user IDs but won't be allowed to touch any system module and probably just to change some control blocks in memory. Somehow, it seems easy to think what you can do in CICS and DB/2 but it's easier said than done in MVS. The systems programmers will be given at least 1-1/2 hour limit to resolve the problem. Thanks and regards Eric Sun [EMAIL PROTECTED] Why would it be easier to do in CICS and DB2 and not MVS? In addition to the powerful TSO user ID, will you have access to Omegamon, TMON, or some other monitor? That would be the way to go for changing some MVS control blocks, even in CICS and DB2 too. Right up to the point of causing an IPL that is. TTFN .Bigrcube -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
Question: how do we know that your organization is not just asking us to provide a way to disrupt mainframe systems? No offense intended, at all; it's just a basic security question. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
What, pray tell, is the point of this exercise? At 02:30 PM 6/25/2007, you wrote: On Mon, 25 Jun 2007 03:29:44 -0500, Eric Sun [EMAIL PROTECTED] wrote: HI, all Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. Just want to know whether anyone out there have done any similar test before and willing to share what they have tested. Btw, we will be provided with powerful TSO user IDs but won't be allowed to touch any system module and probably just to change some control blocks in memory. Somehow, it seems easy to think what you can do in CICS and DB/2 but it's easier said than done in MVS. The systems programmers will be given at least 1-1/2 hour limit to resolve the problem. Thanks and regards Eric Sun snip Doug Fuerst Consultant BK Associates Brooklyn, NY (718) 921-2620 (Office) (718) 921-0952 (Fax) (917) 572-7364 (Cell) [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Mon, 25 Jun 2007 15:06:57 -0400, Doug Fuerst [EMAIL PROTECTED] wrote: What, pray tell, is the point of this exercise? At 02:30 PM 6/25/2007, you wrote: On Mon, 25 Jun 2007 03:29:44 -0500, Eric Sun [EMAIL PROTECTED] wrote: HI, all Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. Just want to know whether anyone out there have done any similar test before and willing to share what they have tested. Btw, we will be provided with powerful TSO user IDs but won't be allowed to touch any system module and probably just to change some control blocks in memory. Somehow, it seems easy to think what you can do in CICS and DB/2 but it's easier said than done in MVS. The systems programmers will be given at least 1-1/2 hour limit to resolve the problem. Thanks and regards Eric Sun snip Doug Fuerst Consultant BK Associates Brooklyn, NY Just E-X-C-E-R-C-I-S-E maybe?! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
Management is history buffs, this is nearest thing they can get to a gladiatorial combat. They are looking forward to some good action and a few rolling heads ! Hail to the Caesar ! On Mon, 25 Jun 2007 15:06:57 -0400, Doug Fuerst [EMAIL PROTECTED] wrote: What, pray tell, is the point of this exercise? At 02:30 PM 6/25/2007, you wrote: On Mon, 25 Jun 2007 03:29:44 -0500, Eric Sun [EMAIL PROTECTED] wrote: HI, all Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. Just want to know whether anyone out there have done any similar test before and willing to share what they have tested. Btw, we will be provided with powerful TSO user IDs but won't be allowed to touch any system module and probably just to change some control blocks in memory. Somehow, it seems easy to think what you can do in CICS and DB/2 but it's easier said than done in MVS. The systems programmers will be given at least 1-1/2 hour limit to resolve the problem. Thanks and regards Eric Sun snip Doug Fuerst Consultant BK Associates Brooklyn, NY (718) 921-2620 (Office) (718) 921-0952 (Fax) (917) 572-7364 (Cell) [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
LOL, I like that. One would think that maybe screwing up an SMP zone and having them resolve it, or botch and install and have them fix it would be a better test these days. At 03:15 PM 6/25/2007, you wrote: Management is history buffs, this is nearest thing they can get to a gladiatorial combat. They are looking forward to some good action and a few rolling heads ! Hail to the Caesar ! On Mon, 25 Jun 2007 15:06:57 -0400, Doug Fuerst [EMAIL PROTECTED] wrote: What, pray tell, is the point of this exercise? At 02:30 PM 6/25/2007, you wrote: On Mon, 25 Jun 2007 03:29:44 -0500, Eric Sun [EMAIL PROTECTED] wrote: HI, all Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. snpip Doug Fuerst Consultant BK Associates Brooklyn, NY (718) 921-2620 (Office) (718) 921-0952 (Fax) (917) 572-7364 (Cell) [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On Mon, 2007-06-25 at 15:06 -0400, Doug Fuerst wrote: What, pray tell, is the point of this exercise? Maybe the IS director is trying to justify another, more senior position. The existing sysprog is the president's PFCSK son, a whiz at windows - but not all that great a S390 gunslinger. Or maybe management wants to bring in a tester merely to *teach* that PFCSK. Once upon a time I used to do something like this to/for members of my staff. I'd arrange to come in way early in the morning, send the operator out for coffee, and then do *something*. When the operator came back, he'd find the IMS master complaining about e.g. a recalcitrant PTERM. Better take a look at that, I'd say unhelpfully. I'd watch him puzzle it out slowly, and offer leading questions if he appeared to be stuck. Is it active to VTAM? Is the phone line to that campus operational? Do you know where the cables are for that line? Are they connected? By the time he got to that interface switch that I'd flipped off on the oh-five, he'd gotten ten times as much value out of the exercise as he'd have gotten from varying the terminal off-and-on and calling a tech. Sure, test your sysprogs. Do it with good humor, and don't publish the results - it's the testing itself that's important. Then when you can't fool 'em anymore, they're promotable and you've done your job. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
David Andrews wrote: On Mon, 2007-06-25 at 15:06 -0400, Doug Fuerst wrote: What, pray tell, is the point of this exercise? Maybe the IS director is trying to justify another, more senior position. The existing sysprog is the president's PFCSK son, a whiz at windows - but not all that great a S390 gunslinger. Or maybe management wants to bring in a tester merely to *teach* that PFCSK. Once upon a time I used to do something like this to/for members of my staff. I'd arrange to come in way early in the morning, send the operator out for coffee, and then do *something*. When the operator came back, he'd find the IMS master complaining about e.g. a recalcitrant PTERM. Better take a look at that, I'd say unhelpfully. I'd watch him puzzle it out slowly, and offer leading questions if he appeared to be stuck. Is it active to VTAM? Is the phone line to that campus operational? Do you know where the cables are for that line? Are they connected? By the time he got to that interface switch that I'd flipped off on the oh-five, he'd gotten ten times as much value out of the exercise as he'd have gotten from varying the terminal off-and-on and calling a tech. Sure, test your sysprogs. Do it with good humor, and don't publish the results - it's the testing itself that's important. Then when you can't fool 'em anymore, they're promotable and you've done your job. Note that the OP was with a Chinese consulting company located in Beijing. That might put a different light on the speculation. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
Digging a little further ... Sunflower Consulting and Services Co., Ltd. is a 100% Canadian owned Company operates in China. We specialize in IBM mainframe system and application services and have been providing high quality services to customers in China. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Monday, June 25, 2007 4:37 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] Testing System Programmer Capabilities David Andrews wrote: On Mon, 2007-06-25 at 15:06 -0400, Doug Fuerst wrote: What, pray tell, is the point of this exercise? Maybe the IS director is trying to justify another, more senior position. The existing sysprog is the president's PFCSK son, a whiz at windows - but not all that great a S390 gunslinger. Or maybe management wants to bring in a tester merely to *teach* that PFCSK. Once upon a time I used to do something like this to/for members of my staff. I'd arrange to come in way early in the morning, send the operator out for coffee, and then do *something*. When the operator came back, he'd find the IMS master complaining about e.g. a recalcitrant PTERM. Better take a look at that, I'd say unhelpfully. I'd watch him puzzle it out slowly, and offer leading questions if he appeared to be stuck. Is it active to VTAM? Is the phone line to that campus operational? Do you know where the cables are for that line? Are they connected? By the time he got to that interface switch that I'd flipped off on the oh-five, he'd gotten ten times as much value out of the exercise as he'd have gotten from varying the terminal off-and-on and calling a tech. Sure, test your sysprogs. Do it with good humor, and don't publish the results - it's the testing itself that's important. Then when you can't fool 'em anymore, they're promotable and you've done your job. Note that the OP was with a Chinese consulting company located in Beijing. That might put a different light on the speculation. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
On 25 Jun 2007 07:23:21 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Charokee Sun) wrote: Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. I've been enjoying the responses to this. I'm in general agreement that we shouldn't give that kind of information on a public forum, and that the OP shouldn't have asked. However, in terms of testing a sysprog: A much better test than being able to hack a system is being able to undo the results of such a hack. I've seen users accidentally bring a system to its knees, and a sysprog's job is to get the system going again without an IPL, and with minimal impact on schedules and people. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
If you do not know how to accomplish this task then your company is not suited to the task and should decline the offer. There are better ways to test the abilities of staff than cuasing damage of any kind. On Mon, 25 Jun 2007 03:29:44 -0500, Eric Sun [EMAIL PROTECTED] wrote: HI, all Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. Just want to know whether anyone out there have done any similar test before and willing to share what they have tested. Btw, we will be provided with powerful TSO user IDs but won't be allowed to touch any system module and probably just to change some control blocks in memory. Somehow, it seems easy to think what you can do in CICS and DB/2 but it's easier said than done in MVS. The systems programmers will be given at least 1-1/2 hour limit to resolve the problem. Thanks and regards Eric Sun [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Testing System Programmer Capabilities
Okay, I'll give it a shot: 1) You have a critical APAR installation which requires management approval to apply it on production. The Ops Manager is in Aruba, the CIO is in a coma, and your other tech support staff are at a beer bust. What do you do? A) Ensure you've got full backups on Prod, then apply the APAR on your own authority. B) Test it on Dev first - your code monkeys aren't as important as keeping Production up and running. C) Test it on a Sandbox LPAR first - that's what it's there for. D) Sneak it into the Operator's night cycle, then go to the beer bust - let the tape apes take the blame! 2) The CIO, a big-iron neophyte, wants an explanation why you need an upgrade from a z890 to a z900, with an addition of 6 new CPUs and 256GB of main memory, as well as an appropriate number of shark spindles. What do you do? A) Explain the business need as outlined by overall production growth over the past four years. B) Provide RMF charts to show the past 2 years of increased use and the next two years of upgrade capacity. C) Go into a deep technical explanation of hardware and software requirements, explaining in hex wherever possible. D) Bore the CIO into the coma mentioned in Question 1, so that you won't catch seven kinds of hell when you apply that APAR on production until s/he regains consciousness. 3) The local bakery is having a special on donuts - 12 assorted for $6.95. You have four Tech Support staff as direct reports, but you also have 5 operators across two shifts who will require bribing, as well as the Ops Manager and the shift managers. You also have two external auditors doing a SOX review of the system. Two of the people are diabetic, one is lactose intolerant, and one is on Atkins. How many donuts do you order from the local bakery? A) 30 - Allows two per person, plus an extra two for you. B) 24 - Auditors (especially externals) don't get donuts, and YOU'RE the one on Atkins. C) 18 - And you keep them out of the site of the folks with the medical issues. D) None - The local bakery ain't Krispy Kreme! Answers on a 80-column card, please! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Sun Sent: Monday, June 25, 2007 04:30 To: IBM-MAIN@BAMA.UA.EDU Subject: Testing System Programmer Capabilities HI, all Our company recently had been given a task by our client to test the responsiveness and capabilities of their systems programmer in their test environment. Our tasks assigned include to hack their system to cause/simulate system and application outage, of course not to the extent of hanging/re-IPLing the whole system. Just want to know whether anyone out there have done any similar test before and willing to share what they have tested. Btw, we will be provided with powerful TSO user IDs but won't be allowed to touch any system module and probably just to change some control blocks in memory. Somehow, it seems easy to think what you can do in CICS and DB/2 but it's easier said than done in MVS. The systems programmers will be given at least 1-1/2 hour limit to resolve the problem. Thanks and regards Eric Sun [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
