RE: QNTC

Oops, forgot about your security question.....   QSECOFR is probably not
known to the NT server you are trying to access.  You will need to run this
job with a user profile that has admin authority to the servers you wish to
save.  If your windows systems are members of a domain, you could set up a
domain user with admin rights to all the NT servers.  You need identical
username and password on both the AS400 and the NT domain.  The AS400
netserver must be configured to the same domain as the target NT boxes.

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



> -----Original Message-----
> From: William A.(Tony) Corbett [mailto:corbett@ASRESOURCES.COM]
> Sent: Tuesday, October 01, 2002 12:08 PM
> To: MIDRANGE-L@midrange. com
> Subject: QNTC
>
>
> I'm trying to use the QNTC file system, using the cpytoimpf
> in a scheduled
> batch job to copy files to the NT server to be imported by an
> NT package.
> This happens every two hours during workdays.  I see on the document
> entitled "Configuration of QNTC (SMB Client) File System" (I
> didn't get the
> doc#)"Notes: Any access created throught MKDIR are removed
> when the AS/400e
> or iSeries 400 system is IPLed and will have to be recreated
> manually".
> This makes using this method much less appealing.  Plus the
> fact that the
> user profiles/passwords have to match between OS400 and NT.
>
> How are you handling this?  Is this still true or has this
> been changed?
> We've only IPL'd once and I had to redo the MKDIR to fix it.
> (not sure if
> the IPL did it or if I did in testing this process)  If true,
> can I just add
> the MKDIR command to the bottom of my startup procedure.
>
> On another point, I've been following the thread on using the
> SAV command to
> backup QNTC folders.  It ended with that is not supported.
> However, I found
> APAR# SE03745 (V5R1) which seems to say that this will work.
> Can anyone
> shed some light on this?  If I could backup an NT server (or
> directory)
> using the AS/400 backup process, this would be really great.
> Part of the
> APAR:
> ------------------------------------------------------------------
> Problem Summary
> SAV DEV('/QSYS.LIB/mylib.LIB/mysavf.FILE') OBJ(('/QNTC*'))
> DSPSAVF sees one entry:  QNTC *DSTMF.  The entry type *DSTMF
> does not give the option to see the subdirectories (using opt 5
> on the DSPSAVF screen) DSPSAVF of QNTC is labeled as *DSTMF and
> not *DDIR as all other subdirectories.  When a DSPSAVF
> OUTPUT(*PRINT) is executed, the subdirectories under QNTC are of
> the type *DDIR.
>
> Comments
> This is an error in the QNTC save/restore code.  The QNTC
> directory is a DIR object, not a DDIR, and the save/restore code
> assumes that anything not a DDIR is a DSTMF.  Code will be
> changed to check for DIR in addition to DDIR.
>
> This change will be made in the next release.  Workaround for
> V4R5 and V5R1 is to SAV /QNTC/* instead of /QNTC*.
> --------------------------------------------------------------------
>
> I tried SAV DEV('/QSYS.LIB/corbett.LIB/qntcsavf.FILE')
> OBJ(('/QNTC/tms2000/bgi/tmsimport/*')) OUTPUT(*print) but got
> error: Error
> exchanging security information for user QSECOFR on Network
> Server tms2000.
>
> Not sure if this means the function won't work or there's
> something flaky
> going on with security between the two OS's.
>
> Anyone have knowledge of this functionality?  Or am I reading
> the APAR info
> right?
>
> Thanks...
>
> AS/Resources, Inc.
> William A.(Tony) Corbett
> IBM Certified Specialist - AS/400 Developer
> http://www.asresources.com
> corbett@asresources.com
> 770-587-4812 (office)
> 678-935-5006 (mobile)
> fax:  404-663-4737
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>