RESOLVING SYMDEFS

Garry Carroll · Posted: Tue Sep 08, 2009 5:59 pm

My position is that batch jobs, in particular jobs run with TYPRUN=SCAN are failing to resolve SYMDEFS as defined in SYS1.PARMLIB(IEASYMnn). Has anyone a simple means of having these resolved?

Thanks in advance,
Garry.

Robert Sample · Posted: Tue Sep 08, 2009 6:05 pm

From the JCL Language Reference manual, link at the top of the page:

Garry Carroll · Posted: Tue Sep 08, 2009 6:19 pm

Thanks Robert,

Yes, I'm aware that Started Tasks & TSO Logons will resolve the SYMDEFS. I also can see that it doesn't mention submitted jobs. If the manual gave me an answer, I'd not be asking.

My problem is that, before submitting updates for such procedures to proclibs, I'd like to be able to demonstrate with, for example, a TYPRUN=SCAN that the SYMDEFS will get resolved. Change Control people don't like to let what appear to be unresolved references through. Each time there's a started task update, they issue a challenge that has to have a response.

Regards,
Garry.

Robert Sample · Posted: Tue Sep 08, 2009 6:23 pm

Since started tasks do not have JOB statements, where are you going to place the TYPRUN=SCAN?

It sounds like you may need to work with your Change Control group to come up with a better process for started task changes, or you'll just have to live with the challenge / response for every started task change.

dick scherrer · Posted: Wed Sep 09, 2009 1:07 am

Hello,

Might it suffice to add a JOB statement and run a TYPRUN=SCAN to prove the expansion, but not promote the JOB/TYPRUN with the change?

MBabu · Posted: Wed Sep 09, 2009 3:36 am

or maybe you can write a small Rexx routine that preprocess the JCL using MVSVAR('SYMDEF',symbol) and get the change control group to agree to (maybe run it and) review its output.

Robert Sample · Posted: Wed Sep 09, 2009 6:17 am

Garry Carroll · Posted: Wed Sep 09, 2009 11:28 am

enrico-sorichetti · Posted: Wed Sep 09, 2009 11:50 am

have You tried to play around with started JOBS ?

it has been a while that the facility is around,
but beware I have not cheched if typrun= scan works with them
IIRC SYMDEFS get resolved in started JOBS,
after having satified the people with funny hats all You have to do is to take away the JOB card when promoting to final production

dick scherrer · Posted: Wed Sep 09, 2009 10:10 pm

Hi Garry,

MBabu · Posted: Wed Sep 09, 2009 11:41 pm

OK - 1st... I have no idea what I'm talking about here

so for whatever it is worth... Is it possible to add a known fatal error to the started task JCL so that the input will run through conversion but not proceed to execution? If so, then you could add an agreed upon flaw to the JCL, start it, let it fail and use the joblog as a means to verify changes. (I know - I don't like it either, but its worth asking since it is similar to typerun=scan, I guess). I'm assuming, of course, that the job log would contain expansions, and that may be wrong - I don't have a sys to test on

Robert Sample · Posted: Thu Sep 10, 2009 12:34 am

Mbabu, you really want to monkey around with the JES start up deck that much? Or the CA-7 JCL? Actually, there's a few started tasks that you could not do this to anyway -- if the CA RIM job fails during the IPL, for example, none of the CA products on that LPAR will be able to run. And CA RIM is typically only executed during an IPL since you only need it once -- but it is a started task that has to be changed every now and then.

The o/p either needs to get an exception for started tasks, or work with the change control group to implement something that is workable.

MBabu · Posted: Thu Sep 10, 2009 1:41 am

I didn't really think it was a viable option to change the actual proc, just a copy (which has its own issues) but still, as I said, I didn't like it either.

Garry Carroll · Posted: Thu Sep 10, 2009 11:58 am

Thanks Enrico,