Author: Admin

  • Popular AO3 Tags

    This tag cloud (Tags | Archive of Our Own) describes a very recognisable fan-fiction consumption niche, but it is more useful for inferring reading behaviour than demographic identity. Tags such as sexual orientation, mental health, religion, or underage content should not be treated as evidence that the reader personally belongs to those categories.

    The dominant signals are unusually clear: Alternate Universe, Angst, Hurt/Comfort, Relationship(s), Sexual Content, Romance, Love, Fluff, Friendship, Family, LGBTQ Themes, Not Canon Compliant, Violence and Smut. Taken together, this is a reader who wants emotionally intensive, character-centred transformative fiction rather than plot-faithful extensions of canon.

    I would characterise the consumer as an โ€œemotionally immersive transformative-fiction reader.โ€

    Their primary consumption loop is approximately:

    attachment โ†’ disruption โ†’ suffering โ†’ intimacy โ†’ emotional resolution

    That is visible in the simultaneous prominence of Angst, Hurt/Comfort, Romance, Love, Fluff, Friendship and Happy Ending. Angst is not being consumed simply because the reader enjoys bleak fiction. The much larger ecosystem around comfort, relationships and affection suggests that distress is frequently valuable because of what it permits afterwards: confession, caretaking, reconciliation, intimacy and emotional payoff.

    There are several strong components to the profile.

    First, they are strongly character rather than lore oriented. Character Study, POV tags, introspection, feelings, communication failure, jealousy, pining, protectiveness, misunderstandings, confessions and trauma all indicate interest in internal states. A 150,000-word story in which two characters gradually renegotiate their relationship may therefore outperform a technically accomplished action story about saving the universe.

    Second, canonical fidelity has relatively low intrinsic value. Alternate Universe is arguably the strongest signal in the entire cloud, reinforced by Not Canon Compliant, Canon Related, Canon Universe, Post-Canon, Pre-Canon, Crossovers & Fandom Fusions, Fix-It, Aged-Up Characters and Original Characters. Canon supplies characters and emotional capital; it does not constrain the product.

    That is an important commercial distinction. This audience effectively treats fictional characters as reusable narrative components.

    Third, relationships are the principal narrative engine. Relationship(s), Romance, Love, Friendship, Family, Getting Together, Marriage, Soulmates, Pining, Slow Build, Kissing, Cuddling, Jealousy and Unrequited all cluster around changing interpersonal states. The consumer is therefore likely to respond strongly to a clear relationship proposition:

    Two people who should not work together are forced into proximity, become emotionally dependent, and eventually have to decide what they mean to one another.

    The surrounding genre can change almost arbitrarily.

    Fourth, this is a relatively high-tolerance audience for tonal extremes. The cloud runs from Fluff, Humor and Light-Hearted material through Death, Gore, Torture, Violence, Trauma, Non-Consensual themes, Drugs and Horror. That apparent contradiction is characteristic rather than anomalous. The consumer appears comfortable moving between comfort fiction and transgressive or disturbing fiction, sometimes within the same work.

    In marketing terms, intensity is probably more important than tonal consistency.

    Fifth, sexuality is a substantial component of the catalogue. Sexual Content and Smut are major categories, surrounded by numerous specific sexual-practice tags. This suggests a consumer who values explicit metadata and wants considerable control over the type of material encountered. It does not necessarily mean that every preferred story is explicit: Fluff, Romance, Hurt/Comfort and Friendship remain equally important parts of the ecosystem.

    The tag cloud also tells you something about the consumer’s information behaviour. This reader is likely to be highly tag-literate. AO3-style metadata isn’t decoration; it is part of the search interface. Tags such as Dead Dove: Do Not Eat, Not Beta Read, POV Multiple, Fix-It, Slow Build, Hurt/Comfort and Not Canon Compliant communicate narrative contracts before the first paragraph is read.

    Consequently, discovery is probably driven less by conventional blurbs and more by combinations of tropes.

    A useful abstract preference model would be:

    DimensionProbable preference
    Character vs worldStrongly character
    Canon fidelityLowโ€“moderate
    Emotional intensityVery high
    RomanceVery high
    Relationship developmentVery high
    Explicit materialModerateโ€“high
    Dark material toleranceHigh
    Comfort/positive payoffHigh
    Experimental premisesHigh
    Plot/action requirementModerate
    Trope awarenessVery high
    Metadata dependenceVery high
    Short vs long fictionProbably broad, with strong support for slow-build serialisation

    There is also an interesting secondary pattern: transformation and altered circumstances. Alternate Universe sits alongside Bodily Modification, Gender Themes, Shapeshifting, Pregnancy, Age Difference, Aged-Up Characters, Alpha/Beta/Omega Dynamics, Mythical Beings, Supernatural Elements and Time Travel. The reader seems interested in scenarios that alter the rules under which familiar people interact. That makes speculative premises particularly useful when they function as relationship machines rather than as exercises in worldbuilding.

    If I were defining this as a publishing persona rather than a person, I would write it as:

    Persona: The Transformative Intensity Reader

    A highly fandom-literate consumer who chooses fiction primarily for character chemistry, emotional jeopardy and relationship progression. Comfortable with canonical divergence, alternate universes, sexuality and dark subject matter. Values strong emotional contrastsโ€”pain followed by tenderness, hostility turning into intimacy, isolation becoming dependency. Searches using tropes and granular tags rather than genre alone. Has relatively little objection to radical reinterpretation provided the characters remain emotionally compelling. Likely to favour serialised or bingeable fiction, recurring characters, ships, escalating emotional stakes and conspicuous tagging.

    The most interesting implication is that this is not fundamentally a โ€œromance readerโ€ or a โ€œsmut reader.โ€ The stronger underlying product appears to be controlled emotional intensity. Romance, sex, horror, violence, fluff and AU scenarios are different mechanisms for producing it.

    For content development, the highest-probability proposition would therefore be something like:

    familiar characters + radical premise + difficult relationship + escalating vulnerability + strong hurt/comfort component + eventual emotional/sexual payoff.

    That combination sits almost exactly at the centre of this cloud.

  • Code Sustainment Across Generations

    The central problem

    Every successful codebase outlives at least three things, and they rarely die at the same time:

    1. The product that originally compiled it (the IDE, the toolchain, the vendor’s commercial interest).
    2. The Platform or environment it targeted (the OS, the runtime, the browser, the hardware).
    3. The people who understood it (the original authors, the cohort who maintained it).

    When all three align, sustainment is routine. When they drift apart, the codebase enters a sustainment gap โ€” it still runs, but the means to rebuild, modify, or safely operate it are eroding. The history of our industry is a series of these gaps. The VB6 situation is one instance of a repeating pattern that began with COBOL and will repeat with whatever you migrate to next.


    The three failure axes

    Code does not die from a single cause. It dies along three independent axes, each on its own clock:

    flowchart LR
      A["Loss axis"]
      A --> P["Product<br/>The compiler/IDE/vendor<br/>withdraws support"]
      A --> E["Environment<br/>The target OS/runtime/platform<br/>moves on"]
      A --> D["People<br/>The cohort who understand it<br/>retire or leave"]
      P --> G["Sustainment gap"]
      E --> G
      D --> G
    
    • Product loss is commercial and abrupt: a vendor announces end-of-support, stops selling licences, or goes out of business. The toolchain freezes at its last released version.
    • Environment loss is gradual and OS-driven: the platform the binary runs on is updated, deprecated, or replaced. The runtime may persist longer than the toolchain (Microsoft ships the VB6 runtime in Windows for the OS lifetime, but withdrew the VB6 IDE in 2008).
    • People loss is demographic and irreversible: developers age out of the workforce, and knowledge isn’t replenished because new entrants learn the currently-marketed stack, not the legacy one.

    The dangerous phase is when these axes desynchronise. The runtime still ships, but the toolchain is gone and the maintainers have retired โ€” exactly your VB6 position. You can run the code but cannot safely evolve it.


    Generational timeline

    Each wave of platform technology produced a cohort of business-critical code that later entered a sustainment gap. The pattern repeats roughly every 15โ€“20 years โ€” long enough for a generation of developers to build careers on a stack, retire, and leave the code behind.

    timeline
      title Five generations of code entering the sustainment gap
      1959 : COBOL
            : Mainframe batch processing era begins
      1970s : COBOL dominates banking, government, insurance
      1991 : PowerBuilder
            : Client/server RAD era begins
      1995 : Delphi, VB6 era
            : Windows desktop business apps explode
      1998 : VB6 final release
            : Delphi and PowerBuilder mature
      2008 : VB6 IDE support withdrawn
            : Product loss for VB6
      2010 : SAP acquires Sybase / PowerBuilder
            : PowerBuilder enters vendor limbo
      2015 : Visual FoxPro end of support
            : Microsoft withdraws
      2020 : Flash / ActionScript EOL
            : Browser plugin era ends
      2025 : COBOL avg developer age 55
            : VB6 IDE unsupported for 17 years
            : PowerBuilder revived by Appeon
      2030 : Windows 10/11 VB6 runtime EOL
            : Environment loss closes the gap for VB6
    

    Generation 1 โ€” Mainframe batch (COBOL, 1959โ€“)

    FactorState
    Code~43% of global banking systems; 95% of ATM transactions process through COBOL; $3T in running systems
    ProductStill supported โ€” IBM Enterprise COBOL 6.5 released June 2025. The compiler is alive.
    EnvironmentMainframe (z/OS) persists; IBM continues investing. Runtime is not the problem.
    PeopleAverage COBOL developer age ~55; ~10% of workforce retiring annually; almost no new entrants.
    Gap driverPeople loss only. Product and environment are healthy. This is the purest demographic-cliff case.
    StatusThe canonical slow-motion crisis. $105B/year in inefficiencies; 80% of legacy-agency IT budgets consumed just keeping systems running.

    Generation 2 โ€” Client/server RAD (PowerBuilder, Delphi, 1991โ€“)

    FactorState
    CodeThousands of enterprise CRUD/ERP apps in government, insurance, banking, education, manufacturing.
    ProductPowerBuilder orphaned by SAP (2010โ€“2016), then revived by Appeon (PowerBuilder 2025 released May 2025). Delphi still sold by Embarcadero but 1.8% developer proficiency (2025 SO survey).
    EnvironmentWindows desktop. BDE deprecated ~2000, breaks on W10/11 updates.
    People1.8% Delphi proficiency; experienced practitioners approaching retirement.
    Gap driverProduct + People. PowerBuilder survived via vendor transfer (Appeon); Delphi is commercially alive but demographically terminal.
    StatusManageable for PowerBuilder (active vendor, migration path to C#/.NET via Appeon). Critical for Delphi (commercial tool exists, no workforce to use it).

    Generation 3 โ€” Windows desktop (VB6, 1998โ€“)

    FactorState
    CodeExtensive enterprise codebases; exact volume untracked but vast. Your situation.
    ProductIDE unsupported since 2008 โ€” 18 years. No vendor will revive it. The toolchain is frozen.
    EnvironmentRuntime supported in Windows 10/11 for the OS lifetime (~2030). Runtime is healthy; toolchain is dead.
    PeopleOriginal maintainers retired or retiring โ€” your stated situation. New entrants effectively zero.
    Gap driverAll three axes simultaneously. Product lost (2008), people leaving (now), environment closing (~2030). This is the most advanced gap in the set.
    StatusThe runtime buys time but the ability to rebuild from source is the immediate casualty. The window between “can still run” and “can no longer rebuild” is closing.

    Generation 4 โ€” Web plugin (Flash / ActionScript, 1996โ€“2020)

    FactorState
    CodeE-learning, rich media, games, enterprise dashboards.
    ProductAdobe Flash Player EOL December 2020. Content blocked from running.
    EnvironmentBrowser vendors removed plugin APIs entirely. The execution environment was destroyed, not just the toolchain.
    PeopleActionScript developers migrated to JavaScript/TypeScript; the language has no remaining practitioner base.
    Gap driverTotal loss โ€” all three axes collapsed simultaneously and irreversibly. The runtime was actively removed, not merely deprecated.
    StatusThe cautionary tale. When environment loss is active removal rather than passive deprecation, there is no sustainment โ€” only migration or abandonment.

    Generation 5 โ€” Current (Java/.NET/JS, 2000sโ€“)

    FactorState
    CodeThe bulk of today’s enterprise systems.
    ProductSupported, but LTS windows are shortening. Java 8 LTS extended repeatedly; .NET moves to 18-month LTS cycles. Old framework versions (e.g. .NET Framework 4.6.2) persist but are feature-frozen.
    EnvironmentCloud-native shifts; containerisation; server OS lifecycles (Windows 10 EOL Oct 2025).
    PeopleActive and large โ€” for now.
    Gap driverNot yet in a gap, but version-stratified. Code written against Java 8 or .NET Framework 4.x is already in a soft gap: the platform persists but the current tooling and workforce target newer versions.
    StatusThis generation’s gap is being created now, in real time, through version churn rather than wholesale platform abandonment. The lesson: today’s supported stack is tomorrow’s legacy.

    The generational pattern

    Looking across all five generations, a clear pattern emerges:

    flowchart LR
      Build["Build phase<br/>New stack<br/>Active product<br/>Young cohort"] --> Mature["Mature phase<br/>Widely deployed<br/>Stable product<br/>Mid-career cohort"]
      Mature --> ProductLoss["Product loss<br/>Vendor withdraws<br/>or moves on"]
      ProductLoss --> PeopleLoss["People loss<br/>Cohort retires<br/>No new entrants"]
      PeopleLoss --> EnvLoss["Environment loss<br/>Runtime deprecated<br/>or removed"]
      EnvLoss --> Gap["Sustainment gap<br/>Code still runs<br/>Cannot rebuild<br/>Cannot staff"]
      Gap --> Migrate["Migrate or abandon"]
      Gap --> Die["Lose the code"]
      Migrate --> Build
    Build phaseNew stackActive productYoung cohortMature phaseWidely deployedStable productMid-career cohortProduct lossVendor withdrawsor moves onPeople lossCohort retiresNo new entrantsEnvironment lossRuntime deprecatedor removedSustainment gapCode still runsCannot rebuildCannot staffMigrate or abandonLose the code

    Each generation follows the same arc: build โ†’ mature โ†’ product loss โ†’ people loss โ†’ environment loss โ†’ sustainment gap โ†’ migrate or lose. The cycle time is roughly 20โ€“30 years from initial build to forced migration. The gap opens when any axis fails, but becomes critical when two or more fail simultaneously.

    Key observations:

    • Runtime long outlives toolchain. In every Microsoft generation, the runtime ships for years after the IDE is withdrawn. This creates a false sense of security โ€” the apps run, so the problem feels theoretical until the maintainers leave.
    • People loss is the slowest and most dangerous axis. COBOL proves this: the compiler is current, the mainframe persists, but the workforce is vanishing. You cannot train your way out of a demographic cliff in time.
    • Environment loss is the hard deadline. When the runtime is removed (Flash) rather than deprecated (VB6), there is no sustainment option โ€” only migration.
    • Vendor transfer can rescue a product. PowerBuilder survived because Appeon took it from SAP. VB6 has no such rescuer because Microsoft will not license it to anyone. The difference between “orphaned” and “transferred” is often the difference between survival and loss.

    Sustainment principles

    From the pattern above, seven principles that apply to any generation โ€” including whatever you migrate your VB6 code to next.

    Principle 1 โ€” Separate the three axes and track each independently

    Sustainment decisions go wrong when “the code is fine” is used to mean “the runtime still runs.” Track each axis on its own clock:

    • Product health: Is the vendor still selling and supporting the compiler? Is there a migration successor? (VB6 IDE: no. COBOL compiler: yes. PowerBuilder: yes, via Appeon.)
    • Environment health: Does the target platform still ship the runtime? Is it deprecated or actively being removed? (VB6 runtime: ships until ~2030. Flash: removed in 2020.)
    • People health: How many people can build and debug this? What is their age distribution? Is the skill being taught anywhere?

    When two of three axes are red, you are in the gap. When all three are red, you are out of time.

    Principle 2 โ€” Never let the toolchain be the single point of failure

    If only one product can compile your code, and that product is unsupported, you cannot rebuild. This is the VB6 trap. Countermeasures:

    • Keep a buildable reference environment (the install instructions I gave you) documented and reproducible.
    • Prefer languages with multiple independent compilers (COBOL has IBM, Micro Focus, GnuCOBOL โ€” three independent vendors). VB6 has exactly one (Microsoft, unsupported). twinBASIC gives you a second.
    • Decouple editing from compiling early (VS Code + command-line vb6.exe /make) so a toolchain failure doesn’t strand your source.

    Principle 3 โ€” Treat source code as the asset, not the binary

    The binary is perishable; the source is the asset. But source without a working toolchain is an archive, not a codebase. Therefore:

    • Keep source in modern version control (git) with full history โ€” not in the proprietary project format alone.
    • Keep build scripts reproducible and documented โ€” the exact compiler switches, the exact environment, the exact dependency versions.
    • Periodically verify reproducibility: can a new machine build from source using only the repository and the documented toolchain? If not, you don’t have source โ€” you have a fossil.

    Principle 4 โ€” Plan migration before the gap, not after

    Every generation shows the same failure mode: organisations assumed the old stack “would eventually be replaced” and underinvested until forced. COBOL banks are the extreme case โ€” they are now paying $105B/year for that assumption. The window for cheap migration is during the mature phase, when the toolchain still works and the people are still present. Once either is gone, migration cost multiplies.

    • Start a pilot on one module while the toolchain still works.
    • Benchmark conversion tools (twinBASIC, Mobilize VBUC) on real code, not samples.
    • Establish a target stack before the crisis, not during it.

    Principle 5 โ€” Prefer incremental over big-bang migration

    The Strangler Fig pattern โ€” replacing legacy components gradually while new functionality is built in the target stack โ€” appears across every successful modernisation case (COBOL-to-Java, PowerBuilder-to-C#, Delphi-to-web). Full rewrites fail at a high rate because they attempt to re-derive decades of accumulated business logic in one move.

    • Migrate module by module, keeping the system running throughout.
    • Maintain a dual-stack period where old and new coexist โ€” expensive but lower-risk than a cutover.
    • Sequence by risk and isolation: start with the most self-contained, lowest-business-criticality module.

    Principle 6 โ€” Capture the business logic before the people leave

    The most valuable thing in legacy code is not the syntax โ€” it is the encoded business knowledge that exists nowhere else. When the maintainers retire, that knowledge leaves with them. Code without people who understand it is archaeology, not engineering.

    • Document business rules in the code’s own comments, in a wiki, or in tests โ€” written by the people who understand them, while they still can.
    • Record walkthroughs: have departing maintainers narrate the critical paths, data flows, and the “why” behind non-obvious decisions.
    • Write characterization tests (tests that document current behaviour) before migration, so you have a correctness oracle after the people are gone.

    Principle 7 โ€” Design the next stack for its own sustainment

    The stack you migrate to will enter its own gap in 20โ€“30 years. Build for that now:

    • Choose a platform with a long support horizon and multiple independent implementations (e.g. .NET has Microsoft + open-source runtime; Java has multiple vendors).
    • Prefer open standards over single-vendor lock-in for data formats and protocols.
    • Keep dependencies minimal and substitutable โ€” every dependency is a future sustainment axis of its own.
    • Maintain build reproducibility from day one โ€” the same principle that is failing you with VB6 now.

    Applying this to the VB6 position

    Your situation maps directly onto the framework:

    quadrantChart
      title Where VB6 sits on the sustainment axes
      x-axis "Product healthy" --> "Product lost"
      y-axis "Environment healthy" --> "Environment closing"
      "COBOL 2025": [0.15, 0.20]
      "PowerBuilder 2025": [0.45, 0.40]
      "VB6 today (2026)": [0.90, 0.35]
      "VB6 ~2030": [0.95, 0.90]
      "Flash 2021": [0.95, 0.95]
    Parse error on line 1:
    quadrantChart  titl
    ^
    Expecting 'NEWLINE', 'SPACE', 'GRAPH', got 'ALPHA'
    • Product axis (red): IDE unsupported 18 years. No vendor will revive it. This is your hardest constraint and the one you cannot fix โ€” only route around (twinBASIC, or command-line vb6.exe /make from the installed kit).
    • People axis (red): your maintainers have retired. This is the slowest axis to recover and the one most often underestimated. Capture their knowledge now, from whoever remains, before it’s gone.
    • Environment axis (amber โ†’ red): runtime ships until ~2030. This is your clock. You have roughly 3โ€“4 years before environment loss compounds the other two failures into a hard deadline.

    Recommended priority order:

    1. People first โ€” document business logic, record walkthroughs, write characterization tests while anyone who understands the code is still reachable.
    2. Toolchain second โ€” establish a reproducible build (command-line vb6.exe /make + VS Code editing) so source is buildable independent of the IDE.
    3. Migration pilot third โ€” run twinBASIC and Mobilize VBUC against one module to measure conversion cost before the clock forces a rushed decision.
    4. Incremental migration fourth โ€” execute module by module into the target stack, using the Strangler Fig pattern, completing before ~2030.

    The runtime gives you time. The retired maintainers do not. Sequence accordingly.

  • Ghosts in the Feedback Loop: Identity, Fear and the Futures That Haunt Us

    Culture does not move cleanly from past to present to future. It circulates. Images survive their eras. Predictions become designs. Designs become habits. Habits become institutions. Institutions become ruins, and the ruins acquire meanings that their builders never intended. The future is imagined through fragments of the past, while the past is repeatedly rewritten by the futures that actually arrive.

    Within this circulation, identity is never entirely stable. Personal identity depends upon memory, recognition, narrative and continuity. Cultural identity depends upon much the same things, only distributed across populations. Both are haunted by what has disappeared, what might have happened, and what was once expected to happen but did not.

    Fear enters precisely where these narratives fail.

    The modern individual tends to imagine the self as coherent: one body, one biography, one name, one history. Yet even before digital technology this coherence was partly fictional. Memory edits. Families suppress. Nations mythologise. Institutions archive selectively. Individuals reconstruct themselves according to circumstances. We inhabit stories about ourselves because without narrative continuity experience would be only a succession of disconnected events.

    Technology has made this instability more visible.

    A person now exists simultaneously as biological body, legal identity, employment record, social profile, photographic archive, search history, credit score, behavioural model, biometric template and statistical prediction. These representations overlap but are not identical. Some are generated by the individual, some by institutions, and others by machines inferring characteristics that the person may never consciously have expressed.

    The self has become distributed.

    This produces a peculiarly contemporary form of horror. The threat is not necessarily that someone will steal your identity. It is that identity has already ceased to belong entirely to you.

    A system somewhere may possess a version of you that determines whether you receive a loan, enter a country, see an advertisement, qualify for insurance or become the subject of investigation. That computational double need not resemble the person you understand yourself to be. Nevertheless, in practical terms, it may become authoritative.

    Here personal anxiety begins to resemble cosmic horror.

    H. P. Lovecraft repeatedly constructed stories in which knowledge destroys the apparent boundaries of the self. A protagonist discovers an ancestry that alters who he believes himself to be, a consciousness that can migrate between bodies, an intelligence older than humanity, or a universe in which human categories possess no privileged significance.

    The terror does not simply come from encountering a monster.

    It comes from discovering that the category called โ€œhumanโ€ is less secure than expected.

    The same structure survives throughout modern horror. The alien becomes parasitic. The body becomes unreliable. Memory becomes questionable. The copy becomes indistinguishable from the original. The environment becomes sentient, or perhaps reveals that the distinction between environment and organism was always artificial.

    Eventually the question ceases to be, โ€œWhat is the monster?โ€

    It becomes, โ€œWhat am I?โ€

    This movement from external fear towards ontological uncertainty is one of the defining features of modern cultural anxiety.

    Yet Lovecraft himself is now part of a larger feedback process. His stories were influenced by earlier anxieties about science, degeneration, empire, race, archaeology and humanity’s shrinking position within an expanding universe. Those anxieties entered fiction. Fiction transformed them into a distinctive symbolic vocabulary. Later writers, filmmakers and game designers reused that vocabulary. Their works then shaped how subsequent generations imagined the unknown.

    The fiction returned to culture as a framework for perceiving reality.

    This is where hyperstition becomes useful.

    A hyperstition is more than a prediction that happens to come true. It is an idea whose circulation contributes to creating the conditions under which something resembling it becomes real.

    Cyberpunk provides particularly obvious examples.

    Early cyberpunk did not predict contemporary technological life in any simple prophetic sense. It exaggerated existing tendencies: computer networking, multinational corporations, prosthetics, surveillance, consumer electronics, virtual environments, artificial intelligence and fragmented urban identities.

    But those stories were subsequently consumed by people who designed software, interfaces, games, corporations and networks.

    Fiction provided metaphors.

    The metaphors became expectations.

    Expectations influenced designs.

    Designs produced technologies.

    Those technologies were then described using the terminology of the fiction.

    The loop closed.

    โ€œCyberspaceโ€ is perhaps the exemplary case. A fictional spatial metaphor helped people conceptualise computer networks. Once the metaphor circulated widely enough, actual technological development began to be understood through it.

    The fiction did not predict reality.

    It participated in constructing reality.

    This process also operates culturally rather than technologically. A society produces stories about itself. Those stories influence behaviour. Behaviour produces circumstances which appear to confirm the stories.

    A nation that continually describes itself as threatened begins constructing institutions around threat. Those institutions generate surveillance, boundaries and enemies. Their existence then seems to prove that the original fear was justified.

    A culture that tells itself technological innovation is inevitable directs money, prestige and labour toward certain technologies. Their eventual appearance is then presented as proof of inevitability.

    Narrative becomes infrastructure.

    But not every imagined future arrives.

    This is where hauntology enters.

    Hauntology concerns the persistence of absences. Its most compelling cultural form is the lost future: something that never existed but was once confidently expected.

    The twentieth century generated vast archives of futurity.

    Monorails crossed conceptual cities. Nuclear electricity promised abundance. Automation promised leisure. Supersonic aircraft promised a shrinking planet. Space stations promised expansion beyond Earth. Public architecture promised enormous civic confidence. Computers promised liberation from bureaucracy.

    Some of these futures arrived partially.

    Some arrived in distorted form.

    Others simply disappeared.

    Their images survived.

    A faded architectural drawing of a pedestrian city can therefore produce a strange emotion. We are not merely looking at the past. We are looking at the past looking toward a future which never became our present.

    The object contains two times simultaneously.

    It is historical and futuristic.

    This is the territory of the semiotic ghost.

    A semiotic ghost is not a supernatural apparition but a sign that has outlived the cultural structure which originally gave it meaning. The chrome rocket, the streamlined tower, the computer terminal glowing green in a darkened room, the flying car, the transparent videophone, the optimistic corporate family standing beneath a geodesic dome: each carries an embedded future.

    When encountered later, these objects appear haunted.

    Not because anything supernatural inhabits them.

    Because an abandoned expectation does.

    They are evidence from timelines that did not occur.

    Personal identity is structured in much the same way.

    Everyone possesses lost futures.

    The career never pursued.

    The relationship that did not continue.

    The city never moved to.

    The version of oneself imagined at seventeen, thirty or fifty.

    These unrealised selves do not simply disappear. They remain available as comparisons against the present.

    One can therefore be haunted by someone who never existed.

    This is one reason nostalgia can become painful. Nostalgia is usually described as longing for the past, but much nostalgia is actually longing for a past future.

    We remember not merely what happened but what we once believed would happen.

    Childhood memories are filled with this peculiar temporal structure. The remembered summer contains the adult knowledge that the future anticipated by the child will not arrive.

    The remembered objectโ€”a toy computer, a magazine, a science-fiction programme, a school textbookโ€”can suddenly recover the expectation attached to it.

    For a moment we remember tomorrow.

    Cultural identity operates through the same mechanism at larger scale.

    Nations construct narratives from remembered victories, defeats, migrations, industries and institutions. Yet they are equally defined by abandoned futures.

    The industrial future.

    The imperial future.

    The socialist future.

    The technological future.

    The European future.

    The post-industrial future.

    The global future.

    Each political generation inherits not merely history but unfinished predictions.

    Consequently public debate is often conducted among ghosts.

    People argue over versions of society that once seemed possible. Political movements promise restorations of conditions that never existed quite as remembered. Technologies are promoted using imagery borrowed from earlier technological revolutions. New crises are interpreted through wars, depressions and cultural conflicts whose original circumstances have disappeared.

    The past is therefore continually projected forward.

    At the same time, imagined futures travel backward.

    Once something happens, earlier history begins to appear as though it were always leading toward it.

    The arrival of the internet made previous networking experiments look like precursors.

    The arrival of smartphones transformed pagers, PDAs and early mobile computers into evolutionary ancestors.

    The arrival of generative AI causes decades of fictional computers and artificial minds to be reread as prophecies.

    This retrospective reconstruction is powerful.

    The successful future colonises the past.

    Technological history becomes populated by inventions which appear inevitable only because we know what eventually succeeded.

    Failures disappear.

    Alternative paths become curiosities.

    The past is reorganised around the present.

    This creates another feedback loop:

    the present selects its ancestors.

    Those selected ancestors then justify the present.

    The resulting narrative makes the present appear inevitable.

    Culture becomes haunted not simply by what came before, but by the paths it has erased.

    This is where fear becomes politically and culturally important.

    Fear simplifies possibility.

    When frightened, individuals and cultures seek strong categories: friend and enemy, human and nonhuman, authentic and fake, normal and abnormal, safe and contaminated.

    Horror repeatedly attacks precisely those distinctions.

    The possessed person looks normal.

    The double possesses the original’s memories.

    The machine imitates human speech.

    The photograph may be synthetic.

    The trusted institution contains the threat.

    The familiar landscape has subtly changed.

    The horror lies in failed classification.

    Contemporary technological life increasingly generates similar uncertainties without requiring supernatural causes.

    A photograph is no longer straightforward evidence that something occurred.

    A voice recording is no longer straightforward evidence that someone spoke.

    A message may have been written by a human, generated by a model, generated by a model and edited by a human, or copied from something generated years previously.

    An online identity may belong to a person, organisation, bot, agent or composite.

    The informational world becomes populated by ambiguous entities.

    Historically, cultures interpreted ambiguous agency through ghosts, spirits, demons, doubles and possession.

    Modern technological society uses algorithms, agents, models and synthetic media.

    The ontologies differ enormously, but the psychological problem has similarities.

    Something acts.

    Its internal state is inaccessible.

    Its intentions are uncertain.

    Its presence must be inferred from traces.

    The ghost returns as an epistemological structure.

    This does not mean contemporary machines are supernatural. It means older supernatural narratives remain useful because human beings repeatedly confront situations in which agency is visible while the agent is obscure.

    Technology does not eliminate ghosts.

    It manufactures new conditions in which ghost metaphors become persuasive.

    Generative artificial intelligence intensifies this effect because it is fundamentally archival.

    Its outputs appear new, yet they emerge from statistical relationships extracted from enormous bodies of previous cultural production.

    The future is generated from the past.

    Ask for a future city and the machine returns accumulated fragments of previous future cities: cyberpunk neon, modernist towers, Gulf megaprojects, science-fiction spacecraft, corporate concept art, Japanese signage, twentieth-century utopian architecture.

    The supposedly unprecedented future arrives pre-haunted.

    AI therefore creates an unusual temporal machine.

    The archive produces the future.

    The generated future enters the archive.

    Future models learn from those generated artefacts.

    The distinction between cultural memory and cultural prediction begins to blur.

    This could be understood as an automated semiotic feedback loop.

    Humanity imagines the future.

    Machines learn humanity’s imagery of the future.

    Machines produce new images of the future.

    Humans consume those images.

    Designers incorporate their aesthetics.

    Products begin to resemble them.

    The generated image gradually acquires causal power.

    Hauntology and hyperstition converge.

    One concerns futures that failed to arrive.

    The other concerns imagined futures that help themselves arrive.

    Between them sits contemporary culture, continuously deciding which ghosts to resurrect.

    This is also why cultural identity is becoming increasingly unstable.

    Identity requires forgetting as well as remembering.

    A person who remembered every humiliation, contradiction and abandoned ambition with equal intensity might struggle to sustain any coherent sense of self. Cultures likewise depend upon selective memory.

    Digital technology weakens forgetting.

    Old photographs return automatically.

    Messages remain searchable.

    Embarrassments survive.

    Dead websites persist in archives.

    Abandoned communities remain indexed.

    Voices can be reconstructed.

    Images can be generated of people at ages they never reached.

    The dead increasingly leave behind interactive informational residues.

    We are entering a culture in which absence itself may become technologically difficult.

    The consequences may be profound.

    Traditional mourning depends partly upon the gradual transformation of presence into memory. Digital systems complicate that transition because traces can continue behaving as though presence persists.

    A dead person’s photographs can appear in automated reminders.

    Their account can remain contactable.

    Their voice may survive in recordings.

    Their written language may become sufficient to approximate a conversational persona.

    The cultural ghost approaches technical implementation.

    Again, the supernatural metaphor should not be confused with literal supernaturalism.

    But the emotional structure is ancient.

    The dead speak.

    The past answers.

    The image moves.

    The voice returns.

    The boundary between memory and encounter becomes uncertain.

    At this point personal hauntology, technological hyperstition and cultural identity converge.

    Human beings construct themselves through stories.

    Cultures construct themselves through stories.

    Stories generate imagined futures.

    Some futures influence behaviour and become real.

    Others fail and become ghosts.

    Those ghosts enter later stories.

    Later stories alter later behaviour.

    The cycle continues.

    Past and future are therefore not opposite directions.

    They are participating systems.

    The past provides materials from which futures are imagined.

    The future determines which parts of the past become significant.

    Fear concentrates attention upon certain possibilities.

    Fiction gives those possibilities form.

    Culture repeats the forms until they become familiar.

    Technology sometimes embodies them.

    Experience then appears to validate the fiction.

    Eventually the distinction between prediction, memory and design becomes difficult to locate.

    Perhaps that is the deeper social haunting of the twenty-first century.

    We inhabit environments crowded with unrealised futures, reconstructed pasts, digital doubles, artificial voices and stories that have escaped the conditions that created them.

    Our ghosts no longer need graveyards.

    They inhabit databases, interfaces, brands, ruins, archives, algorithms and expectations.

    And among them moves the most persistent apparition of all: the imagined coherent self, attempting to preserve a continuous identity while being constantly rewritten by memory, technology and culture.

    We are haunted by what happened.

    We are haunted by what did not happen.

    We are haunted by what we once believed would happen.

    And increasingly, we are haunted by futures that may be becoming real precisely because we imagined them first.

  • Novell NetWare

    Architecture, Administration, Operations, and Migration

    NetWare 3.12 through 6.5 SP8  |  Bindery, NDS/eDirectory, TFS, NSS, IPX, and native IP

    Version 1.0  |  8 August 2026

    For legacy operations, recovery, technical archaeology, and controlled migration

    Contents

    Select an entry in Word or a compatible viewer to jump to that section. Major sections begin on a new page for field use.

    How to use this reference

    Scope and conventions

    Support and security status

    Version families at a glance

    Compatibility questions to ask first

    Architecture and operating model

    The NetWare mental model

    Bindery versus NDS and eDirectory

    Core services stack

    Boot, configuration, and runtime

    Boot sequence

    NCF configuration files

    Safe boot and recovery switches

    NLMs and protected address spaces

    Networking and service discovery

    IPX and SPX environments

    Native IP and SLP environments

    Core ports and flows

    Client-to-file-service flow

    NDS and eDirectory administration

    Tree structure and naming

    Partitions, replicas, and replica rings

    Bindery emulation

    Time synchronization and directory health

    Directory administration tools

    Rights and security model

    File system trustee rights

    eDirectory object and property rights

    Effective rights and inherited rights filters

    Practical rights patterns

    File and directory attributes

    Storage, volumes, and file systems

    Traditional file system versus NSS

    NSS storage hierarchy

    Namespaces and path compatibility

    Salvage, purge, quotas, and capacity

    Repair boundaries

    Clients, drive mappings, and login scripts

    Client families

    Path syntax and mappings

    Login script execution order

    Login script example

    Administration quick reference

    Primary administration tools

    Console command quick reference

    Workstation utility quick reference

    Core NLM quick reference

    Illustrative NCF skeletons

    Operations runbook

    Daily, weekly, and monthly checks

    Controlled maintenance shutdown

    Change preparation checklist

    Troubleshooting playbooks

    Server will not start or SYS will not mount

    Clients cannot find a server

    Authentication or login script failure

    Access denied or files are invisible

    Slow response or high utilization

    Volume or pool is full

    Abend or repeated restart

    eDirectory synchronization errors

    Backup and disaster recovery

    What a usable backup must preserve

    Recovery rehearsal

    Printing and ancillary services

    Printing generations

    Other common services

    Containment, preservation, and migration

    Minimum containment pattern

    Migration sequence

    Virtualization and historical preservation

    Appendix A – Common paths and files

    Appendix B – Glossary

    Appendix C – Official source set

    How to use this reference   Back to contents

    This is a practical reference for engineers who must understand, recover, operate, or retire a Novell NetWare environment. It is not a replacement for the manual matching the exact server version, support pack, hardware driver set, eDirectory build, and installed applications.

    WORKING ASSUMPTION: The operational detail is centered on NetWare 4.x through 6.5, while NetWare 3.12 and Bindery behavior are called out where they differ. Commands marked as examples must be validated on the target server before use.

    Scope and conventions   Back to contents

    1. Server-console commands appear in uppercase for readability; NetWare commands are generally not case-sensitive.
    2. A path such as SYS:SYSTEM identifies a volume and directory. A path such as SERVER/SYS:PUBLIC also identifies the server.
    3. NDS refers to Novell Directory Services; later documentation uses eDirectory. In this guide, NDS/eDirectory means the directory service family.
    4. TFS means the NetWare Traditional File System. NSS means Novell Storage Services.
    5. Source markers such as [S2] refer to the official source set in Appendix C.

    Support and security status   Back to contents

    NetWare 6.5 SP8 is the terminal NetWare release line. It entered extended support in 2010, and the vendor’s later Premium Lifeline offering ended on 31 December 2016. It must therefore be treated as unsupported legacy infrastructure in 2026. [S1, S13]

    SECURITY BOUNDARY: Do not expose NCP, SLP, IPX routing, Telnet, RConsoleJ, legacy web administration, LDAP, or old TLS endpoints directly to the Internet or to an untrusted enterprise segment. Place the server behind an allow-list firewall on an isolated VLAN and administer it through a controlled jump host or modern encrypted tunnel.

    • Use unique legacy credentials; do not reuse current privileged passwords.
    • Disable services and protocols that are not required, particularly Telnet, IPX, anonymous LDAP, and legacy web components.
    • Keep ALLOW UNENCRYPTED PASSWORDS set to OFF unless a documented, temporary compatibility exception exists. [S2]
    • Assume that old cryptographic implementations and browser-based interfaces do not meet modern security baselines.
    • Capture configuration and recovery media before every change because replacement drivers, patches, and vendor support are scarce.

    Version families at a glance   Back to contents

    Version family summary

    FamilyDirectory modelNetwork emphasisOperational significance
    2.xPer-server BinderyIPX/SPXDedicated 286-era file server; highly version- and hardware-specific.
    3.x / 3.12Per-server BinderyIPX/SPX with SAP/RIP32-bit 386 line; NLM model; mature departmental file and print platform.
    4.x / intraNetWareNDS tree plus Bindery emulationIPX/SPX; IP add-onsIntroduced global directory, partitions, replicas, and directory-based administration.
    5.0 / 5.1NDSNative IP plus optional IPXNCP became transport-independent; SLP and NSS became central; multiprocessor and memory model advanced. [S14]
    6.0eDirectoryIP preferred; IPX optionalExpanded web access, iPrint/iFolder era services, and user-oriented licensing.
    6.5 / SP8eDirectory 8.7.3 or 8.8.xIP preferred; IPX retainedFinal mature NetWare line. New SP8 installs used eDirectory 8.8.4; updated systems could retain 8.7.3. [S1]
    OES / Enterprise ServereDirectory on LinuxIPSuccessor platform providing NCP, NSS, trustee semantics, CIFS, iPrint, and migration paths without the NetWare kernel. [S12]

    Compatibility questions to ask first   Back to contents

    1. What exact NetWare version, support pack, eDirectory version, JVM, and application build are installed?
    2. Is the server Bindery-only, NDS/eDirectory-native, or serving legacy clients through Bindery emulation?
    3. Are clients using IPX, native IP, or both? Which Ethernet frame types and SLP scopes are in use?
    4. Are volumes Traditional or NSS? Which namespaces, trustee assignments, quotas, compression, encryption, and salvage policies exist?
    5. Does the server hold directory partitions or replicas, and is it a Master replica, time source, SLP Directory Agent, Organizational CA host, licensing host, or cluster node?
    6. Which third-party NLMs, backup agents, database engines, and hardware-specific .HAM, .CDM, .LAN, and .PSM drivers are required?
    7. Are licenses, installation media, overlay media, support packs, driver disks, and keys preserved and legally usable?

    Architecture and operating model   Back to contents

    The NetWare mental model   Back to contents

    NetWare is a network services operating system, not a general-purpose desktop Unix or Windows server. The kernel is optimized around file, print, directory, protocol, and application services. Administrators interact with a server console and loadable modules; users interact through NCP clients, mappings, login scripts, and directory objects.

    Logical layers

    LayerExamplesRole
    ClientsDOS requester, VLM, Client32, Novell Client, NetStorageAuthenticate, discover services, map paths, consume file/print services.
    DirectoryBindery or NDS/eDirectoryStores identities, groups, servers, volumes, policies, schema, and service objects.
    Application/file serviceNCP, queue print, NDPS/iPrint, GroupWise, BtrievePresents network resources and application services.
    Discovery and transportSAP/RIP over IPX; SLP over IP; TCP/UDPLocates services and carries NCP or application traffic.
    File systemTraditional volumes or NSS pools and volumesStores data, trustees, attributes, quotas, namespaces, and salvage metadata.
    RuntimeSERVER.EXE, NLMs, protected address spacesExecutes kernel services, drivers, protocol stacks, and server applications.
    Hardware interfacePSM, HAM, CDM, LAN drivers, NWPAConnects processors, storage, and network adapters to the runtime.

    KEY DISTINCTION: An eDirectory Volume object represents a volume in the directory, but file access is governed by trustee metadata stored in the file system. Directory rights and file-system rights are related administration domains, not interchangeable ACLs. [S8]

    Bindery versus NDS and eDirectory   Back to contents

    Directory model comparison

    CharacteristicBinderyNDS/eDirectory
    ScopeOne database per serverDistributed tree spanning servers and sites
    NamingFlat object names on a selected serverHierarchical distinguished names in containers
    AdministrationRepeat users/groups on each serverCreate identities and policies once in the tree
    ResilienceServer-local backup and recoveryPartitions and replicas provide distributed availability
    Legacy supportNative to 2.x/3.x4.x+ can expose selected containers as a Bindery context
    Authentication targetServerTree and context, with a server used to reach a replica

    Core services stack   Back to contents

    1. NCP provides file-service semantics, connection management, locking, trustee enforcement, and related client services.
    2. NDS/eDirectory provides identities, objects, schema, authentication, partitions, and replication.
    3. NSS provides a journaling file system, storage pools, volumes, trustee metadata, salvage, quotas, compression, and optional encryption.
    4. IPX/SPX with SAP/RIP supplies legacy transport and discovery; TCP/IP with SLP supplies the later native-IP equivalent.
    5. NLMs extend the kernel with drivers, protocol stacks, management tools, backup agents, and server applications.

    Boot, configuration, and runtime   Back to contents

    Boot sequence   Back to contents

    1. The machine firmware starts the boot device and the small DOS boot environment used by classic NetWare installations.
    2. AUTOEXEC.BAT normally changes to C:\NWSERVER and invokes SERVER.EXE.
    3. SERVER.EXE reads STARTUP.NCF from the boot directory, applies pre-mount SET parameters, and loads platform and storage drivers.
    4. The server discovers storage and mounts SYS. If SYS cannot mount, SYS:SYSTEM modules and AUTOEXEC.NCF are unavailable.
    5. SYS:SYSTEM\AUTOEXEC.NCF executes, setting the server identity and loading LAN drivers, protocols, directory services, logging, and installed applications.
    6. Additional service-specific NCF files are called in their configured order. Users and clients can then discover and connect to the server.

    RECOVERY PRINCIPLE: Separate pre-SYS failures from post-SYS failures. STARTUP.NCF, platform support, and storage drivers dominate the first class. AUTOEXEC.NCF, network bindings, directory services, and application NLMs dominate the second.

    NCF configuration files   Back to contents

    Important NCF files

    FileNormal locationPurpose
    STARTUP.NCFC:\NWSERVERPre-SYS parameters plus platform and storage driver load order.
    AUTOEXEC.NCFSYS:SYSTEMServer identity, network drivers/bindings, services, and application start order.
    SHUTDOWN.NCFSYS:SYSTEMOptional orderly unload or stop commands run by DOWN or restart. [S2]
    SECURE.NCFConfigured locationOptional commands executed through the secure-start mechanism.
    Application .NCFUsually SYS:SYSTEM or application pathStarts or stops a product-specific set of NLMs.
    • Use EDIT or NWCONFIG to change NCF files, and retain a dated known-good copy before editing.
    • Place CONLOG near the beginning of AUTOEXEC.NCF if early console messages are needed; the default log is SYS:ETC\CONSOLE.LOG. [S2]
    • Only persist a SET parameter after confirming whether it belongs in STARTUP.NCF or AUTOEXEC.NCF. The SET display identifies valid locations. [S2]
    • Do not reorder storage, directory, or application modules without documenting dependencies.

    Safe boot and recovery switches   Back to contents

    SERVER and restart switches

    InvocationEffectUse
    SERVER -NSSkips STARTUP.NCFDiagnose a bad pre-mount parameter or driver line; storage may need loading manually.
    SERVER -NASkips AUTOEXEC.NCFMount SYS but prevent post-mount services and applications from starting.
    SERVER -S filename.NCFUses an alternate startup fileBoot a controlled known-good driver set. [S1, S2]
    RESTART SERVER -NSRestarts without STARTUP.NCFRepeat controlled pre-mount diagnosis.
    RESTART SERVER -NARestarts without AUTOEXEC.NCFRepeat controlled post-mount diagnosis.

    BEFORE REPAIR: Photograph or capture the console, preserve BOOT$LOG.ERR, CONSOLE.LOG, ABEND.LOG, STARTUP.NCF, AUTOEXEC.NCF, driver versions, and disk layout. Do not begin with VREPAIR, REBUILD, or DSREPAIR repair operations merely because the server failed to boot.

    NLMs and protected address spaces   Back to contents

    LOAD links an NLM or driver into the operating system; UNLOAD releases it and returns resources. Many server utilities can be loaded when needed, while LAN, storage, directory, and protocol modules form persistent dependencies. MODULES lists loaded modules and their address spaces. [S2, S3]

    1. Kernel address space provides maximum integration but a faulty NLM can abend the server.
    2. Protected address spaces run suitable applications in ring 3. PROTECT filename.NCF loads the modules from an NCF into a named protected space.
    3. PROTECTION lists protected spaces and can enable restart behavior. Drivers, SERVER.EXE, and some core modules cannot run protected.
    4. Unload dependent modules in reverse order. Never force-kill an address space until the data-integrity and vendor implications are understood.

    Networking and service discovery   Back to contents

    IPX and SPX environments   Back to contents

    Legacy IPX/SPX components

    ComponentFunctionDiagnostic focus
    IPXConnectionless routed network protocolNetwork numbers, frame types, bindings, routes
    SPXConnection-oriented transport over IPXSessions, sequence/retry behavior, compatible stack
    SAPAdvertises server and service namesDISPLAY SERVERS; hop count; filtering
    RIP/NLSPRoutes IPX networksDISPLAY NETWORKS; duplicate network numbers; convergence
    NCP/IPXCarries NetWare file and service requestsNCPIPX.NLM, connection state, packet loss
    ODIClient LAN driver and protocol interfaceLSL, NIC driver, frame type, IPXODI/VLM order

    Common Ethernet frame types include ETHERNET_802.2, ETHERNET_II, ETHERNET_802.3, and ETHERNET_SNAP. A client and server can share the physical Ethernet while remaining logically invisible if frame type or external network numbers do not match.

    IPX DISPLAY CAVEAT: DISPLAY SERVERS and DISPLAY NETWORKS show SAP/RIP information. They are not native-IP service-discovery commands; use SLP and TCP/IP tools for IP-only systems. [S2]

    Native IP and SLP environments   Back to contents

    NetWare 5 made NCP transport-independent and introduced a practical pure-IP deployment model. NCP over TCP/UDP uses native IP, while Service Location Protocol (SLP) replaces much of the name-to-address discovery previously supplied by SAP. [S3, S14]

    1. SLP User Agents issue queries, Server Agents register services, and Directory Agents provide a repository for registrations.
    2. Named SLP scopes partition discovery information. A server or client that queries the wrong scope can appear unable to find an otherwise healthy service.
    3. SLP uses TCP and UDP port 427. NCP over IP uses port 524. [S14]
    4. SYS:ETC\SLP.CFG can define static Directory Agents with DA IPV4 entries; DHCP options 78 and 79 can also supply agents and scopes.
    5. Directory replication can be affected when NDAP and Bindery service entries are absent from the scopes used by replica servers.

    Core ports and flows   Back to contents

    Common TCP/UDP ports – verify against the installed service configuration

    PortProtocol/serviceOperational note
    524 TCP/UDPNCP over IP / eDirectory service accessPrimary Novell client and server service path.
    427 TCP/UDPSLPService queries, registrations, and Directory Agent traffic.
    389 TCPLDAPDirectory access; clear-text unless protected externally or upgraded to TLS.
    636 TCPLDAPSDirectory access over legacy TLS; validate certificate and cipher compatibility.
    123 UDPNTPTime synchronization when XNTPD/NTP is selected.
    53 TCP/UDPDNSName service when DNS is hosted or consumed.
    80/443 TCPApache, iManager, NetStorage, iPrint or application web servicesActual bindings vary by installed pattern and reverse proxy design.
    8008/8009 TCPNovell Remote Manager, commonlyVersion/configuration dependent; never expose to an untrusted segment.
    413 TCPSMDR, commonlyStorage Management Services remote backup communication. [S3]
    2034-2036 TCPRConsoleJ agent/proxy variantsHistorical remote console ports; firewall-only and version dependent. [S2]

    FIREWALL RULE METHOD: Inventory listening modules and configured bindings on the actual server, capture a known-good traffic trace, then allow only required source/destination pairs. Do not use a generic ‘NetWare ports’ rule set as an exposure baseline.

    Client-to-file-service flow   Back to contents

    1. The client obtains a server or tree target from a preferred server, preferred tree, explicit name, SLP, SAP, DNS, or cached configuration.
    2. The client resolves the service to an IP or IPX address and opens an NCP connection.
    3. The user authenticates to the Bindery server or to NDS/eDirectory through a server holding or locating the required replica.
    4. Container, profile, and user login scripts execute and create drive/search mappings.
    5. NCP evaluates trustee rights, IRFs, security equivalence, file attributes, locks, quotas, and namespace rules for each operation.

    NDS and eDirectory administration   Back to contents

    Tree structure and naming   Back to contents

    Common eDirectory objects

    ObjectPurposeTypical relationship
    [Root]Top of one directory treeContains top-level organizations and holds the root partition.
    O / OrganizationTop-level administrative containerOften represents the enterprise.
    OU / Organizational UnitDelegation and policy containerOften represents geography, function, or service domain.
    UserIdentity and login propertiesMember of groups; may have home directory and login script.
    GroupSecurity equivalence and shared assignmentUsed for file trustees and application roles.
    ServerRepresents a serverAssociated with volumes, addresses, services, and directory replicas.
    VolumeDirectory representation of a volumePoints users and tools to file storage; data rights remain in the file system.
    ProfileReusable login scriptAssigned to users between container and user scripts.
    Alias / Directory MapAlternate object name or path abstractionReduces path coupling and supports user-friendly mappings.

    Typed name:     CN=PJONES.OU=ARCHITECTURE.O=ACME
    Typeless name:  PJONES.ARCHITECTURE.ACME
    Absolute name:  .PJONES.ARCHITECTURE.ACME
    Relative name:  PJONES   (when the current context is ARCHITECTURE.ACME)

    Dot notation is written from the leaf toward [Root]. LDAP notation normally reverses the order and separates components with commas, for example CN=PJONES,OU=ARCHITECTURE,O=ACME.

    Partitions, replicas, and replica rings   Back to contents

    • A partition is a contiguous subtree stored and replicated as a unit.
    • The Master replica coordinates partition operations. Read/Write replicas accept updates; Read-Only replicas serve reads; Subordinate Reference replicas preserve connectivity across partition boundaries.
    • All servers holding a replica of a partition form its replica ring. A healthy ring exchanges changes and agrees on partition and replica metadata.
    • Partitions improve scale and locality; replicas improve availability. Excessive partitioning or poorly placed replicas increase synchronization and WAN complexity.
    • The first servers in a new tree normally receive root-partition replicas; later placement should be planned around site availability and directory dependencies. [S7]

    MASTER IS NOT PRIMARY: Ordinary object writes can occur on writable replicas. The Master is special for partition and replica operations; it is not a single writable directory server in the Active Directory PDC sense.

    Bindery emulation   Back to contents

    NetWare 4.x and later can present selected NDS/eDirectory containers to Bindery-aware clients and applications. The BINDERY CONTEXT SET parameter identifies up to 16 containers, separated by semicolons, whose objects are exposed through Bindery services. [S2]

    SET BINDERY CONTEXT = OU=SALES.O=ACME;OU=ACCOUNTING.O=ACME

    1. The specified containers must be available on the server through local directory replicas or references.
    2. Bindery-aware applications see a flat view and can encounter duplicate short names across contexts.
    3. Changing the Bindery context is a compatibility change; test authentication, print, backup, and application dependencies.

    Time synchronization and directory health   Back to contents

    Directory operations depend on coherent timestamps. Official health procedures call for time checks, replica synchronization checks, schema checks, and review of obituaries and directory versions. A dynamic tree should be checked about weekly; a static tree about monthly, and every tree before a major directory operation. [S10]

    LOAD DSREPAIR
      Time Synchronization
      Report Synchronization Status

    SET DSTRACE=ON
    SET DSTRACE=NODEBUG
    SET DSTRACE=+S
    SET DSTRACE=*H
      Expected healthy indicator: All Processed = Yes
    SET DSTRACE=NODEBUG
    SET DSTRACE=OFF

    DO NOT REPAIR BY REFLEX: DSREPAIR is both a diagnostic and a repair tool. Start with time, version, replica, and synchronization reports. Preserve a supported directory backup and understand the replica ring before initiating destructive or topology-changing repair options.

    Directory administration tools   Back to contents

    Directory tool map

    ToolBest useCaution
    NWAdminClassic Windows NDS object administrationSnap-ins and behavior are version specific.
    ConsoleOneCross-platform objects, schema, rights, and product snap-insJava/runtime dependencies can be fragile.
    iManagerBrowser-based role and task administrationOld TLS and plug-ins require isolation and compatible browser/runtime.
    iMonitorDirectory health, partitions, replicas, agents, tracesDiagnostic visibility can expose sensitive directory data.
    DSREPAIRTime, replica, database, and synchronization diagnostics/repairUse health reports first; repairs can alter directory state.
    DSTRACELive directory process and synchronization traceFilters can be noisy; capture to file and disable when finished.

    Rights and security model   Back to contents

    File system trustee rights   Back to contents

    File and directory trustee rights

    CodeRightMeaning
    SSupervisorAll file-system rights; cannot be blocked by an IRF.
    RReadOpen and read files.
    WWriteModify file contents.
    CCreateCreate files/subdirectories; supports salvage semantics where applicable.
    EEraseDelete files and directories.
    MModifyRename items and change file or directory attributes.
    FFile ScanSee and search names in the file-system structure.
    AAccess ControlAdd/remove trustees and change trustee rights and IRFs.

    The workstation RIGHTS utility displays or changes assignments. ALL grants all rights except Supervisor. A plus adds rights, a minus removes rights, and a rights list without plus/minus replaces the assignment. [S2]

    RIGHTS SYS:DATA R W C E M F /NAME=.TEAM_ARCHITECTURE.ACME
    RIGHTS SYS:DATA /NAME=.PJONES.ARCHITECTURE.ACME /I
    RIGHTS SYS:DATA /T
    RIGHTS SYS:DATA REM /NAME=.OLDGROUP.ACME

    eDirectory object and property rights   Back to contents

    eDirectory rights

    ClassRightMeaning
    ObjectSupervisorAll rights to the object and its properties.
    ObjectBrowseSee the object; does not reveal its property values.
    ObjectCreateCreate objects beneath a container; includes Browse.
    ObjectDeleteDelete the target object.
    ObjectRenameChange the target object’s name.
    PropertySupervisorComplete control over the selected property.
    PropertyCompareTest a value without reading it.
    PropertyReadRead property values; includes Compare.
    PropertyWriteCreate, change, or delete property values.
    PropertyAdd SelfAdd/remove the trustee itself in object-valued properties such as group membership.

    SENSITIVE DELEGATION: Broad Read access to all User attributes can expose password-management attributes in some eDirectory configurations. Delegate only the object and property rights required for the task. [S8]

    Effective rights and inherited rights filters   Back to contents

    Effective rights are the rights available at the moment of access after NetWare/eDirectory combines explicit trustee assignments, group membership, security equivalence, inherited assignments, and the applicable IRFs. [S8]

    1. An IRF removes selected rights as they flow down a directory or file-system hierarchy.
    2. A lower explicit trustee assignment can add required rights back at the target level.
    3. File-system Supervisor cannot be filtered by a file-system IRF; assign it sparingly.
    4. An apparent rights failure can instead be a visibility failure: File Scan is required to see names, and Read is required to open content.
    5. Check the user’s direct assignment, group assignments, security equivalences, IRFs along the path, the target’s explicit assignment, and file attributes.

    Practical rights patterns   Back to contents

    Common assignment patterns

    Use caseSuggested trustee patternNotes
    Home directoryUser: R W C E M F; administrator group: SSet at each home root or through automated provisioning; protect parent visibility.
    Shared read-only dataReader group: R FRead alone is insufficient for useful browsing; File Scan exposes names.
    Shared working areaContributor group: R W C E M FExclude Access Control unless users must delegate rights.
    Drop boxPurpose-built rights and visibility designTest create, read-back, overwrite, rename, delete, and listing behavior separately.
    Delegated folder ownerR W C E M F AAccess Control permits trustee/IRF changes; does not confer Supervisor.
    Service accountDedicated group with minimum path-specific rightsAvoid security equivalence to Admin or broad container-level Supervisor.

    File and directory attributes   Back to contents

    Common attributes

    AttributeEffect / use
    Read OnlyPrevents file modification; older implementations may also imply rename/delete protection.
    ArchiveMarks a file as changed for archive-aware backup workflows.
    Hidden / SystemControls client visibility and marks operating-system content.
    ShareablePermits compatible shared access semantics.
    TransactionalEnables transaction tracking where supported.
    Purge ImmediateDeletes without retaining a salvageable copy.
    Rename InhibitPrevents renaming.
    Delete InhibitPrevents deletion.
    Copy InhibitRestricts copying where supported by the client/protocol path.

    Attribute support varies between Traditional and NSS volumes and between access protocols. A change is effective only when the underlying file system and NCP path can enforce it. [S6]

    Storage, volumes, and file systems   Back to contents

    Traditional file system versus NSS   Back to contents

    File-system comparison

    CharacteristicTraditional file systemNSS
    StructureNetWare partition containing one or more volumesDevices/partitions feed pools; pools contain logical volumes
    RecoveryVREPAIR on an unmounted volumeVERIFY/REBUILD and NSS-specific tools; VREPAIR is not used
    Mount behaviorDirectory/FAT structures can make large-volume recovery slowJournaling and modern metadata support faster activation
    Capacity modelFixed allocation within the NetWare partitionVolumes allocate pool space dynamically and can be overbooked
    NamespacesDOS plus added LONG/MAC/NFS namespacesMultiple namespaces integrated into NSS semantics
    Advanced featuresTrustees, salvage, compression on supported versionsTrustees, quotas, salvage, compression, snapshots/DFS options, encryption
    MigrationRequires metadata-aware copy and namespace planningDesigned for compatibility with OES NSS and NCP services

    NSS storage hierarchy   Back to contents

    1. Physical disks, SAN LUNs, RAID devices, virtual disks, or multipath devices are presented as storage devices.
    2. NSS partitions or segments allocate device space to one or more pools.
    3. A pool aggregates space and can span devices. Its failure domain therefore includes every device contributing segments.
    4. One or more NSS volumes allocate space from a pool only as needed. A volume belongs to one pool; a pool can contain multiple volumes.
    5. NCP, CIFS, AFP, NetStorage, and application services expose the volume through their configured identity and trustee model.

    NetWare 6.5 NSS supports dynamic volume growth within a pool and overbooking. The official guide describes volumes up to 8 TB and very large file counts, while individual devices presented to NetWare NSS are limited to 2 TB. Verify the exact build, device carving, and storage vendor limits before expansion. [S5]

    POOL FAILURE DOMAIN: Spanning a pool across devices increases capacity but also couples availability. Hardware RAID, NSS mirroring, SAN protection, multipathing, and backup are different controls; document which layer actually protects each segment.

    Namespaces and path compatibility   Back to contents

    A namespace records names and metadata for a client environment. Traditional volumes begin with DOS semantics and can add LONG for Windows/OS2, MAC for Macintosh, and NFS for Unix-style names. [S2]

    LOAD LONG.NAM
    ADD NAME SPACE LONG TO DATA

    REM Equivalent choices exist for MAC and NFS where the modules are installed.

    • Do not remove a namespace until every file name and metadata dependency has been assessed.
    • Migration tools may require the NFS namespace on a Traditional source volume to preserve names and metadata correctly.
    • Case, forbidden characters, alternate data, Macintosh metadata, and long-name collisions must be tested against the destination protocol.

    Salvage, purge, quotas, and capacity   Back to contents

    • Salvage retains deleted files until they are restored, purged, or reclaimed according to policy. It is not a backup because it shares the same volume and failure domain.
    • Purge permanently removes salvageable files. PURGE IMMEDIATE bypasses recovery for selected files/directories.
    • NSS can enable salvage per volume; NSS console commands include NSS /SALVAGE=volume and NSS /NOSALVAGE=volume. [S2, S5]
    • User, directory, and volume quotas control consumption. Always check the pool as well as the logical volume: an overbooked pool can exhaust physical space before volume quotas appear full.
    • Keep SYS for operating-system and extension content where practical; place user data and applications on separate pools/volumes. [S5]

    Repair boundaries   Back to contents

    Repair decision table

    TargetDiagnostic / repair familyBoundary
    Traditional volumeVOLUME/VOLUMES, MONITOR, VREPAIRDismount before VREPAIR; preserve logs and backup first.
    NSS volume/poolNSS /STATUS, NSSMU, VERIFY/REBUILD, iManager/NRMDo not use VREPAIR; confirm pool/device state before metadata repair.
    eDirectoryiMonitor, DSREPAIR, DSTRACEDirectory repair is separate from volume repair; start with health checks.
    Hardware/storage pathNWPA/driver tools, vendor array, mirror/RAID statusFile-system repair cannot correct a failing controller, path, or LUN.
    Application dataVendor consistency and recovery toolsA mounted volume does not prove a database or message store is consistent.

    Clients, drive mappings, and login scripts   Back to contents

    Client families   Back to contents

    Client generations

    ClientTypical environmentKey components / notes
    NETX requesterEarly DOS / BinderySmall conventional-memory requester; server-centric login.
    VLM clientDOS / NDSLSL + ODI LAN driver + IPXODI + VLM modules; NDS-aware.
    Client32Windows 3.x/9x32-bit client stack, NDS login, improved cache and transport support.
    Novell ClientWindows NT through supported later Windows releasesNCP, eDirectory authentication, SLP, mappings, trustee extensions.
    Novell Client for LinuxLinux workstationsNCP and eDirectory integration; some login-script commands differ.
    NetStorageBrowser/WebDAV-style accessInterprets selected MAP and conditional login-script commands.
    CIFS/AFP/NFSNative OS accessProtocol-specific identity mapping and metadata semantics; not identical to NCP.

    Path syntax and mappings   Back to contents

    Path examples

    FormExampleMeaning
    Current serverSYS:PUBLICPUBLIC directory on SYS of the current/default server.
    Server qualifiedNW65LAB/SYS:PUBLICPUBLIC on SYS of server NW65LAB.
    Object qualified.DATA.NW65LAB.SERVERS.ACME:PROJECTSDirectory under a Volume object identified from [Root].
    Drive mappingMAP G:=NW65LAB/DATA:PROJECTSMap G to the explicit server/volume path.
    Home mappingMAP H:=%HOME_DIRECTORYMap from the user’s eDirectory Home Directory property.
    Search driveMAP INS S1:=SYS:PUBLICInsert a program search mapping without replacing existing search drives.
    Fake rootMAP ROOT F:=SERVER/VOL:APPPresent APP as the apparent root for a legacy application.

    Login script execution order   Back to contents

    1. The container login script runs first and establishes defaults for users in that O or OU.
    2. The assigned Profile object’s login script runs next and adds role- or team-specific mappings.
    3. The User object’s login script runs last and can override earlier mappings.
    4. If the user has no user login script, the built-in default login script runs unless NO_DEFAULT was issued by a container or profile script. [S9]
    5. Prefer reusable container and profile scripts; reserve user scripts for true exceptions.
    6. Use IF MEMBER OF to drive group-based mappings, INCLUDE for shared text scripts, and MAP DISPLAY OFF/ON for clean output.
    7. The last conflicting MAP wins. Diagnose the full chain rather than only the user script.

    Login script example   Back to contents

    REM Container/Profile example – validate names and client behavior
    MAP DISPLAY OFF
    MAP ERRORS OFF
    MAP INS S1:=NW65LAB/SYS:PUBLIC
    MAP H:=%HOME_DIRECTORY

    IF MEMBER OF “.TEAM_ARCHITECTURE.ACME” THEN
      MAP G:=NW65LAB/DATA:ARCHITECTURE
    END

    IF MEMBER OF “.NETWARE_ADMINS.ACME” THEN
      MAP M:=NW65LAB/SYS:SYSTEM
    END

    MAP ERRORS ON
    MAP DISPLAY ON
    MAP

    TEST MATRIX: Test login scripts with each supported client family, transport, context, roaming site, and group combination. A script that works in the Windows Novell Client may be only partially implemented by the Linux client or NetStorage. [S9]

    Administration quick reference   Back to contents

    Primary administration tools   Back to contents

    Administration tool map

    ToolRuns atPrimary job
    System ConsoleServerCore commands, screen switching, NLM control, boot and emergency operation.
    MONITORServer consoleConnections, CPU, memory, service processes, storage, LAN statistics, SET parameters.
    NWCONFIGServer consoleDrivers, products, NCF editing, installation options, traditional volume tasks.
    INETCFG / TCPCONServer consoleProtocol configuration and live TCP/IP status/statistics.
    NSSMUServer consoleNSS devices, partitions, pools, volumes, RAID, and attributes.
    Novell Remote ManagerWeb browserHealth, console, modules, connections, volumes, parameters, logs, diagnostics. [S11]
    iManagerWeb browserRole-based eDirectory, NSS, files, rights, certificates, and service administration.
    ConsoleOne / NWAdminWorkstation or server GUIDirectory objects, schema, rights, login scripts, and product snap-ins.

    Console command quick reference   Back to contents

    Common server-console commands

    CommandPurposeNotes
    HELP [command] / HELP ALLShow console command helpPrefer local help because loaded modules register additional commands.
    VERSIONShow NetWare, support pack, license, and eDirectory versionsRecord before any change.
    CONFIGShow server, LAN, IPX, tree, and Bindery context informationUseful hardware/network baseline.
    TIMEShow server timeCompare with directory time sources.
    MODULES [prefix*]List loaded modules and address spacesUse before unload or abend analysis.
    SEARCHShow or modify NLM search pathsUnexpected paths can load the wrong module version.
    MEMORYShow installed/addressable memoryUse NRM for deeper attribution.
    DISPLAY PROCESSORSShow processor online/offline stateNetWare 5/6 multiprocessor environments.
    DISPLAY ENVIRONMENTShow search paths and SET parametersDISPLAY MODIFIED ENVIRONMENT shows deviations only.
    SETBrowse or change server parametersConfirm valid range and persistence file.
    MONITOROpen live system monitorConnections, resources, parameters, storage, LAN.
    LOAD / UNLOADLink or unlink an NLM or driverRespect dependencies and application shutdown procedure.
    PROTECT file.NCFLoad an NCF into a protected address spaceOnly for compatible modules.
    PROTECTIONList/configure protected spacesCan enable restart behavior.
    MOUNT volume / MOUNT ALLMount volumesUse NSS tools for NSS-specific activation issues.
    DISMOUNT volumeMake a volume unavailableClose files and stop dependent applications first.
    VOLUME / VOLUMESList mounted volumesSpelling varies by release/module registration.
    NSS /STATUS / NSS /HELPShow NSS state and helpNSS commands are version specific.
    NSSMUOpen NSS management utilityDestructive functions can erase device metadata.
    NWCONFIGOpen server configurationDriver/product/NCF and traditional storage tasks.
    INETCFG / TCPCONConfigure or monitor networkingSave before restart; distinguish configuration from live state.
    PING / TPINGTest IP reachabilityTPING syntax and implementation vary.
    DISPLAY SERVERSList SAP-advertised IPX servicesNot an IP/SLP discovery test.
    DISPLAY SLP …Show SLP agents, services, addresses, or typesExact subcommands depend on SLP.NLM build.
    DSREPAIRDirectory diagnostics and repairStart with time and sync reports.
    SET DSTRACE=…Control directory traceDisable filters/logging when complete.
    CONLOGCapture console messagesDefault SYS:ETC\CONSOLE.LOG; load early.
    DISABLE LOGIN / ENABLE LOGINControl new loginsExisting connections remain until cleared or logged out.
    SECURE CONSOLERestrict console operationsLoad required nonstandard-path modules first. [S2]
    DOWNOrderly shutdownFlushes caches, closes files, executes SHUTDOWN.NCF.
    RESTART SERVER [-NA|-NS]Orderly NetWare restartUse diagnostic switches deliberately.

    Workstation utility quick reference   Back to contents

    Common client/workstation utilities

    UtilityPurposeExample
    LOGINAuthenticate and execute login scriptsLOGIN TREE/USER or LOGIN SERVER/USER
    LOGOUTClose authenticated connectionsLOGOUT or client GUI equivalent
    MAPView/create/delete drive and search mappingsMAP G:=SERVER/VOL:PATH
    CXView/change eDirectory contextCX /T /A
    RIGHTSView/change file trustees, rights, IRF, and sourcesRIGHTS path /NAME=user /I
    FLAGView/change file or directory attributesSyntax varies; prefer client property page for safety
    SALVAGE / PURGERestore or permanently remove deleted filesUse client GUI or matching release utility
    CAPTURE / NPRINTLegacy queue-based print redirection/submitVersion and client dependent

    Core NLM quick reference   Back to contents

    Common modules – not exhaustive

    ModuleRoleOperational warning
    DS.NLMNDS/eDirectory engineDirectory-dependent services and authentication rely on it.
    NCP.NLM / CONNMGR.NLMCore NCP and connection servicesFoundation for client file service.
    NCPIP.NLMNCP over TCP/UDPUnloading removes IP NCP access. [S3]
    NCPIPX.NLMNCP over IPXLegacy transport; not intended for casual unload after activation.
    TCPIP.NLMTCP/IP stackLarge dependency tree; use INETCFG/TCPCON.
    IPXSPX.NLMIPX/SPX stackRequired by legacy IPX clients/services.
    SLP.NLM / SLPDA.NLMIP service discovery / Directory AgentScopes and directory replicas affect availability.
    NSS.NLMNovell Storage ServicesDo not unload with active NSS volumes or dependent services.
    NWPA.NLMStorage driver architectureHAM/CDM storage access depends on it. [S3]
    MONITOR.NLMSystem monitoringCan be loaded and unloaded as a utility.
    NWCONFIG.NLMServer configurationInstallation and driver operations can alter NCF files.
    DSREPAIR.NLMDirectory diagnostics/repairRepairs can change replicated state.
    CONLOG.NLMConsole loggingConfigure rotation; unlimited logs can consume SYS.
    PORTAL.NLM / HTTPSTK.NLMRemote Manager and HTTP stackLegacy web/TLS exposure requires containment.
    TIMESYNC.NLM / XNTPD.NLMTime synchronizationUse one planned time model; eDirectory depends on stable time.
    SMDR.NLM / TSAFS.NLM / SBCON.NLMStorage Management Services backupCoordinate application and directory-aware backup.
    SNMP.NLMMonitoring agentLegacy community-based SNMP is not suitable across untrusted networks.

    Illustrative NCF skeletons   Back to contents

    NOT PASTE-READY: Driver names, load order, bindings, addresses, and SET parameters must come from the target server’s known-good configuration and matching manuals. The skeletons show separation of concerns only.

    REM C:\NWSERVER\STARTUP.NCF – schematic only
    REM Pre-mount SET parameters validated for this exact release
    SET <pre-mount parameter> = <validated value>
    REM Platform, storage adapter, and device modules from known-good media
    LOAD <platform>.PSM
    LOAD <adapter>.HAM <validated parameters>
    LOAD <device>.CDM

    REM SYS:SYSTEM\AUTOEXEC.NCF – schematic only
    FILE SERVER NAME <SERVERNAME>
    LOAD CONLOG ARCHIVE=YES MAXIMUM=<validated-kilobytes>
    REM Load/bind LAN and protocols or invoke generated network configuration
    <known-good network configuration>
    REM Start directory, discovery, storage, management, and applications
    <service-specific NCF files>
    MOUNT ALL

    REM SYS:SYSTEM\SHUTDOWN.NCF – schematic only
    REM Stop application services in reverse dependency order
    <application stop commands>
    REM Flush/close product-specific engines before DOWN completes

    Operations runbook   Back to contents

    Daily, weekly, and monthly checks   Back to contents

    Operational cadence

    CadenceChecksEvidence to retain
    DailyServer up time; health summary; ABEND.LOG; SYS/pool free space; mirror/RAID/path state; backup completion; time state; critical service availabilityAlert record, console/health snapshot, backup result
    WeeklyDirectory sync for dynamic trees; CONSOLE.LOG and SYS$LOG.ERR review; NLM/application errors; packet buffers; LAN errors; salvage growth; sample restoreDSTRACE/DSREPAIR report, capacity trend, restore evidence
    MonthlyDirectory health for static trees; replica and partition inventory; DS versions; schema/obituary status; account review; recovery media and cold-image verificationSigned health report and configuration archive
    Before major changeFull directory health check; application-consistent backup; boot/config export; driver/media check; rollback rehearsal; maintenance communicationsChange record, hash/manifest, rollback decision point

    Controlled maintenance shutdown   Back to contents

    1. Confirm a current usable backup and record the current VERSION, up time, active modules, volume/pool status, mirror/RAID state, time status, and directory health.
    2. Notify users and application owners; quiesce or stop databases, message stores, print services, and backup jobs through their supported procedures.
    3. Issue DISABLE LOGIN. Review MONITOR connections and open files; have users close data and log out rather than clearing active sessions blindly.
    4. Dismount only the volumes required by the maintenance procedure. Confirm cluster or shared-storage ownership where applicable.
    5. Issue DOWN for an orderly shutdown. DOWN flushes cache, closes files, updates file-system structures, and runs SHUTDOWN.NCF if present. [S2]
    6. Wait for the completion message or return to DOS before powering off or rebooting hardware.
    7. After startup, validate volumes, directory synchronization, SLP/SAP discovery, applications, clients, logging, and backups before re-enabling normal access.

    Change preparation checklist   Back to contents

    • Exact server, support pack, eDirectory, NLM, driver, and hardware/virtual hardware versions recorded.
    • STARTUP.NCF, AUTOEXEC.NCF, SHUTDOWN.NCF, SYS:ETC configuration, driver set, and application NCF files copied and hashed.
    • Storage map records devices, partitions, pools, volumes, namespaces, quotas, trustee metadata, cluster resources, and free space.
    • Directory map records tree, partitions, replicas, Master roles, time sources, SLP scopes/DAs, CA host, licensing, and schema extensions.
    • Application-consistent backup and a directory-aware backup completed; representative restore tested.
    • Rollback is time-bounded, resourced, and tested; the point beyond which rollback is unsafe is explicit.
    • Management access remains available if clients, SLP, DNS, or the normal AUTOEXEC.NCF path fails.

    Troubleshooting playbooks   Back to contents

    Server will not start or SYS will not mount   Back to contents

    1. Capture the screen and preserve BOOT$LOG.ERR. Classify the failure as before STARTUP.NCF, during driver load, during storage discovery, during SYS mount, or after AUTOEXEC.NCF begins.
    2. Boot with SERVER -NA when SYS can mount but post-mount services fail. Use SERVER -NS or a known-good alternate startup file only when prepared to load required storage support manually.
    3. Compare STARTUP.NCF, platform support, HAM/CDM drivers, firmware, virtual hardware, and device presentation with the known-good baseline.
    4. Confirm the controller/LUN/device is present and stable before attempting file-system repair. A missing or changing device is not a metadata-repair problem.
    5. For a Traditional volume, use VREPAIR only while unmounted and after preserving evidence/backup. For NSS, use NSS status, NSSMU, and the appropriate VERIFY/REBUILD procedure; never VREPAIR an NSS volume.
    6. Once SYS mounts, start AUTOEXEC.NCF services in controlled groups to isolate the failing module or binding.

    Clients cannot find a server   Back to contents

    Discovery fault isolation

    CheckIP/SLP environmentIPX/SAP environment
    Basic reachabilityPING/TPING, routing, VLAN/firewall, DNSFrame type, external network number, router path
    Service discoverySLP scope, DA list, SYS:ETC\SLP.CFG, port 427DISPLAY SERVERS, SAP filters, hop count
    File serviceNCPIP.NLM, TCP/UDP 524, server object addressNCPIPX.NLM, IPX binding/socket
    Client settingsPreferred tree/server, SLP DA/scope, protocol orderPreferred server, frame type, network number
    Directory dependencyReplica reachability, NDAP service registrations, timeDirectory SAP service and route

    Authentication or login script failure   Back to contents

    1. Separate authentication failure from post-authentication login-script failure. Test a minimal login without application mappings where possible.
    2. Confirm user distinguished name, context, preferred tree/server, password status, account restrictions, and client date/time.
    3. Check server time and DSREPAIR Time Synchronization; then verify the required partition replica is reachable and synchronized.
    4. For legacy clients/applications, verify BINDERY CONTEXT and unique short names.
    5. Trace the container, profile, user, and default login scripts in order. Enable MAP errors and remove conditionals temporarily in a test account, not in production for every user.
    6. Verify that the user is a trustee of the Profile object and that mapped servers/volumes are reachable through the selected protocol. [S9]

    Access denied or files are invisible   Back to contents

    1. Confirm the exact path, server, volume, namespace, protocol, and user identity. Alias and Directory Map objects can conceal the real target.
    2. Use RIGHTS with /NAME and /I, or the client’s Current Effective Rights view, to identify direct, group, security-equivalent, and inherited rights.
    3. Inspect IRFs at every level from the relevant parent to the target. Confirm that Read and File Scan exist for visibility and content access.
    4. Inspect target file/directory attributes: Read Only, Hidden, Delete Inhibit, Rename Inhibit, Purge Immediate, and protocol-specific enforcement.
    5. Check user/directory/volume quotas, free pool space, open-file and record locks, ownership, and application-level permissions.
    6. Remember that rights on the eDirectory Volume object do not substitute for file-system trustee rights stored on the volume.

    Slow response or high utilization   Back to contents

    • Establish whether the delay is client-only, service-specific, server-wide, site-specific, or time-of-day dependent.
    • Use Novell Remote Manager or MONITOR for CPU, service processes, packet receive buffers, memory, connections, open files, LAN errors, and disk activity.
    • Check mirror/RAID state, controller errors, LUN latency, low SYS/pool space, salvage backlog, and concurrent backup/antivirus/application jobs.
    • Review SLP timeouts and DA availability for slow logins; review directory replica placement and time for slow authentication.
    • Record DISPLAY MODIFIED ENVIRONMENT. NetWare defaults were tuned as a balanced system; do not copy old tuning folklore without evidence. [S4]
    • If No ECB Available Count grows, investigate dropped packets, driver/TSM compatibility, and packet receive buffers; more buffers consume memory. [S4]

    Volume or pool is full   Back to contents

    1. Identify whether the constraint is a user quota, directory quota, logical volume quota, physical NSS pool, Traditional partition, SYS, or underlying storage device.
    2. Stop the process generating data before deleting evidence or expanding storage.
    3. Review salvageable files and purge only under an approved retention decision. Salvage is shared-capacity recovery, not free space.
    4. For NSS, check every volume in the pool and account for overbooking. Extend the pool only after validating device size, RAID/path protection, backups, and vendor limits.
    5. For SYS, remove or rotate logs and temporary/support-pack content only when ownership is known. Do not delete hidden directory or product files by pattern.
    6. After remediation, restore alert thresholds, logging rotation, quota controls, and capacity trend monitoring.

    Abend or repeated restart   Back to contents

    1. Preserve the abend screen, ABEND.LOG, CONSOLE.LOG, core dump if configured, MODULES list, application logs, and the exact preceding change/workload.
    2. Prevent an uncontrolled restart loop. Automatic restart can hide recurring abends; check ABEND.LOG and server up time routinely. [S2, S4]
    3. Identify the faulting NLM, address space, thread, and dependency chain. Determine whether it ran in the kernel or a protected space.
    4. Reproduce only in an isolated clone with matching data and versions. Do not swap NLMs across support packs merely because file names match.
    5. If a protected application space faults, review restart/no-restart policy and product recovery semantics before reloading it.
    6. Treat resulting file-system or application inconsistency separately; a recovered kernel does not prove data consistency.

    eDirectory synchronization errors   Back to contents

    1. Run the directory health sequence: versions, time synchronization, replica synchronization, schema synchronization, obituaries, and external references.
    2. Verify IP/IPX reachability, NCP/NDAP service addresses, SLP/SAP discovery, DNS, firewall rules, and the replica ring’s server objects.
    3. Use DSREPAIR Report Synchronization Status and DSTRACE filters to collect the error and affected partition; seek All Processed = Yes for healthy rings. [S10]
    4. Resolve time, connectivity, name/address, disk-space, and version defects before repairing the directory database.
    5. Back up directory state and record replica roles before partition, replica, or obituary repairs. Coordinate changes across every server in the ring.

    Backup and disaster recovery   Back to contents

    What a usable backup must preserve   Back to contents

    Recovery asset inventory

    AssetPreserveWhy
    Boot environmentDOS partition/image, SERVER.EXE, STARTUP.NCF, AUTOEXEC.BAT, driversNeeded before SYS and network services are available.
    SYS configurationAUTOEXEC.NCF, SHUTDOWN.NCF, SYS:ETC, NLM/application config, logsReconstructs service identity and load order.
    DirectorySupported NDS/eDirectory backup, schema, partitions/replicas, certificatesA file copy of the live DIB is not a supported directory backup.
    File dataFiles plus trustees, IRFs, ownership, attributes, namespaces, quotas, linksA generic SMB copy can lose NetWare metadata and security.
    ApplicationsVendor-consistent database/message-store backup and transaction logsVolume-level consistency does not ensure application consistency.
    Storage mapController/LUN/RAID, devices, partitions, pools, volumes, cluster resourcesRequired to present the same data in the same ownership model.
    Software entitlementInstall/overlay media, support packs, patches, drivers, licenses, keysDownloads and activation services may no longer be obtainable.
    Operational evidenceRunbooks, credentials escrow, dependencies, test results, hashesTurns backup media into a repeatable recovery.

    BACKUP SEMANTICS: Use Storage Management Services or another NetWare-aware product for trustee and namespace fidelity, plus an application-aware method for databases and directory services. Test the exact restore path; a successful backup job is not evidence of recoverability.

    Recovery rehearsal   Back to contents

    1. Create an isolated recovery network with no route to production and a controlled time/DNS/SLP design.
    2. Recover the boot environment and virtual/physical hardware drivers, then start with normal NCF files suppressed if necessary.
    3. Present storage consistently and recover SYS before application/data volumes. Validate TFS/NSS type before any repair action.
    4. Restore the directory using its supported method and intended replica topology. Avoid creating duplicate server or tree identities on a connected network.
    5. Restore file data with trustees, IRFs, ownership, attributes, quotas, and namespaces, then application data with vendor consistency checks.
    6. Test representative authentication, login scripts, rights, mappings, locks, salvage, print, backup, and application transactions.
    7. Record recovery time, manual decisions, missing assets, and new hashes. Update the runbook and repeat until another engineer can execute it.

    Printing and ancillary services   Back to contents

    Printing generations   Back to contents

    NetWare printing models

    ModelCore objects/servicesClient experience
    Queue-based printingPrint Queue, Printer, Print Server; PSERVER; CAPTURE/NPRINTLPT redirection or queue submission; common in 3.x/4.x.
    NDPSBroker, Manager, Printer Agent; NDPSMDirectory-discovered printers, driver distribution, status and notification.
    iPrintIPP-based print services and web installationBrowser/client printer installation and IP transport; mature in 6.x/OES.
    • Inventory printer agents, gateways, drivers, queues, ports, DNS names, and application dependencies before migration.
    • A user can authenticate and map drives successfully while printing fails through an independent Broker/Manager/gateway path.
    • Legacy printer drivers are executable code. Preserve them for recovery but do not deploy them to unsupported modern clients without containment and testing.

    Other common services   Back to contents

    Common optional services

    ServiceTypical roleMigration/containment note
    DNS/DHCPDirectory-integrated network servicesExport zones, subnets, options, and service-object dependencies.
    NetStorageWeb access to NCP/CIFS-backed filesIsolate old web/TLS; login-script support is partial.
    iFolderUser file synchronizationInventory clients, stores, policies, and conflict behavior.
    Apache/Tomcat/MySQL/PHPWeb/application platform on 6.5Version-specific security/consistency; migrate rather than expose.
    GroupWiseMessaging and collaborationUse product-specific domain, post-office, and agent migration.
    Btrieve/PervasiveTransactional database engineCoordinate shutdown, logs, locks, and version compatibility.
    Cluster ServicesFailover for volumes and servicesPreserve virtual NCP identity, scripts, preferred nodes, and shared storage.
    SMS backupTSA/SMDR/SBCON backup frameworkRecord agent, media, catalog, encryption, and restore dependencies.

    Containment, preservation, and migration   Back to contents

    Minimum containment pattern   Back to contents

    1. Place NetWare and any dependent legacy clients on a dedicated VLAN or virtual switch with no direct Internet route.
    2. Default-deny at the firewall. Permit NCP, SLP, DNS, NTP, backup, directory, print, and application flows only between documented endpoints.
    3. Use a hardened jump host with the compatible Novell Client and management tools. Reach the jump host through modern MFA and encrypted remote access.
    4. Send logs and monitoring outward through a controlled relay or poll from a collector; do not install untested modern agents into the NetWare kernel.
    5. Keep offline, immutable copies of installation media, patches, drivers, configuration, license artifacts, system images, and data backups.
    6. Set an explicit retirement date and risk owner. Containment reduces exposure; it does not make unsupported code supportable.

    Migration sequence   Back to contents

    Staged migration

    StageActivitiesExit criterion
    DiscoverInventory services, directory roles, applications, volumes, trustees, clients, print, protocols, and dependenciesAuthoritative dependency and data map approved
    StabilizePatch to the approved terminal level, fix time/replication/storage errors, test backup and restoreHealthy, repeatable source baseline
    DesignSelect supported OES/Enterprise Server, Windows/Linux, SaaS, or application-specific destinations; map identity and rightsTarget architecture and rollback signed off
    PilotMigrate representative users/data/printers/apps with metadata-aware toolsFunctional, security, performance, and recovery tests pass
    CoexistIntroduce target services, NCP/CIFS/client changes, DNS/SLP updates, and staged data synchronizationUsers operate on target with measured exceptions
    Cut overQuiesce source, final sync, redirect mappings/services, validate rights and applicationsBusiness acceptance and rollback decision closed
    RetireRemove applications, replicas, service objects, licenses, routes, and storage in supported orderNo hidden dependency; evidence and retention complete

    METADATA-AWARE COPY: Use the supported migration/consolidation tool or an NSS/NCP-aware process when trustee assignments, IRFs, ownership, namespaces, Macintosh metadata, quotas, or application attributes matter. Generic drag-and-drop or SMB copies are not equivalent. [S12, S15]

    Virtualization and historical preservation   Back to contents

    • NetWare 6.5 SP8 documented VMware and Xen guest deployments, but compatibility depends on virtual CPU, storage, network adapter, and driver choices. [S1]
    • Preserve the original disk images before converting formats. Work on a verified copy and record hashes before and after transformation.
    • Keep the virtual NIC disconnected during the first boot of a clone to prevent duplicate server names, internal network numbers, tree identities, or replica activity.
    • Match old virtual hardware where possible. A newer hypervisor’s default controller or NIC may have no NetWare driver.
    • Capture console video/screens, configuration, volumes, application behavior, and client workflow as part of preservation, not only a bootable VM.
    • If the goal is evidence or data extraction rather than continued service, prefer an offline, read-only recovery workflow over production resurrection.

    Appendix A – Common paths and files   Back to contents

    Locations commonly encountered on NetWare 4.x-6.5

    LocationContents / use
    C:\NWSERVER\SERVER.EXENetWare server loader/kernel image.
    C:\NWSERVER\STARTUP.NCFPre-SYS SET parameters and platform/storage drivers.
    C:\NWSERVER\BOOT$LOG.ERRBoot messages/errors according to logging configuration.
    C:\ABEND.LOG then SYS:SYSTEM\ABEND.LOGAbend record before and after restart/copy.
    SYS:SYSTEMCore NLMs, AUTOEXEC.NCF, SHUTDOWN.NCF, utilities, application start files.
    SYS:PUBLICClient utilities and management program files.
    SYS:LOGINFiles accessible during login and pre-authentication workflows.
    SYS:ETCNetwork/service configuration and logs, including SLP.CFG and CONSOLE.LOG.
    SYS:ETC\CONSOLE.LOGDefault CONLOG output.
    SYS:SYSTEM\DSTRACE.DBGDirectory trace output when trace-to-file is enabled.
    SYS:_NETWAREHidden/system directory containing directory database and security data; never treat as ordinary file content.
    SYS:SYSTEM\SYS$LOG.ERRCommon system error log location on many releases.
    volume-root\VOL$LOG.ERRTraditional volume error/repair log commonly found at a volume root.

    VERSION VARIANCE: Paths can be redirected, clustered, or changed by products and support packs. Treat this appendix as a discovery list, then confirm with CONFIG, SEARCH, module parameters, NCF files, and the matching manual.

    Appendix B – Glossary   Back to contents

    Glossary

    TermDefinition
    AbendAbnormal end: a NetWare fault or exception that can suspend a thread, fault an address space, or stop/restart the server.
    BinderyPer-server flat database of users, groups, properties, and services used primarily by NetWare 2.x/3.x.
    Bindery contextOne or more eDirectory containers exposed as a flat Bindery view for legacy clients/applications.
    CDMCustom Device Module in the NetWare Peripheral Architecture storage stack.
    DIBDirectory Information Base: the local NDS/eDirectory database.
    Directory MapeDirectory object that represents a path and reduces hard-coded mapping dependencies.
    Distinguished nameAn object’s unique hierarchical name in the eDirectory tree.
    eDirectoryLater name and evolution of Novell Directory Services (NDS).
    HAMHost Adapter Module: storage adapter driver in NWPA.
    IRFInherited Rights Filter: blocks selected rights inherited through a hierarchy.
    IPX/SPXLegacy Novell routed network and connection-oriented transport protocol suite.
    NCPNetWare Core Protocol: client/server file and network service protocol.
    NCFNetWare Command File: a server-side batch/configuration file.
    NDSNovell Directory Services: distributed directory introduced with NetWare 4.
    NDPSNovell Distributed Print Services, the directory-based successor to queue printing.
    NamespaceFile-name and metadata representation for DOS, LONG/Windows, Macintosh, NFS, or other clients.
    NLMNetWare Loadable Module: executable server component linked into the runtime.
    NSSNovell Storage Services: journaling file system and storage-pool/volume architecture.
    NWPANetWare Peripheral Architecture for HAM/CDM-based storage drivers.
    ODIOpen Data-Link Interface used by classic Novell client LAN/protocol stacks.
    OESOpen Enterprise Server, the Linux-based successor platform for eDirectory, NCP, NSS, iPrint, and related services.
    PartitionContiguous subtree replicated as a unit in NDS/eDirectory.
    PSMPlatform Support Module for processor/chipset/platform integration.
    ReplicaCopy of a directory partition held by a server; types include Master, Read/Write, Read-Only, and Subordinate Reference.
    Replica ringSet of servers holding replicas of the same partition.
    SAPService Advertising Protocol used to advertise services in IPX networks.
    SalvageRecovery of files retained after deletion but before purge/reclamation.
    SLPService Location Protocol used for IP service discovery and registration.
    SMSStorage Management Services: NetWare backup architecture using agents such as TSA and SMDR.
    TFSTraditional NetWare File System, distinct from NSS.
    TrusteeUser, group, or object assigned rights to a target directory, file, or directory object.
    VLMVirtual Loadable Module client architecture used by DOS NDS-aware clients.
    VolumeNamed NetWare file-system container such as SYS or DATA, exposed through NCP and represented by an eDirectory object in NDS-era systems.

    Appendix C – Official source set   Back to contents

    Sources were selected from surviving Novell, Micro Focus, NetIQ, and OpenText documentation. They were accessed on 8 August 2026. Product pages and document hosts can move; retain local archival copies where licensing permits.

    [S1] NW 6.5 SP8 Installation Guide. Open official source

    [S2] NW 6.5 SP8 Utilities Reference. Open official source

    [S3] NW 6.5 SP8 NLM Reference. Open official source

    [S4] NW 6.5 SP8 Server Operating System Administration – Troubleshooting. Open official source

    [S5] NW 6.5 SP8 NSS File System Administration Guide. Open official source

    [S6] NW 6.5 SP8 File Systems Management Guide – attributes and trustees. Open official source

    [S7] NW 6.5 SP8 Planning and Implementation Guide. Open official source

    [S8] NetIQ eDirectory 8.8 SP8 Administration Guide – eDirectory Rights. Open official source

    [S9] Novell Login Scripts Guide. Open official source

    [S10] NDS/eDirectory Health Check Procedures – Cross Platform. Open official source

    [S11] NW 6.5 SP8 Novell Remote Manager Administration Guide. Open official source

    [S12] Open Enterprise Server – Coexistence and Migration of File Services. Open official source

    [S13] OpenText Product Support Lifecycle. Open official source

    [S14] SLP Design and Implementation Guidelines. Open official source

    [S15] Novell Server Consolidation and Migration Toolkit. Open official source

    EDITION NOTE: This reference deliberately avoids prescribing hardware-specific driver lines, destructive repair options, or a current migration destination without an environment inventory. Those decisions must be made against the exact server state and the current support/interoperability matrix.