TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I'm doc'ing mainframe (ISPF) procedures that can include a number of runtime options. The user specifies input data sets and runtime options on the initial screen. Depending on the runtime options the user selects, various other screens might appear, one per option.
For example, a typical flow is:
1. Component screen, for input data sets and options (filter statements, report titles, report parameters)
2. Possible screen for filters.
3. Possible screen for report titles.
4. Possible screen for report parameters.
5. Back to the regular flow, for print options, job cards, jcl review, and submitting the job.
At first, I'd want to break out each of these possibilities into a subsection. But each of these possibilities is a stage in the process, a means to an end, not an end inandofthemselves (although that might be the best way to go).
But if I keep to one procedure flow, I get all these "if" conditions: "If you selected option X way back 12 screens ago, then this panel displays now. Otherwise the next panel appears, unless you didn't select option Y way back 12 screens ago..."
You get the idea. It's just nasty.
If anyone can help me out with other ways to tackle this problem, I'd appreciate it. If you can, please CC droberts -at- isogon -dot- com so that I can get your responses. Thanks!
