How can I CHGCURDIR before a SBMJOB?

[Mr. K.V.B.L.]

I really need to make a process I start with SBMJOB have a different IFS path than the one that is specified in the user profile. If I SBMJOB with a user profile it always uses the IFS path in the user profile. I was hoping that in a CL I could override that some way.

Possible, or no?

[Emile]

Why can you not you use CHGCURDIR DIR(/OTHERDIRTHANUSRPRF) in a CL you
submit ?

Please tell us more about the program you submit etc.


"Mr. K.V.B.L." <kenvery...@gmail.com> schreef in bericht
news:8166a47a-e034-4f2b...@googlegroups.com...

[Mr. K.V.B.L.]

On Monday, October 15, 2012 3:25:49 PM UTC-5, Emile wrote:
> Why can you not you use CHGCURDIR DIR(/OTHERDIRTHANUSRPRF) in a CL you
>
> submit ?
>
>
>
> Please tell us more about the program you submit etc.
>
>
>
>
>

> "Mr. K.V.B.L." <...> schreef in bericht

>
> news:8166a47a-e034-4f2b...@googlegroups.com...
>
> I really need to make a process I start with SBMJOB have a different IFS
>
> path than the one that is specified in the user profile. If I SBMJOB with a
>
> user profile it always uses the IFS path in the user profile. I was hoping
>
> that in a CL I could override that some way.
>
>
>
> Possible, or no?

I am submitting a CALL to a C program.

SBMJOB CMD(CALL PGM(&ENGLIB/&ENGNAME) PARM('--port' &MY_PORT '--children' &MY_NUMCHLD)) JOB(&JOBNAME) JOBD(&JOBLIB/&JOBDESC) USER(&USR) CURLIB(QGPL) INLLIBL(*JOBD) CPYENVVAR(*YES)

I need to make use of a *JOBD on a per-process basis, that's why I'm doing it via SBMJOB. I'm not seeing a good way out of this. I'd really like to not have to change any code other than CL. The &USR parameter if the problem, I fear. I'd like for all of my jobs to run under the same user, just different home IFS paths.

[Mr. K.V.B.L.]

On Monday, October 15, 2012 2:29:43 PM UTC-5, Mr. K.V.B.L. wrote:
> I really need to make a process I start with SBMJOB have a different IFS path than the one that is specified in the user profile. If I SBMJOB with a user profile it always uses the IFS path in the user profile. I was hoping that in a CL I could override that some way.
>
>
>
> Possible, or no?

I think my approach is wrong. I'm thinking that my SBMJOB should be a CL, not a CALL, and in the CL I do the CHGCURDIR followed by my CALL. I want all of this to be driven by a CMD. So, if I'm following myself correctly, I would be doing a CMD to a CL(1) that is issuing a SBMJOB that is issuing another CL(2). CL(2) is then running CHGCURDIR then CALL to C program.

Ugh, that's the best my brain can come up with at the moment.

[CRPence]

On 15 Oct 2012 15:59, Mr. K.V.B.L. wrote:

>> On Monday, October 15, 2012 14:29, Mr. K.V.B.L. wrote:
>>> I really need to make a process I start with SBMJOB have a
>>> different IFS path than the one that is specified in the user

>>> profile. If I SBMJOB with a user profile <ed: named\specified>
>>> it always uses the IFSpath <ed: the HOMEDIR> in the user profile.

>>> I was hoping that in a CL I could override that some way.
>>>
>>> Possible, or no?
>>>

> On 15 Oct 2012 15:44, Mr. K.V.B.L. wrote:
>> I am submitting a CALL to a C program.
>>
>> SBMJOB CMD(CALL PGM(&ENGLIB/&ENGNAME)
>> PARM('--port' &MY_PORT '--children' &MY_NUMCHLD))
>> JOB(&JOBNAME) JOBD(&JOBLIB/&JOBDESC) USER(&USR)
>> CURLIB(QGPL) INLLIBL(*JOBD) CPYENVVAR(*YES)
>>
>> I need to make use of a *JOBD on a per-process basis, that's why
>> I'm doing it via SBMJOB. I'm not seeing a good way out of this. I'd
>> really like to not have to change any code other than CL. The &USR

