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/17/2007 03:30:39 PM: > On Sep 17, 3:03 pm, norm.raph...@metso.com wrote: > > Ron, > > > > The message in the output logfile> *%SEARCH-I-NOMATCHES, no strings matched* > > > > indicates that there was no ...

+ Reply to Thread
Results 1 to 3 of 3

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/17/2007 03:30:39 PM:

    > On Sep 17, 3:03 pm, norm.raph...@metso.com wrote:
    > > Ron,
    > >
    > > The message in the output logfile> *%SEARCH-I-NOMATCHES, no strings

    matched*
    > >
    > > indicates that there was no match, but the rerun indicates (no

    message)
    > > that there was
    > > a match. There should have been a match. the stat variable is not

    wrong,
    > > the result
    > > of the embedded search is wrong in the batch, correct in the at-ed
    > > procedure file.
    > > This seems not to be an issue of the stat variable.
    > >
    > > -Norm

    >
    > Where below is the @-run version?


    > > > === Extracted batch log except:
    > > > $ pipe diff/igno=trail -
    > > > *JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML_2007091522383962;1 -*
    > > > nl: /nonumb | -
    > > > sear sys$pipe ""/window=(0,6)/mat=or/exact/nonumb

    |
    > -
    > > > sear sys$pipe "" /exact/nonumb | -
    > > > sear sys$pipe "> ","><"/exact/out=nl:
    > > > $ sever=$severity
    > > > $ show sym sever
    > > > SEVER = "1"
    > > > ===



    >
    > Could PIPE or SEARCH be defined as different symbols in batch and
    > interactive mode? (Check login procedures.)
    >


    Nope. Same account. PIPE and SEARCH are not overdefined in either
    batch or interactive (I rechecked).

    > Doesn't using a PIPE command complicate figuring out which subcommand
    > generated the $STATUS and $SEVERITY?


    Does it? I would think it still would be the same given the same
    pipe command. Remember the only variables are one is batch and the other
    is at-ed, and one is the original file and the other is the renamed file.


    >
    > AEF
    >
    > > Ron Johnson wrote on 09/17/2007 02:53:56 PM:
    > >
    > >
    > >
    > > > On 09/17/07 11:45, 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.

    > >
    > > > Something's somewhere changing $STATUS, and you just don't realize
    > > > it. (That's why I don't like "magic variables".)

    > >
    > > > > 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.

    > >
    > > > $SEVERITY is too generic for my taste. I'd use $STATUS instead.

    > >
    > > > Thus, (like you saving the value) I'd do something like:

    > >
    > > > $ SAY := WRITE SYS$STATUS
    > > > $ MSG_NOMATCHES = %X08D78053
    > > > $ MSG_NOFILE = %X08D7804A
    > > > $ MSG_SUCCESS = %X00000001
    > > > $!
    > > > $ PIPE ...
    > > > $ HOLD_STAT = $STATUS
    > > > $ SAY HOLD_STAT
    > > > $ IF HOLD_STAT .EQ. MSG_SUCCESS blah

    > >
    > > > > 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:
    > > > > /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*
    > > > > $ sever=$severity
    > > > > $ if sever .eq. "1"
    > > > > $ endif
    > > > > $write sys$output "File: JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1"
    > > > > File: JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1
    > > > > $rename/log JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1
    > > > > *.xml_2007091522383962;*
    > > > > %RENAME-I-RENAMED, *JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1*

    renamed
    > > to
    > > > > *JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML_2007091522383962;1*
    > > > > === Extracted batch log except:
    > > > > $ pipe diff/igno=trail -
    > > > > *JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML_2007091522383962;1 -*
    > > > > nl: /nonumb | -
    > > > > sear sys$pipe

    ""/window=(0,6)/mat=or/exact/nonumb |
    > > -
    > > > > sear sys$pipe "" /exact/nonumb | -
    > > > > sear sys$pipe "> ","><"/exact/out=nl:
    > > > > $ sever=$severity
    > > > > $ show sym sever
    > > > > SEVER = "1"
    > > > > ===

    > >
    > > > --
    > > > Ron Johnson, Jr.
    > > > Jefferson LA USA

    > >
    > > > Give a man a fish, and he eats for a day.
    > > > Hit him with a fish, and he goes away for good!

    >
    >



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

    In article
    ,
    norm.raphael@metso.com wrote:

    > Remember the only variables are one is batch and the other
    > is at-ed, and one is the original file and the other is the renamed file.


    Sorry, I haven't followed this thread, but I have seen cases where the
    the batch log file can consume just enough resources to exceed a quota.

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

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

    On Sep 17, 4:45 pm, norm.raph...@metso.com wrote:
    > AEF wrote on 09/17/2007 03:30:39 PM:
    > > On Sep 17, 3:03 pm, norm.raph...@metso.com wrote:
    > > > Ron,

    >
    > > > The message in the output logfile> *%SEARCH-I-NOMATCHES, no strings

    > matched*
    >
    > > > indicates that there was no match, but the rerun indicates (no

    > message)
    > > > that there was
    > > > a match. There should have been a match. the stat variable is not

    > wrong,
    > > > the result
    > > > of the embedded search is wrong in the batch, correct in the at-ed
    > > > procedure file.
    > > > This seems not to be an issue of the stat variable.

    >
    > > > -Norm

    >
    > > Where below is the @-run version?
    > > > > === Extracted batch log except:
    > > > > $ pipe diff/igno=trail -
    > > > > *JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML_2007091522383962;1 -*
    > > > > nl: /nonumb | -
    > > > > sear sys$pipe ""/window=(0,6)/mat=or/exact/nonumb

    > |
    > > -
    > > > > sear sys$pipe "" /exact/nonumb | -
    > > > > sear sys$pipe "> ","><"/exact/out=nl:
    > > > > $ sever=$severity
    > > > > $ show sym sever
    > > > > SEVER = "1"
    > > > > ===

    >
    > > Could PIPE or SEARCH be defined as different symbols in batch and
    > > interactive mode? (Check login procedures.)

    >
    > Nope. Same account. PIPE and SEARCH are not overdefined in either
    > batch or interactive (I rechecked).


    You checked for mode-dependent symbols in SYLOGIN.COM?

    >
    > > Doesn't using a PIPE command complicate figuring out which subcommand
    > > generated the $STATUS and $SEVERITY?

    >
    > Does it? I would think it still would be the same given the same
    > pipe command. Remember the only variables are one is batch and the other
    > is at-ed, and one is the original file and the other is the renamed file.


    Well, how would it tell you, for example, which search command is
    finding your string?

    If you are troubleshooting, you want to reduce the complexity as much
    as possible and isolate the bugger. The PIPE command, while
    convenient, is not helpful for this!

    One thing you could try is to SEARCH for "" at different search levels
    and see what actually comes up. Did you try just removing /OUT=NL: or
    redirecting the output to a file you can examine afterwards?

    AEF

    [...]


+ Reply to Thread