Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Passing parameters using SBMRMTCMD

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Passing parameters using SBMRMTCMD

    On Friday, March 26, 1999, 06:47 AM, Tim Hutson wrote: When using the SBMRMTCMD command to run a remote AS/400 command on the remote machine, I have run into a brick wall. I am trying to use the command to issue a program call. This program call is issued on the remote AS/400 and I need to pass it program parameters. This is not the problem, however. The problem is that the program being called on the remote machine changes one of the passed parameters and the program calling it on the local machine needs to know what the parameter is returned to the calling program. Since I can't (or don't know how) to pass program variables rather than the actual program values in the parameters with this program using the SBMRMTCMD command, I am at a loss here. Is there a way to do this? I have already thought of DDM links, which I am doing in some instances. However, in this case, I don't want to do this because there would just be too many DDM links to add. Seems like this would be a better way to do it, rather than the DDM links. Has anyone run into this before? You might want to use data queue to communicate between the 2 programs

  • #2
    Passing parameters using SBMRMTCMD


    On Tuesday, March 09, 1999, 05:50 AM, Roger Dethloff wrote: I was wondering if anyone could tell me if it was worth the time and effort to look at each file set and logicals to create the longest keyed logicals first. [/i] Roger: It is definitely worth it to create them in order, so that the LFs with the longest access paths are created first. The following is an article I published in the Toronto Users Group Newsmagazine in July 1998. Implicit Shared Access Paths It seems to be a fairly common misconception that logical files take up no real space or resources on the AS/400. After all, the frequently heard story goes, the system doesn’t need to store the actual records, but only needs an index or access path to the records. However, every access path does take up disk space, and all of the access paths must be maintained whenever the based-on physical file is updated. Implicit Sharing of Access Paths The AS/400 is designed to allow sharing of access paths where possible. For example, if a logical file already exists with a key of FLDA, FLDB, FLDC, and you create a new logical file with a key of FLDA, FLDB, the AS/400 will automatically use the access path that already exists, instead of creating a new one. By doing this, the system can save on logical file access path maintenance and on disk space. However, the system will only share access paths if the logical files are created in an order that allows the system to find an existing useable access path. In the above example, if the logical file with key FLDA, FLDB is created first, the system cannot find a useable access path when the logical file with key FLDA, FLDB, FLDC is created. In this case, there will be two access paths, one for each logical file. Note that this concept of implicit sharing of access paths is not related to Shared Open Data Paths. The Shared ODP concerns itself with reducing the amount of time required to open a file, and can be controlled when creating and/or using a file. Shared ODPs are complex and should be used with care. Why Don’t Files Always Share? The situation that occurs in many application systems is that a new application requires a logical file (say, LFILE1) with key FLDA. Months later, a new report or function is needed that requires a logical file (say LFILE2) with key FLDA, FLDB. It’s not common for a programming shop to go back and update the first program so that it uses the new logical file. This is especially true when many programs in production already use the first logical file. Instead, there are now two logical files (LFILE1 and LFILE2) over the same physical file, and each logical file has its own access path. The system could not use the access path for LFILE1 when creating LFILE2, because the key for LFILE1 (FLDA) was not as specific as LFILE2 (FLDA, FLDB). Find Out Who’s Sharing You can find out which files are sharing access paths by checking the file description. DSPFD FILE(mylib/lfile*) TYPE(*MBR) FILEATR(*LF) If the access path is being shared by another logical file, you’ll see on the display “Implicit Access Path Sharing: Yes”. If you have sent the DSPFD to an outfile, the field name is MBISMT, and sharing is indicated with an “I”. In addition, if the access path is implicitly shared, you can see which access path is being used. On the display, it is presented as “File Owning Access Path: mylib/lfile2”. In the outfile, the fields are MBISL for the library and MBISF for the file name of the File Owning Access Path. Learning to Share Instead of making program changes to many programs that are already in place, simply re-create the access paths in the correct order, and the AS/400 will automatically share the access path. My test was based on a physical file with object size of about 15.5 megabytes. Three logical files were used: LF1 with key FLDA LF2 with key FLDA, FLDB, FLDC LF3 with key FLDA, FLDB, FLDC, FLDD, FLDE, FLDF First, I created LF1, then LF2, then LF3, so that the system needed to create a new access path for each logical file. My result was the following object sizes: LF1 2,630 kb LF2 5,186 kb LF3 7,611 kb So, the three logical files added up to 15.4 megabytes, almost as much as the based-on physical file. Next, I used the RMVM command for all three of the logical files to eliminate all of the access paths. For example, to remove the logical file member for LF2: RMVM FILE(mylib/LF2) MBR(LF2) Then, I added back the logical file members, but did the logical file with the most key fields (LF3) first, then logical file LF2, then LF1. For example, to add the logical file member for LF2: ADDLFM FILE(mylib/LF2) MBR(LF2) My new results were: LF1 5 kb LF2 5 kb LF3 7,612 kb Now, the logical files add up to 7.6 megabytes, which is less than half the amount of disk previously used. In addition to the disk savings, the reduced maintenance of access paths may improve program performance. Review Your Logical Files Review your largest physical files and also those physical files with the most dependent logical files, in order to maximize the benefits of implicit sharing of access paths. Your mother always urged you to learn to share, and now you can see HTH, Debbie Gallagher

    Comment


    • #3
      Passing parameters using SBMRMTCMD

      On Monday, March 29, 1999, 07:01 PM, Debbie Gallagher wrote: It is definitely worth it to create them in order, snip....HTH, Debbie Gallagher This forum never ceases to amaze me. Thanks Debbie this is just what I needed to know and I didn't even know enough to ask the question. 'I love deadlines. I especially like the whooshing sound they make as they go flying by.' - Dilbert

      Comment


      • #4
        Passing parameters using SBMRMTCMD

        On Monday, March 29, 1999, 07:01 PM, Debbie Gallagher wrote: ...Why Don’t Files Always Share? The situation that occurs in many application systems is that a new application requires a logical file (say, LFILE1) with key FLDA. Months later, a new report or function is needed that requires a logical file (say LFILE2) with key FLDA, FLDB. It’s not common for a programming shop to go back and update the first program so that it uses the new logical file. This is especially true when many programs in production already use the first logical file. Instead, there are now two logical files (LFILE1 and LFILE2) over the same physical file, and each logical file has its own access path. The system could not use the access path for LFILE1 when creating LFILE2, because the key for LFILE1 (FLDA) was not as specific as LFILE2 (FLDA, FLDB)... HTH, Debbie Gallagher Debbie, I agree that sharing an access path is better than not sharing. However, I would not consider creating a new logical file to avoid re-compiling a program, or even 10 programs. In most cases the analysis required to create the access paths in order cannot be justified. A much better case could be made for this if you have automated the creation of logical files, and store key attributes which can be analyzed to identify this situation. I would use the technique you describe in two cases. The first case is vendor supplied software over which I have little control. The second case would be to provide better SQL performance. SQL is able to avoid record I/O when a file's access path contains all of the fields requested. For example, running:
        select order_no, customer_no, customer_name from order join customer on order_cust = customer_no
        will perform significantly better if a customer_no, customer_name key exists. The shorter customer_no key will most likely be required to enforce unique keys. I suspect that this would also improve query access, but I have not tested it. David Morris

        Comment


        • #5
          Passing parameters using SBMRMTCMD

          Note that Sav/Rst of the access paths will attempt maximizing of sharing; you have to explicitly prevent it. Refer to the Adv B&R Gd for more information. Accidental sharing can actually cause programs to fail . Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

          Comment


          • #6
            Passing parameters using SBMRMTCMD

            On Tuesday, March 30, 1999, 08:32 AM, David Morris wrote: . . . I would not consider creating a new logical file to avoid re-compiling a program, or even 10 programs. David: I definitely agree with your point, and think that it is better to re-compile the programs. However, in my experience, programmers will ignore my pleas and continue to create the logicals. Sometimes they will even create logicals that are exactly the same as other logicals! You'll notice that my sentence said "It’s not common for a programming shop to go back and update the first program so that it uses the new logical file." It was completely intentional that I didn't say "Programmers shouldn't go back . . ." I probably should have added your point to the note in this forum. Thanks for making the point for me. Debbie Gallagher

            Comment


            • #7
              Passing parameters using SBMRMTCMD

              Creating logicals with identical keys is very ugly, although there is no cost in performance since the access path will be shared. I liked the article you wrote for TUG News. One more thing: If LFILE1 (FLDA) shares an access path with LFILE2 (FLDA, FLDB) and LFILE2 is deleted, the shared access path stays in place and requires overhead, even though the logical file that caused it to be built is deleted. Aside from being told to share, we were also told to clean up.
              On Tuesday, March 30, 1999, 04:50 PM, Debbie Gallagher wrote: ...snip However, in my experience, programmers will ignore my pleas and continue to create the logicals. Sometimes they will even create logicals that are exactly the same as other logicals! ...snip

              Comment


              • #8
                Passing parameters using SBMRMTCMD

                On Wednesday, March 31, 1999, 08:57 AM, Tom Conover wrote: <> One more thing: If LFILE1 (FLDA) shares an access path with LFILE2 (FLDA, FLDB) and LFILE2 is deleted, the shared access path stays in place and requires overhead, even though the logical file that caused it to be built is deleted. This also is often the source of a question: "I saved my access paths, but upon restore it/some are rebuilding." When the described condition is detected, the access path is rebuilt with the shorter key; another space saving technique like the ordering-for-sharing done on restore. The database recognized that the key was defined for one column originally, but the saved version had two keys. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

                Comment

                Working...
                X