Re: Command fails in batch, seems to work at-ed interactively - VMS

This is a discussion on Re: Command fails in batch, seems to work at-ed interactively - VMS ; AEF wrote on 09/19/2007 08:23:02 PM: > On Sep 19, 8:19 pm, David J Dachtera > wrote: > > AEF wrote: > > > > > On Sep 17, 9:33 pm, Doug Phillips wrote: > > > > On Sep ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Command fails in batch, seems to work at-ed interactively

  1. Re: Command fails in batch, seems to work at-ed interactively

    AEF wrote on 09/19/2007 08:23:02 PM:

    > On Sep 19, 8:19 pm, David J Dachtera
    > wrote:
    > > AEF wrote:
    > >
    > > > On Sep 17, 9:33 pm, Doug Phillips wrote:
    > > > > On Sep 17, 8:26 pm, David J Dachtera
    > > > > wrote:

    > >
    > > > > > Doug Phillips wrote:

    > >
    > > > > > > On Sep 17, 11:45 am, norm.raph...@metso.com wrote:
    > > > > > > > This code checks for an empty or blanked PostalZip field.
    > > > > > > > When run inside the batch, is seems to give a

    different,incorrect
    > > > > > > > result then when the code is extracted to another procedure

    file
    > > > > > > > and run against the renamed data file.
    > > > > > > > In this case there is a match and Sever is "1".
    > > > > > > > In the nomatch case Sever is "3".
    > > > > > > > Here the "no strings matched" sets Sever to "3" indicating a

    wrong
    > > > > > > > result as there should have been a match.
    > > > > > > > Why would the same code fail to work and later work on the

    renamed
    > > > > > > > file. (The diff command is to eliminate the trailing

    > spaces first.)
    > > > > > > > [OpenVMS Alpha V7.3-1]
    > > > > > > > === Actual log excerpt:
    > > > > > > > Sent file JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML.1, 571384

    bytes.
    > > > > > > > QUIT
    > > > > > > > <221
    > > > > > > > $@mfgcom:check_postal.com "JAM317:[CM_PROD.DATA]

    > FRONTIER_ATO.XML;1;"
    > > > > > > > $!$ ffile="jamdata:FRONTIER_SHR.XML_2007090603045085;1"
    > > > > > > > $
    > > > > > > > ffile=f$search(f$parse("JAMDATA:FRONTIER_SHR.

    > XML_*;",,,,"SYNTAX_ONLY"),3)
    > > > > > > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]

    > FRONTIER_ATO.XML;1;"
    > > > > > > > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]

    > FRONTIER_ATO.XML;1; nl:
    > >
    > > > > > > Is the semicolon ";" *after* the version (i.e. .XML;1 a

    > posting typo
    > > > > > > or is it really in your command?

    > >
    > > > > > Interesting thought; however, ...

    > >
    > > > > > DJAS02:DACHTERA$ pipe diff/nonumb/igno=trail login.com;1; nl:
    > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of

    > special characters
    > > > > > \;NL\
    > > > > > DJAS02:DACHTERA$ sh sym $status
    > > > > > $STATUS == "%X00038110"

    > >
    > > > > > (VMS V7.3-2, V7.2-2 gives same result interactively.)

    > >
    > > > > > Gives a different message/status.

    > >
    > > > > Yes it does. It pipes the error to the next command, but it

    doesn't
    > > > > display it. The $status is from the last command in the pipe, no?

    > >
    > > > Apparently so! See below.

    > >
    > > > Try
    > > > > piping it your example. Here's mine:

    > >
    > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | type sys$pipe
    > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
    > > > > characters
    > > > > \;NL\
    > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | search

    sys$pipe
    > > > > "whatever"
    > > > > %SEARCH-I-NOMATCHES, no strings matched

    > >
    > > > Yes, this extra semicolon appears to be the cause of the problem:

    > >
    > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE SET
    > > > %SEARCH-I-NOMATCHES, no strings matched
    > > > $ PIPE DIFF LOGIN.COM;4 NL: | SEAR SYS$PIPE SET
    > > > 2 $ set noon
    > > > 7 $ set terminal/inquire/noeightbit/INSERT/FORM
    > > > $

    > >
    > > > Apparently, errors in the first steps aren't reported to SYS$ERROR

    or
    > > > SYS$ERROR isn't the screen until the last command is run (deja vu:

    why
    > > > is this only a warning?!):

    > >
    > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE invalid
    > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
    > > > characters
    > > > $

    > >
    > > > This looks like a good reason _not_ to use PIPE in a command
    > > > procedure. In this case it saves you from working with temporary

    files
    > > > and their cleanup but makes troubleshooting more difficult. Friendly
    > > > comments welcome on this.

    > >
    > > I wouldn't go quite that far. Yes it complicates debugging; however

    see:
    > > $ HELP PIPE Description Pipelines_and_TEEs Using_TEEs_and_SYS$PIPE
    > >
    > > ...for an example of TEE.COM that you can insert into the pipeline and

    see
    > > what's actually being PIPEd into SEARCH, in this case.
    > >
    > > $ PIPE DIFF LOGIN.COM;4; NL: | @TEE SYS$COMMAND | SEAR SYS$PIPE SET
    > >
    > > Probably only works on-line. In batch, send the TEE output to a disk

    file.
    > >
    > > --
    > > David J Dachtera
    > > dba DJE Systemshttp://www.djesys.com/
    > >
    > > Unofficial OpenVMS Marketing Home

    Pagehttp://www.djesys.com/vms/market/
    > >
    > > Unofficial Affordable OpenVMS Home

    Page:http://www.djesys.com/vms/soho/
    > >
    > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/
    > >
    > > Unofficial OpenVMS Hobbyist Support

    Page:http://www.djesys.com/vms/support/
    >
    > OK, thanks.
    >
    > AEF
    >

    Points taken, but in this case (I covered myself with the "seems" in the
    subject)
    the debugging problem was "old eyes" as I failed to see the typo-induced
    extra
    ";" from the calling procedure, so none of these issues would have helped
    bring
    to light the problem in a "test" scenerio; the real problem, not being
    understood,
    was not presented to the testing.


  2. Re: Command fails in batch, seems to work at-ed interactively

    On Sep 20, 9:39 am, norm.raph...@metso.com wrote:
    > AEF wrote on 09/19/2007 08:23:02 PM:
    >
    >
    >
    > > On Sep 19, 8:19 pm, David J Dachtera
    > > wrote:
    > > > AEF wrote:

    >
    > > > > On Sep 17, 9:33 pm, Doug Phillips wrote:
    > > > > > On Sep 17, 8:26 pm, David J Dachtera
    > > > > > wrote:

    >
    > > > > > > Doug Phillips wrote:

    >
    > > > > > > > On Sep 17, 11:45 am, norm.raph...@metso.com wrote:
    > > > > > > > > This code checks for an empty or blanked PostalZip field.
    > > > > > > > > When run inside the batch, is seems to give a

    > different,incorrect
    > > > > > > > > result then when the code is extracted to another procedure

    > file
    > > > > > > > > and run against the renamed data file.
    > > > > > > > > In this case there is a match and Sever is "1".
    > > > > > > > > In the nomatch case Sever is "3".
    > > > > > > > > Here the "no strings matched" sets Sever to "3" indicating a

    > wrong
    > > > > > > > > result as there should have been a match.
    > > > > > > > > Why would the same code fail to work and later work on the

    > renamed
    > > > > > > > > file. (The diff command is to eliminate the trailing

    > > spaces first.)
    > > > > > > > > [OpenVMS Alpha V7.3-1]
    > > > > > > > > === Actual log excerpt:
    > > > > > > > > Sent file JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML.1, 571384

    > bytes.
    > > > > > > > > QUIT
    > > > > > > > > <221
    > > > > > > > > $@mfgcom:check_postal.com "JAM317:[CM_PROD.DATA]

    > > FRONTIER_ATO.XML;1;"
    > > > > > > > > $!$ ffile="jamdata:FRONTIER_SHR.XML_2007090603045085;1"
    > > > > > > > > $
    > > > > > > > > ffile=f$search(f$parse("JAMDATA:FRONTIER_SHR.

    > > XML_*;",,,,"SYNTAX_ONLY"),3)
    > > > > > > > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]

    > > FRONTIER_ATO.XML;1;"
    > > > > > > > > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]

    > > FRONTIER_ATO.XML;1; nl:

    >
    > > > > > > > Is the semicolon ";" *after* the version (i.e. .XML;1 a

    > > posting typo
    > > > > > > > or is it really in your command?

    >
    > > > > > > Interesting thought; however, ...

    >
    > > > > > > DJAS02:DACHTERA$ pipe diff/nonumb/igno=trail login.com;1; nl:
    > > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of

    > > special characters
    > > > > > > \;NL\
    > > > > > > DJAS02:DACHTERA$ sh sym $status
    > > > > > > $STATUS == "%X00038110"

    >
    > > > > > > (VMS V7.3-2, V7.2-2 gives same result interactively.)

    >
    > > > > > > Gives a different message/status.

    >
    > > > > > Yes it does. It pipes the error to the next command, but it

    > doesn't
    > > > > > display it. The $status is from the last command in the pipe, no?

    >
    > > > > Apparently so! See below.

    >
    > > > > Try
    > > > > > piping it your example. Here's mine:

    >
    > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | type sys$pipe
    > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
    > > > > > characters
    > > > > > \;NL\
    > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | search

    > sys$pipe
    > > > > > "whatever"
    > > > > > %SEARCH-I-NOMATCHES, no strings matched

    >
    > > > > Yes, this extra semicolon appears to be the cause of the problem:

    >
    > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE SET
    > > > > %SEARCH-I-NOMATCHES, no strings matched
    > > > > $ PIPE DIFF LOGIN.COM;4 NL: | SEAR SYS$PIPE SET
    > > > > 2 $ set noon
    > > > > 7 $ set terminal/inquire/noeightbit/INSERT/FORM
    > > > > $

    >
    > > > > Apparently, errors in the first steps aren't reported to SYS$ERROR

    > or
    > > > > SYS$ERROR isn't the screen until the last command is run (deja vu:

    > why
    > > > > is this only a warning?!):

    >
    > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE invalid
    > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special
    > > > > characters
    > > > > $

    >
    > > > > This looks like a good reason _not_ to use PIPE in a command
    > > > > procedure. In this case it saves you from working with temporary

    > files
    > > > > and their cleanup but makes troubleshooting more difficult. Friendly
    > > > > comments welcome on this.

    >
    > > > I wouldn't go quite that far. Yes it complicates debugging; however

    > see:
    > > > $ HELP PIPE Description Pipelines_and_TEEs Using_TEEs_and_SYS$PIPE

    >
    > > > ...for an example of TEE.COM that you can insert into the pipeline and

    > see
    > > > what's actually being PIPEd into SEARCH, in this case.

    >
    > > > $ PIPE DIFF LOGIN.COM;4; NL: | @TEE SYS$COMMAND | SEAR SYS$PIPE SET

    >
    > > > Probably only works on-line. In batch, send the TEE output to a disk

    > file.
    >
    > > > --
    > > > David J Dachtera
    > > > dba DJE Systemshttp://www.djesys.com/

    >
    > > > Unofficial OpenVMS Marketing Home

    >
    > Pagehttp://www.djesys.com/vms/market/
    >
    > > > Unofficial Affordable OpenVMS Home

    >
    > Page:http://www.djesys.com/vms/soho/
    >
    > > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/

    >
    > > > Unofficial OpenVMS Hobbyist Support

    >
    > Page:http://www.djesys.com/vms/support/
    >
    > > OK, thanks.

    >
    > > AEF

    >
    > Points taken, but in this case (I covered myself with the "seems" in the
    > subject)
    > the debugging problem was "old eyes" as I failed to see the typo-induced
    > extra
    > ";" from the calling procedure, so none of these issues would have helped
    > bring
    > to light the problem in a "test" scenerio; the real problem, not being
    > understood,
    > was not presented to the testing.


    But what about this:

    Here's the relevant log snippet:

    $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;
    1;"
    $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1; nl:
    /nonumb | -
    sear sys$pipe ""/window=(0,6)/mat=or/exact/nonumb |
    -
    sear sys$pipe "" /exact/nonumb | -
    sear sys$pipe "> ","><"/exact/out=nl:
    %SEARCH-I-NOMATCHES, no strings matched

    Now, suppose instead of using PIPE you did this:

    $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;
    1;"
    $ diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1; nl:
    /nonumb


    The error message from the DIFF would tell you right away what the
    problem was, no?

    AEF


+ Reply to Thread