HPOC common mistakes
HPOC · Understand the traps and how to avoid them.
Assuming the process priority field is a simple 0-31 scale and answering priority questions using only base priority values, without accounting for the four priority classes (0-15, 16-31, 32-47, 48-63) and how a process's class is fixed at creation.
Candidates learn that OpenVMS priorities run 0-63 and then treat them as one continuous adjustable range, forgetting that a process created in the interactive class cannot simply be SET PROCESS/PRIORITY into the real-time class without also being in that class.
What to do instead
Memorize the four classes and their ranges, and always state both the class and the numeric priority in answers. Practice tracing what SET PROCESS/PRIORITY does when the requested value crosses a class boundary (it is rejected) versus staying within class.
Confusing the system disk's page file and swap file behavior, and answering performance questions as if all paging is to disk, ignoring that OpenVMS pages from the page file but swaps whole processes to the swap file.
The terms paging and swapping are used loosely in general operating system study, so candidates apply generic Unix/Windows memory models to OpenVMS and miss the distinct roles of PAGEFILE.SYS and SWAPFILE.SYS.
What to do instead
Write out the distinction explicitly: paging moves individual pages to the page file; swapping removes an entire process's working set to the swap file. Then review how AUTOGEN sizes both and what SYSGEN parameters (e.g., FREEGOAL, GROWTH) influence them.
Treating the system disk as just another volume and forgetting that it carries the boot files, page/swap files, and often the cluster common files, leading to wrong answers about what can be moved off it.
Storage questions focus on volume structure and candidates mentally file the system disk under 'storage' rather than 'boot and cluster', so they overlook its special constraints.
What to do instead
Build a one-page map of the system disk contents (SYSBOOT, page and swap files, SYS$SYSTEM, cluster common files) and for each item note whether it can be relocated and what breaks if it is. Rehearse the consequences of moving PAGEFILE.SYS or the cluster common files.
Answering startup and shutdown questions by listing commands in the wrong order, e.g., placing STARTUP.COM execution before the system parameters are loaded or confusing the role of SYSBOOT versus STARTUP.COM.
The boot sequence has many named stages (console boot, SYSBOOT, parameter loading, STARTUP.COM phases, DECnet startup) and candidates memorize the names without anchoring them to a strict order.
What to do instead
Draw the boot sequence as a numbered timeline from console prompt to login, annotate each stage with the file or program responsible, and then answer practice questions by walking the timeline rather than recalling isolated facts.
Confusing AUTHORIZE qualifiers when creating or modifying accounts, particularly mixing up /FLAGS options such as DISUSER, DISCTLU, and CAPTIVE, and applying them to the wrong account state.
AUTHORIZE has many similar-sounding qualifiers and candidates skim them, assuming they all simply enable or disable an account rather than each controlling a distinct capability.
What to do instead
Create a table of each /FLAGS keyword with a one-line effect and a scenario where it matters (e.g., a captive account for a menu-driven application versus a disabled account). Test yourself by predicting the login behavior for each flag combination.
Assuming a volume's free space is what DIRECTORY or a casual check suggests, without accounting for the difference between free blocks, the volume's cluster factor, and space consumed by file headers and extensions, leading to wrong capacity answers.
Candidates apply a simple 'total minus used equals free' model and ignore that OpenVMS allocates in clusters and that file headers and extension headers consume space outside the file's apparent size.
What to do instead
Review how cluster size is set at INITIALIZE and how it affects allocation granularity. Practice reading SHOW DEVICE/FULL output and interpreting free blocks, and work an example computing usable space for a given cluster factor.
Treating cluster quorum as a fixed majority of all nodes rather than as a computed value affected by votes, expected votes, and the quorum disk, and answering failover questions using a simple 'more than half' rule.
Quorum is taught initially as majority rule, and candidates do not internalize that votes can be assigned per node, that a quorum disk contributes votes, and that expected votes can be adjusted.
What to do instead
Work through several scenarios computing quorum from node votes plus quorum disk votes, and trace what happens to the cluster when nodes are added or removed. Learn the commands that display and modify votes and expected votes.
Confusing DECnet Phase IV node addresses with IP-style addressing, or assuming DECnet/IP integration is automatic, when answering networking questions about node numbers and address formats.
Candidates bring TCP/IP mental models to DECnet and expect dotted-decimal addresses or automatic configuration, missing that DECnet Phase IV uses area.node numbers and that integration requires specific configuration.
What to do instead
Separate the two addressing schemes on paper: DECnet Phase IV area.node format and rules versus IP addresses and masks. Then review how DECnet over IP and multi-protocol configurations are set up and what each layer requires.
Answering backup and recovery questions by naming BACKUP commands without distinguishing image versus file-oriented operations, or ignoring that a restore may require the correct saveset and volume set.
BACKUP has parallel image and file modes with similar syntax, and candidates memorize command names without linking each mode to the recovery scenario it supports.
What to do instead
For each BACKUP mode, write the command form, what it produces, and the exact restore command that reverses it. Then rehearse recovery scenarios (single file lost, whole volume lost, incremental chain) and match each to the correct mode and saveset.
Diagnosing problems by guessing at the first symptom instead of using the standard information-gathering tools, e.g., skipping error log analysis or process/queue status checks before proposing a fix.
Under time pressure candidates jump to a familiar cause, and troubleshooting questions reward a disciplined sequence of evidence gathering over pattern matching.
What to do instead
Adopt a fixed triage checklist (check the error log, check process and queue status, check device and volume status, check network links) and apply it to every troubleshooting question before selecting an answer. Practice reading error log entries and mapping them to likely causes.