Amazing RUNOFF defect? - VMS

This is a discussion on Amazing RUNOFF defect? - VMS ; So there I was, minding my own business, building a new Zip kit on an ODS5 disk (ALP$DKA100) -- what could go wrong? -- when all of a sudden, something like this happened ... Clean start: alp $ dire /size ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Amazing RUNOFF defect?

  1. Amazing RUNOFF defect?

    So there I was, minding my own business, building a new Zip kit on an
    ODS5 disk (ALP$DKA100) -- what could go wrong? -- when all of a sudden,
    something like this happened ...

    Clean start:

    alp $ dire /size ALP$DKA100:[sms.runoff]
    %DIRECT-W-NOFILES, no files found

    alp $ dire /size []

    Directory ALP$DKA0:[SMS.RUNOFF]

    VMS_ZIP.RNH;1 131

    Total of 1 file, 131 blocks.

    Copy a (non-random) file to two different names.

    alp $ copy VMS_ZIP.RNH ALP$DKA100:[]lc.rnh
    alp $ copy VMS_ZIP.RNH ALP$DKA100:[]UC.RNH

    alp $ dire /size ALP$DKA100:[]

    Directory ALP$DKA100:[sms.runoff]

    lc.rnh;1 131
    UC.RNH;1 131

    Total of 2 files, 262 blocks.

    Just in case:

    alp $ diff ALP$DKA100:[]lc.rnh ALP$DKA100:[]UC.RNH
    Number of difference sections found: 0
    Number of difference records found: 0

    DIFFERENCES /IGNORE=()/MERGED=1-
    ALP$DKA100:[sms.runoff]lc.rnh;1-
    ALP$DKA100:[sms.runoff]UC.RNH;1

    Attack the files using RUNOFF:

    alp $ runoff /output = uc.mem ALP$DKA100:[]UC.RNH
    alp $ runoff /output = lc.mem ALP$DKA100:[]LC.RNH

    Examine the results:

    alp $ dire /size []

    Directory ALP$DKA0:[SMS.RUNOFF]

    LC.MEM;1 142 <--- Hmmm.
    UC.MEM;1 138 <---
    VMS_ZIP.RNH;1 131

    Total of 3 files, 411 blocks.

    And they're really different:

    alp $ diff lc.mem uc.mem

    ************
    File ALP$DKA0:[SMS.RUNOFF]LC.MEM;1
    1

    2

    3

    4 1 ZIP

    ******
    File ALP$DKA0:[SMS.RUNOFF]UC.MEM;1
    1 1 ZIP

    ************
    [...]
    ************
    File ALP$DKA0:[SMS.RUNOFF]LC.MEM;1
    1353
    1354
    Page 24

    1355

    1356

    ******
    File ALP$DKA0:[SMS.RUNOFF]UC.MEM;1
    1266

    ************

    Number of difference sections found: 24
    Number of difference records found: 90

    DIFFERENCES /IGNORE=()/MERGED=1-
    ALP$DKA0:[SMS.RUNOFF]LC.MEM;1-
    ALP$DKA0:[SMS.RUNOFF]UC.MEM;1


    If I had to program for a result like this, I wouldn't know how to
    start.

    Is this a feature, or does anyone know of a fix? I suppose that
    there's an obvious work-around, but Yikes!

    Directory SYS$COMMON:[SYSEXE]

    RUNOFF.EXE;1 533 1-OCT-2003 21:19:36.53 (RWED,RWED,RE,RE)

    ALP $ anal /imag SYS$COMMON:[SYSEXE]RUNOFF.EXE
    [...]
    Image Identification Information

    image name: "RUNOFF"
    image file identification: "V3.2-01"
    image file build identification: "X9ZK-0060100000"
    link date/time: 1-OCT-2003 21:19:36.23
    linker identification: "A11-50"
    [...]


    I see the same behavior on td183.testdrive.hp.com (rx2600, IA64,
    V8.3) as on my system (XP1000, Alpha, V7.3-2). (Where did I put those
    eight-part SPR forms?)

    ------------------------------------------------------------------------

    Steven M. Schweda sms@antinode-org
    382 South Warwick Street (+1) 651-699-9818
    Saint Paul MN 55105-2547

  2. Re: Amazing RUNOFF defect?

    > Directory ALP$DKA100:[sms.runoff]
    > lc.rnh;1 131
    > UC.RNH;1 131



    When you use runoff on both, are the only differences in the output some
    extra blank lines present in one and not the other ?


    If you take the "good" file and rename it to have a non .RNH file type,
    does it now start to have the extra blank lines etc ?

    aka: perhaps Runoff doesn't recognize .rnh as one of its own file
    extensions and processes the contents differently ?

  3. Re: Amazing RUNOFF defect?

    In article <9dd9d$4757b7ff$cef8887a$30803@TEKSAVVY.COM>, JF Mezei writes:
    >
    >
    >> Directory ALP$DKA100:[sms.runoff]
    >> lc.rnh;1 131
    >> UC.RNH;1 131

    >
    >
    >When you use runoff on both, are the only differences in the output some
    >extra blank lines present in one and not the other ?
    >
    >
    >If you take the "good" file and rename it to have a non .RNH file type,
    >does it now start to have the extra blank lines etc ?
    >
    >aka: perhaps Runoff doesn't recognize .rnh as one of its own file
    >extensions and processes the contents differently ?


    ..RNH *is* one of RUNOFF 's known input file extensions. It is to format
    an output file of the type .HLP. This can then be used as the input to
    create a HELP library or HELP library entry. Using RUNNOF and the .RNH
    would create a more consistent look/feel to formatted help information.

    (Pg. 4-2 of the RUNOFF manual: Section 4.1 Input and Output File Specif-
    ications)


    I'll take a look into this "phenomenon" later myself.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  4. Re: Amazing RUNOFF defect?

    In article , VAXman- @SendSpamHere.ORG writes:

    > .RNH *is* one of RUNOFF 's known input file extensions.


    I would not be suprised if the code RUNOFF uses to look at file
    extensions is case sensitive. .RNH may be recognised but not .rnh .
    Back when folks were writing runoff everyone KNEW file names came
    back in all uppercase.

    Maybe you can submit an SPR?


  5. Re: Amazing RUNOFF defect?

    On Dec 6, 2:56 am, s...@antinode.org (Steven M. Schweda) wrote:
    > So there I was, minding my own business, building a new Zip kit on an
    > ODS5 disk (ALP$DKA100) -- what could go wrong? -- when all of a sudden,
    > something like this happened ...
    >

    [...]
    > alp $ diff ALP$DKA100:[]lc.rnh ALP$DKA100:[]UC.RNH
    > Number of difference sections found: 0
    > Number of difference records found: 0
    >
    > DIFFERENCES /IGNORE=()/MERGED=1-
    > ALP$DKA100:[sms.runoff]lc.rnh;1-
    > ALP$DKA100:[sms.runoff]UC.RNH;1
    >
    > Attack the files using RUNOFF:
    >
    > alp $ runoff /output = uc.mem ALP$DKA100:[]UC.RNH
    > alp $ runoff /output = lc.mem ALP$DKA100:[]LC.RNH
    >
    > Examine the results:
    >
    > alp $ dire /size []
    >
    > Directory ALP$DKA0:[SMS.RUNOFF]
    >
    > LC.MEM;1 142 <--- Hmmm.
    > UC.MEM;1 138 <---
    > VMS_ZIP.RNH;1 131
    >
    > Total of 3 files, 411 blocks.
    >
    > And they're really different:
    >
    > alp $ diff lc.mem uc.mem
    >
    > ************
    > File ALP$DKA0:[SMS.RUNOFF]LC.MEM;1
    > 1
    >
    > 2
    >
    > 3
    >
    > 4 1 ZIP
    >
    > ******
    > File ALP$DKA0:[SMS.RUNOFF]UC.MEM;1
    > 1 1 ZIP
    >
    > ************
    > [...]
    > ************
    > File ALP$DKA0:[SMS.RUNOFF]LC.MEM;1
    > 1353
    > 1354
    > Page 24
    >
    > 1355
    >
    > 1356
    >
    > ******
    > File ALP$DKA0:[SMS.RUNOFF]UC.MEM;1
    > 1266
    >
    > ************
    >
    > Number of difference sections found: 24
    > Number of difference records found: 90
    >
    > DIFFERENCES /IGNORE=()/MERGED=1-
    > ALP$DKA0:[SMS.RUNOFF]LC.MEM;1-
    > ALP$DKA0:[SMS.RUNOFF]UC.MEM;1
    >
    > If I had to program for a result like this, I wouldn't know how to
    > start.
    >
    > Is this a feature, or does anyone know of a fix? I suppose that
    > there's an obvious work-around, but Yikes!
    >

    [...]
    > Steven M. Schweda sms@antinode-org

    [...]

    See what happens when you use lower case filenames?! Perhaps those
    three extra lines are RUNOFF experience shock and disbelief in
    encoutering a file name in lower case! |;-) |:-)

    Did you try repeating the RUNOFF commands using uppercase?

    At least you didn't get my favorite VMS error message:


    AAA, 'file-spec'

    Facility: RUNOFF, DIGITAL Standard Runoff (DSR)

    Explanation: This message should never be displayed.

    User Action: Contact a Digital support representative.


    Oh no! I displayed this message!!! ... Yikes.

    AEF

  6. Re: Amazing RUNOFF defect?

    On Dec 6, 2007 1:56 AM, Steven M. Schweda wrote:
    > So there I was, minding my own business, building a new Zip kit on an
    > ODS5 disk (ALP$DKA100) -- what could go wrong? -- when all of a sudden,
    > something like this happened ...
    >
    > Clean start:
    >
    > alp $ dire /size ALP$DKA100:[sms.runoff]
    > %DIRECT-W-NOFILES, no files found
    >
    > alp $ dire /size []
    >
    > Directory ALP$DKA0:[SMS.RUNOFF]
    >
    > VMS_ZIP.RNH;1 131
    >


    What is the parse style of your process set to? RUNOFF probably
    doesn't handle the parse style of "extended" very well.

    Do a

    $ sho process/parse

    If it says:

    Parse Style: Extended

    set it back to "traditional"

    $ set proc/parse=traditional

    Also, look at the case lookup setting

    $ sho proc/case

    if doesn't say

    Case Lookup: Blind

    set it to "blind"

    $ set proc/case=blind

    Ken

  7. Re: Amazing RUNOFF defect?

    In article <07120600562608_202002AB@antinode.org>,
    sms@antinode.org (Steven M. Schweda) wrote:

    > Directory ALP$DKA0:[SMS.RUNOFF]
    >
    > LC.MEM;1 142 <--- Hmmm.
    > UC.MEM;1 138 <---
    > VMS_ZIP.RNH;1 131


    Duplicated on another .RNH file here. The resulting .MEM has page
    numbers and form feeds, hence the larger size.

    The setting of SET PROCESS/PARSE doesn't make any difference here.

    This on Alpha V8.3.

    --
    Paul Sture

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

+ Reply to Thread