Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1516
  • Last Modified:

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?

jjjjjjj
0
jjjjjjj
Asked:
jjjjjjj
  • 3
  • 3
1 Solution
 
HelixirCommented:
Your Key is RTVJOBA, I hope you'll understand what I write down !!

DCL   &TYPE  *CHAR 1

RTVJOBA TYPE(&TYPE)
&TYPE = '1' if interactive and = '0' if Batch

If you call CL1

*** CL1 ***
PGM

DCL   &TYPE *char 1
DCLF  Screen

RTVJOBA TYPE(&TYPE)

 * INTERACTIVE PART
if &TYPE = '1'

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

 * BATCH PART
if &TYPE = '0'

 call RPG1

endif

endpgm

*** END CL1 ***

0
 
tliottaCommented:
jjjjjjj:

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.

Tom
0
 
HelixirCommented:
You mean that if the interactive gives is Device name tu the Batch job, The batch job can overide a screen to that Device ?
0
Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

 
tliottaCommented:
Helixir:

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 )
      return
   enddo


   return
endpgm
---------------------------------- 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.

Tom

0
 
HelixirCommented:
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 !! :)
0
 
tliottaCommented:
Helixir:

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.)

Tom
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now