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 assembler 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 >>
]
|
