Author: steve-myers
Posted: Mon Jun 19, 2017 7:18 pm (GMT 5.5)
I have no idea what the designers of OS/360 were actually thinking, but I suspect they were thinking they did not want application programmers to run into the problems the topic starter had when they did not provide dynamic allocation in OS/360.
As most of us know, TSO for OS/360 had a primitive dynamic allocation. There were a multitude of problems, most of them because TSO dynamic allocation was serialized using the same locks as JCL allocation, so if JCL allocation was working it blocked TSO allocation. This meant a TSO user had to wait for JCL allocation to complete.
The ALLOCATE and FREE commands, with their multitude of options illustrate the problems. TSO ALLOCATE and FREE, though they have been enhanced over the years, are little changed from the ALLOCATE and FREE commands for OS/360 TSO. The enhancements since OS/360 TSO are rarely used.
MVS, of course, has had dynamic allocation from the beginning, but it's mainly targeted at Assembler programmers. Most Assembler programmers find it difficult to use. Quite honestly, having observed its use over the years, I find dynamic allocation misused rather than properly used. The biggest problem is message support when a problem is encountered. It's usually done poorly; all too often mysterious error codes from dynamic allocation are presented to the end user, and even then presented in a fashion that make it difficult to use the available documentation.
The BPXWDYN function gives some clues.
First, BPXWDYN has never been part of the mainline z/OS product. Its documentation, such as it is, is not in any mainline z/OS document. I suspect most BPXWDYN users would not know where its documentation is located, much less actually use its documentation. I can recall, some years ago, spending several hours trying to find its documentation. Few people would guess where its documentation is hidden, much less deduce the rational that placed the documentation where it is.
Second, the character strings used with BPXWDYN are loosely based on the ALLOCATE and FREE TSO commands. I suppose this is a complement to the designers of the ALLOCATE command in 1970 or so. BPXWDYN does not use the sophisticated string parser used by TSO to examine the ALLOCATE and FREE commands so its message support when there is a syntax error is non-existent; this is a problem the topic starter encountered. The parser used in BPXWDYN seems to acknowledge many alternates accepted in TSO and commonly used by users of the TSO ALLOCATE and FREE commands, but these seemed to be programmed into the parser rather than unintentioned byproducts of the TSO parser. An example: the official syntax in TSO is FILE(xxx), but many TSO users found the OS/360 TSO parser accepted F(xxx) because there were no other keywords in the OS/360 ALLOCATE command that started with F, and lazy bums that we are we still use F(xxx) Eventually, of course, TSO ALLOCATE was changed to accept the more correct DDNAME(xxx) syntax. Regardless, BPXWDYN appears to use FI(xxx) and DD(xxx) as its official short cuts.
Third, the official documentation does not say BPXWDYN can be used in Cobol, though we all know, as does the topic starter, that it can be used in Cobol and some other high level languages such as C, as documented.
Posted: Mon Jun 19, 2017 7:18 pm (GMT 5.5)
I have no idea what the designers of OS/360 were actually thinking, but I suspect they were thinking they did not want application programmers to run into the problems the topic starter had when they did not provide dynamic allocation in OS/360.
As most of us know, TSO for OS/360 had a primitive dynamic allocation. There were a multitude of problems, most of them because TSO dynamic allocation was serialized using the same locks as JCL allocation, so if JCL allocation was working it blocked TSO allocation. This meant a TSO user had to wait for JCL allocation to complete.
The ALLOCATE and FREE commands, with their multitude of options illustrate the problems. TSO ALLOCATE and FREE, though they have been enhanced over the years, are little changed from the ALLOCATE and FREE commands for OS/360 TSO. The enhancements since OS/360 TSO are rarely used.
MVS, of course, has had dynamic allocation from the beginning, but it's mainly targeted at Assembler programmers. Most Assembler programmers find it difficult to use. Quite honestly, having observed its use over the years, I find dynamic allocation misused rather than properly used. The biggest problem is message support when a problem is encountered. It's usually done poorly; all too often mysterious error codes from dynamic allocation are presented to the end user, and even then presented in a fashion that make it difficult to use the available documentation.
The BPXWDYN function gives some clues.
First, BPXWDYN has never been part of the mainline z/OS product. Its documentation, such as it is, is not in any mainline z/OS document. I suspect most BPXWDYN users would not know where its documentation is located, much less actually use its documentation. I can recall, some years ago, spending several hours trying to find its documentation. Few people would guess where its documentation is hidden, much less deduce the rational that placed the documentation where it is.
Second, the character strings used with BPXWDYN are loosely based on the ALLOCATE and FREE TSO commands. I suppose this is a complement to the designers of the ALLOCATE command in 1970 or so. BPXWDYN does not use the sophisticated string parser used by TSO to examine the ALLOCATE and FREE commands so its message support when there is a syntax error is non-existent; this is a problem the topic starter encountered. The parser used in BPXWDYN seems to acknowledge many alternates accepted in TSO and commonly used by users of the TSO ALLOCATE and FREE commands, but these seemed to be programmed into the parser rather than unintentioned byproducts of the TSO parser. An example: the official syntax in TSO is FILE(xxx), but many TSO users found the OS/360 TSO parser accepted F(xxx) because there were no other keywords in the OS/360 ALLOCATE command that started with F, and lazy bums that we are we still use F(xxx) Eventually, of course, TSO ALLOCATE was changed to accept the more correct DDNAME(xxx) syntax. Regardless, BPXWDYN appears to use FI(xxx) and DD(xxx) as its official short cuts.
Third, the official documentation does not say BPXWDYN can be used in Cobol, though we all know, as does the topic starter, that it can be used in Cobol and some other high level languages such as C, as documented.
