sponsored links



No announcement yet.

Program information about parameters and how and when is called

  • Filter
  • Time
  • Show
Clear All
new posts

  • Program information about parameters and how and when is called

    Hi guys,
    I have several legacy programs, meaning some programs from a vendor without having the possibility to change the sources, the objects are trigerred by another upstream application from queues or from the vendor menus. I need to find how they are called , with which parameters, do I have any possibility?

  • #2

    Are the programs RPG400 or RPG IV (RPGLE) ?

    Do you have any CL programs in the suite? If so you may be able to retrieve the CL source and gain some insights there.

    Is the debug listing present?

    Are the programs observable?

    The CL is your best bet. Because the chances of vendor software allowing any of the others is slim. They may have even prevented the CL retrieval.

    There are other methods but they are very labour intensive and involve looking at program dumps.

    There are one or two vendors who can do source retrieval - but it is expensive and they may be unwilling to do it on vendor programs where there are issues of copyright.

    Can I ask _why_ you need this information and why you can't simply ask the vendor? If we know what/why you want this information we may be able to suggest an alternative approach.


    • #3
      Thanks Jon. They are RPGLE, I have the sources retrieved on a test server, on production I have access only to the objects ,the sources are not supposed to be modified by me, also I am not able to change anything on production related to vendor objects. Is important for me to find the parameters passed to the programs from vendor menus, when these RPGLE objects are called because I need to do some setup on upstream application which need to send an XML with the name of the objects and their parameters with values.
      the issue is that the RPGLE objects have something like this as parameters :
      return_flag - char 1
      data_filler1 - char 500
      data_filler2 - char 500

      At the runtime it will receive the values something like this:
      return_flag blank - will be filled by the program
      data_filler1= "client1 account_client1 ... "
      data_filler2="client_name1 .."
      Inside it have some data structures mapped to this parameters but is pretty dificult to catch for all the objects, I have some hundreds..

      I thought to find all the values of parameters and also the pattern regarding the position of the values inside the fillers by monitoring somehow the call of the objects and to log the command CALL MYPGM PARM(" " "client1 account_client1 "... ) to be able to buildthe xml in upstream with the proper call of the program . Do I have any chance to catch it based on object names?


      • #4
        The RPGLE objects are called on demand from some menus - I can ask to the business to do their operations in order to call inside these programs or to catch the call command when they are trigerred from queues based on XML sent by upstream - I have some of the objects called in this manner- with XML sent on MQ containing the call of pgm with parms. I need to do a catalog with all the objects and how can be called - values of parameters meaning the positions for the substring sent in parms data_filler1,2 and also to build the xml to call in this manner with message sent on MQ containing name of the program and his parameters with the values to be passed


        • #5
          Ok - so you know the _definitions_ of the parameters - what you want to know is their _content_ - which is a very different matter.

          The only easy answer is to ask the vendor.

          If you have the source programs why not recompile them with debug view and look at the contents in debug on the dev system?


          • #6
            Yes, the only issue is that I have hundreds of programs, for some of them I don't have the latest updates on the sources retrieved on dev box, so I will have differences.. those sources are something like a view version, only to have a look inside, to see somehow the logic but this is it all..
            I will not be able to compile it in QTEMP as they have several external components which are not on the system.

            I wanted to catch all the information required somehow using a custom tool developed by me and to write in a log file something like this:
            object name;
            last date used;
            command string --- and my tool to run on a setup table where I can define the objects on which to do this monitoring - for me is important to do this monitoring on those objects to know how and what to pass via XML messages under MQ.

            I really would like to find the command string executed with the values of the parameters from runtime... they are in the system at runtime and I wondered how can I catch it to record it, this basically will fix my issue.

            The parameters of those programs are pretty ugly as they are some fillers and they have substrings and the values depends on the context.. basically is something like a data structure inside the programs which will be filled from this filler, but in some cases I will have some fields of the data structures filled from the filler and in other cases I will have other fields, depending of the CALL PGM and how the filler is filled.. I hope that is pretty clear :S.. sorry because first time I was not so clear


            • #7
              oh.. sorry, forgot to answer about the vendor... in the last scenario I will ask the vendor but I would prefer to do a nice solution for me, to can use every time I need it, for any legacy object which is not controlled by me and I don't have the source on production, when I will need information regarding his submission to integrate with upstream...
              many thanks for your help.


              • #8
                Don't forget that if the vendor updates the software you may have to work it all out again!

                Only other thing I can think of (since you know the basic form of the parts would be to try to put a stub (same name - different library) program in place - it would receive the parms and dump them out somewhere before simply passing them along to the original version of the program. Won't work if the library on the menu is hard coxed, but it would work if LIBL is in play.


                • #9
                  Many thanks Jon!! great idea, it will work. I will do it


                  • #10
                    Good - let us know how you get on.


                    • #11
                      Reply #8 - great idea!


                      • #12
                        Actually I've used Jon's idea even when the library was hard-coded. I simply renamed the original program, then inserted my own into the original library under the original name. I then could see exactly which parameters were passed, and could call the old program (using the new name). It didn't need to be using library list because I replaced the program in its original location.

                        If you're going to do that, you should back things up (just in case), and also do it when others won't be using the software, so you don't screw anyone else up.


                        • JonBoy
                          JonBoy commented
                          Editing a comment
                          Great idea Scott - I'll remember that for any cases where the library is hard coded.