How to get jobnum from BPXBATCH environment

[Mark Wheeler]

All,

I've been using Robert Zenuk's code below to retrieve jobnum info...
tcb = storage(21c,4)
tiot = storage(d2x(c2d(tcb)+12),4)
jscb = storage(d2x(c2d(tcb)+180),4)
ssib = storage(d2x(c2d(jscb)+316),4)
jobname = strip(storage(d2x(c2d(tiot)),8))
ssib_data = c2x(storage(d2x(c2d(ssib)),32))
jobtype = storage(d2x(c2d(ssib)+12),3)
jobnum = strip(storage(d2x(c2d(ssib)+15),5),l,0)
Alas, from BPXBATCH (or OMVS) the jobtype and jobnum are binary zeroes
(derived from SSIBJBID).

Is there a way to get jobnum some other way when in the USS environment?

Mark L. Wheeler
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel: (651) 733-4355, Fax: (651) 736-7689
mlwheeler at mmm.com
--
"I have this theory that if one person can go out of their way to show
compassion then it will start a chain reaction of the same. People will
never know how far a little kindness can go." Rachel Joy Scott

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Robert Zenuk]

I am pretty sure this is because under OMVS and BPXBATCH your EXEC is
running under a different shell than your JOB's default shell or your OMVS
session's default shell. When you watch a job in SDSF using BPXBATCH run a command
(REXX or not), you will see the *OMVSEX address space appear. These are not
the same address space as your original job. Each level of shell you cascade
through causes another *OMVSEX address space to appear. It looks like these
*OMVSEX address spaces do not get the full compliment of control blocks...
Maybe someone else has a better explanation. There are some BPXBATCH parms to
avoid the spawning of these new address spaces. Maybe that would help in
this case. I have not tried it yet.

Rob

In a message dated 5/15/2008 6:11:57 P.M. US Mountain Standard Time,
mlwh...@MMM.COM writes:

All,

**************Wondering what's for Dinner Tonight? Get new twists on family
favorites at AOL Food.
(http://food.aol.com/dinner-tonight?NCID=aolfod00030000000001)

[Drew, AJ]

I know that this little trick can get you the jobname of the task that
spawned the OMVS thread - JOBNAME=$(exec ps -o jobname= -p $$).

So I would imagine that there is some way to find out the jobnum as
well.

A J

Rob

All,

-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Con...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

[billla...@gmail.com]

On May 16, 1:47 am, Robze...@AOL.COM (Robert Zenuk) wrote:
> I am pretty sure this is because under OMVS and BPXBATCH your EXEC is
> running under a different shell than your JOB's default shell or your OMVS
> session's default shell. When you watch a job in SDSF using BPXBATCH run a command
> (REXX or not), you will see the *OMVSEX address space appear. These are not
> the same address space as your original job. Each level of shell you cascade
> through causes another *OMVSEX address space to appear. It looks like these
> *OMVSEX address spaces do not get the full compliment of control blocks...
> Maybe someone else has a better explanation. There are some BPXBATCH parms to
> avoid the spawning of these new address spaces. Maybe that would help in
> this case. I have not tried it yet.
>
> Rob
>
> In a message dated 5/15/2008 6:11:57 P.M. US Mountain Standard Time,
>

> mlwhee...@MMM.COM writes:
>
> All,
>
> I've been using Robert Zenuk's code below to retrieve jobnum info...
> tcb = storage(21c,4)
> tiot = storage(d2x(c2d(tcb)+12),4)
> jscb = storage(d2x(c2d(tcb)+180),4)
> ssib = storage(d2x(c2d(jscb)+316),4)
> jobname = strip(storage(d2x(c2d(tiot)),8))
> ssib_data = c2x(storage(d2x(c2d(ssib)),32))
> jobtype = storage(d2x(c2d(ssib)+12),3)
> jobnum = strip(storage(d2x(c2d(ssib)+15),5),l,0)
> Alas, from BPXBATCH (or OMVS) the jobtype and jobnum are binary zeroes
> (derived from SSIBJBID).
>
> Is there a way to get jobnum some other way when in the USS environment?
>
> Mark L. Wheeler
> IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
> Tel: (651) 733-4355, Fax: (651) 736-7689
> mlwheeler at mmm.com
> --
> "I have this theory that if one person can go out of their way to show
> compassion then it will start a chain reaction of the same. People will
> never know how far a little kindness can go." Rachel Joy Scott
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,

> send email to LISTS...@VM.MARIST.EDU with the message: INFO TSO-REXX

>
> **************Wondering what's for Dinner Tonight? Get new twists on family
> favorites at AOL Food.
> (http://food.aol.com/dinner-tonight?NCID=aolfod00030000000001)
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,

> send email to LISTS...@VM.MARIST.EDU with the message: INFO TSO-REXX

[billla...@gmail.com]

Sorry .. Google problems ..

BPXBATCH spawns a process that runs on an OMVS initiator (BPXAS) to
execute the command. That
environment looks different from the JES2/JES3 environment that your
REXX is designed for. The
OMVS initiator looks like a started task to JES2/JES3. You can use the
following REXX to retrieve
the correct jobid for the environment where the REXX is executing:
http://members.tripod.com/~billlalonde/rexx/findjsab.txt
That will work for either the OMVS initiator or a batch job. However,
it will return the jobid
of the started task for the OMVS initiator. That may not be what you
want. You can force the REXX
to execute in the same environment as the batch job by using program
BPXBATSL (local spawn) instead
of BPXBATCH. Then, your REXX should return the expected results.

Bill

On May 16, 1:47 am, Robze...@AOL.COM (Robert Zenuk) wrote:

> I am pretty sure this is because under OMVS and BPXBATCH your EXEC is
> running under a different shell than your JOB's default shell or your OMVS
> session's default shell. When you watch a job in SDSF using BPXBATCH run a command
> (REXX or not), you will see the *OMVSEX address space appear. These are not
> the same address space as your original job. Each level of shell you cascade
> through causes another *OMVSEX address space to appear. It looks like these
> *OMVSEX address spaces do not get the full compliment of control blocks...
> Maybe someone else has a better explanation. There are some BPXBATCH parms to
> avoid the spawning of these new address spaces. Maybe that would help in
> this case. I have not tried it yet.
>
> Rob
>
> In a message dated 5/15/2008 6:11:57 P.M. US Mountain Standard Time,
>