Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

SAVDLO vs SAV

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SAVDLO vs SAV

    TTBOMK, SAVDLO only backs up the folders in QDLS. SAV backs up folders in the entire IFS except for what is omitted. You would not want SAV to back up QSYS.LIB, because it is far easier to restore individual objects with RSTOBJ. Similarly if you are using QDLS as a DLO repository, RSTDLO works easier. Dave

  • #2
    SAVDLO vs SAV

    Whenever a new folder is created in the IFS they (the non-AS/400 people) always add them to QDLS. I'm not sure if this means they are using QDLS as a DLO repository. I have always been a little confused as to what DLO really was vs the ISF.

    Comment


    • #3
      SAVDLO vs SAV

      DLO or /QDLS is a DOS-type file system, with 8.3 file names, max 2GB files size, max 63 char path length. The files are actually stored as *DOC objects in library QDOC. The file and folder characteristics are stored in QUSRSYS/QAO* files which have many LFs and are journalled. The /QDLS file system is rather slow. "The" IFS "contains" all other file systems, including /QDLS, but all the file systems retain their individual identities and characteristics. In general, if you do something like md '/OurFiles' then the /OurFiles directory is basically like Windows 98/NT/2K and allows very long file names which are NOT case-sensitive, deep directories, and max file size of 256GB. The files are not stored in a library and file manipulation is much faster than /QDLS. In general, if you perform an IFS command on a QDLS file, like "md '/qdls/MyDir'", it'll run the equivalent QDLS command "under the covers"; it'll run "crtflr MyDir" for example. Currently, there are no good tools for querying & maintaining the IFS, like for finding & purging old files. You'll have to roll your own, generally by using QSHELL commands.

      Comment


      • #4
        SAVDLO vs SAV

        Ken, I think that is the best description I've heard. I think I actually understand the difference now (miracle never cease). For all those users that have folders they really should be putting them under /root instead of in /QDLS (correct). That way they are accessed faster and can retain there original file names and can be larger. I found out why they are always using QDLS, the software company told them to put their folders there. I guess it goes to show that even a company who claims to be "AS/400 experts" are not really experts. Anyway, thanks again

        Comment


        • #5
          SAVDLO vs SAV

          Think about this. Ever heard of a Worm Virus. If you map a user to the root directory and the user gets a virus. What do you think will happen when the virus starts to replicate into /QSYS.LIB and starts adding records to your i-Series Database files. You wind up with a trashed system. Trust me I have seen it with my own eyes. If you don't know what you are answering definitivly please qualify. There is a reason for this Software company to tell their clients this.

          Comment


          • #6
            SAVDLO vs SAV

            I'm a little confused. Our back up uses both the SAVDLO and SAV commands. The SAVDLO runs (*chg daily and *all weekly) then the SAV runs (object '/*') omitting '/QSYS.LIB' and '/QDLS'. We are running V4R5. Our weekly back up is taking 4 hours (daily ia only about 1 hours) and it is mainly between these 2 commands. Can these be combined into 1 save command? I'm looking for anyway to cut down the time on the weekly save.

            Comment


            • #7
              SAVDLO vs SAV

              Creazyidea wrote: "Think about this. Ever heard of a Worm Virus. If you map a user to the root directory and the user gets a virus. What do you think will happen when the virus starts to replicate into /QSYS.LIB and starts adding records to your i-Series Database files. You wind up with a trashed system. Trust me I have seen it with my own eyes. If you don't know what you are answering definitivly please qualify. There is a reason for this Software company to tell their clients this." First if a virus (which has happened does hit QDLS or a folder in /root then there is a problem with your antivirus software on the individual computer. Second, we have had objects in QDLS that had a virus (detected by a PC accessing the file and not by the computer that put the file there). When the virus is found it is cleaned. Due to the fact that most if not all viruses attact ASCII systems I'm not sure if it could do any damage to the files and objects on the iSeries (since they are EBCDIC) and in my experience hasn't. Any file on the IFS/Shared Folders (/root and qdls) are subject to attack by virus's regardless of which area they are in. Lastly, the information from the Software company was that they have always recommended QDLS to put folders because of there software that had an integration with OfficeVision. There comments to others was that the only place to put folders was QDLS. This is the same company that instructed my clients to create all printers as "Virtual" printers and then go into the Output Queue definition and add the I/P address of the printer. My client believed (until I explained it) that these printers were still virtual printers because the Software Company said so. We know that once you put an I/P address on the Output Queue it is now a remote writer. Therefore, the only reason the Software company told my clients to use QDLS for shared folders is because of their lack of knowledge and not for any technical reasons. Heck the software company didn't certify their software for V5R1 until December 2002 (a few weeks before the end of the minimum extention on software program support for V4R5 and not 1 of there systems has V5R2 on it. (There are supposed to be one of the "major" consulting companies in the U.S.) You can draw your own conclusions, but from where this veteran is sitting the Software company didn't know what they were doing and were only interested in generating revenue and not doing things right. As a side note, I wasn't brought in until after the implementation (early last year) so I wasn't here to correct their misstatements.

              Comment

              Working...
              X