It’s no secret that for several years z/VSE users have expressed concern about the 255 task limit. User and WAVV requirements were forwarded to IBM, noting the issue, and the status of the requirement was changed from accepted to delivered when z/VSE 4.2 became available in late 2008. Having been perceived as the next major limitation for many z/VSE users, the delivery was timely and welcomed.
While it may have seemed like a simple request and a simple implementation to some, it wasn’t. By looking at the implementation, we can begin to understand the complexities encountered in delivering the extended task support. Additionally, there may be some situations that require considerations, testing, and perhaps minor changes within our production environments.
For purposes of this discussion, “old” task refers to the original 255 task, and “new” task refers to extended task— 256 through 512.
The first consideration will be the initiation of extended support via the enhanced // SYSDEF SYSTEM command, as shown below:
>>_ ____ _SYSDEF SYSTEM_ ___________________ __|____________|___>
|_//_| |_,NTASKS=_ _nnn_ __| |_,TASKS=OLD_|
NTASKS can be any number from 255 to 512; 255 implies TASKS=OLD, and a number larger than 255 implies TASKS=ANY. Absent a really excellent reason, coding TASKS=MAX is preferred. MAX today implies 512. Should a future extension occur, MAX could then mean a number greater than 512.
Note that the initial 32 systems task and the maintask for every partition will always use an old task. Partition subtask can be old or new, depending on your selection of controlling statement parameters.