System variables not available in MFCOBOL any longer

I haven't done unix systems in awhile but It sounds like the cobol process does not have all the environment variables set that you do when you log in. If I am right then you can ask the following questions

1. What process kicks off the cobol program?
2. What process kicks off the process(es) in question 1?

You will probably need to make sure the $ATEMP variable is setup in the original process. You probably need to ask yourself how Lawson process are started in general on your system. If it is with scripts then you probably can just add in the setting of the environment variables there.

Another way to look at this might be to find out what is in your login shell script? This is probably setting $ATEMP for you.

Hopefully this is the right direction to look.

 It's a very simple batch program written in MFCOBOL. Just a shell which calls the script. That's it. 

WHen I (The 'lawson' user) logs in, I can and do run the script just fine. THe variables are already set when I log in. It's already written in the .profile. It's only when running the COBOL program does it not find the variables such as $ATEMP.

What process kicks off the batch program written in MFCOBOL?

 It's a very simple batch program. User submits the job. That's it. That's the process which executes the script.

Roger,
I have done this many times and have no problem at all using cobol. If your script is called inside cobol and you have several productlines in one environment, the script can only be called from the default product line. You do not put $ATEMP/script.ksh as part of your string only the script name. The system knows where to call these scripts based on the classpaths of your environment variables (see your unix admin). You need to know a little bit of unix to understand how things work. See sample of creating GENDIR where it knows that the executables are coming from gen/bin directory, or see LAWDIR and other environment variables. Instead we created an environment variable called LAWENVNAME whose value is the default productline (PROD). In our script we just assign PL=$LAWENVNAME, so our complete path to the producl line would be
$LAWDIR/$PL/ etc.For other productlines in the same environment you will need to hard code the productline because as I said cobol only knows the default PL and there is only one productline environment per unix box. We also created our own bin directory where all our custom scripts are located and again we created an environment variable to included these paths and in LID we just type in the script
name and it knows where to get it. In our scenario we have 3 unix boxes that house our prod, dev and
test environments, we only have one PL per box and the name is the same as the environments. So here's
what the value of LAWENVNAME would be per box:

prod = 'prod', dev='dev and test= 'test'

As you can see we only have one set of script that we can move around boxes because we don't have to hard code the product lines. Hope this helps.

Forgot to mention. While it's true you cannot use $ATEMP in your cobol string, you can instead use the full path to your executable. ex. STRING "/lawson/prod/law/prod/bin/XYZ.ksh' and this should work however this method you will need different copy of you cobol pgm for different PL.

I just remember that in cobol you can use an API to get the complete path to $LAWDIR. It is called 1000-CREATE-LAWDIR-FILENAME. This what I use to call different scripts like perl.

 Sam,

I've not ever seen that API before, and I can't find any documentation on that API.Is that a custom API you wrote? Do you have any documentation on what exactly it does? I've looked in the API guide and KB but nothing. I'd like to find out what that does.

THanks,

-R

Well sure there's a lot of APIs that Lawson never bothers to publish. You can see this routine under ICLAWDPD library.

Roger, try putting the "sh" in front of the call in the cobol WS.