Hello all,
I searched for all of the key words related to my post and found nothing, so I decided to create a new one.
I have recently been given a project to re-architect and upgrade that uses an EntireX Broker to connect Natural Mainframe processes to various other processes. From what I understand so far, it mostly includes updating databases and sending notification emails. Along with the Broker, there is a custom module written in VB, which is over ten years old. I am rewriting this in a different language.
My question is simple:
Would the EntireX Process Extractor help me to trace the various RPC calls that the Broker is helping to route?
Thanks in advance to anyone with advice on the topic.
I am not sure if I understand exactly what you are trying to accomplish.
Are you trying to identify all of the clients calling your Natural mainframe services? Or are you trying to do more than that?
Regards,
Wayne
Sorry for the confusion. I have only had about three weeks of exposure to Natural and EntireX, so I am still getting up to speed.
Identifying some or all would at least be a start. At this point I will take any information I can get since I have to reverse engineer this whole project.
The Broker Attribute file contains all of your service definitions. But, client processes are not defined there so you will need to use the EntireX Command and Information Services (CIS).
EntireX includes an administration tool that is built on top of CIS. Depending on what version of EntireX you have installed, you will have access to the Broker Control Center (BCC), System Management Hub (SMH), or the new Command Central. You can also write your own custom applications using the CIS API.
In addition to the tools I mentioned above, the EntireX command line tools can also provide information about EntireX clients.
What kind of client information are you looking for?
Regards,
Wayne
The product “EntireX Process Extractor” has been retired in 2014.
All I know about the project is that the mainframe team has been using Natural and the EntireX Broker system to automate various events related to the business process here. It seems like the stuff is all pretty typical; updating database entries when x happens, using pub/sub for email notifications, etc. The thing that makes this confusing is that in 2003, a former employee wrote an application in Visual Basic apparently to augment or extend the EntireX Broker’s functionality. The pub/sub functionality? Done in VB, not EntireX. Moving forward to today, no one I work with has a complete understanding of what the VB application does, or which processes the Broker is managing. I have some information, but it is pretty disjointed. The VB app is not a big application at all, nor is it extremely complicated. But I am brand new here, and no one else has a clear idea of how the system is working. I am hoping to gather some more information by simply running the VB app in debug mode and following everything it does, but I am also having a problem with broken DLL references. I have what look like the right DLLs, but none of them seem to work.
I was hoping to use the Process Extractor to gather as much information as possible so I can more quickly replace the components of this system. Then once I know where all of the calls are going, I would just write something new in Java.
I hope this is understandable, but if it is not, just ask me to clarify again. Until about three/four weeks ago, I had never dealt with any mainframe software, so I am still learning how EntireX works.
Glad to see that posting this helped someone else out a little.
Thanks for mentioning that Rolf. I guess I will forget about using the process extractor.
Any thanks to everyone posting here, it is really nice that I posted a question and got replies almost immediately. Thank you all for that, I appreciate it.
You can switch on accounting in the Broker. This gives you a good idea which clients are calling which servers.
Thank you Rolf. I will try your suggestion before doing anything else.
As I mentioned in an earlier post, the service definitions are in the Broker Attribute file. The service “address” is the combination of CLASS, SERVER, and SERVICE parameters. Your VB client has to set these parameters before it sends a request to a service. Once you know the service “address” (CLASS/SERVER/SERVICE) your VB client is calling, you should be able to locate the process (most likely a Started Task on the mainframe) that provides the service. If the service is called via Natural RPC, the SERVICE part of the “address” will be “CALLNAT” and your VB client will have to specify the name of the Natural Subprogram that should be invoked.
Another aspect that is often overlooked is that your VB client might not be a client (service consumer), it may be a server (service provider).
If it is a server then it will implicitly or explicitly issue a REGISTER command with the service “address” of the service it provides. This service “address” will have an entry in the Broker Attribute file. Then you will need to locate the module that consumes the service.
Regards,
Wayne
1 Like
Thank you Wayne. Now that I am back from the weekend, I will follow your suggestions and see what I can find. What you wrote sounds good, so I am confident that at the very least, this will get me closer to solving the problem. As soon as I find the solution, I will post my results in the hopes that it helps someone else in the future.