Design of assembler-programs.
When making technical designs we usually emphasize the structure of
the
data to be handled (control block structure), and the segmentation of
the
programs to be realized.
Depending upon the level of knowledge and experience of those who
are
eventually to build the program, the level of detail subsequently
will be
more or less extensive. For the experienced programmer it will
suffice to
summarize the desired functionality per module and CSECT. For the
less
experienced ones it may be necessary to explicitly design the
structure of
each subroutine.
For you Bixoft can make a technical design for any of the following
kinds
of programs:
- Non-reusable programs.
The usual kind of "vanilla" applications. For each
invocation a
fresh copy has to be brought into storage.
- Reusable programs.
These programs can be executed repeatedly though not at the same
time. The
program needs to be loaded only once.
- Reenterable programs.
These programs can be executed by several callers at the same time.
Think
e.g. of common routines in a multi-tasking application. Mainly,
however,
these programs are heavily used routines, placed in common storage.
Such as
exits (both of the operating system and of installed products) and
SVC-routines.
- Refreshable programs.
During execution these programs can be replaced by a fresh copy.
Only a
limited number of SVC-routines need be refreshable. You will
therefore not
likely ever have anything to do with this kind of program.
- Failsafe mechanisms.
For programs that should never abend, we can build a shell to catch
all
abends, and - whenever possible - repair them. All incidents will
be
reported to the controller through the joblog or through a separate
error
log. Because this is a shell, the application need not be changed.
- Callable services.
These can be all kinds of helper routines for your application. The
services
are activated simply by calling them. Callable services usually
offer access
to system resources, shielding the application programmer from all
the
resource's technical details. Another name for callable services is
API
(Application Programmer Interface).
- Compatibility modules.
This is a variant of the callable service. Compatibility modules are
implemented such, that changes in functionality or technical details
will
not hamper your application. The compatibility module will take care
of all
required backward compatibility. Thus, the extent of your
maintenance
projects may be reduced considerably.
- Transparent conversions.
This is a variant of the compatibility module. Transparent
conversions give
your applications the ability to carry on with their work while you
are
converting your database. These programs can also be used to enable
you
to make a back-up while your application is running.
The last three categories (callable services, compatibility
modules, and
transparent conversions) can be implemented as non-reusable,
reusable,
re-entrant, or even refreshable modules.
You can realise all this and even more with the help of
experienced
assembler programmers. And without any requirements regarding your
current
staff of application programmers!
That's why we advocate the prudent application of
programs.
Keeping always in mind, that whenever the target can be achieved by
other
means that must always be considered thoughtfully.
Remarks? Questions? More information? Select the topic of your
choice or
e-mail us with your
questions.
This site is a member of WebRing.
You are invited to browse the
list of mainframe-loving sites.
|
|
Dinos are not dead. They are alive and well and living in data
centers all
around you. They speak in tongues and work strange magics with
computers.
Beware the dino! And just in case you're waiting for the final
demise of
these dino's: remember that dinos ruled the world for 155-million
years!
|
Dinos and other anachronisms
[
Join Now
|
Ring Hub
| Random
|
<< Prev
|
Next >>
]
|
