tokendef to call batch file fails

Within your batch file, you can put in break points or other flags to diagnose what is going on. Also within your Lawson program (the tokendef program) try writing break points to the log file itself.

Roger, Can you explain what you mean by break points?

I tried modifying the batch file, adding in echo statements before or after the SQL command line. When I run the token, this time the job completes successfully but it doesn't actually execute the SQL command. Yet I can see it piped it out to the examine log. If there is nothing at all in the batch file but the SQL command, the job goes into Needs Recovery.

I wonder if it's the quote (") characters within the command line of the batch file that's throwing off Lawson? Could it be the job execution utility within the environment doesn't know how to parse a command string containing quotes?

Break points, as in echo statements, DISPLAYS, PRINTs, etc., which you can use to write out or display messages to logs, reports, etc at various points within your programs to test execution statements.

Can you post here or send me the actual batch file containing the SQL command?

Thanks,
Roger
rfrench5@gmail.com

Nope, it's not quote characters throwing it off either. Running a simple DIR /w "C:\" command results in a successful job execution. But it's obvious it definitely does not like the SQL command I am trying to execute even though it executes from DOS just fine.

I can feel my hair getting mroe and more gray....

, file has been sent to you for review. Thanks for taking a look.

You said that it executes fine with you do it interactively, which means that it's probably an issue with environment variables and/or PATH. Check that whatever user that runs the environment service has the same values that you do.
If you need to add some, put them in batch file -- although I'd recommend just setting them in system environment variables.

Thanks for chiming in, John. The Lawson environment on my app server starts up under the "Local System" account. I know it's gotta be something within the environment, but I don't know where else to look. I have a privileged identity defined on the server and within Lawson Security that is used during the execution of all batch jobs. I've tried specifying the privileged identity within lajs.cfg, taking it out, putting in the Lawson admin account, etc. I've verifed the correct location of the batch file, verified it's security settings (it's wide open), and I've even changed the SQL command within the file. Nothing has made a difference and the job still goes into Needs Recovery even though it continues to run from DOS. I've checked the server's event logs to see if there's anything in there to tell me why the job fails, but there's nothing.

I'm not referring necessarily to privileges, but to variables/values and the PATH. Since you say that it's working when you run it interactively, are you sure that the PATH and variables are the same for you as the ones used by the lawson services?

OK, I figured it out, though I'm pretty sure we have some sort of unidentified environment issue, either with the third-party tools (MKS Toolkit, NetExpress, etc.) or if it's something else.  Or maybe this is "just the way it is" under the LSF9 environment.

I made two changes:

(1) Changed the file extension of my batch file from bat to cmd.  I don't believe this actually has a bearing on things, but reading up on batch files in general and their use on later Windows server operating systems suggested this was a prudent change.

(2) In my tokendef command, I preceded the command with the word "start".  My resulting command string was:  start F:/LAWPROD/triggers/LAW_ACCOUNT_ASSIGN.cmd

When I looked at the examine log for the job, the first thing that struck me was that the executable command was executed from my C:\MKS\mksnt folder rather than from where the batch file is located (F:/LAWPROD/triggers).   I was expecting the 'Start' prefix on my command line to just spawn a Windows process to execute the batch file; I was surprised to see that MKS actually spawned the process.

In any case, I am happy to get my jobs executing as they should.