Find the Db2 unloads and what it would take to run them on the base utility

Report every Db2 unload the portfolio runs and mark the EXEC card each is reached from with what moving it off the High Performance Unload product would take. The classification is by the dialect the control cards are written in and never by PGM=: a shop may alias DSNUTILB to the product's compatibility entry point INZUTILC, and the product reads three vendors' dialects through one program name of its own, so the row says what in the deck proved the engine. Each unload lands in one of four: ALREADY_THE_TARGET for a deck already written in the base utility's language, MAPS_KEYWORD_FOR_KEYWORD where IBM's own option table covers every keyword — OUTDDN to UNLDDN, LOADDDN to PUNCHDDN, LOCK YES QUIESCE YES to SHRLEVEL REFERENCE — NEEDS_REDESIGN where the deck reads a table space once and writes several files, orders rows, joins tables, unloads an image copy or calls an exit, and NOT_DECIDABLE where a name in the job was not followed or the deck leaves what it writes to the site parmlib. The findings beside them are the changes that would alter the bytes downstream readers get without anybody noticing: the access mode, a lock and quiesce pair no SHRLEVEL matches, output DDs the base utility would default elsewhere, and a deck carrying both JES symbols and the product's own template variables. AnalyzeHpuUsage answers the same question and changes nothing.