Windows does not support the ALWSAV attribute so it does not exist.
ALWSAV is *YES on QNTC folder. It is also *YES on the Servers under
QNTC though windows does not support this attribute. The Shares on the
server also show as *YES. Creating new directories and files the ALWSAV
is *YES but when we copy from *ANY QNTC share, it gets set to *NO. Did
not use to work that way. This just started happening a couple of
months ago. (When I look at old backup logs.)
I was just wondering what may have changed. If anyone knew of a global
setting that would affect files copied from QNTC. Funny thing is if the
file is created on a NETSERVER share by the same PC program, it is set
to *YES.
Dennis I would rather code the CHGATR command then rewrite to use QSH.
I just did not want to start changing a bunch of programs and scripts if
there was that global setting.
Chris Bipes
Director of Information Services
CrossCheck, Inc.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dennis Lovelady
Sent: Tuesday, March 02, 2010 2:12 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: ifs attribute alwsav(*no)
When we copy stream files from the QNTC file system, (Window Server
Shares), the attribute ALWSAV is set to *NO. I know I can run the
CHGATR command to fix it but I have over a dozen programs that are
using
PC servers to create XML and X937 batches. (Among other things.)
CPY OBJ('/qntc/server/share/path/obj.type')
TODIR('/home/permretentiondir')
FROMCCSID(*OBJ)
TOCCSID(*OBJ)
DTAFMT(*BINARY)
OWNER(*NEW)
Hmm... OK. So two more questions: What is the ALWSAV attribute of the
original file? And have you tried copying this from qsh, as in:
QSH CMD('cp /qtnc/server/share/path/obj.type /home/permretiondir')
As an Amazon Associate we earn from qualifying purchases.