{'fraction_non_alphanumeric': 0.018056749785038694, 'fraction_numerical': 0.0, 'mean_word_length': 4.849246231155779, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
No Program Is An Island : Passing Parameters to Tasks Launched by Servers and Schedulers

Many computer tasks are controlled and modified by parameters. They convey to our tasks information such as what range of dates to include, which reports to run, where to find the raw data, and sometimes whether an error has occurred that should cause suspension of the requested task. Parameters are one of the main means for tying tasks together to form applications. When using SAS/AF and SCL, parameters can be passed along with CALL statements, through SCL Lists and SLIST catalog entries, parameter data sets and files, and through macro variables. This paper will explore and contrast examples of these techniques. Strategies to choose the best means for passing parameters to different types of successor tasks will be offered. When tasks are launched by a web server or a production scheduler, additional problems may emerge. How can we anticipate and accommodate changes in the computing environment between when a task is scheduled or requested, and when the task starts to run? Strategies to make server and scheduler launched tasks more robust will be shared.