Dezhi Systems support site

The physical server is up and running but the ZOS was down for some reason. Only Mr. "sysprog" can fix this issue.

By the way, the ZOS and this web forum share the same hardware, so I don't think it's a hardware problem.

Someone stopped VTAM, cause TCP/IP and TSO unavailable. It has been fixed.

Please do not stop any existing started tasks. Allowing users to issue system administration commands does not mean allowing abusing it, otherwise we have to remove these access from general public.

sysprog wrote:Someone stopped VTAM, cause TCP/IP and TSO unavailable. It has been fixed.

Please do not stop any existing started tasks. Allowing users to issue system administration commands does not mean allowing abusing it, otherwise we have to remove these access from general public.

Just remove the ability of users to issue admin commands, z/OS is not Windoze which can be rebooted if you screw up. Hell, in most companies most people cannot install programs willy-nilly or even change the time.

Just slap RACF protection on essential started tasks.

prino wrote:

sysprog wrote:Someone stopped VTAM, cause TCP/IP and TSO unavailable. It has been fixed.

Please do not stop any existing started tasks. Allowing users to issue system administration commands does not mean allowing abusing it, otherwise we have to remove these access from general public.

Just remove the ability of users to issue admin commands, z/OS is not Windoze which can be rebooted if you screw up. Hell, in most companies most people cannot install programs willy-nilly or even change the time.

Just slap RACF protection on essential started tasks.

Let me chime in: I don't know if this system has production running (apparently the server runs the Website, under a zLinux guest?) -but since this appears to be a demonstration/training/what-have-you VM guest, I hope that sysprog's admonition can be enough of a warning to us not to do stupid things. I tried logging on this morning, couldn't, and was as concerned as anyone about why, but over-reacting concerns me more. I am actually in the process of brushing up for a RACF engineering contract position not too far away, and this system, in it's current maybe-not-airtight-but-reasonable mode is invaluable to me, and, I would expect, to others. I use it in the spirit of doing some lightweight problem-mode testing (today, a RACROUTE, tomorrow maybe IDCAMS,) in such a way as to not compromise/impact other users, or the system. Console commands are invaluable here to build knowledge as well.

I could be totally wrong, of course, perhaps fandezhi.efglobe.com:23 is really running payroll, but I doubt it...?

-Perhaps someone could (or maybe I can in future) write/donate an "Are you sure?/Are you REALLY sure?" routine to prompt folks who might otherwise accidentally kill the wrong things.

MikeOfNC wrote:... I hope that sysprog's admonition can be enough of a warning to us not to do stupid things. I tried logging on this morning, couldn't,

Given that the site is again unavailable, slapping RACF on essential services is absolutely required!

Someone was playing those MVS commands again, and even issued 'Z EOD' to cause loss of activity tracks. As a result, we had to re-IPL the system.
Thanks for all your valuable input. We are considering removing the MVS command with update access (STOP, START, etc), just allowing READ access (D A,L, etc).

danilohg wrote:I think the lack here is the reason why this mainframe server is available to the people ,that is knowledge and research , and not to work as a playground
And also theres a log..find who did and give him a good bye !

I second that. I'm sure most of us here are, or have been, good solid IT people in real life, and care about this or any machine's health. As a 23-year career system programmer, I do hate getting handcuffed, but totally understand, and both pro-and-con lockdown comments do resonate with me. This deserves discussion.


Suggestion: (I'm sure that I have not been the first one with this thought.)

- My RACF profile, supposedly being nothing special, is in both the USER and ADMIN RACF groups, so I assume(!?) that everyone's is. Perhaps the site might want to consider assigning ADMIN membership to only those who ask for it??

Perhaps petitioners can pass a "board (a thread?) of review" by senior members. Don't know exactly what, but I'm comfortable with some more solid assurance that either (a) you know what you're doing, (b) you know that the onus is on you to keep it stable, and (c) there will be consequences (I hereby volunteer my Mafia connections ) if one tries to get fishy / furtive / "Z EOD"-ey / cracker-ish.

A responsible user/admin/sysop can, of course, make a genuine screw-up, and should be forgiven, provided it is not repeated.

Just my $.02

Oh, also, has anyone else recently been getting a RACF violation when they try to purge/release SDSF held output that they own?

I now only have read access to resource JES2.CANCEL.TSUOUT amd JES2.MODIFY.TSUOUT in the OPERCMDS class, but need update.
I'm guessing that ADMIN group had update access, and now does not...?
[interesting workaround: TSO command processor DELETE will still delete my jobs from JES2.]

MikeOfNC wrote:Oh, also, has anyone else recently been getting a RACF violation when they try to purge/release SDSF held output that they own?

I now only have read access to resource JES2.CANCEL.TSUOUT amd JES2.MODIFY.TSUOUT in the OPERCMDS class, but need update.
I'm guessing that ADMIN group had update access, and now does not...?
[interesting workaround: TSO command processor DELETE will still delete my jobs from JES2.]

We just re-granted UPDATE access to JES2.CANCEL.** and JES2.MODIFY.* to public. However we had to limit MVS commands to READ access to public.

sysprog wrote:We just re-granted UPDATE access to JES2.CANCEL.** and JES2.MODIFY.* to public. However we had to limit MVS commands to READ access to public.

'P' on SDSF is still not possible, see syslog for my tries of purging PRINOJOB, but purging individual JES output is possible.

prino wrote:'P' on SDSF is still not possible, see syslog for my tries of purging PRINOJOB, but purging individual JES output is possible.

It should be fine now.

Not able to get in! Is VTAM down again?


Or the problem is that IBM is blocking my connection?

vedovatto wrote:Not able to get in! Is VTAM down again?


Or the problem is that IBM is blocking my connection?

You should be able to login. If not, please post your specific symptoms.