Conference cookie::archive_backup

    Ted,
    
    We'll do some checking.  I'm not sure what to have you look
    at.  I have someone else respond with some information and 
    questions.
    
    Chris

Ted,

Not sure where to start on this one.  Have you checked to ensure that
the UCX quotas for TCP/IP are set high enough.  This is mentioned
in the release notes: 5.2.3

$ UCX SET PROTOCOL TCP /QUOTA=(SEND:250000,RECEIVE:250000)

The log shows that the connection to the NT system failed for some
reason.

The NT Client appears to have died with a fatal write error, which is
what a value of 3 usually means.

The problem is, which died first?

Is this reproducable?
What was the SAVE request include spec. What NT files were you backing
up?

Thanks,
Lyle

Hi Lyle,

>$ UCX SET PROTOCOL TCP /QUOTA=(SEND:250000,RECEIVE:250000)

These values were way too low.  I will bump them up and try
again.

Dang...I missed those release notes again.  I really should
read those 8*)

Ted

Bummer....failed again.  Happens everytime. I'm backing up my C partition which
has a few directories on it including the ABS directory.  It probably has some
open files on cause I have PIRCH and FX32 on it.

Ted

Save Request
    Name            - SAUL__2-MAY-1997_10_03_10_14
    Version         - 2
    UID             - D1CBC0A0-C609-11D0-978A-08002BBFCCF2
    Movement Type     - FULL_ARCHIVE
    Data Object Set
        Sequence Option    - SEQUENTIAL
        Commit Option - KEEP_PARTIAL
        Node Name - HAVASU
        Include Spec - C:\
        Exclude Spec -
        Object Type Name - WINDOWS NT FILES GTAR
        Agent Qualifiers -
        Data Safety Options - None
        Compression Options - None
        Source File System Options - FILE_IGNORE_WRITERS
        Span Filesystem Options - SPAN FILESYSTEMS
        Symbolic Links Option - LINKS_ONLY
        Object Date Options - None
        Selection Options - None
        Restore Options - RETAIN_EXISTING_VERSIONS
        Date Identifier - NONE
        Low Limit Date - 17-NOV-1858 00:00:00.00
        High Limit Date - 17-NOV-1858 00:00:00.00
    Owner     - AXPBRD::SAUL
    Access Right - AXPBRD::SAUL
        Access Granted - READ, WRITE, SET, SHOW, DELETE, CONTROL, EXECUTE
    Media Management Info
        Storage Class Name - OMT_BACKUPS
        Media Type - None
        Device Name - None
        Start Time - NOW
        Schedule Interval - ON_DEMAND
        Explicit Interval -
        Special Day On - None
        Special Day Off - None
        Execution Envir - OMT_BACKUPS_ENV
        Storage Class retention value used.
        Original Object Action - RECORD_BACKUP_DATE
    Restart Interval - 17-NOV-1858 00:00:00.00
    Wait Flag - NO
    Prologue Command - None
    Epilogue Command - None

1) Try the following on the NT system.

	- Set your PATH variable so that it includes the location 
          of ABSGTAR.EXE
	- From your ABS LOG find the ABSGTAR command for the SAVE.  
          Should look something like:
	      ABSgtar -cvPpb20 --totals --same-owner  -f -  |C:\|

          Replace the   -f -   with   -fNUL:  
                  and   |C:\|  with   "C:\"

	  Command should look like:	 
              ABSgtar -cvPpb20 --totals --same-owner  -fNUL:  "C:"

	This should invoke ABSGTAR on the NT system, sending the
	archive data on the floor.  This should tell us if we are dieing
	from something wrong happening on the NT system with ABSGTAR.

2) From your server, try SAVING only one file.  This can be anything in
   C: try "C:\CONFIG.SYS" or C:\COMMAND.COM" if they exist.

Thanks,
Lyle

Hi Lyle,

Step 1 .. worked

Step 2 .. worked

Also tried backing up a whole directory in Step 2 as well as the ABS directory
They both worked as well.

Ted

Ted,

Do you have another node configured to run ABS?  If so can
you execute this same save request from that node?  

What version of UCX is running on the V6.1 AXP?  