>> parameter is the problem, I fear. I'd like for all of my jobs to

>> run under the same user, just different home IFS paths.
>

> I think my approach is wrong. I'm thinking that my SBMJOB should be
> a CL, not a CALL, and in the CL I do the CHGCURDIR followed by my
> CALL. I want all of this to be driven by a CMD. So, if I'm following
> myself correctly, I would be doing a CMD to a CL(1) that is issuing a
> SBMJOB that is issuing another CL(2). CL(2) is then running CHGCURDIR
> then CALL to C program.
>
> Ugh, that's the best my brain can come up with at the moment.

I see nothing wrong with the approach as implied by the earlier
posts. Nothing that implies using a CLP or even a command would be
inherently better than just calling the program directly. If I infer
correctly, the value that should be used on the CHGCURDIR request to set
the Current Directory in the submitted job should be derived from the
Home Directory of some user *other* than the User Profile name specified
as USER(&USR) under which the process was submitted.? And the C program
should remain unchanged, continuing to operate under its current
assumption that the current directory is to be used.? Only the latter
requirement would seem to imply an obvious benefit from adding a CL
"wrapper" for the C program processing; i.e. the unchanged program might
best have a pre-processor to setup the environment, to meet the
assumptions made by the C application, although at least a routing
program is one alternative.

Seems then that the crux is determining from where and when both the
intended User Profile name and its Home Directory value can be
extracted. While either the submitting or the submitted job could
possibly determine\derive the home directory name, doing so in one may
best be accomplished in one versus the other. If that can only be done
in the submitting job, then some means to communicate to the batch job
the desired directory name becomes a requirement. How that is done may
best be accomplished using a CL wrapper or routing program, if\because
the C program should remain unchanged; e.g. an environment variable per
use of the CPYENVVAR(*YES), a parameter, a routing program chosen via
specified routing data, or żother?. If the batch job can easily
determine the User Profile from which the HomeDir value is obtained,
then probably best to just let the batch job extract both values;
nothing obvious about the scenario makes that seem likely, except
perhaps if the User name is in the JOBD being used.

--
Regards, Chuck

[Mr. K.V.B.L.]

On Monday, October 15, 2012 3:25:49 PM UTC-5, Emile wrote:

> Why can you not you use CHGCURDIR DIR(/OTHERDIRTHANUSRPRF) in a CL you
>
> submit ?
>
>
>
> Please tell us more about the program you submit etc.
>

I'll do more than that, I'll post the code! See below, then see my comments after the code post.

>
> news:8166a47a-e034-4f2b...@googlegroups.com...
>
> I really need to make a process I start with SBMJOB have a different IFS
>
> path than the one that is specified in the user profile. If I SBMJOB with a
>
> user profile it always uses the IFS path in the user profile. I was hoping
>
> that in a CL I could override that some way.
>
>
>
> Possible, or no?

Here is my CL source.

PGM PARM(&ENG_PROG &PATH &PORT &NUMCHLD &JOBNAME &JOBD &USR)

DCL VAR(&ENG_PROG) TYPE(*CHAR) LEN(20)
DCL VAR(&PATH) TYPE(*CHAR) LEN(1000)
DCL VAR(&PORT) TYPE(*UINT)
DCL VAR(&NUMCHLD) TYPE(*UINT)
DCL VAR(&JOBNAME) TYPE(*CHAR) LEN(10)
DCL VAR(&JOBD) TYPE(*CHAR) LEN(20)
DCL VAR(&USR) TYPE(*CHAR) LEN(10)

DCL VAR(&MY_PORT) TYPE(*CHAR) LEN(10)
DCL VAR(&MY_NUMCHLD) TYPE(*CHAR) LEN(10)
DCL VAR(&JOBLIB) TYPE(*CHAR) STG(*DEFINED) +
LEN(10) DEFVAR(&JOBD 11)
DCL VAR(&JOBDESC) TYPE(*CHAR) STG(*DEFINED) +
LEN(10) DEFVAR(&JOBD 1)
DCL VAR(&ENGLIB) TYPE(*CHAR) STG(*DEFINED) +
LEN(10) DEFVAR(&ENG_PROG 11)
DCL VAR(&ENGNAME) TYPE(*CHAR) STG(*DEFINED) +
LEN(10) DEFVAR(&ENG_PROG 1)
DCL VAR(&ERRORSTR) TYPE(*CHAR) LEN(1000)

