The February/March column identified one user’s issue with the partition limit for Programmer Logical Units and solicited input from the user community. From the responses received to date, it appears that only the original reporting user expects to encounter this issue in the future.
The affected user certainly should submit a requirement to IBM identifying the issue. But, since the affected base of users is limited, it’s unlikely a requirement against the product would generate sufficient interest and support for a high-priority vote. Therefore, it doesn’t appear the issue would generate a business case for expansion until more users are affected.
That column identified several potential methods for short- and long-term relief, including conservation, reassignment and redistribution of existing SYS numbers, migration to larger DASD devices, and modifying the application to use two or more partitions.
Suleiman Shahin, a systems programmer at Palm Coast Data, shares this: “My first thought would be, is the limitation a VSE one or is it really an application limitation? Why not modify the application to force it into dynamic allocation of resources?” Excellent idea, Suleiman, and thanks for the solution.
Using dynamic allocation, only the devices actually in use would receive a SYS number. Then, if or when SYS numbers are exhausted, a device not currently in use could have its SYS number “stolen” and reused. You may remember the days before multiple alternate consoles, when systems programmers would switch the SYS number pointer to the device (CUU) to move or steal the console to another terminal.
Thanks to everyone who responded.
Financial Hard Times
It hasn’t gotten any easier lately for z/VSE installations to survive financially. And from recent prognostications, the next year appears to offer little chance for improvement. The continued cutting of z/VSE budgets, travel, education and hiring restrictions, and retrenching markets isn’t inspiring investment in the z/VSE marketplace.
While this is simply an acknowledgement of what’s happening in the z/VSE marketplace and others with this current economic “disaster,” it isn’t the intent of this column to examine the causes of the disaster. Rather, our goal is to discuss expectations and prudent actions.
Most z/VSE installations aren’t buying services, software, or hardware because of current financial restrictions. Vendors are aware z/VSE customers aren’t spending money and are restricting their expenditures, too.
Should users expect major new enhancements to products? Probably not, but if so, the enhancements will be limited, focused, and financially conservative. Should users expect major new product introductions? Perhaps, some product introductions early on as development started before the downturn completes. But definitely less to none as the economic disaster becomes longer and suppliers financially retrench.
Should users expect new companies, offering new solutions to enter the z/VSE environment? Probably not until z/VSE sites have money to spend and a willingness to spend it. Successful companies don’t enter a market that isn’t in growth mode. Will some companies discontinue, stabilize or divest products? Yes, products with fewer users and lower financial returns run a higher risk of being discontinued, stabilized, or divested simply because wise vendors will concentrate on products with better profit potential.
Will some companies offering z/VSE solutions exit the z/VSE marketplace? Yes; if they can’t sell products and make money, why would they stay? Will some companies cease to exist? Yes, companies that are in weak financial condition or make poor financial decisions may not have a choice. Hopefully, their assets will be acquired by another company and the product will continue to exist for your use.
So, what can we z/VSE users do? Pay attention to the financial strength of your vendors. For those that appear financially weak, put in place a replacement plan, if possible, or an elimination plan. If a company is going out of business, help find an acceptable home for the products you use. If no acceptable home is found, make plans to acquire the source code, so you and/or other users can continue to use the product. Work with your vendors, where possible, to control costs. Have reasonable expectations for their service, enhancements, and expenditures during these trying times. They’re in survival mode, too, so sharing your techniques and methods could also help them.
Thanks for reading the column; see you all in the next issue.