lsatenstein
11th September 2002, 02:07
The original request was to modify the settings in a job step without deleting the step and reinserting it with updated values.
I was given a solution to this problem that was quite specific by Gary who gave me some ideas. I needed to generalize his solution.
The approach I took was to parse the input into three tables.
I build a parser to take the existing job data and used it to build three tables (length of data, variable name, and string representation of data).
I then encorporated the form from the session pertaining to the job by referring to it in the session setup (form area), and I added the form externals to the code containing the parse tables. These externals also matched the parsed tables. The session opened the form, changes were accepted, and then applied to the appropriate entries in the parse table.
The moving of parse data to initialize the form, and from the form back to the parse tables was pretty straight forward. I did not use any data dictionary functions (such as rdi.*) to try to automate some of this logic.
I have another function that takes the parse tables and creates the string to use to rewrite the ttaad503 table rows.
The code is available on demand. Any buglets you find or any enhancements would be appreciated.
There is no editing of data for range checking. It assumes that not too many fields on the form would be revised (typically, invoice ranges), and that the human would be careful.
Anyway, I am writing this from the office. I could not find my email from the kind gentleman who discussed and forwarded his solution to me.
I was given a solution to this problem that was quite specific by Gary who gave me some ideas. I needed to generalize his solution.
The approach I took was to parse the input into three tables.
I build a parser to take the existing job data and used it to build three tables (length of data, variable name, and string representation of data).
I then encorporated the form from the session pertaining to the job by referring to it in the session setup (form area), and I added the form externals to the code containing the parse tables. These externals also matched the parsed tables. The session opened the form, changes were accepted, and then applied to the appropriate entries in the parse table.
The moving of parse data to initialize the form, and from the form back to the parse tables was pretty straight forward. I did not use any data dictionary functions (such as rdi.*) to try to automate some of this logic.
I have another function that takes the parse tables and creates the string to use to rewrite the ttaad503 table rows.
The code is available on demand. Any buglets you find or any enhancements would be appreciated.
There is no editing of data for range checking. It assumes that not too many fields on the form would be revised (typically, invoice ranges), and that the human would be careful.
Anyway, I am writing this from the office. I could not find my email from the kind gentleman who discussed and forwarded his solution to me.