CHGVAR VAR(&MY_PORT) VALUE(&PORT)
CHGVAR VAR(&MY_NUMCHLD) VALUE(&NUMCHLD)

/* Strip leading zeroes off of the port #. You can */
/* leave them in, but I wanted them gone. Besides, */
/* I learned something this way. */
TESTZERO: IF COND(%SST(&MY_PORT 1 1) *EQ '0' *AND +
%SST(&MY_PORT 2 1) *NE ' ') THEN(DO)
CHGVAR VAR(&MY_PORT) VALUE(%SST(&MY_PORT 2 9))
GOTO CMDLBL(TESTZERO)
ENDDO

/* Now do the same for the number of children parameter. */
TESTZERO2: IF COND(%SST(&MY_NUMCHLD 1 1) *EQ '0' *AND +
%SST(&MY_NUMCHLD 2 1) *NE ' ') THEN(DO)
CHGVAR VAR(&MY_NUMCHLD) VALUE(%SST(&MY_NUMCHLD 2 9))
GOTO CMDLBL(TESTZERO2)
ENDDO

/* SNDPGMMSG MSG('engine ' *cat &ENG_PROG) */
/* SNDPGMMSG MSG('engine library ' *cat &ENGLIB) */
/* SNDPGMMSG MSG('engine name ' *cat &ENGNAME) */
/* SNDPGMMSG MSG('path ' *cat &path) */
/* SNDPGMMSG MSG('port ' *CAT &MY_PORT) */
/* SNDPGMMSG MSG('num ' *cat &MY_NUMCHLD) */
/* SNDPGMMSG MSG('jobd ' *cat &JOBD) */
/* SNDPGMMSG MSG('joblib ' *cat &JOBLIB) */
/* SNDPGMMSG MSG('jobdesc ' *cat &JOBDESC) */

/* Check to see that our program name and library actually */
/* exist. We're catching the library and program name */
/* component. */
CHKOBJ OBJ(&ENGLIB/&ENGNAME) OBJTYPE(*PGM)
MONMSG MSGID(CPF9810) EXEC(DO)
CHGVAR VAR(&ERRORSTR) VALUE('Library ' *CAT +
&ENGLIB *TCAT ' is not found. Engine not started.')
SNDPGMMSG MSG(&ERRORSTR)
RETURN
ENDDO
MONMSG MSGID(CPF9801) EXEC(DO)
CHGVAR VAR(&ERRORSTR) VALUE('Program ' *CAT +
&ENGNAME *TCAT ' is not found. Engine not started.')
SNDPGMMSG MSG(&ERRORSTR)
RETURN
ENDDO

/* Change to our working directory. Bolt if it */
/* doesn't exist. */
CHGCURDIR DIR(&PATH)
MONMSG MSGID(CPFA0A9) EXEC(DO)
CHGVAR VAR(&ERRORSTR) VALUE('Directory ' *CAT +
&PATH *TCAT ' is not found. Engine not started.')
SNDPGMMSG MSG(&ERRORSTR)
RETURN
ENDDO

/* The checks we have have passed so far, so try and start */
/* an engine with the correct number of children helpers. */
SBMJOB CMD(CALL PGM(&ENGLIB/&ENGNAME) PARM('--port' +
&MY_PORT '--children' &MY_NUMCHLD)) +
JOB(&JOBNAME) JOBD(&JOBLIB/&JOBDESC) +
USER(&USR) CURLIB(QGPL) INLLIBL(*JOBD) +
CPYENVVAR(*YES)
ENDPGM

