ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

QSH "Touch" command suddenly failing

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

  • QSH "Touch" command suddenly failing

    Hello,

    We have a CL program that has been in place since 2014, it is running on 13 different iSeries of varying levels of O/S - the majority are V7R1MO L00, a few are V6R1M1 L00.

    This program works everywhere albeit recently, on a single machine, it stopped working.
    I am convinced that something O/S related has changed but, as the box is hosted by a 3rd party, getting them to advise what is like getting blood out of a stone.
    I want to prove it has changed, but I lack the skills/knowledge to identify what has changed.

    To give an overview of the issue, the CL program does this;
    Code:
    CHGVAR     VAR(&QSHSTRING) VALUE('touch +     
                 -C 1208' *cat  ' ' *cat &NewFile)
    QSH    cmd(&qshString)
    When this started failing, analysis was done and it was was advised that the '-C 1208' needed to be on the end of the command - so I changed the program to this;

    Code:
    CHGVAR     VAR(&QSHSTRING) +                       
               VALUE('touch '|| &NewFile |< ' -C 1208')
    QSH    cmd(&qshString)
    This is a temporary fix whilst we try to ascertain the cause.
    When this command runs now, it ends with an exist status of 0 and I can see the file which is great.
    However, shortly after it does this;
    Code:
    CHGVAR     VAR(&QSHSTRING) VALUE('iconv  +               
                 -f 1208 -t 819' *tcat  ' ' *CAT &IntFile +  
                 *tcat ' ' *cat '>' *cat  ' ' *cat &FullFile)
    QSH    cmd(&qshString)
    Which ends with a status of '1' and produces a print that says; iconv: 0791-004 cannot open converter

    So the "quick fix" I was asked to do, is now going to mean I'll need to run through all commands in program and figure out which work and which won't.

    ===========

    I am just wondering if anyone knows how I can maybe determine the version of QSH or has any idea where to look to find something that would affect the syntax of the commands - I am guessing it is probably some sort of update but I'm not sure it was a PTF.
    From what I understand; PTFs have to be installed via an IPL, this started happening in June and QCTL has been active since May.
    I've been through this; https://www.ibm.com/support/knowledg...ahzdevelop.htm but not finding anything, I will go through it again though.

    Thanks in advance,
    Ryan

  • #2
    Ok.
    So I searched google for QSHELL and just opened the top 10 results without pre-checking them.
    One of them highlighted the use of /bin/usr and /QOpenSys/usr/bin being used by QSH when looking for commands
    The objects in: /QOpenSys/usr/bin/ have an update date of the day the program started failing, the other iSeries have an update date of 2013.

    So I guess this is proof enough - although if you can provide any further sticks that I can beat the 3rd party with , it would be greatly appreciated

    Comment


    • #3
      Before anything else, can you tell us what the failing command is expected to do? That is, I know what touch is used for; but exactly what is it used for in your program? If you describe what you expect to happen, it might be easier to say how any program should be 'fixed'.

      Originally posted by RDKells View Post
      This program works everywhere albeit recently, on a single machine, it stopped working.
      Is the "single machine" i 6.1 or is it i 7.1?

      I am convinced that something O/S related has changed but, as the box is hosted by a 3rd party, getting them to advise what is like getting blood out of a stone.
      I want to prove it has changed, but I lack the skills/knowledge to identify what has changed.
      Specifically for the QShell touch utility, you could check if any PTFs have been applied against it by running this command:
      Code:
      DSPOBJD OBJ(QSHELL/TOUCH) OBJTYPE(*PGM) DETAIL(*SERVICE)
      You found that QShell primarily relies on files in the /usr/bin directory, and touch is at /usr/bin/touch. You can determine the program behind that file by:
      Code:
      WRKLNK OBJ('/usr/bin/touch')
      Take option 12='Work with links' to see the value of the symbolic link. That should point to the program.

      When this started failing, analysis was done and it was was advised that the '-C 1208' needed to be on the end of the command -...
      AFAIK, there are no (POSIX-compliant) versions of touch that need options to come after the filename. Can you cite the source that pointed in that direction?

      From what I understand; PTFs have to be installed via an IPL, this started happening in June and QCTL has been active since May.
      PTFs might need to be installed via IPL, but perhaps most do not. I've never seen a breakdown that indicates how many require it. For a case such as yours, the length of activity for QCTL won't likely be helpful. There is quite a lot more that might be said. Unfortunately, most would be a waste and simply confuse the issue until it's clear exactly what is supposed to happen in the programming.
      Tom

      There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

      Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

      Comment


      • #4
        Hi Tommy,

        Thanks for your reply.

        Apologies for the misunderstanding, I was after a way to prove QSHELL had changed rather than after a way to fix the program.

        After I highlighted that the /QOpenSys/usr/bin/ objects had changed, on the day the program started failing, the program started magically working again today - I can see the commands in that directory now have an update day of today... they also replaced the objects in /usr/bin/


        I have reviewed what you said and you are correct, all of the syntax documents that I can find for QSH state the options come before the filename;

        http://public.dhe.ibm.com/systems/po...n_US/rzahz.pdf
        touch [-acfm] [-r ref_file] [-t [[CC]YY]MMDDhhmm[.SS] ] [-C CCSID] file

        http://public.dhe.ibm.com/systems/po...n_US/rzahz.pdf
        touch [-acfm] [-r ref_file] [-t [[CC]YY]MMDDhhmm[.SS] ] [-C ccsid] file

        https://www.ibm.com/support/knowledg...hz.pdf?view=kc
        touch [-acfm] [-r ref_file] [-t [[CC]YY]MMDDhhmm[.SS] ] [-C ccsid] file

        https://www.ibm.com/support/knowledg...hz.pdf?view=kc
        touch [-acfm] [-r ref_file] [-t [[CC]YY]MMDDhhmm[.SS] ] [-C ccsid] file

        https://www.ibm.com/support/knowledg...df.pdf?view=kc
        touch [-acfm] [-r ref_file] [-t [[CC]YY]MMDDhhmm[.SS] ] [-C ccsid] file


        I don't know who found that -C 1208 after the filename worked or the source (maybe they just decided to give it a go) but it did work.

        The advice here is that a PASE install in June had corrupted QSHELL and this had gone unnoticed, so QSHELL was re-installed today.

        Thanks again,
        Ryan

        Comment


        • #5
          The standard UNIX touch tool does not have a CCSID option, but the one that IBM ships with QShell does. You'll want to be careful that you're getting the right 'touch' program. It's always possible that a user would modify his/her PATH so that a different one, such as the PASE version, would come first.

          Comment

          Working...
          X