In the exchange below there is an important point about how we get
from where we are to where the system is going. Shmeul is saying we
will need a compatibility interface for BSAM and BPAM while I am
contending this won't be necessary. We may or may not be as far apart
as the discussion below indicates but I am certain there are a number
of areas where this same discussion will occur. I will agree that so
far as any higher level language program (COBOL, PL1, maybe C/C++,
etc.) the only program change should be a straight recompile at most
and depending on the support routines involved, it might all be
handled by the LE or language specific run-time completely transparent
to the application programmer. 64 bit support probably necessitates a
recompile.
For the rest of the points raised I am making the following
assumptions and need to understand if they are correct.
1. BSAM and BPAM are only used by assembler level programs. I know
that COBOL has no BPAM and BSAM capability.
2. There will be a multi-year overlap between when the ability to
fully run a system on FBA native devices first becomes available and
when support for CKD is finally dropped where multi means at least 5.
3. COBOL will finally lose the distinction between ESDS and QSAM data
sets. This would be in line with the SHARE Guide Lanuage Futures Task
Force report. Note that I would hope for the same thing to happen for
the other languages that I can read with difficulty and frequent
reference to a manual.
4 Few if any applications programs in most shops (as opposed to
system or home grown utilities) depend on BSAM and BPAM in
installation written code.
5. Vendors currently using BPAM and BSAM will need to upgrade to
using the new access mechanisms because they will need to be able to
handle the new facilities and functions available for sequential and
library files.
The ability to handle any mixture of QSAM and ESDS files (and allowing
ESDS files to go to tape and "printer") is probably a compatibility
interface. However I consider it more a conformance to the Language
Futures Task Force idea that we want the program to be as independent
as possible of how the data is actually stored and only be concerned
with whether the logical access is possible. Thus we wanted a program
to be able to access a QSAM file, an ESDS, a KSDS, a DB2 view or any
other input that shared the same record description with zero program
change. VSAM transparency facilities for ADABAS and DB2 reflect this
vision.
Various things will change drastically as we move toward FBA, 64 bit
addressing, different character sets, and larger names. Since
compatibility interfaces represent code that can break, I would want
to see as few as possible. On the other hand, the amount of change
needed to existing facility must be minimized and change must be as
non-disruptive as possible. I do not envy those who have to design
the migration path. I will be interested to find out what others
think. It won't be the first time I have overlooked the obvious.
The reason I believe that the JES component will be drastically hit by
the change in name provision is that a high percentage of the JES
control blocks contain names from JCL and similar sources.
On 28 Jun 2005 04:57:21 -0700, in bit.listserv.ibm-main you wrote:
>In <[EMAIL PROTECTED]>, on 06/25/2005
> at 11:32 PM, Clark Morris <[EMAIL PROTECTED]> said:
>
>>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.
>
>I wasn't suggesting new device-dependent code for the old access
>methods; I was suggesting a compatibility interface similar to that
>used to allow you to open a DCB to a subsystem data set. Currently
>OPEN has the ability to automatically acquire an ACB, open it and link
>it to the DCB. I suspect that IBM could lift from VSE and OS/VS1 what
>little code is needed beyond what is already there for SYSOUT.
>
>>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.
>
>That won't make them go away. They are an economic reality, and if IBM
>wants to retain the customer base then it will need to provide for a
>smooth migration.
>
>>The need is to move any still needed functions of BPAM and BSAM to
>>newer architectures, not to move BPAM and BSAM.
>
>No, the need is to preserve investment. The customer doesn't care
>about "architecture"; he cares about fiscal issues, one of which is
>the residual value of code that he has already spent a lot of money
>one. Tell him that he must spend additional money to rewrite that code
>and you have removed his incentive to stay with IBM.
>
>Also, your statement has an implication contrary to fact. There was no
>proposal to "move BPAM and BSAM"; there was a proposal to provide a
>device-independent CI.
>
>>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.
>
>Why?
>> rest snipped
----------------------------------------------------------------------
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
