I have a natrual program within CICS which is invoked from within a CICS transaction. The purpose othe natural program is to grab some of the global parms, invoke a VB script and provide mainframe information (through entire x calls) to the VB script.

The question is how do I set this up on the mainframe? Is there doc somewhere? We can call entirex from batch, but the natural program, when executed from within CICS, gives a 0004 program “broker” not found.

Please help. Thanks,

BJ

Just as in batch, when you linkedit your CICS NATURAL nucleus you should have an INCLUDE for the Broker stub. By default this is NATETB23 for NATURAL. No PPT entry is required.

However, when a called program cannot be located (CALL ‘BROKER’) you should receive a NAT0920 error. If you are not receiving the NAT0920 then BROKER is being found (it should be found if it is linked to the CICS NATURAL nucleus). If BROKER is found then you need to check the value of ERROR-CODE in the Broker Control Block after the call.

Exactly where are you getting the value 0004 from?

Wayne Campos

Are you using the ACI or RPC model to invoke your Natural program from VB? If the VB Script is to initiate the call to the Natural program, the Natural program either has to be a Natural ACI Server, likely running as an asynchronous task or it needs to be a Natural subprogram to be invoked from a Natural RPC server (which would also be set up to run as an asynchronous task).

In either case, this is not set up as a CICS transaction invoked one-off for each request nor does it receive global parms. The server (ACI or RPC) is running continuously, waiting for requests unless you use Broker Services to start the server as a CICS transaction via Attach Manager.

Thanks for responding to my post. We are progressing, but have not resolved the problem. Here is where we stand:

When we hit enter from our CICS/Natural application, we invoke a natural program that is gathering information (global parms) and calling broker. Instead of the return code 004, we now get return code 0 sent back to the natural program. However, the broker address space on the mainframe shows the following:

[size=12][size=7]M NATSRVD 4880 NAT6978 Version error on Server, reason 2 ,
M *** Ready for reply to at 13:37:15
********** USER-ID: BE5CCC96E8DE8360 LIB : ENTIRE SERVER: DEVL
B *** Reply sent for at 13:37:15
FUNCTION: R RC: 0
00000000 Successful response
SEND-LEN: 192 REC-LEN: 192

The messages you are showing are from a Natural RPC Server trace. Thus, to call this server from Natural, you would use a CALLNAT statement and SYSRPC or DFS parameters to point your Natural (calling) environment to the appropriate Natural (server) environment…

which is at odds with what you describe when you say that the client is VB Script.

Could you give a description of the application and environments involved? I think there is some confusion as to what is the client and what is the server here?

A typical setup for a VB Script client would be:

• define a Natural subprogram to perform the work desired. Input and output from the subprogram is entirely through the PDA (parameter data area). No global variables are involved or available.
• a Natural RPC Server is established, either in batch or CICS. Typically, it is easier to set up the server in batch. A server is needed in CICS only if you are accessing CICS-specific services (for example, Natural VSAM or the application calls some CICS/COBOL routines).
• use the EntireX Natural IDL generator to obtain the PDA and create the IDL.
• use the EntireX Workbench to generate a wrapper (probably a DCOM wrapper for VB Script). Make the generated DLL available to be called from the VB Script host.

If, on the other hand, you are attempting to have a CICS/Natural program invoke a VB program on Windows, you will need to establish a server (ACI or RPC) on the Windows platform (not the mainframe). Let us know if this is what you are attempting to do and we can elaborate on some of the possible ways to solve this too.

Deleted…