Cannot start up TSO

[Pedro]

The logon proc is not always in SYS1.PROCLIB! As mentioned earlier, you should be able to use FTP to access the datasets. Look at 'SYS1.PROCLIB(JES2)' for PROCxx DD statements - one of the data sets in those concatenations will have the logon proc.

It is notoriously difficult to diagnose an uncataloged data set in the logon proc because typically the 'job' output is discarded when the job ends (for this purpose, consider a TSO user as a job). I use this JCL, which allows me to save the output to a held class:

Code: Select all

//CKLOGON JOB ,                                       
//   MSGCLASS=H,TIME=(5,00),MSGLEVEL=(0,0),REGION=12M,
//   USER=&SYSUID,NOTIFY=&SYSUID       
//         JCLLIB  ORDER=SYS1.SYSTEM.LOGON             
//LOGON    EXEC LOGON                                 
//SYSPRINT DD   SYSOUT=H                               

[Robert Sample]

Pedro: as I stated, it is NOT clear whether the failure is in the TSO started task JCL or in the logon procedure being used. Without clarification from the op, we can't go much further with this one. It is possible that the TSO started task JCL is not in SYS1.PROCLIB but that's where I'd look first. On the other hand, if TSO is not in SYS1.PROCLIB there's a chance that JES2 isn't either -- in which case the op will have lots of problems finding any of the started tasks from a remote system.

[FILLAH]

When we IPL our system, the TSO started task is failing with a JCL error.

[Robert Sample]

The first question I have, is why is an IMS application programmer (per your profile) having to deal with a system issue?

The second question is, why is your site support group not dealing with the problem?

The third (etc.) question is, have you tried to FTP your TSO start up JCL to another machine yet? If not, why not -- what was the result of trying this?

And the ultimate question is, who changed the TSO start up JCL -- or removed the data set(s) used in it?

[FILLAH]

Because I am a member of this forum and I want to help my manager to solve this problem.

[FILLAH]

All of us look for the solution.
Some one has accidentaly changed the JCL

[prino]

All of us look for the solution.
Some one has accidentaly changed the JCL

Given your involvement in this, does that someone by any chance happen to be you?

Why the flippin' ell aren't these datasets RACF protected so that only those who know what they are doing are allowed to change them? Or better, why don't you use Thomas Conley's Dynamic ISPF, where you have a logon procedure that never ever needs changing.