No announcement yet.

Apparent change in ERR report for MKDIR post Fixpack 12 in OS/2 DOS-VDM's

  • Filter
  • Time
  • Show
Clear All
new posts

  • Apparent change in ERR report for MKDIR post Fixpack 12 in OS/2 DOS-VDM's

    I realize the number of people using PB 3.5 in OS/2 DOS-VDM's is
    small compared to all the use of PB.3.5. However for those that are,
    I'll post a curious change in the error level value that MKDIR
    will report after moving from FixPack 8 for Warp 4 and FixPack 8409
    for IBMPEER for those of interest.

    Those NOT using OS/2 might be interested to note that it is important
    to move upward, as I understand it, to FIXPAK 12 for OS/2 Warp 4.0,
    in that the entire OS/2 user base is being readied, in the field, to
    move to the standardized Warp 4.5 WSeB server kernal. This is being
    done to standardize the product line on the future kernel for what will
    become, in October or November, either OS/2 version 5.0, or as it
    looks now, the new product for OS/2 that will not carry the OS/2 name
    for the platform. OS/2's formal announcement of major development
    support by IBM in the Phoenix, Arizona conference spoke to substantial
    on-going development through the year 2006, and that the major users
    are, so noted, indicating a minimal extensive support need through
    2008 under their agreements, as well.

    IBM follows the same policy that Bob Zale an PowerBasic follow, to a
    great extent, based on my observation. They won't talk unless they
    are ready to announce. No vaporware, period. Per what I have seen
    posted, they, under the ongoing terms of the original DOJ overview, which
    they have been on for MANY years now as a monopoly in the mainframe game,
    are actually forbidden to talk about anything new more than 90 days ahead
    of the actual release date.

    Us IBM watchers include a number that think that the OS/2 name will
    be dropped .. or .. phased out, simply to remove the ability of the market
    and the press to keep harping on the past ...

    FIXPACK 12 is the latest level for WARP 4.0 prior to the recently
    released FIXPACK 13 which moves the whole system to the Warp Server
    for EBiz engine and kernel. The latest IBMPEER fixpack is 8413. On
    installation of these two most recent updates to the system the
    PB 3.5 MKDIR function changed error reporting, as far as we and
    our user base can see.

    In fairness to Bob Zale and the PowerBASIC crew, it looks to me that
    a reported unhappiness at the error level of directory handinglin and
    creation from a long time ago, may, indeed, be a problem in the IBM
    operating system, and not what PB 3.5 reported for certain errors

    At FIXPACK 8 and PEER 8409, if you attempted to MKDIR on a networked
    drive and the applicable directory was already there, under a DOS-VDM
    in OS/2, you would receive an ERR 76 from PB 3.5. My original contention
    was that the ERR 76 wasn't really what we should expect, but it was
    easy to simply fix the symptom, trap the ERR 76 and forget about the
    issue. Get on with life.

    Post FIXPACK 12 and PEER 8413 fixes, suddenly the exact same compiled
    programs that have been in use for months, began showing an ERR 70,
    Permission Denied, for that exact same actual error point in the code.
    From a conceptual standpoint, it sure seems that ERR 70 is a far better
    description of the actual error, than was the ERR 76.

    The important point is two-fold. Those using the IBM OS/2 DOS-VDM's
    when in a network environment, and working with remote directories on
    servers like we do, should be alert for the change in error number
    that is reported! It's simple to solve the proble and trap both the
    ERR 76 and ERR 70 and forget about the past, yet leave it for those
    still wishing to keep the older FixPack level.

    The second most important point is that Bob Zale was correct about his
    original comment; I ain't PB 3.5 folks, it's the operating system. If
    you're going to gripe, in my view, you ought to post the rest of the
    story when you find out the facts .. so I've done so to give the
    proper credit and post what's been learned on this particular problem.

    I have no idea what other experience has been with this one, but that's
    what surfaced from a user blowup we just finished solving.

    Mike Luther
    [email protected]
    Mike Luther
    [email protected]