xychange command does not report missing input trans tables

Hello.  While running xychange, I ran into something that puzzles me.  It may be a bug in the code but I wanted to run it by the group before opening up a ticket, just in case I’m missing something obvious.

When I run xychange using command “/opt/xyvision/xz/bin/xychange” and my job ticket is set to call the wrong Xychange Library, xychange does not work, as I would expect.  However, I still get this information in a log file for my job:

Pass 1, Transformation table: Table1
Transformed … bytes

Pass 2, Transformation table: Table2
Transformed … bytes

>>> Successful completion of XyChange <<<

But, if I manually run an Import command on the same DIV in PathFinder, I get this, which I consider correct:

Running Xychange
Pass 1, Transformation table: Table1
Transformation file ' Table1' does not exist
ERROR: Xychange failed

I know that the manual import is using “/opt/xyvision/xz/bin/import.pl”.

My question is why does running /opt/xyvision/xz/bin/xychange report success to my log file even though the transformations actually do fail?

Any feedback is appreciated.

Thanks.

Parents
  • Hi, Barry.  If I add -X, I get this:
    Pass 1, Transformation table: crentity
            /opt/xyvision/sd_liz/Lsyslib/_tt_sys.x, Size=577
    Transformed ... bytes
    ...
    Pass 2, Transformation table: TestXych
            /opt/xyvision/sd_liz/Lsyslib/_tt_sys.x, Size=577
    Transformed ... bytes
    ...
    >>> Successful completion of XyChange <<<
    It almost looks like the process is going to Lsyslib to grab the default "sys" trans tables and swapping them in for the tables in the JT.  I do have an output file for my command and it has no byte size changes from the input file so that would support the idea that the "sys" table is being called since all it does is replace "a" with "a".
    I also tried adding -debug to my command line call but I saw no new information.
    Am I the only one with this behavior?
  • Since the beginning of Xy (somewhere back in 1982), xychange has always defaulted to "tt sys" if it cannot find the specified translation table. As you have noticed, it contains a translate of "a" to "a" which basically does nothing. I don't know for sure why it does this, but if I had to guess its because we did not want auto-processing to stop for any reason. An error would abort and the goal is to always have some Division produced even though it might not be correct.

    If you look at "xyhelp xychange", you will see that there is a "-e" option which means exact match the translation table and not default to "sys". So if you can have it anyway you want.

  • Although you might find it strange behaviour, Xychange translation tables are looked up in exactly the same way as any other style file. If it can not find a file it ends up by using the 'sys' version that is sitting in the Lsyslib folder.
    (just like Steve just explained)

    So the behaviour you see is (and has always been) intended. Whether it makes sense that is a different question.

    That is why I asked a couple of years ago to change the default behaviour. But as engineering hates to change existing behaviour (and that is a good thing but at the same time very annoying), I got the -e option in return.

    I always make sure that the '-e' option is set in the interface and then set the profile to remember my last settings. Like that you will always run xychange manually with the -e option set and get an error when the translation table can not be found. (I always set the -kp option as well, a wonderful thing when debugging things)

    Tip for your programmers: if you create a script that transforms things always make sure to add the -e option when running a xychange step. Like that xychange will fail when it can not find the table it needs!

Reply
  • Although you might find it strange behaviour, Xychange translation tables are looked up in exactly the same way as any other style file. If it can not find a file it ends up by using the 'sys' version that is sitting in the Lsyslib folder.
    (just like Steve just explained)

    So the behaviour you see is (and has always been) intended. Whether it makes sense that is a different question.

    That is why I asked a couple of years ago to change the default behaviour. But as engineering hates to change existing behaviour (and that is a good thing but at the same time very annoying), I got the -e option in return.

    I always make sure that the '-e' option is set in the interface and then set the profile to remember my last settings. Like that you will always run xychange manually with the -e option set and get an error when the translation table can not be found. (I always set the -kp option as well, a wonderful thing when debugging things)

    Tip for your programmers: if you create a script that transforms things always make sure to add the -e option when running a xychange step. Like that xychange will fail when it can not find the table it needs!

Children