Pathworks vs CIFS performance - VMS

This is a discussion on Pathworks vs CIFS performance - VMS ; We are considering switching out Pathworks in favor of CIFS. The main reason is for performance: Pathworks being single threaded gets really slow when a Windows user makes heavy use of it (example: accessing a large directory from Windows). This ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Pathworks vs CIFS performance

  1. Pathworks vs CIFS performance

    We are considering switching out Pathworks in favor of CIFS. The main
    reason is for performance: Pathworks being single threaded gets really
    slow when a Windows user makes heavy use of it (example: accessing a
    large directory from Windows). This impacts everyone else's
    performance. We have searched for info on CIFS performance versus that
    of Pathworks but have come up empty.

    Any experiences and comments relative to the merits of Pathworks
    versus CIFS (aka Samba in VMS clothes) would be most appreciated.

  2. Re: Pathworks vs CIFS performance

    I noticed warning's in the release notes that CIFS on Alpha was slow
    (or really slow if you use a non-current version of VMS)
    What the performance is like on VMS I64 I know not,



  3. Re: Pathworks vs CIFS performance

    In article , VMS is Virus Free writes:
    >Any experiences and comments relative to the merits of Pathworks
    >versus CIFS (aka Samba in VMS clothes) would be most appreciated.


    Pathworks vs. SAMBA V1 I had experiences with.
    And the conclusio was that SAMBA V1 was awful, dead slow and brought the
    whole VMS system to its knees (permanently 100% CPU, one single process
    per client means hundreds vs. 30% CPU and 9 processes total with PATHWORKS)

    Now, it's ASOVMS vs. SAMBA V3 (?) and my experiences are worthless, I think.

    Why not try it yourself and let us know?

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  4. Re: Pathworks vs CIFS performance

    VMS is Virus Free wrote:
    > We are considering switching out Pathworks in favor of CIFS. The main
    > reason is for performance: Pathworks being single threaded gets really
    > slow when a Windows user makes heavy use of it (example: accessing a
    > large directory from Windows). This impacts everyone else's
    > performance. We have searched for info on CIFS performance versus that
    > of Pathworks but have come up empty.


    Pathworks is not single threaded, Pathworks is multi-threaded in a
    single process per cluster. It is far more efficient on CPU resources
    and context switching than the current V3 generation of SAMBA. If you
    are having problems with performance with Pathworks, SAMBA will probably
    not be much better, and possibly will be worse.

    There may be tuning or other issues like disk / file fragmentation that
    are causing the slowdowns you are seeing.

    > Any experiences and comments relative to the merits of Pathworks
    > versus CIFS (aka Samba in VMS clothes) would be most appreciated.


    I left the SAMBA / VMS project before the various planed performance
    enhancements could be implemented and tested, so I do not know the
    specifics.

    The SAMBA V4 design allows a single process similar to Pathworks /
    Advanced Server to be used. I have no idea if it will be more efficient.

    The SAMBA V1 through V3 model of separate processes has a much higher
    overhead than threads, but provides the appearance of higher reliability
    as a failed process only briefly affects one client until it is
    restarted, where a single process model would affect all clients.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  5. Re: Pathworks vs CIFS performance

    On 10/24/07 22:55, John E. Malmberg wrote:
    [snip]
    >
    > The SAMBA V1 through V3 model of separate processes has a much higher
    > overhead than threads, but provides the appearance of higher reliability


    Why do you "appearance"?

    > as a failed process only briefly affects one client until it is
    > restarted, where a single process model would affect all clients.


    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  6. Re: Pathworks vs CIFS performance

    On 24 Oct 2007 23:43:46 +0200, peter@langstoeger.at (Peter 'EPLAN'
    LANGSTOeGER) wrote:

    >In article , VMS is Virus Free writes:
    >>Any experiences and comments relative to the merits of Pathworks
    >>versus CIFS (aka Samba in VMS clothes) would be most appreciated.

    >
    >Pathworks vs. SAMBA V1 I had experiences with.
    >And the conclusio was that SAMBA V1 was awful, dead slow and brought the
    >whole VMS system to its knees (permanently 100% CPU, one single process
    >per client means hundreds vs. 30% CPU and 9 processes total with PATHWORKS)
    >
    >Now, it's ASOVMS vs. SAMBA V3 (?) and my experiences are worthless, I think.
    >
    >Why not try it yourself and let us know?


    The problem we face is that our main production VMS cluster is running
    VMS V7.3-2. It would be most difficult to marshall the resources to
    upgrade it to V8.3 which CIFS requires. Management's view: VMS is dead
    and we're getting rid of it. Reality view: the VMS systems run at 70%
    to 100% CPU all day long. They are minimally 4 CPU systems with 8 GB
    of memory, relatively new EV levels and are well tuned. They are just
    used because they can reliably put out the work, especially when
    compared to other more, umm, "modern" GUI based systems.

    Why not try it out ourselves? Well, we are testing but that's nothing
    like real-life experiences. For us to propose the upgrade and get it
    approved, there needs to be strong business reasons to do so.
    Management's view is that (a) it's working okay, (b) don't mess with
    it, and (c) it's going away. Well, it's been going away for the last 5
    years; it'll likely be running 5 years from now.

    So with that atmosphere, the answer is quite simply that we need to
    know that the effort will be worth the reward. What I've been able to
    read on the CIFS literature speaks nothing about performance, only
    functionality. That's why I'm asking those that may have already been
    done this path to offer their experiences.

  7. Re: Pathworks vs CIFS performance

    On Thu, 25 Oct 2007 03:55:47 GMT, "John E. Malmberg"
    wrote:

    >
    >Pathworks is not single threaded, Pathworks is multi-threaded in a
    >single process per cluster. It is far more efficient on CPU resources
    >and context switching than the current V3 generation of SAMBA. If you
    >are having problems with performance with Pathworks, SAMBA will probably
    >not be much better, and possibly will be worse.


    We currently see Pathworks use 100% of one CPU. My guess is that it
    was designed before Kernel threads were available. When threading
    became available, it was too late or not enough energy left at Digital
    to optimize the product to take full advantage of threading.
    Otherwise, Pathworks would be able to use more than one CPU.

    >There may be tuning or other issues like disk / file fragmentation that
    >are causing the slowdowns you are seeing.


    There are always tuning, umm, "opportunities". AUTOGEN doesn't find
    anything. There is ample memory, multiple CPUs. Everything else runs
    well, only Pathworks gets bogged down.

    The problems we see stems from Windows desktops accessing files on VMS
    when

    (a) the directory being accessed has lots of files (lots = 10K to 100K
    files). Many .DIR files are in the 5K to 10K blocks size. DFU on a
    directory compress helps but does not offer much relief.

    (b) large files (500 GB to 1 TB) being read/written

    (c) lots of file transfers (both directions)

    Typical scenario is that access is relatively robust then one or more
    users start doing some of these activities and slows Pathworks file
    access down for everyone.

    The large directory sizes are the results of program design that did
    not think through design decisions when decade's worth of file
    activity would need to be available online. We cannot change this
    behavior. Reason: works okay, bigger fish to fry, no time to go back
    and fix an old app.

    >> Any experiences and comments relative to the merits of Pathworks
    >> versus CIFS (aka Samba in VMS clothes) would be most appreciated.

    >
    >I left the SAMBA / VMS project before the various planed performance
    >enhancements could be implemented and tested, so I do not know the
    >specifics.
    >
    >The SAMBA V4 design allows a single process similar to Pathworks /
    >Advanced Server to be used. I have no idea if it will be more efficient.


    We currently see Pathworks use 100% of one CPU. What we were looking
    (hoping) for with CIFS is that the design would make better use of the
    available CPU resources in a multi-CPU environment.

    What is sounds like is that CIFS still has a ways to go to catch up to
    Pathworks (performance-wise).

    >The SAMBA V1 through V3 model of separate processes has a much higher
    >overhead than threads, but provides the appearance of higher reliability
    >as a failed process only briefly affects one client until it is
    >restarted, where a single process model would affect all clients.
    >
    >-John
    >wb8tyw@qsl.network
    >Personal Opinion Only


  8. Re: Pathworks vs CIFS performance

    Ron Johnson wrote:
    > On 10/24/07 22:55, John E. Malmberg wrote:
    > [snip]
    >
    >>The SAMBA V1 through V3 model of separate processes has a much higher
    >>overhead than threads, but provides the appearance of higher reliability

    >
    >
    > Why do you "appearance"?


    The only reason that a process would fail is from hitting a software bug
    somewhere. While in theory the separate process model is more robust,
    since all processes share the same code, in all probability a software
    bug that crashed one process will eventually crash them all or
    repeatedly crash in the same place.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  9. Re: Pathworks vs CIFS performance

    On 10/25/07 22:49, John E. Malmberg wrote:
    > Ron Johnson wrote:
    >> On 10/24/07 22:55, John E. Malmberg wrote:
    >> [snip]
    >>
    >>> The SAMBA V1 through V3 model of separate processes has a much higher
    >>> overhead than threads, but provides the appearance of higher reliability

    >>
    >>
    >> Why do you "appearance"?

    >
    > The only reason that a process would fail is from hitting a software bug
    > somewhere. While in theory the separate process model is more robust,
    > since all processes share the same code, in all probability a software
    > bug that crashed one process will eventually crash them all or
    > repeatedly crash in the same place.


    Ah.

    From Jargon File (4.4.4, 14 Aug 2003) [jargon]:

    robust
    adj.

    Said of a system that has demonstrated an ability to recover
    gracefully from the whole range of exceptional inputs and
    situations in a given environment. One step below
    {bulletproof}. Carries the additional connotation of elegance
    in addition to just careful attention to detail. Compare
    {smart}, oppose {brittle}.

    So, having one thread die while the others soldier along isn't
    *robust*, but it does *isolate* those people who are impacted by
    corner-case bugs, while the majority of users (who aren't affected
    by that corner case) keep on plugging away.

    And that's a darned site better than many apps.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  10. Re: Pathworks vs CIFS performance

    In article , VMS is Virus Free writes:
    >The problem we face is that our main production VMS cluster is running
    >VMS V7.3-2. It would be most difficult to marshall the resources to
    >upgrade it to V8.3 which CIFS requires. Management's view: VMS is dead
    >and we're getting rid of it. Reality view: the VMS systems run at 70%
    >to 100% CPU all day long. They are minimally 4 CPU systems with 8 GB
    >of memory, relatively new EV levels and are well tuned. They are just
    >used because they can reliably put out the work, especially when
    >compared to other more, umm, "modern" GUI based systems.


    Oh I understand. I fight such management views for the last decades and
    lost. Because DEC, COMPAQ and now HP always proved the management right.

    But technically, go upgrade to VMS V8.3. VMS Performance and TCPIP features/
    bugfixes/performance seems worth it. Only problem is see with V8.3 is with
    the new root feature (see $ SHOW ROOT $ SET ROOT) for GNV (and GNV itself).
    There is still A LOT missing to make this feature on par with VMS quality.

    >Why not try it out ourselves? Well, we are testing but that's nothing
    >like real-life experiences. For us to propose the upgrade and get it
    >approved, there needs to be strong business reasons to do so.


    We had problems with our application with TCPIP scalable kernel and this
    was mandatory since TCPIP V5.5 so we had to stay on VMS V7.3-2 (= UCX V5.4).
    But we would love to use our application on VMS 8.3 to gain the performance.

    But now that we heard that the application runs on TCPIP scalable kernel,
    we haven't upgraded so far. We have now other work to do (and most is
    not technical but administrative and boring) and upgrade is postponed.
    Maybe there is VMS V8.4 then (and the game starts again)...

    >Management's view is that (a) it's working okay, (b) don't mess with
    >it, and (c) it's going away. Well, it's been going away for the last 5
    >years; it'll likely be running 5 years from now.


    We have only 1-2 years left, because then our MARVELs are too old and
    application is still not running on Itanic and so we are forced to switch
    to Solaris (which demoes some performance advantages of up to 400% already
    with Oracle Classic - so first mover will be our Oracle Database RSN).

    >So with that atmosphere, the answer is quite simply that we need to
    >know that the effort will be worth the reward. What I've been able to
    >read on the CIFS literature speaks nothing about performance, only
    >functionality. That's why I'm asking those that may have already been
    >done this path to offer their experiences.


    I see, but I can't help. CIFS will only run on my DS10/XP1000/zx6000 @home
    next year (but then again, 1-3 clients is not comparable to you ;-)

    Good luck (and tell us how it went)

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  11. RE: Pathworks vs CIFS performance

    > -----Original Message-----
    > From: VMS is Virus Free [mailto:vms@virusfree.org]
    > Sent: October 24, 2007 8:01 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Pathworks vs CIFS performance
    >
    > We are considering switching out Pathworks in favor of CIFS. The main
    > reason is for performance: Pathworks being single threaded gets really
    > slow when a Windows user makes heavy use of it (example: accessing a
    > large directory from Windows). This impacts everyone else's
    > performance. We have searched for info on CIFS performance versus that
    > of Pathworks but have come up empty.
    >
    > Any experiences and comments relative to the merits of Pathworks
    > versus CIFS (aka Samba in VMS clothes) would be most appreciated.


    I do not know what the current beta Samba performance levels are, but like all new
    software products, the goal is typically get functionality required in place first -
    then worry about fine tuning performance.

    Hence, while its always fun to do mini-benchmarks, I would be very, very careful
    about making any preliminary conclusions comparing beta Samba versions vs Pathworks
    performance levels.

    This approach is not unique to OpenVMS - most software vendors take the same approach
    with new products.

    Regards



    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.






  12. Re: Pathworks vs CIFS performance

    Do you know if you can run both Pathworks and CIFS at the same time?
    If so, this might allow a second path to VMS files from Windows,
    effectly doubling the bandwidth since both Pathworks and CIFS are tied
    to the max performance of a single CPU.

  13. Re: Pathworks vs CIFS performance

    On Oct 25, 4:25 pm, VMS is Virus Free wrote:
    > The problems we see stems from Windows desktops accessing files on VMS
    > when
    >
    > (a) the directory being accessed has lots of files (lots = 10K to 100K
    > files). Many .DIR files are in the 5K to 10K blocks size. DFU on a
    > directory compress helps but does not offer much relief.

    ....
    > The large directory sizes are the results of program design that did
    > not think through design decisions when decade's worth of file
    > activity would need to be available online. We cannot change this
    > behavior. Reason: works okay, bigger fish to fry, no time to go back
    > and fix an old app.


    Directory files of this size (multiple thousands of blocks) will have
    serious performance problems even without Pathworks or Samba involved.
    What did you did do back in the pre-version-7.2 days when the edge of
    the performance clifff was much sharper/steeoer and you hit it at 128
    blocks?

    Could you divide the directories up, spread the files around among
    smaller directories, and use a search list logical name to locate
    them, putting the most-used files in the first directory and seldom-
    used files in the last directory in the search list?


  14. Re: Pathworks vs CIFS performance

    On Mon, 29 Oct 2007 21:42:55 -0000, keithparris_NOSPAM@yahoo.com
    wrote:

    >Directory files of this size (multiple thousands of blocks) will have
    >serious performance problems even without Pathworks or Samba involved.
    >What did you did do back in the pre-version-7.2 days when the edge of
    >the performance clifff was much sharper/steeoer and you hit it at 128
    >blocks?
    >
    >Could you divide the directories up, spread the files around among
    >smaller directories, and use a search list logical name to locate
    >them, putting the most-used files in the first directory and seldom-
    >used files in the last directory in the search list?


    Agree with all that you say. I have used the "search list" method as
    you described in the past to save the day. This may be an option here
    as well. A talk with the developers may allow this or perhaps make it
    impossible. To their credit, everything they refer to is via a logical
    name, so that makes moving stuff around a tad easier. The only
    downside of the logical name stuff is that they put their logical
    names, as in ALL of their logical names, into one table. That table
    currently has around 30K entries. Talk about having to juice up your
    LNMHASTBL size to something gargantuan! If you do a SHOW LOGICAL, the
    process, job, and group tables are zippy quick, as one would expect.
    Wedged inbetween the group and system table is this monster that
    literally takes 30 to 45 seconds to build the list before it displays
    it. Not my design; not in my control; I just inherited it.

    Talk about coughing up a hairball!

  15. Re: Pathworks vs CIFS performance

    In article , Malcolm Dunnett writes:
    >VMS is Virus Free wrote:
    >> Do you know if you can run both Pathworks and CIFS at the same time?
    >> If so, this might allow a second path to VMS files from Windows,
    >> effectly doubling the bandwidth since both Pathworks and CIFS are tied
    >> to the max performance of a single CPU.

    >
    >I don't think there's any reasonable way to run SMB on a non-standard
    >port - so I'd say the answer is no, only one server could listen on that
    >port at a time.


    It *may* work if you find a way to use different IP addresses (but the
    same TCP port) for the different packages on the same node. But as long
    as every one of the 2 packages binds to all addresses (0.0.0.0) you're SOL...

    --
    Peter "EPLAN" LANGSTOEGER
    Network and OpenVMS system specialist
    E-mail peter@langstoeger.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  16. Re: Pathworks vs CIFS performance

    Hi,

    "VMS is Virus Free" wrote in message
    news:e552i3h4s9v5v3nlqc254c3gljlncdl1ro@4ax.com...
    > On Thu, 25 Oct 2007 03:55:47 GMT, "John E. Malmberg"
    > wrote:
    >
    >>
    >>Pathworks is not single threaded, Pathworks is multi-threaded in a
    >>single process per cluster. It is far more efficient on CPU resources
    >>and context switching than the current V3 generation of SAMBA. If you
    >>are having problems with performance with Pathworks, SAMBA will probably
    >>not be much better, and possibly will be worse.

    >
    > We currently see Pathworks use 100% of one CPU. My guess is that it
    > was designed before Kernel threads were available. When threading
    > became available, it was too late or not enough energy left at Digital
    > to optimize the product to take full advantage of threading.
    > Otherwise, Pathworks would be able to use more than one CPU.
    >
    >>There may be tuning or other issues like disk / file fragmentation that
    >>are causing the slowdowns you are seeing.

    >
    > There are always tuning, umm, "opportunities". AUTOGEN doesn't find
    > anything. There is ample memory, multiple CPUs. Everything else runs
    > well, only Pathworks gets bogged down.
    >
    > The problems we see stems from Windows desktops accessing files on VMS
    > when
    >
    > (a) the directory being accessed has lots of files (lots = 10K to 100K
    > files). Many .DIR files are in the 5K to 10K blocks size. DFU on a
    > directory compress helps but does not offer much relief.
    >
    > (b) large files (500 GB to 1 TB) being read/written
    >
    > (c) lots of file transfers (both directions)
    >
    > Typical scenario is that access is relatively robust then one or more
    > users start doing some of these activities and slows Pathworks file
    > access down for everyone.
    >
    > The large directory sizes are the results of program design that did
    > not think through design decisions when decade's worth of file
    > activity would need to be available online. We cannot change this
    > behavior. Reason: works okay, bigger fish to fry, no time to go back
    > and fix an old app.
    >
    >>> Any experiences and comments relative to the merits of Pathworks
    >>> versus CIFS (aka Samba in VMS clothes) would be most appreciated.

    >>
    >>I left the SAMBA / VMS project before the various planed performance
    >>enhancements could be implemented and tested, so I do not know the
    >>specifics.
    >>
    >>The SAMBA V4 design allows a single process similar to Pathworks /
    >>Advanced Server to be used. I have no idea if it will be more efficient.

    >
    > We currently see Pathworks use 100% of one CPU. What we were looking
    > (hoping) for with CIFS is that the design would make better use of the
    > available CPU resources in a multi-CPU environment.
    >
    > What is sounds like is that CIFS still has a ways to go to catch up to
    > Pathworks (performance-wise).
    >
    >>The SAMBA V1 through V3 model of separate processes has a much higher
    >>overhead than threads, but provides the appearance of higher reliability
    >>as a failed process only briefly affects one client until it is
    >>restarted, where a single process model would affect all clients.
    >>
    >>-John
    >>wb8tyw@qsl.network
    >>Personal Opinion Only


    If you're truly running PATHWORKS for OpenVMS and not Advanced Server for
    OpenVMS then, yes you'll see problems you describe - until you get some
    patches from HP.

    If you have Advanced Server for OpenVMS (and to a lesser extent PATHWORKS
    for OpenVMS) you may benefit from:

    http://h10025.www1.hp.com/ewfrf/wc/g...reg_R1002_USEN

    Regards,

    Paul



  17. Re: Pathworks vs CIFS performance

    Hi,

    "VMS is Virus Free" wrote in message
    news:2tabi3hf7escaeptgbn4cd0aj8r7csjtei@4ax.com...
    > Do you know if you can run both Pathworks and CIFS at the same time?
    > If so, this might allow a second path to VMS files from Windows,
    > effectly doubling the bandwidth since both Pathworks and CIFS are tied
    > to the max performance of a single CPU.


    Yes, it is possible.

    PATHWORKS will allocated TCP port 139 and UDP ports 137 and 138 - nothing
    you can do to "control" that - and PATHWORKS binds to all interfaces -
    again, nothing you can do about that.

    But, CIFS supports TCP port 445 too. So if you configure CIFS to use TCP
    port 445 ONLY (by setting the tcpip smbd service accordingly) and do NOT
    start the NMBD process you can map drives to both CIFS (over TCP port 445)
    and PATHWORKS (over TCP port 139).

    Of course, they cannot share the same file simulataneously - the first to
    open it wins and the other is going to get a file currently is use error.

    HTH,


    Paul



  18. Re: Pathworks vs CIFS performance

    On Tue, 30 Oct 2007 07:41:41 -0400, "PEN"
    wrote:

    >If you have Advanced Server for OpenVMS (and to a lesser extent PATHWORKS
    >for OpenVMS) you may benefit from:
    >
    >http://h10025.www1.hp.com/ewfrf/wc/g...reg_R1002_USEN
    >
    >Regards,
    >
    >Paul
    >


    We are running Advanced Server and believe we have things reasonably
    well tuned. However, you referenced a good article on Pathworks
    tuning. We will go thru this to see if it affords any help.

  19. Re: Pathworks vs CIFS performance

    On Mon, 29 Oct 2007 21:42:55 -0000, keithparris_NOSPAM@yahoo.com
    wrote:

    >Could you divide the directories up, spread the files around among
    >smaller directories, and use a search list logical name to locate
    >them, putting the most-used files in the first directory and seldom-
    >used files in the last directory in the search list?


    Maybe I'm missing the obvious here; please help me out if it's just
    too simple to see.

    Assume disk:[a] is overloaded. Create some sub-dirs to hold the files:

    $ create/dir disk:[a.a1]
    $ create/dir disk:[a.a2]
    $ create/dir disk:[a.a3]

    Make the searchlist:

    $ define/system a_searchlist disk:[a.a1],disk:[a.a2],disk:[a.a3]

    Move some files around:

    $ rename disk:[a]a*.*,b*.*,c*.* disk:[a.a1]
    $ rename disk:[a]d*.*,e*.*,f*.* disk:[a.a2]
    $ rename disk:[a]g*.*,h*.*,i*.* disk:[a.a3]

    Create the share in Pathworks:

    $ admin add share/dir test a_searchlist /desc="Searchlist version"
    %PWRK-E-ERRADDSHARE, error adding share TEST_A
    -LM-E-ERROR_INVALID_N, invalid name

    If i replace the a_searchlist logical with something like disk:[a]
    then the command works as expected.

    I am probably just missing something but I couldn't figure out a way
    to make Pathworks happy with a searchlist.

    Any hints? Well, to heck with the hints, any outright answers?

  20. Re: Pathworks vs CIFS performance

    OK, neither a hint nor an answer, more like
    a shoot in the dark... :-)

    VMS is Virus Free wrote:

    Try somthing like :

    > $ create/dir disk:[a.a1]
    > $ create/dir disk:[a.a2]
    > $ create/dir disk:[a.a3]
    >
    > $ def/sys/tran=(con,term) f_root -
    > $ disk:[a.a1.], -
    > $ disk:[a.a2.], -
    > $ disk:[a.a3.]
    >
    > Move some files around...
    >
    > $ admin add share/dir test f_root:[000000] -
    > /desc="Searchlist version"
    >


    It works from plain DCL anyway. Not tested with PW...

    Jan-Erik.

    > On Mon, 29 Oct 2007 21:42:55 -0000, keithparris_NOSPAM@yahoo.com
    > wrote:
    >
    >> Could you divide the directories up, spread the files around among
    >> smaller directories, and use a search list logical name to locate
    >> them, putting the most-used files in the first directory and seldom-
    >> used files in the last directory in the search list?

    >
    > Maybe I'm missing the obvious here; please help me out if it's just
    > too simple to see.
    >
    > Assume disk:[a] is overloaded. Create some sub-dirs to hold the files:
    >
    > $ create/dir disk:[a.a1]
    > $ create/dir disk:[a.a2]
    > $ create/dir disk:[a.a3]
    >
    > Make the searchlist:
    >
    > $ define/system a_searchlist disk:[a.a1],disk:[a.a2],disk:[a.a3]
    >
    > Move some files around:
    >
    > $ rename disk:[a]a*.*,b*.*,c*.* disk:[a.a1]
    > $ rename disk:[a]d*.*,e*.*,f*.* disk:[a.a2]
    > $ rename disk:[a]g*.*,h*.*,i*.* disk:[a.a3]
    >
    > Create the share in Pathworks:
    >
    > $ admin add share/dir test a_searchlist /desc="Searchlist version"
    > %PWRK-E-ERRADDSHARE, error adding share TEST_A
    > -LM-E-ERROR_INVALID_N, invalid name
    >
    > If i replace the a_searchlist logical with something like disk:[a]
    > then the command works as expected.
    >
    > I am probably just missing something but I couldn't figure out a way
    > to make Pathworks happy with a searchlist.
    >
    > Any hints? Well, to heck with the hints, any outright answers?


+ Reply to Thread
Page 1 of 2 1 2 LastLast