|
TPF Systems Technical Newsletter, Vol. 4 No.4
by Jacki Cooper, IBM TPF Customer and Vendor Relations
As the TPF product becomes a more open platform, the TPF Lab can
use software that already exists for other platforms to provide
equivalent functionality on TPF. This use of existing software
allows us to deliver new functions to our customers much more
quickly. However, there is an occasional drawback when the
developer of the software we are using will not permit us to
distribute the source code for that function to our customers. When
this happens, TPF's implementation of this function will be
distributed in object code only (OCO) format without source
code.
The following reprint of a handout addressing OCO-related
concerns was distributed at the TPF Users Group (TPFUG) meeting
recently held in Atlanta, Georgia.
General
| Question |
Answeer |
Q1 |
After all
these years of having source code for our TPF system, why is it now
necessary to start shipping OCO functions with TPF? |
| A1 |
A little
clarification might help to start things out. The first thing to
note is that not all of TPF will be distributed as OCO; th ose
portions that have source code now will still have source code
available in the future.
Another thing is that IBM's TPF Lab is using a new strategy to
maximize the addition of functional enhancements to TPF. We are
using software originally created for non-TPF platforms (for
example, OS/390, OS/2, AIX, UNIX, and others) as the basis for
providing these same functions on TPF. This effort is referred to
asporting and results inported code.
One of the benefits to porting an existing function to TPF is
obviously the more rapid delivery of that function. Additionally,
what is delivered may be more complete, robust, and standard than
if it was implemented from scratch. Another benefit is that this
existing function has been tested by a lot of users on those other
platforms.
However, there are drawbacks with this strategy, too. The
original developer of a function remains the owner of that function
regardless of how many different platforms on which that function
executes. When a piece of software is a valuable business asset,
they will usually take steps to protect that asset. One way to
accomplish this is by not distributing the source code.
Whenever this method of protection is being used for code that
we want to port to TPF, we are being forced to make a choice
between providing that new function to our customers as OCO
(without source code), or not providing it at all!
|
Ordering Procedures
| Q1 |
Do we have to
do anything different to get these new functions? |
| A1 |
No. At this
time, our plans are to distribute these new functions as
enhancements to TPF and as an APAR in our normal maintenance st
ream. |
Installation
| Q1 |
How will
having OCO functions impact our APAR installation process? |
| A1 |
There is
nothing unique about OCO modules that would require you to change
your maintenance installation process. |
|
|
| Q2 |
Our TPF
system is not at the current maintenance level. Will we still be
able to install enhancement APARs even though our system is
back-level? |
| A2 |
It has always
been the TPF Lab's position that all APARs must be installed to
maintain system currency and integrity. With the advent of OCO
modules, it is now even more important for customers to maintain
their systems at current maintenance levels as much as possible. We
realize, however, that this is not always possible. As a result,
our customer service organization will be able to help you identify
the prerequisite and/or corequisite APARs that must be applied to
your system before attempting to apply a specific APAR. |
|
|
| Q3 |
OK, we "bit
the bullet" and are going to implement some OCO functions, but we
are really nervous about this and how it is going to work. Will
someone from IBM be here with us during implementation and for the
first few days as we shake out any problems? |
| A3 |
There are
currently no plans for the TPF Lab to modify its cutover coverage
policy because of the advent of OCO functions. However, services
contracts for additional coverage at implementation time are
available. |
|
|
| Q4 |
What changes
will we see as a result of OCO modules in TPF? |
| A4 |
There will be
an additional file on the PUT tape you receive from IBM. This file,
which will be fully described in the unpacking instructions you
receive with each PUT tape, will contain OCO modules being shipped
with the TPF product without source code. This file is separate
from another file on that tape that already exists and contains
preassembled TPF modules for which source code is available.
We are investigating whether there might be a need for a
separate library for these OCO modules to avoid conflicting names
between the OCO functions being ported and existing TPF software.
If this is necessary, there might be more changes necessary to our
product distribution methods.
|
|
|
| Q5 |
Are there any
other changes that we will see? |
| A5 |
Yes, but this
one is the result of porting software from other platforms
regardless of whether source code is available. It may be necessary
for you to modify your library control systems because the names of
ported modules are unpredictable. They may be longer than currently
allowed or may be duplicates of names already in existence, or
both. We have had to make some changes to our library control
system and will be glad to share our experiences with you. |
|
|
| Q6 |
Are there
things we should be aware of as we make plans to install and use
ported (OCO) functions? |
| A6 |
Yes.
* When porting code, the portion that interfaces with the
operating system is where most of the TPF-specific changes for this
functio n will be made.
* Each project will be implementing error recovery facilities
that, following an error, will provide the ability to return the
system to a point where things used to work. These facilities will
do such things as disable/recover or migrate/fallback individual
functions, or fix/recover/purge such things as database problems.
You should familiarize yourself with these facilities and construct
error recovery procedures for your system.
* Messages and system errors that are issued from existing
packages ported to TPF may not comply with TPF standards.
|
Usage
| Q1 |
If we will
not have the source code, how will we be able to write programs
that use these new functions? |
| A1 |
Publications
have been provided with TPF describing the application programming
interfaces (APIs). This will not change . . . API do cumentation
will still be available for those functions we port to TPF; it is
just that we may refer you to a publication for another product for
this information.
What you may see reflected in TPF publications, particularly
inTPF Messages, are messages and system errors that have
been im plemented and/or modified as a result of porting new
functions to the TPF platform.
|
|
|
| Q2 |
Will we have
to buy a license for that other product just so we can get a copy
of the API documentation? |
| A2 |
We are not
aware of any IBM product that requires a license for obtaining the
API publications for that product. |
|
|
| Q3 |
Will we be
able to create user exits within these modules? |
| A3 |
No, you will
not be able to create new user exits within modules for which no
source code is available. As we go through our product development
cycle, the TPF Lab will be more proactive in establishing user
exits in TPF code. We will try to anticipate where TPF users, both
customers and vendors, may want a user exit instead of what we do
today where you tell us after the fact that a user exit is needed
and where. |
|
|
| Q4 |
How do we
enhance or otherwise modify functions provided by OCO modules? How
can we tailor these to better fit our installation? |
| A4 |
It will not
be possible for you to modify functions provided without source
code. The functions we port to TPF tend to be cross-platform
functions and, therefore, maintaining cross-platform
compatibilities, modifications, or enhancements by you are not
permitted. |
Diagnosis
| Q1 |
How will we
be able to solve dumps if we do not have the source code? |
| A1 |
The error
numbers and error messages that accompany any dumps should provide
enough information for you to identify and correct or ci rcumvent
the problem. In some cases, however, it may be necessary for you to
contact your IBM representative. |
|
|
| Q2 |
What will we
do if we encounter problems with this new code once we start to use
it? |
| A2 |
Each function
will provide capabilities to disable/recover or migrate/fallback
that function. |
|
|
| Q3 |
What will we
do if there are performance problems with this new code once we
start to use it? |
| A3 |
This should
not differ from what you do today. Gather as much information as
possible (through such procedures as a data collection or a manual
dump) and contact your IBM representative. Consider disabling the
function if performance is sufficiently degraded. |
Maintenance
| Q1 |
Our TPF
system is not at the current maintenance level. Will we still be
able to install maintenance APARs even though our system is
back-level? |
| A1 |
As stated
previously, it has always been the TPF Lab's position that all
APARs must be installed to maintain system currency and inte grity.
With the advent of OCO modules, it is now even more important for
customers to maintain their systems at current maintenance levels
as much as possible. We realize, however, that this is not always
possible. As a result, our customer service organization will be
able to help you identify the prerequisite or corequisite APARs
that you must apply to your system before attempting to apply a
specific APAR. |
|
|
| Q2 |
We have run
into an error with an OCO module and we need a fix for it now. We
cannot wait for the next program update tape (PUT). How will we get
the fix? |
| A2 |
With the
understanding that prerequisite and corequisite APARs must be
applied, fixes will be available in the same manner in which they
are today: through RETAIN, IBMLink, your TPF SE, or TPF Customer
Service. |
|
|
| Q3 |
Can we still
selectively apply APARs? |
| A3 |
This will be
much more difficult now, especially if any of the prerequisites or
corequisites for the APAR you want to apply contain OCO modules.
Whenever an APAR contains an OCO text file, you must apply that
entire APAR, not just parts of that APAR. Additionally, if an OCO
module is affected by multiple prerequisite or corequisite APARs,
you must apply all parts of those prerequisite and corequisite
APARs. |
|
|
| Q4 |
Our shop does
not blindly apply all APARs that IBM ships. We use the "if it's not
broken, don't fix it" principle. Will this still be possible? |
| A4 |
No. As
described in the answer to the previous question, it is not
possible to know what the interactions are between OCO modules and
the rest of your TPF system. Therefore, you will not be able to
make an educated determination of the applicability of any given
APAR. |
|
|
| Q5 |
What will be
necessary if we have to apply a critical APAR? |
| A5 |
Upon
identifying the critical APAR that you need to apply, you will need
to determine all of its prerequisite and corequisite APARs t hat
have not yet been applied to your system, and apply those
prerequisites and corequisites. If any of these APARs contain OCO
text files, you must apply that APAR in its entirety. Once you have
satisfied the prerequisite/corequisite conditions, you can then
apply the critical APAR. |
|
|
| Q6 |
What has to
be done to the OCO text files I receive? |
| A6 |
One of two
things will be necessary. After putting the text file on your
system (for example, as a member in an OS/390 partitioned data
set), you will either use a TPF loader to load it directly from
that data set, or you will link-edit it with other object modules
to create a load module and then use a TPF loader to load that load
module. . |
Field Support
| Q1 |
How will we
be able to solve dumps if we do not have the source code? |
| A1 |
A significant
amount of time is spent making sure the publications that are
available contain enough information for you to be able t o resolve
or circumvent error conditions encountered in OCO modules. If for
some reason you need further assistance, it will be necessary for
you to contact TPF Customer Service in the TPF Lab to help resolve
problems in OCO modules. |
|
|
| Q2 |
Will 24x7
coverage now be available for the TPF product? |
| A2 |
There are
currently no plans to make any changes to the TPF Lab's customer
service structure or policy. This decision is based on the
following considerations:
* When outages occur in a test environment, the need for
immediate resolution is reduced considerably.
* With the error recovery facilities that are being provided, it
is our belief that none of the functions being provided as OCO can
b ring down a TPF system and keep it down.
|
|
|
| Q3 |
Central site
service will not work for OCO functions. We have to be able to
reach someone knowledgeable when the TPF Lab is not open (any time
other than Monday to Friday, 8 a.m. _ 5 p.m. Eastern time), and we
are trying to resolve problems. How will this be possible? |
| A3 |
With current
plans, this will not be possible. Instead, before implementing one
of these functions, you should become familiar with the error
recovery facilities that are being provided with the OCO functions
and construct error recovery procedures that will be executed if an
error occurs. |
|
|
| Q4 |
How will
requests for additional on-site support will be handled? |
| A4 |
See your IBM
TPF representative to make arrangements for additional on-site
support through a services contract. |
|