I've already tested this. It won't work. When the SMBJOB runs, it is going to use the default directory of the user profile represented by the CL variable &USR, and ignore the CHGCURDIR as submitted in the CL variable &PATH. I guess it's doing this because it's starting a job in its own 'space', if you will, leaving the current job's space. I know this because after the SBMJOB runs, the PGM starts creating its log files in that user profile IFS path, not the one I CHGCURDIR to.

My next thing to try is to not SBMJOB a CALL to a program, but a CALL to a CL. In the CL you would do.

CHGCURDIR DIR(&PATH)
CALL PGM(...) PARM(...)

Sounds like it will work, I just need to find some time to try it out.

[CRPence]

What I have typically seen and used myself, for what I infer may be a
similar scenario to yours, is to use the same program to effect both the
interactive and the batch CL. If the job is running in batch, then
[optionally with some validation of the batch job attributes] the CL
program infers the request is to call the intended program [the "engine"
in this case]. However when the job is running interactively, the
program /knows/ it is not the engine job running, and thus submits a job
that will call itself; i.e. calls the program that is running now, in
the submitted job.

So, for example....

pgm (&path ...) /* pgm name MySelf */
dcl &path *char 1000
dcl ... /* other parms */
dcl &pathx *char 1001
dcl &sbmrqd *char 1
mainline:
rtvjoba type(&sbmrqd)
/* <<SNIP validation except chgcurdir>> */
CHGCURDIR DIR(&PATH) /* OK to muck with interactive job? +
probably best to do an effective chkobj instead; e.g. +
use CLLE instead and the 'stat' api.? */
monmsg ... exec(do) /* monitor\identify path problem */
... /* diagnose bad path */
enddo
if (&sbmrqd *eq '1') +
then(do) /* per interactive, submit batch engine: */
chgvar &pathx &path /* using *CMD avoids this silliness */
chgvar %sst(&pathx 1001 01) 'X'
sbmjob cmd(call MySelf parm(&pathx)) ...
enddo
else do /* per batch, start the batch engine: */
/* optionally validate this is the "engine" job */
CALL PGM(&ENGLIB/&ENGNAME) +
PARM('--port' &MY_PORT '--children' &MY_NUMCHLD)
/* Does the C program really accept four parms, or */
/* should above data be concatenated into one parm? */
end
return
endpgm

--
Regards, Chuck

On 17 Oct 2012 11:06, Mr. K.V.B.L. wrote:
>
> Here is my CL source.
>
> PGM PARM(&ENG_PROG &PATH &PORT &NUMCHLD &JOBNAME &JOBD &USR)
>
> DCL VAR(&ENG_PROG) TYPE(*CHAR) LEN(20)
> DCL VAR(&PATH) TYPE(*CHAR) LEN(1000)
> DCL VAR(&PORT) TYPE(*UINT)
> DCL VAR(&NUMCHLD) TYPE(*UINT)
> DCL VAR(&JOBNAME) TYPE(*CHAR) LEN(10)
> DCL VAR(&JOBD) TYPE(*CHAR) LEN(20)
> DCL VAR(&USR) TYPE(*CHAR) LEN(10)
>
> DCL VAR(&MY_PORT) TYPE(*CHAR) LEN(10)
> DCL VAR(&MY_NUMCHLD) TYPE(*CHAR) LEN(10)
> DCL VAR(&JOBLIB) TYPE(*CHAR) STG(*DEFINED) +
> LEN(10) DEFVAR(&JOBD 11)
> DCL VAR(&JOBDESC) TYPE(*CHAR) STG(*DEFINED) +
> LEN(10) DEFVAR(&JOBD 1)
> DCL VAR(&ENGLIB) TYPE(*CHAR) STG(*DEFINED) +
> LEN(10) DEFVAR(&ENG_PROG 11)
> DCL VAR(&ENGNAME) TYPE(*CHAR) STG(*DEFINED) +
> LEN(10) DEFVAR(&ENG_PROG 1)
> DCL VAR(&ERRORSTR) TYPE(*CHAR) LEN(1000)
>
> CHGVAR VAR(&MY_PORT) VALUE(&PORT)
> CHGVAR VAR(&MY_NUMCHLD) VALUE(&NUMCHLD)
>

> <<SNIP>>

<ed: in the submitter's job>.