On 24 Jun 2005 15:26:48 -0700, in bit.listserv.ibm-main you wrote: >In <[EMAIL PROTECTED]>, on 06/23/2005 > at 02:12 PM, Clark Morris <[EMAIL PROTECTED]> said: > >>In regard to the legacy code, ten years ago I might have agreed with >>you and argued for a compatibility interface. Since the FBA change >>would be part of an overall revolutionary set of changes requiring >>all new control blocks, I suspect trying to maintain compatibility >>would result in a real kludge. > >Why? Most of the required infrastructure is already in place. Or do >you see a need to do away with the ACB and RPL control blocks as well?
While we will need the logical functions of the ACB and RPL, they will be affected by the need for 8 byte addresses and I think VSAM ESDS, KSDS and RRDS are currently limited to 32K for both LRECL and CI size. > >>Since BSAM, QSAM and BPAM can't handle records larger than 32k and >>names greater than 8 bytes anyway, significant changes would be >>needed for any program that actually used BSAM, the Assembler >>interface to QSAM or BPAM. > >My concern was that existing programs continue to run with new DASD. >Exploitation of new features is a separate issue. I see no need for >any changes to existing applications using BPAM, BSAM or QSAM. Since the actual hardware is FBA now and the magic is done in the controller, I see no need for the CKD oriented access methods to be ported to new style devices. Indeed I can see that some FBA devices would be native HFS or other Unix file system of choice or affliction while others would be oriented to the more traditional z series VSAM and VSAM related file structures. Given the graying, balding and aging of the MVS etc. community, the BPAM and BSAM applications are fast becoming a millstone around the necks of our organizations. The need is to move any still needed functions of BPAM and BSAM to newer architectures, not to move BPAM and BSAM. QSAM and enhanced VSAM ESDS structures should be transparent to any higher level language program (SHARE Guide Language Futures Task Force 1984). > >>Similarly, job names and usernames larger than 8 characters are going >>to break much of the existing JES structure so a new work flow >>manager may well be the cheapest way to go. > >I don't see that; it would seem less expensive to just modify the >existing C/I, Initiator, JES2 and JES3 control blocks and code. User >exits, of course, would not be portable, and you would need new SSI >calls. I suspect that the changes would be far heavier in the BCP than >in the JES's. > The devil is in the details. I agree that changes to name lengths and use of Unicode will require drastic changes to the BCP but the combination of FBA and name length and character set changes will have a drastic impact on the JESs. The most important questions are: 1. Are the changes that I have recommended including longer names, move to Unicode, Fixed Block Architecture, etc. necessary for the future? 2. Is there functionality currently in z/OS and z/VM that is both needed and not available at least one other IBM platform? 3. Assume z series functionality is either unique to the platform or is for critical functions significantly more advanced than other IBM platforms and the functions I recommended are vital to have in environments in the future. Then what is the least resource consumptive way to get to an operating environment that has all of the function required for the future from both an IBM point of view and a customer point of view? Any of the choices that I can envision are expensive and potentially disruptive. Any course of action will have to be able to be executed in incremental steps. Basically where do we think our organizations should be heading and how do we see them getting there? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
