TSO Access Revoked

This forum provides the support of Dezhi Mainframe systems. Please post your questions about logon, usage of our mainframe environment.

Moderators: sysprog, prino, sfan, steve-myers, Tim001

TSO Access Revoked

Postby tarique » Sat 20 Sep 2014, 08:35

Hello,

I had registered my TSO login ID yesterday and was using IBM Personal Communication (Trial version) to access the Fandezhi MF. Unfortunately, I had fiddled around with the 'Session Parameters" and changed the screen size on the Emulator, which resulted in "IKT00405I SCREEN ERASURE CAUSED BY ERROR RECOVERY PROCEDURE" errors. I tried using a new PCOMM profile and kept logging in and out, hoping that the problem would resolve itself, but to no avail. Upon searching around the net for quite sometime, I came across a probable solution which said that they had to delete the ISPROF dataset to resolve the problem. Source : http://ibmmainframeforum.com/viewtopic.php?f=46&t=4553. I did the same thing to resolve the issue and when I logged in today, I found that my TSO access has been revoked.

The admins might have considered it a 'dangerous' behavior (considering that I had only just registered my ID) but I had no intentions otherwise, whatsover. If that consituted a RACF violation, might I ask, how do I seek help in such circumstances? Since I was not messing up with someone else's datasets, I did not think it could result in a ban.

Could you please suggest if the ban could be revoked? If not, do you suggest that I request for a new ID? Would that be considered?
tarique
 
Posts: 3
Joined: Fri 19 Sep 2014, 20:01

Re: TSO Access Revoked

Postby steve-myers » Sat 20 Sep 2014, 11:03

Your ISAPTAN ID was "banned" because you allocated well over 4000 tracks for a data set. The TARIQUE ID was banned because it appeared to be the same person; the admins have a policy that once a user has been banned they are banned forever. However, since ISAPTAN was not "banned" for a security issue, I think the admins might be persuaded to reinstate the ID. The other ID will remained "banned."

I have - 20+ years ago - assisted people with ISPF issues by deleting their ISPPROF data set, but these were established users that somehow damaged their data set. For a "new" user I'm not sure deleting the ISPPROF data set will have a positive effect.

I have used PCOMM in the past with no real issues, but that was in the 1990s. My colleague here favors the Vista TN3270 emulator; I use a different, very slightly more expensive (though much less expensive than PCOMM), emulator that I've been using for almost 15 years. One big advantage with Vista is it's author has a userid on Fandezhi and can investigate issues quite easily.

When you configure PCOMM, stick with "standard" screen sizes like 24x80 or 43x80. I've been using 43x80 for 14 years now. It was a bit of a shock at first, but I can't conceive of life with a 24x80 screen now. You'll revert to 24x80 for your logon, but it will change to 43x80 once you're logged on.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43

Re: TSO Access Revoked

Postby tarique » Sat 20 Sep 2014, 14:15

Hi Steve,

Thanks for the quick reply. ISAPTAN was indeed my first ID and the only ID I had hoped to continue with. I did not realise that my ID was *banned* for allocating a PDS with 4000 tracks. I do understand that that's a big size for a guest user, but the rules don't state that the userID will be revoked for allocating a big dataset, if I'm not wrong? Perhaps a warning would have helped? I understand that the admins do not have emails for every user so it is not possible to inform someone beforehand, but banning someone for this sounds a little harsh IMO.

Do not allocate oversized data sets, allocating something with (CYL,(50,50)) (and we have seen even worse) will result in those data sets being deleted without warning. Ditto for VSAM data sets, do not use more space than you need. Also do not allocate multi-volume data sets, they will get the same treatment, i.e. deletion without warning! Do not define GDG's with excessive (> 10) limits, and make sure you create the base with the 'NOEMPTY' and 'SCRATCH' options!

Always make the blocksize of any data set you allocate as close as possible to, but not exceeding to a half-track, i.e. 27998 bytes. For an FB(80) data set this means a BLKSIZE=27920, for any VB data set this means BLKZIZE=27998. We do not want to see any more FB(80) data sets with a BLKSIZE=800! Any FB(80) source data set (COBOL, PL/I, JCL, DBRM, CNTL, PROC, OBJ) that does not have a BLKSIZE=27920 is subject to deletion without warning, and if you persist in allocating such datasets, you will be banned!


Honestly, I had believed that the ISAPTAN id was revoked as I had tried to allocate a dataset with the HLQ TEST.ISAPTAN (as I'm used to, at work). That had resulted in a couple of RACF warnings but I had no intentions of going against the community rules.

It would be great if you could please delete the TARIQUE user ID and reinstate the access for ISAPTAN. Appreciate your concerns and all your help in this regard.

Regards,
Tarique
tarique
 
Posts: 3
Joined: Fri 19 Sep 2014, 20:01

Re: TSO Access Revoked

Postby steve-myers » Sat 20 Sep 2014, 14:24

The admins will delete TARIQUE about October 1; you can delete it yourself through the web site.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43

Re: TSO Access Revoked

Postby tarique » Sat 20 Sep 2014, 14:32

Hi Steve,

I've just deleted the ID TARIQUE and I'm able to login with the previous ID ISAPTAN. Thanks again for your help.

Much appreciated.

Regards,
Tarique
tarique
 
Posts: 3
Joined: Fri 19 Sep 2014, 20:01

Re: TSO Access Revoked

Postby steve-myers » Sat 20 Sep 2014, 18:09

Quite a few of my data sets are not FB/80/27920, though not F/80/80 or FB/80/800. The "large" PDS data sets follow their rules, though I just noticed one is FB/80/6160, probably to match SYSFAN.CLIST; the data set was allocated 4 years ago so I don't remember. In a PDS, FB/80/27920 doesn't buy you all that much anyway, and there are situations when it costs. Long ago, as an experiment, I wrote a custom source type PDS copy that did track management and it would write short blocks at the end of a track to fill the track so there was essentially no unused space at the end of a track, in spite of nominal FB/80/27920 DCB attributes. Yes, it did save a little space, but not enough to justify the cost of doing it. Worse, I realized there were some situations where it could hurt down stream. I got the idea after examining load module PDS data sets built by the Binder, where it seemed to me the Binder was playing the same game. In any event, I gave up on the idea.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43


Return to Dezhi systems: Mainframe

Who is online

Users browsing this forum: No registered users and 0 guests