Submit a batch job in one CL pgm

I want to call a pgm in batch mode using one CL pgm only, by combining the batch call with the final pgm call.

I am passing parms and can do so with a DS or by passing the parms themselves.

The programmer before me would always have one CL interact with the screen, call the batch pgm with the final pgm in the parm list and the second CL would call the final pgm in batch mode.

How do I do this?

Who is Participating?
tliottaConnect With a Mentor Commented:

I'm a little confused... since you're going to need to do SBMJOB to get the CL into batch, why would you not SBMJOB for the batch function itself?

By trying to get it done in a single program, you're putting too much function into it. I assume the desired batch function is business logic of some sort. You seem to want to mix control logic with business logic.

For future maintenance and flexibility, the two kinds of function should be separated -- IMO.

However, the key to doing what you want is mentioned above, RTVJOBA to get the job type, either batch or interactive. Code your program to avoid any SNDRCVF or SNDF commands against a display file whenever you're in batch. Also, keep in mind that parms ought to be matched for both batch and interactive -- this can get tricky if parms exist, especially if you need to pass them after interaction with a display file.

You can access a display file from batch as long as you can attach a device. Use OVRDSPF DEV() to attach. The device needs to be varied on and at a signon screen, otherwise you'll get CPF4128. And you can handle parms that aren't passed by monitoring for MCH3601 when you reference each parm; this allows you to omit parms on the CALL and use default values.

Still, I'd use two separate programs without a _very_ good reason to use one.

Your Key is RTVJOBA, I hope you'll understand what I write down !!


&TYPE = '1' if interactive and = '0' if Batch

If you call CL1

*** CL1 ***

DCL   &TYPE *char 1
DCLF  Screen


if &TYPE = '1'

READ  Screen
SBMJOB(PGM(CL1) PARM(with Parm))

if &TYPE = '0'

 call RPG1



*** END CL1 ***

You mean that if the interactive gives is Device name tu the Batch job, The batch job can overide a screen to that Device ?
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.


A sample DSPF and CLP:
---------------------------------- Begin DDS
     A                                      DSPSIZ(24 80 *DS3)
     A          R DUMMYFMT
     A                                      KEEP
     A                                      ASSUME
     A                                  1  2':'
     A          R ACQBCR1
     A                                      TEXT('Acquisition format')
     A                                      ALARM
     A                                      CLRL(*NO)
     A                                      OVERLAY
     A                                 13 25'..................................-
     A                                      ..'
     A                                      COLOR(BLU)
     A                                 14 25':'
     A                                      COLOR(BLU)
     A                                 14 27'Just testing...'
     A                                      COLOR(YLW)
     A            ACTION        10   B 14 46
     A                                 14 60':'
     A                                      COLOR(BLU)
     A                                 15 25':'
     A                                      COLOR(BLU)
     A            MSG1          32A  O 15 27
     A                                 15 60':'
     A                                      COLOR(BLU)
     A                                 16 25':'
     A                                      COLOR(BLU)
     A            MSG2          32A  O 16 27
     A                                 16 60':'
     A                                      COLOR(BLU)
     A                                 17 25':'
     A                                      COLOR(BLU)
     A            MSG3          32A  O 17 27
     A                                 17 60':'
     A                                      COLOR(BLU)
     A                                 18 25'..................................-
     A                                      ..'
     A                                      COLOR(BLU)
---------------------------------- End DDS
---------------------------------- Begin CL
pgm        ( &DEV )

   dcl       &DEV       *char      10

   dclf      ACQBCH

   ovrdspf   acqbch   dev( &DEV )

   chgvar    &msg1       ( 'Message line 1 (*char 32)' )
   chgvar    &msg2       ( 'Message line 2 (*char 32)' )
   chgvar    &msg3       ( 'Message line 3 (*char 32)' )

   sndrcvf   rcdfmt( ACQBCR1 )
   monmsg  ( CPF4128 )  exec( do )
      sndpgmmsg  msgid( CPF9898 ) msgf( QCPFMSG ) +
                   msgdta( 'Device is in use or not varied on' ) +
                   msgtype( *COMP )

---------------------------------- End CL

Compile both with appropriate names. Submit the CLP with something like:

 ==>  sbmjob cmd( call BCHDSP parm(DSP99))

Now, assuming DSP99 is varied on and available, i.e., not in use by another job, the DSPF should show up on its screen and wait for a respone. An interactive job could supply its _own_ device name _only_ if the interactive job releases the device -- e.g., signs off.

In RPG, see the ACQ op-code. In COBOL, see the ACQUIRE statement. Opening a second emulator session window and leaving it at a signon display is probably easiest to demo. This is commonly used for never-ending programs that continually provide updated status info.


It Works fine, thanks for your example.

But the fact you need a screen on signoff is not really usefull !! It would be great if you could be work on something and BANG a windows appear to ask you a price on something !! :)

Since multiple sessions is often not a problem, it usually doesn't matter.

But for your specific concern... That's what a break-handler would be good for. Technically, not a "break-handler" but a message queue monitor in any case.

Create a temporary message queue in job initial program or routing program or at whatever time is most useful, then assign the break-handling program to that message queue. Whenever you want to interrupt from somewhere else, send a message to that message queue. "Temporary message queue" does not mean "in QTEMP".

The break-handler gets control and can do whatever it's programmed to do including opening a new display file, setting an attention program or whatever. (Setting an attention program and sending a status message could notify the user to press <Attn>. The attn-program could open a display file, etc., and perhaps return the <Attn> key to it's previous setting.)

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.