backups on AS/400, objects missing

[Schmuel <schmuel@xxxxxxxxxxx>]

Hi Midrange

Thanks Al..

I am keeping the whole message on forum for now as others may appreciate
also your expertise...

Realize some of this is kindergarten stuff so I appreciate your time, though
some of the issues are obviously real significant..

><snip> You should run SAVSECDTA and SAVCFG every day.

Understood, our system user or config change rarely, so unless it is on the 
same tape
as the save, we will probably do this once a week...  if we put it before 
or after
the SAVLIB on the daily tape, we would do it daily...

>Every tape should be initialized uniquely.  They way you can use PRTERRLOG
>*VOLSTAT to determine when tapes are going bad.  If you would like to see
>an example of this, send me a private e-mail, and I will send you a copy of
>my presentation "ABC's of AS/400 System Management", which shows this.

Great.. Please do.. Thanks.. (I will email you this part separately so you 
can hit reply)
I gather you have it available on email .txt .doc or .pdf
May business addy for your records is (yes I don't mind other AS/400 
mailings :-)
  Steven Spencer 342 East Jericho Tpke PMB 153 Mineola, NY 11501

>There is a tool on TAA Tools to calculate an expiration date.  It's called
>ADDDAT.

k.. but if I am not so worried about expiration dates, could I just put in
say a no expiration parameter meaning TODAY ..basically we have a
small shop without any tape confusion so I just want to be sure the
  Initialization and Save run without any tape msg intervention
The command for that would be.. ? :-)

>    3) I set up the following
>          SAVLIB LIB(*NONSYS)
>          DEV (TAP01)
>          SAVACT (*SYSDFN)
>          ACCPTH (*NO)
>          OMITLIB (couple of unimportant libs here)
>          OUTPUT (*OUTFILE)
>          OUTFILE (QS36F/(filename))
>          OUTMBR(*FIRST *ADD)
>          INFTYPE(*ERR)
>I thought the SAVACT would allow an immediate save in shared mode
>    (tho I wasn't sure whether to use *SYSDFN or *SYNCLIB or *LIB)
>    but I immediately got a "Not all subsystems ended" response... <snip>

>A few issues here.  DO NOT ATTEMPT TO DO SAVE-WHILE-ACTIVE IF YOU DON'T
>KNOW WHAT YOU'RE DOING.  This can be a very dangerous function.  You can
>run a function with SWA, get a bad save, and it will never tell you!  You
>need to understand the theory of quiescence, and this is not OS/400 101.

Ahh.. well my compatriot recommended it as a solution, after some objects
weren't saved including an important QS36F file .. still don't really know 
why...
since the one who checks said nobody was in any user programs (we do have
a domino-network-client access setup that stays up basically 24/7 but the
office is empty and screens are at menus... hmmm maybe there was an evoked
job with a msg that the lady missed, that is the only sensible thought and it
might match up with the files that didn't save ..   you see that is my concern
eg... if a program is sitting with a msg in the user area and the program uses
a couple of data files, I still want those files saved.. yes ideally that 
shouldn't
be.. :-)

>I have a presentation that I do, and a magazine article, and I would be
>happy to forward that you anyone interested.  Again, please send me private
>mail.

Done... Thanks.. Maybe that will answer my questions :-)

>Secondly, SWA does not support *NONSYS.

Ahh. .interesting.. if I switch to *ALLUSR plus separately *IBM is it 
supported ?
  (yes, I know you mentioned the danger, however there will definitely be
   0 activity when this is running and first I just want to get a save to 
run and
see the results)

basically first I am wondering why ANY of these would give the subsystem msg
I got....

>Lastly, ALWAYS change the default from ACCPTH (access path) from *NO to
>*YES.  It can mean the difference of DAYS of restore time.  (I believe the
>world's record occurred at one of my accounts of 11 days!)

Will do.. :-)

>PS:  Happy Memorial Day Weekend to everyone.

Thanks, and Shavout for those who tend toward scriptural days..

Thanks Al

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---