Does the save requests that fails cause a volume change
to occur?  Check the log, if so did you set the TCPIP
parameter for WNT?

As you can see, at this point I'm "grasping" or "gasping"
at straws.

This sounds like it could be a resource problem or a problem
with UCX.  Since two smaller requests work then I can only
assume that the network layer is causing us to fail for some
reason.

Thanks,
Lyle

I've been trying to test this on another machine but I keep getting an error
about my node not being licensed...but it is.  What causes ABS not to look at
the license database?

Ted

Try deleting or showing the licensed node.  If you get an error
saying that "XXXX NOT FOUND" then the name that is actually in
the database is not what you think you entered.

There is a problem with the license utility in that embedded or
trailing spaces, inadvertently entered will not be trimmed.

You can try adding a space to the end of your node when doing
a show or delete to see if it finds the node.

This will be fixed in next release.

Lyle

Don't think this is the problem.  I did delete and enter it again.  I can't see
it if I put a space in.  Don't know if this has anything to do with it, but the
log file shows the nodename in lower case...


THREAD #1:  _$ af?SL
THREAD #1:  S os?"Windows NT"  s -
THREAD #1:  _$ "c?ABSgtar -cvPpGb20 --totals --same-owner  --ignore-failed-read
THREAD #1:  %ABS-F- >>havasu<< Not licensed
THREAD #1:  %ABS-F-License Error
THREAD #1:  %SYSGEN-W-NORMAL, normal successful completion
THREAD #1:  %ABS-F- socket error
THREAD #1:  %ABS-F-Shell failed


I can't find anywhere where it was entered in lower case though.  The license
shows upper case.

URQUEL> run ABS_CLIENT_LICENSE.EXE;1
Would you like to Add/Modify/Remove/Show the Client License?: show
Enter Node Name or [ALL]:
Client Node Type (UNIX or NT) [UNIX]: NT
Node Name           Type         Transport    Port
---------           ----         ---------    ----
HAVASU              Windows NT    TCP/IP      1800

License Count: 1 used of 1 total


Ted

P.S. If you modify a license and <cr> through the port field, it sets it to
10473.  It might be better to default to the original value.

Let me give you a bit more of that log file...


THREAD #1:  $
THREAD #1:  SET NOON
THREAD #1:  $ DEFINE SYS$COMMAND sys$input:
THREAD #1:  %DCL-I-SUPERSEDE, previous value of SYS$COMMAND has been superseded
THREAD #1:  $ ubs := $ABS$SYSTEM:ABS$UBS.EXE
THREAD #1:  $ ubs n?HAVASU u?"root" l?_MBA7969: -
THREAD #1:  _$ "d?$127$MUA5:22MAY19970946230." -
THREAD #1:  _$ af?SL
THREAD #1:  S os?"Windows NT"  s -
THREAD #1:  _$ "c?ABSgtar -cvPpGb20 --totals --same-owner  --ignore-failed-read
 -f - -N @1970-1-2@ |C:\|"
THREAD #1:  %ABS-F- >>havasu<< Not licensed
THREAD #1:  %ABS-F-License Error
THREAD #1:  %SYSGEN-W-NORMAL, normal successful completion
THREAD #1:  %ABS-F- socket error
THREAD #1:  %ABS-F-Shell failed
THREAD #1:  %ABS --UBS FAILURE--
THREAD #1:  $
THREAD #1:  Agent retry exhausted
THREAD #1:  Normal successful completion
THREAD #1:

- The UBS command has a space in it...could this be the problem?

- Why a SYSGEN-W-NORMAL message....we doing something with SYSGEN?

Thanks,

Ted

    Ted,
    
    	Check the protection on the database file:
    
    	ABS$ROOT:[DATABASE]CLIENT_DB.DAT
    
    	Make sure that the process can access it (ABS).
    
    	Chris

Please provide the following:

1) ABS V2.1 or ABSOMT V2.1?
2) Do a LICENSE LIST ABS-NT-CLIENT-LICENSE/FULL and report the
   number of UNITS that are active for this license.
3) Run the ABS_CLIENT_LICENSE utility and do a SHOW ALL NT
   Capture the results and list them here.
4) If possible, provide me a copy of the client license database
   so that I can analyze it.

Thanks,
Lyle