ProC in job submission
I have setup many proC programs and unix shells in job submission without problems. This week I was setting up a proC and I encountered an issue I never saw before.
While the proC works great when called from the unix prompt, it does not when called from job submissions.
Assume the program is called myprog.pc, the executable is myprog. This program uses SCT delivered calls for the login; rptopen and login.
from the prompt I can call
myprog -f -o myprog_$$.lis << EOF
$UIPW
param1
param2
param3
EOF
The blank line after $UIPW represents the one up number. This call works and I get the expected output. But when I ran if from job submissions the program runs, gets the right parameters but it creates a report with headers but no data. I have run myprog from the command line as banjobs and it worked too. I used the 'which' command to make sure that I'm using the right executable in both cases (anyway, there is only one copy of the executable)
Any suggestion is welcomed.
Thank you in advance!!!
Marc
From command line run as this "myprog -f -o <file> <user>/<Pass>
try to run same way the banner job sub is ruuning c program from job sub ans execute same command from unix command
if possible every time job submitted it create a temp shell capture this by commenting lin ein gjajobs.shl to not to delete and see run that shell from coomand line in order to debug.
Basicallu job submission is not going to pass parm1 2 or 3 it is only going to pass job number.
Vipul Patel
Senior Enterprise Resource Plng Developer
The George Washington University
ISS/AdminApps/BannerApps
vpatel@gwu.edu
That's what I was trying :)
Hi Vipul,
That's exactly what I was doing by running
myprog -f -o myprog_$$.lis << EOF
$UIPW
param1
param2
param3
EOF
I could also run
myprog -f -o myprog_$$.lis << EOF
$UIPW
--one_up number--
EOF
Thanks
Marc
SOLVED
We solved this issue a while ago, thanks to Jackie from Longwood University. She provided the key that opened the door :)
The ProC program was created a while ago and it was calling a pl/sql procedure like this:
package.process(:p_par1:Ind_01, :p_par2:Ind_02, :p_par3:Ind_03);
Ind_xx are global variables used when reading parameters from GJBPRUN to make sure they are not null. But they were being passed in the call, and if Ind_01 indicated that the parameter was null (because the select were it was used returned a null) p_par1 was no even read by the process.
Someone suggested using a new Indicator, Ind_07 not being used in any select, but the we would be depending on its correct initialization.
I prefer the following change
package.process(:p_par1, :p_par2:Ind_02, :p_par3:Ind_03);
(Ind_02 and Ind_03 can be left here because they are OUT parameters for the procedure)
p_par1 is never going to be null because of the way the ProC creates it, so, the indicator makes no sense. If someone is using Indicators as global variables, he needs to be very careful about the flow of the function calls. If you read something from the database and use and indicator to see if its null, don't use the same indicator for another select before checking the current value.
Thanks Jackie!!
Marc