Conference hydra::amiga_v1

I think thats a bug with calling a script from a script. There is
a workaround. Randy Meyers knows! Randy?

(it's in a note in here somewhere...)

john

P.S. How's UUCP working? I seem to be running mail ok now. Now to get 
News up!

    Ok, but why would it show up now as opposed to earlier, since I didn't
    modify the calling script and the called script never even appears to
    get started?  Maybe file size of the called script?
    
    UUCP for mail and file copies is working GREAT!  I've been able to
    copy ZOO files from a VAX/VMS system to an Ultrix system and then
    UUCP them to my 500.  From the timestamps on some large transfers, it
    appears to get about 180 bytes/sec throughput over a 2400 bps modem.
    Great for unattended file transfers.
    
    I'm using a Scholar and it appears that I'll have to modify the uucico
    modem.c routine to get UUCP to dial it.
    
    -tl

    Well I found the problem and I guess you could call it a bug.  It
    certainly wasn't obvious, although trying to debug it at 3:30 in the
    morning after panicking and madly backing up/restoring my disk and
    kv'ing my entire drive thinking it might be hardware or a virus, was
    tough.  I had files that I could LIST but reported "No such object"
    when attempted to be COPY'd or TYPEd.  Not sure what caused that, but
    apparently was unrelated.
    
    It turns out the EXECUTE scans the entire file before executing any
    lines.  The following line that was added was part of the problem:
    
run <nil: >nil: Getty -B2400 -A -Md -x9 -c0 -7
    
    Apparently EXECUTE ignores spaces, newlines, everthing in it's scan for
    brackets.  So it thought "<nil: >" was a key that wasn't defined. 
    Furthermore, I changed the line to:
    
run >nil: <nil: Getty -B2400 -A -Md -x9 -c0 -7
    
    and it still failed, apparently because I have another "<" further up
    in the file.
    
    The moral of the story is:  
    
    "Use .BRA and .KET directives to redefine the standard < > brackets
    when using EXECUTE."
    
    -tl

    sssssssss
    saw this topic too late. I had the same problem some weeks ago.
    Read 3229.0-5 for additional infos.
    
    Ralf
    ====

    
>    UUCP for mail and file copies is working GREAT!  I've been able to
>    copy ZOO files from a VAX/VMS system to an Ultrix system and then
>    UUCP them to my 500.  From the timestamps on some large transfers, it
>    appears to get about 180 bytes/sec throughput over a 2400 bps modem.
>    Great for unattended file transfers.

Why copy them to unix then uucp? Just uuencode them on VMS and mail them 
to your uucp 'server', which will them get them to you. Not sure if the 
uucp mail transfers are faster or slower (or the same) as uucp copies.

    
>    I'm using a Scholar and it appears that I'll have to modify the uucico
>    modem.c routine to get UUCP to dial it.


If your using Matt Dillon's AmigaUUCP, then just put the scholar in 
'AT' mode and it will work fine.

(from term emulator connected to your modem)
^B
Ready.
enable at
(something about modem's access password): scholar

Now regular dialing goes like this:

(used to be ^B dial xxxxxxx)

^B
ATDT xxxxxx

Simple!

john

    re: .4    Oh well... that's what I get for not keeping up on all of
    the notes in here.
    
    re: .5
    
    Well I'm not that familiar with uuencode, but doesn't that turn a
    binary file into a plain ASCII text file by using a limited portion of
    the the ASCII character set?  That would suggest at least a 25% or
    greater increase in file size.  The actual transfers for mail and uucp
    copies use the same protocol (I think) and should give equivalent
    throughput.  The real solution (and the one in the works) is to
    properly configure the VMS/Ultrix Connection software such that I can
    mount my VMS disks on my puny Ultrix system and access the files
    transparently.
    
    As for the Scholar modem.  What you suggest I think only works on a
    Scholar Plus, not the normal Scholar (DF224).  I'll try it in any case
    and report back here if I find out otherwise.
    
    -tl

I think you reported 180 bytes/sec uucp copy. I measured a 2400 baud
ZMODEM xfer using VLTjr the other night and got 230 bytes/sec - thats about
 30% faster...

I guess having uucp handle the details makes it worth while.

Yes, uuencode does increase the file size a bit. But mailing is real easy 
and unnattended downloads wvia uucp are painless anyway. (so what if it 
finishes at 4 am instead of 3 !)

Once I get News up and running, it's gonna be a wash anyway since News volumes
can get huge!

john