Disconnect Issues!

[mainframer]

Hello,

Initially I could submit n-number of jobs. But later it was restricted to 4-5, and just 1 in case of multiple Steps.

I know the fact that spool should be clean & clear. I always do that.(expect some occasions like no login or power issue)
As disconnect feature is not working and I have electricity fluctuation in my area, I can not re-connect in few minutes I may miss to purge the Jobs from SPOOL.
I have done pre Userid* in spool so I can view only my jobs and clean them and do not miss on this, as I used to do always. I immediately cancel the JOB that enters in Infinite LOOP.(exception is valid here as well)

Now, my request is : 1) can we disconnect our session so we can login again (Disconnect is not working anymore).
2) Can Jobs in spool be deleted automatically.
and main 3). Can we increase the number of submitting JOBs, at least 10 should be there.(just request)

If it is possible, please let us know. I am not a Trainee, just want to be in touch with Mainframes and FANDeZHI is wonderful.


You may introduce Warning system !! depending on severity of Crime( ) so users get few chances to divert himself on right path before any harsh action and avoid abuse of our system.

Thanks,
Garry

[mainframer]

I just tried knowing if am doing something, alone, not following certain rules.

Please do not take it as complaint, just need some focus on this.
Thanks
Garry.

[steve-myers]

I don't think TSO has ever had a disconnect option like z/VM. It does have a "reconnect" option for use when your session is interrupted because of some sort of network issue, but it seldom works, particularly for TCPIP sessions. IBM has made some changes in more recent z/OS releases that are supposed to make TCPIP reconnect more reliable, but I have no direct knowledge if this really works.

Right now the only really reliable reconnect capability is when you use a session manager. The session manager will keep your connection alive if you have a network problem, but dezhi doesn't use a session manager. This works because your TSO session is connected to the session manager, not to your terminal.

[prino]

Initially I could submit n-number of jobs. But later it was restricted to 4-5, and just 1 in case of multiple Steps.

I can submit jobs with 250 steps. I guess you mean multiple jobs in one member. Anyway, I've upped the limit a bit, which should be enough for now. But why do you need to keep so many jobs in the output queue, if the output is really required, you can put it in a dataset, rather than SYSOUT=*...

I know the fact that spool should be clean & clear. I always do that.(expect some occasions like no login or power issue) As disconnect feature is not working and I have electricity fluctuation in my area, I can not re-connect in few minutes I may miss to purge the Jobs from SPOOL. I have done pre Userid* in spool so I can view only my jobs and clean them and do not miss on this, as I used to do always. I immediately cancel the JOB that enters in Infinite LOOP.(exception is valid here as well)

And why would there be an exception?

To give an example of the things that we have seen: A COBOL program that did a bubble-sort. The input? Five records. The job was canceled when it had clocked up more than 5 hours CPU time... With some exceptions, jobs on this system should not need more than a few seconds of CPU time - I know I am somewhat of a sinner as I have one job that will clock up to half an hour of CPU time, but given its nature, it uses the PL/I "COUNT" option to count executed statements, there is little I can do about it. Hoever, to minimize poblems for others, I run it at PRTY=1 and at a time (midnight after here in Europe) when there are few other users on the system.

Now, my request is : 1) can we disconnect our session so we can login again (Disconnect is not working anymore).
2) Can Jobs in spool be deleted automatically.
and main 3). Can we increase the number of submitting JOBs, at least 10 should be there.(just request)

If it is possible, please let us know. I am not a Trainee, just want to be in touch with Mainframes and FANDeZHI is wonderful.

Jobs are (supposed to be) deleted automatically a few times per day, but this does not always work, so please clear out the spool when you log off. As for the disconnect via the website feature, I'd suggest you send a private message to sysprog and ask him if he can restore it.

You may introduce Warning system !! depending on severity of Crime( ) so users get few chances to divert himself on right path before any harsh action and avoid abuse of our system.

I'm not sure if that is possible on z/OS and besides that, it would put a burden on us to administer it. Revoking someone maybe harsh, but it's far easier...

[steve-myers]

Time based output deletion is accomplished using a JES2 command, which I looked up in the FM, but won't repeat here. The JES2 command is periodically issued using JES2 automatic commands; again I looked up in the FM and won't repeat here. I know there are no automatic commands in the JES2 initialization parms, but that doesn't mean they could not be added.

My recollection is it seemed somewhat flaky.

[mainframer]

Thanks steve and Prino for prompt reply.

it would put a burden on us to administer it. Revoking someone maybe harsh, but it's far easier...

For sure it will increase burden . I am unaware with RACF so can only request let it be the way it working. "TSO SEND" can also be an option.(not sure if applicable here)
I just want to be in safe zone and don't want to commit mistake to be revoked! , it's really painful.
Bye!

Garry

[sysprog]

Disconnect function is fixed.

cgi-bin/mainframe/mainuser?F=DISCONNECT

Normally you don't need to take care of their JES2 outputs, as the system delete them automatically if they over 6 months old.

[steve-myers]

6 months!

I used to support an output management product. For a few days after I started there I wondered why they had their own spooling function rather than use the very efficient JES2 SPOOL. Then I realized JES2 folks think of output retention in units of hours or even minutes, not days, weeks, or, even multiple years! We had one customer running our product on IBM's Multiprise hardware. In some ways similar to Hercules; emulation on PC type real machines. I remember looking at the CPU times for some of his runs. Very high!

Prino's comment about CPU time is quite apt. I've been playing with an app that did a linear search through a longish list for 75000+ input records. SLOW! So I reprogrammed it to use a hash function. Huge improvement! We have to remember dezhi is not really a mainframe, and is really quite slow!