IBM Mainframe Forum

Hello all,

I have created my own PROCLIB which is not in the system concatenation.

I want to know how I can run my PROC's as started tasks.

Could I concatenate this PROCLIB to my logon PROC and issue a start command from the console and start it as an STC?

I am not sure how else I can run my STC's without having my PROCLIB in the system concatenation.

Any advice is much appreciated!

Thanks!

I am not sure how else I can run my STC's without having my PROCLIB in the system concatenation.

why would You want to run Your own STCs
trying to do it will in some cases end with proper lawful termination

hint.
the security managers ( TACF, TOP SECRET, ACF ) deal with started tasks in a different way
usually giving them higher privileges than the standard batch / two users

if You have the impelling need to have Your own STC talk to Your SYSTEM PROGRAMMING support

Hi Enrico, thank you for your answer!

I understand where you are coming from and you are of course correct.

I just wanted to know if it was possible for me to create a task myself to understand how the process works.

Thanks a lot!

A started task is submitted from the system concatenation. If your PROCLIB is not in the system concatenation then it can't be started. So you would need to talk to your site support group.

Thanks Enrico.

When I run my proc as a job it runs like a started task, is this different than when it would run from the system proclib?

Thanks!

deucalion0 wrote:Hello all,

I have created my own PROCLIB which is not in the system concatenation.

I want to know how I can run my PROC's as started tasks.

Could I concatenate this PROCLIB to my logon PROC and issue a start command from the console and start it as an STC?

No.

deucalion0 wrote:I am not sure how else I can run my STC's without having my PROCLIB in the system concatenation.

You can't.

As Mr. Soriochetti says, discuss this with your systems programmers. There are other issues.

• Security
  
  Mr. Sorichetti mentioned this, though rather incompletely. What you do and what they do is up to your installation; it is improper to discuss this in this forum.
  
• Priority
  
  Is there a requirement to run this task at a higher execution priority than some other task, such as CICS? In the early 1980s I developed a tool to measure some internal functions in JES2, but external to JES2. To do this is it had to run at a higher execution priority than JES2.
  
• Start up
  
  Manually starting a task has security implications that you must discuss with your systems programmers.
  
• Shut down
  
  Manually shutting down a task also has security implications that you must discuss with your systems programmers.
  
• Communication with the task
  
  Sadly, effective communication with a task requires fairly deep Assembler knowledge as well as security implications. The relatively simple QREG0 interface no longer works, though its rather more complicated replacement allows your TSO session to interact with your started task.
  
• Why?
  
  The systems and security people are most likely going to ask, "Why must this function run as a started task?" You better have good reasons that they will buy. Fortunately, this is not the over powering concern it was perhaps 30 years ago, but these concerns still run deeply.

When I run my proc as a job it runs like a started task, is this different than when it would run from the system proclib?

Yes. Depending upon your release of z/OS, a started task may have access to system symbols whereas the job may not use them -- this only changed with z/OS 2.1 to allow batch jobs to use system symbols. There are other differences as pointed out by others.

deucalion0 wrote:... When I run my proc as a job it runs like a started task, is this different than when it would run from the system proclib? ...

Mr. Sample's discussion about system symbols only applies to batch JCL. The source of the JCL is immaterial. Any program that knows how to retrieve system symbols can retrieve them, whether it is run as a started task, in a TSO session, or as a batch program.

I believe - though I am not certain about this - the restriction was imposed because JCL retrieves symbols when it is converted to internal text, which may occur on a different physical system and long before it is run for batch JCL.

If your sole reason to run your program as a started task is because the JCL has access to system symbols, you most likely will be reminded that any program can retrieve the symbols, and that there are other ways to retrieve symbols

Thank you very much guys for your detailed explanations. I have wondering about this for a long time.

I was surprised my PROC/JCL ran as an STC with no issues, but as you explained it to me it makes sense now.

Cheers!!