IBM integration bus

[Anon Anon]

IIB is the latest avatar of what used to be the MQ Broker, IBM's enterprise bus product.  IIB has a cool feature that lets you invoke COMMAREA based Cobol/CICS programs (kind of similar to how you can use CICS web services)

Given that Gen transactions don't have a commarea as we know it (we can't LINK or XCTL to Gen transactions) has anyone any experience of invoking Gen transactions from IIB?  Or would someone have an idea where to even start? 

Thanks!

[Daniel Stratton]

Gen prior to the new CFB limit did use a CommArea - they do LINK/XCTL under the covers.  However, it was a proprietary 32kb format which did some view compression and other hoopla, which prevented you from trivially using it.  With the new 24bit CFB, I suspect they've moved to a Container/Channels combo.

 

Theoretically, you could LINK/XCTL to the PStep directly.  However, you'll need to essentially rewrite the Dialog Manager and it's various functions, otherwise you'll lose a stack of Gen's capabilities (flows, error/abend handling, exit states, etc.).  Probably not worth it to be honest, though it has risks/rewards.

[Anon Anon]

Hi Daniel,

Thanks for the response.  Isn't CFB specific to client server flows?  Is it applicable in block mode too? We too were considering doing that business with directly invoking the Pstep and bypassing the DM.  The DM CALLs the Proc step so I'm not sure if the Pstep is set up to be LINKed to?

Wonder if anyone else on this group has experience with LINKing to Gen programs...

[Daniel Stratton]

The CFB isn't just client=>server, as I understand it.  It did apply to block mode, in the circumstances where you're flowing from one screen to another where they are packaged in different load modules.  But the Gen runtimes take care of that under the covers.

 

The PStep AD and normal Action Blocks are just like any other COBOL program, just with some specific inputs/exports.  I've worked on projects where it's successfully been done - but generally decided the extra burden of wrapping some of the DM issues weren't worth the benefits gained.  Granted, it wasn't MQ, so that may change the balance.

 

But it's certainly doable.

[Anon Anon]

Thanks again Daniel.  As  you said, some of the challenges are formidable like handling exceptions and flows.  For instance I don't know how message exit states are handled.  It looks like the value of PSMGR-EXIT-STATE is set to a variable depending on the actual exit state and this is passed back up to the dialog manager.  If I were to CALL the PStep directly then I would have to interrogate this and decide what happened, right?  I don't know if the fact that MQ is involved makes any of this simpler!

But FWIW, can I take this offline and ask you specifically about your experience where it was done successfully?

[Daniel Stratton]

For sure, no worries.

[Anon Anon]

I'm not able to send you a message directly .  I get a strange red bar across the bottom of the screen and it refuses to send the message.  Can you try sending me one- perhaps I might be able to respond!

[Anon Anon]

I'd create an EEB with the comm-area. It works the same as writing an EAB to call a Cobol module, basically just do it the other way round.

[Anon Anon]

Thanks Werner- hate to sound thick, but not sure what an EEB is?

[Anon Anon]

Hi Sumithar

 

Where the EAB (External Action Block) connects your CA:Gen module to a Cobol or C module external to your application, you can use an EEB (External Entry Block) to let another application make use of the application functionality developed in CA:Gen. To do this in Cobol you would Generate the Cobol code locally (on your pc) and copy the content of the complete Linkage Area to a data area in the Working Storage of the EEB (the calling module). The EEB would typically:

1. move data that is received in it's linkage area to the Import Views which is now situated in the Working Storage (remember to also fill items as length and occurances as the CA:Gen module would otherwise presume the field to be empty), then
2. do a CALL USING WS-CAGEN-AREA's and
3. upon return fill the output fields of the Linkage area with the information from the Export Views in de the Working Storage. Also remember to do the translation of the CA:Gen error-handling (fields like the SQL-code in the GLOBDATA) to give the information back to the Cobol calling module.

[Anon Anon]

Thanks Werner, I had not heard the term EEB before but it is apt.  I wonder if you could explain a couple of things...

"To do this in Cobol you would Generate the Cobol code locally (on your pc) and copy the content of the complete Linkage Area to a data area in the Working Storage of the EEB (the calling module)"

You talk about generating Cobol on the PC- but hasn't that option been discontinued for some time now?  I guess I could generate on the host itself right?

 

Also later on you say

"upon return fill the output fields of the Linkage area with the information from the Export Views in de the Working Storage. Also remember to do the translation of the CA:Gen error-handling (fields like the SQL-code in the GLOBDATA) to give the information back to the Cobol calling module"

Which Linkage area are we talking about here?  That of the EEB?  This is what the EEB would pass back to the Cobol program that called it?

 

If you could provide an example, that would be great.

Thanks!

[Anon Anon]

You can generate COBOL from the toolset using the cross generator for z/OS or COBOL (I can’t remember the name).  This generator is for creating remote files (.rmt) that may be transferred to the mainframe and then built there using either the host encyclopedia or z/OS build tool.