Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
13 replies Latest Post - ‏2012-02-03T19:37:52Z by barbara_morris
Triggerman400
Triggerman400
7 Posts
ACCEPTED ANSWER

Pinned topic SSD's

‏2012-01-24T14:52:03Z |
We've added SSD's to our production system and are having good results with them, but are still just feeling our way around as far as working out all the associated kinks and I have been able to find very little information on the subject in this or any other forum.

The specific problem we have currently is that when someone uses cpyf or crtdupobj to make a copy of physical or logical file that we have assigned to the SSD's the new copy of the file carries the same Preferred Storage Unit of *SSD as the original file did. We then have to do a change physical or logical file command or an alter to the file to change that Unit setting to *ANY so that the copy of the file will not reside on the SSD unit. Since we do not always know when someone or some program is making a copy of these files, we need to have some way to incorporate the cleanup (via a call to Chgpfm, etc) into the original cpyf or crtdupobj commands.

I know that changing the CPP of a System Command is frowned upon and may not work anyway (if IBM is now hardcoding the CPP call to QSYS as I have seen elsewhere). Is there an exit program where a followup command or a call to a CL program could be attached to a System Command? Or, any other workarounds for this? Any suggestions would be appreciated.
Updated on 2012-02-03T19:37:52Z at 2012-02-03T19:37:52Z by barbara_morris
  • ScottForstie
    ScottForstie
    38 Posts
    ACCEPTED ANSWER

    Re: SSD's

    ‏2012-01-24T15:44:49Z  in response to Triggerman400
    Hi there,
    One approach to consider would be to query the QSYS2/SYSPARTITIONSTAT catalog, looking for instances of MEDIA_PREFERENCE=255.
    This query could be executed on a regular basis to identify cases where the media preference contains the wrong setting.
    Regards, Scott Forstie
    • Triggerman400
      Triggerman400
      7 Posts
      ACCEPTED ANSWER

      Re: SSD's

      ‏2012-01-24T17:38:33Z  in response to ScottForstie
      Thanks for the reply Scott,

      What we really want to accomplish is to prevent the copies from being made on the SSD's in the first place. Then, there would be no need to have to go back in and move the files off the SSD with a change command.
      • ScottForstie
        ScottForstie
        38 Posts
        ACCEPTED ANSWER

        Re: SSD's

        ‏2012-01-24T20:55:18Z  in response to Triggerman400
        You could create a command exit program.
        The exit program could use DSPFD examining 'Preferred storage unit' or the catalog query I gave you, to determine the media preference of the source file.

        Command exit programs today are always run before the command runs.
        The QIBM_QCA_CHG_COMMAND exit point lets the called exit program change the command string to be run which can include adding, removing, or changing parameters and even changing the command being run.
        There can only be one (1) exit program registered at this exit point per command.

        For this scenario, I guess you would need to change the command being run since there is no existing media-preference CRTDUPOBJ command parameter.

        Regards, Scott
        • Triggerman400
          Triggerman400
          7 Posts
          ACCEPTED ANSWER

          Re: SSD's

          ‏2012-01-27T21:02:39Z  in response to ScottForstie
          Scott,
          In looking at all our options, QIBM_QCA_CHG_COMMAND looks like the best way to keep CPYF and CRTDUPOBJ from creating new tables with the Storage Unit set to 255 (*SSD).

          One odd thing I noticed in researching this was that the Media_Preference column is not showing up in either the SysPartitionStat or SysPartitionIndexStat views, although other new columns (like LowValue, HighValue, and Partitioning Key) are there. We are currently on 6.1.1 and the SSD's are function correctly and the tables show the Preferred Storage Unit value on DSPFD ok, so I thought we were current on PTF's.

          Were there some special PTF's that added the Media_Preference column to the catalogs?

          Also, are there any plans to add the UNIT parm to CPYF and CRTDUPOBJ in the future? That would allow us to address the problem with Command Defaults.
          • ScottForstie
            ScottForstie
            38 Posts
            ACCEPTED ANSWER

            Re: SSD's

            ‏2012-01-28T20:19:53Z  in response to Triggerman400
            We currently have no plans to add the UNIT parameter to CPYF or CRTDUPOBJ.
            We recommend using the existing commands CHGPF, CHGLF, CHGPFM, or CHGLFM when you need to change the media preference.
            The Media_Preference support in the catalogs exists only on IBM i 7.1, sorry for not pointing that out in my earlier post.
            Regards, Scott
        • Triggerman400
          Triggerman400
          7 Posts
          ACCEPTED ANSWER

          Re: SSD's

          ‏2012-02-01T21:31:07Z  in response to ScottForstie
          I haven't used this exit point before, so I'm researching how it works.

          If I understand the QIBM_QCA_CHG_COMMAND exit point, it runs the exit point program PRIOR to prompting the command, so I would not be able to see the 'From' file or Object on prompted commands (which will probably be the case more often than not). The QIBM_QCA_RTV_COMMAND, on the other hand, runs just before the call to the CPP, so the exit point program could see the 'From' file or Object in that case. However, it will need to call CrtDupObj or Cpyf to create the new copy of the file, followed by a call to ChgPF or ChgLF to change the Unit value to *ANY. Since I will already have the Exit Point program registered for CrtDupObj and Cpyf, How can I avoid recursion on the exit point programs call to CrtDupObj?

          The documentation says recursion "may" occur. I'm not sure what that means. Will I get a hard error or can I tell I'm in my second invocation of the exit point program and just let that one go on through without any changes?
          • ScottForstie
            ScottForstie
            38 Posts
            ACCEPTED ANSWER

            Re: SSD's

            ‏2012-02-02T00:10:56Z  in response to Triggerman400
            Yes you understand QIBM_QCA_CHG_COMMAND correctly.

            For the recursion concern, it is possible to get yourself into a loop situation where the exit program for command A uses command A which then calls the exit program which calls command A etc.

            I don't think that applies to you because you plan to have the command exit program over CRTDUPOBJ/CPYF and call CHGPF/CHGLF from within the exit program.

            Regards, Scott
            • Triggerman400
              Triggerman400
              7 Posts
              ACCEPTED ANSWER

              Re: SSD's

              ‏2012-02-02T13:45:43Z  in response to ScottForstie
              Unfortunately, the new table has not been created yet at that point in time. I would need to create it first with CrtDupObj inside the exit program, and then call ChgPf or ChgLf while still inside the exit program. It's that second call to CrtDupObj that gets me into recursion.

              Could I create a second copy of the CrtDupObj command in another library and not have it registered to the Exit Point and have the exit point program that is registered on the QSYS version of the command call it without running into recursion? Some posts I've read seemed to indicate that IBM was preventing that now (through hard-coding the CPP call within the command or something like that). Is that true?
              • ScottForstie
                ScottForstie
                38 Posts
                ACCEPTED ANSWER

                Re: SSD's

                ‏2012-02-02T16:49:37Z  in response to Triggerman400
                Yes you can have your own CRTDUPOBJ command in a different library and control its use by controlling the library list.
                Such an approach has short-comings, including:
                • if IBM ships an improvement to the command, your command may need to change
                • if someone changes the library list, your command may not be called

                An alternative approach would be to utilize the CRTPRXCMD (proxy command) to establish a proxy command in a different library for CRTDUPOBJ. Then, your exit program could interrogate the proxy information to distinguish between normal CRTDUPOBJ calls and command exit program initiated calls, to avoid recursion.

                I still like the approach of periodically querying the catalog to identify tables and indexes with incorrect media preference settings. Its much simpler to deploy and you might find that its an effective way to educate users.
                • Triggerman400
                  Triggerman400
                  7 Posts
                  ACCEPTED ANSWER

                  Re: SSD's

                  ‏2012-02-03T16:28:27Z  in response to ScottForstie
                  So when the exit point documentation says "a recursive loop 'may' occur", they are talking about the limitations of the language used for the exit program and not something built into the Exit Point process itself?

                  I think I've about got an automated solution mapped out now. I'll let you know if I run into any more 'gotchas'.

                  Thanks for your help Brian, Barbara, Scott.
                  • barbara_morris
                    barbara_morris
                    7 Posts
                    ACCEPTED ANSWER

                    Re: SSD's

                    ‏2012-02-03T19:37:52Z  in response to Triggerman400
                    I think the documentation is assuming that recursion is supported by the language used for the exit program. I think the word 'may' is used because the recursion loop would only happen if the exit program unconditionally used a command that caused it to be called again.
          • SystemAdmin
            SystemAdmin
            102 Posts
            ACCEPTED ANSWER

            Re: SSD's

            ‏2012-02-02T17:30:03Z  in response to Triggerman400
            CL is happy being called recursively. Assume your exit program is CL and is named "MYEXITPGM"...
            SNDPGMMSG to MYEXITPGM

            IF FAIL
            NOT RECURSIVE
            CONTINUE
            ELSE
            IS RECURSIVE
            EXIT
            END IF FAIL

            CONTINUE:
            ...
            If youre writing in RPG, create the above as a CL module that serves as the entry procedure for MYEXITPGM.

            Or you could handle recursion detection in RPG. You just need a program entry procedure that allows recursion. CL can do that, but RPG cannot. However a NOMAIN RPG procedure can be called recursively. So you have a CL entry module that does nothing but call a NOMAIN RPG procedure were all processing takes place.
            • barbara_morris
              barbara_morris
              7 Posts
              ACCEPTED ANSWER

              Re: SSD's

              ‏2012-02-02T17:45:28Z  in response to SystemAdmin
              Starting in 6.1, you can create an RPG main procedure that can be called recursively.

              Use the MAIN keyword in the H spec to identify which subprocedure is the main procedure.
              
              H main(helloWorld) D helloWorld      pr                  extpgm(
              'HELLOWORLD') D   times                       15p 5 
              
              const   P helloWorld      b D helloWorld      pi D   times                       15p 5 
              
              const /free dsply (
              'hello - parm is ' + %
              
              char(%
              
              int(times))); 
              
              if times > 1; helloWorld(times - 1); endif; /end-free P helloWorld      e
              

              
              ===> crtbndrpg helloworld ===> call helloworld 3 DSPLY  hello - parm is 3 DSPLY  hello - parm is 2 DSPLY  hello - parm is 1