AS/400 Observability
DAdams7363
Could anyone please give me a little information about "Observability."
Management where I work does not provide us with many manuals and I have tried
to look into "Observability," online, without success. Technical staff recently
upgraded our software from R2V3 to R3V2, which, I believe, is itself already
outdated.
Any information provided would be greatly appreciated. I am trying to keep
myself educated, something that is difficult considering that we have almost no
technical manuals on the AS/400.
Thank you.
Wayne Johnson
Observability is something that has been around since the first days
of the AS/400 and, to my knowledge, has been around since the days of
the 38.
Observability is that part of the object code that permits you to use
debugging tools. It is also that part of the program that tell you
that you had a decimal data error in line 47000. If you remove
observability, the object code is smaller because all of these 'tags'
are no longer in the object. You will also have a tough time
determining where a program fails (assuming, of course, that there is
a failure).
There is another part of observability that is not commonly thought
of: IBM supposedly includes a copy of the source code within the
object so that it can be re-compiled should there be a massive change
in the operating system. IBM could then re-compile all programs as
part of the system upgrade.
If I am not mistaken, V1R0M0 was immediately replaced by V1R1M0 and it
took about 30 hours to do this on our B40. I suspect that the
programs had to be re-compiled as it didn't take this long to
orginally load the operating system.
What do you do with observability ... good question with no solid
answer.
If the programs are behaving as they should, then remove
observability!!! This creates a smaller program which requires less
memory and it doesn't have to keep track of the program line numbers
which could permit it to run a little faster. But what if it craps
out on me?? Then I would compile to get the observability back and
run the program again to get more information on the problem.
I know that I'll get arguements about this but I still believe that
one should remove observability once the programs are running well.
Most programs run day in and day out with no problems. It is these
that I remove observability from.
Also, try to optimize the program. Optimizing analyzes the object and
sometimes it can help.
Wayne Johnson
danh...@millcomm.com
In <19980301160...@ladder02.news.aol.com>, dadam...@aol.com (DAdams7363) writes:
>Could anyone please give me a little information about "Observability."
>Management where I work does not provide us with many manuals and I have tried
>to look into "Observability," online, without success. Technical staff recently
>upgraded our software from R2V3 to R3V2, which, I believe, is itself already
>outdated.
>
>Any information provided would be greatly appreciated. I am trying to keep
>myself educated, something that is difficult considering that we have almost no
>technical manuals on the AS/400.
Observability is basically two sets of information. First there is the
debug information -- variable maps, line number info, etc -- that is
needed not only to debug but also to get the optimally useful exception
messages and dumps. Note that, unlike other systems, debug on AS/400 does
not imbed extra instructions in the code to facilitate debug (though
debugability decreases as optimization level increases). Thus there is no
performance penalty due to leaving this observability information present.
The second set of observability information (partially overlapping with
the first) is the "creation template" for the program. This information
is the "intermediate representation" of the program and is "machine
independent". It is this set of information that allowed System/38
programs to be brought forward onto AS/400 and that allows CISC AS/400
programs to be run on RIS AS/400s. In essence, this set of information
allows the program to be recreated "from scratch" even though the source
is unavailable.
Obviously, if you anticipate moving from a CISC to a RISC system you
should make sure you have and keep observability. If you don't intend to
do this, or your are confident in your backups, then you can delete
observability to save storage. Another option is to compress the
observability information (an option that I believe is available on some
releases, though I don't know which ones).
Dan Hicks
Hey!! My advice is free -- take it for what it's worth!
http://www.millcomm.com/~danhicks
Charles M. Wilt
You've got a couple of good answers about observability, so I will only
focus on your question about V3R2 being outdated.
Basically, there are 3 types of AS/400's
CISC AS/400
RISC AS/400 AS
RISC AS/400e series.
The e series is the latest and runs only V4 of OS/400. The original V4 was
V4M1, the latest which was just released is V4R2.
The RISC AS series was released with V3R6, then V3R7 became available for
this system. Also, the AS can run the new V4 systems.
The latest version of OS/400 for the original CISC processor is V3R2, this
was released at the same time as V3R7 for the RISC processor and has
comparable features.
So, to answer your question. You are running the latest version of the
operating system that you can without upgrading your hardware.
--
Charles Wilt
Miami Luken, Inc.
Springboro, OH. 45066
e-mail: charle...@worldnet.no.spam.att.net
--remove the .no.spam
DAdams7363 <dadam...@aol.com> wrote in article
<19980301160...@ladder02.news.aol.com>...
> Could anyone please give me a little information about "Observability."
> Management where I work does not provide us with many manuals and I have
tried
> to look into "Observability," online, without success. Technical staff
recently
> upgraded our software from R2V3 to R3V2, which, I believe, is itself
already
> outdated.
>
> Any information provided would be greatly appreciated. I am trying to
keep
> myself educated, something that is difficult considering that we have
almost no
> technical manuals on the AS/400.
>
> Thank you.
>
Raul Cristian Aguirre
There are practically no performance gains in removing observability. If
you do that just to improve performance, optimizing the product could be
a better idea. The OS/400 does not waste CPU cycles in "keeping track"
of source code lines for each compiled instruction it executes. Simply,
there is a internal table where the error handling routines can locate
that corresponding source code line for the offending instruction, and
that info is also useful for debugging purposes.
I do not recommend to remove program observability as there are tools
in the market (and in the OS/400 itself) that allow you to do amazing
things in production programs if you do have observability (like
decompiling the object program, showing the actual source code in
execution, debugging it, changing variable values in a batch program to
avoid a never ending loop, show dictionary tables, and much more). It is
a safety net, as you never know when another significant technology
change will occur, like going from CISC to RISC. People without
observability in object programs had to recompile every single program;
people who lost source code, lost it forever.
A program could be succesfully tested and in production for years, but
how sure can you be that all cases have been tested in a complex
application environment? You are never sure. A hidden logic bug may
appear at any time. Also, a data-driven bug can also appear, or a
user-driven bug or a cancellation message because another program (that
calls or is called by our "perfect" program) is buggy or changed or
whatever. Two library entries in the library list can be switched, and
that could generate arcane results, very difficult to debug unless you
use an interactive source debugger utility on the spot. An object can
get damaged too, and the observability even allows the OS/400 to fix the
object code itself.
I hope this helps.
Raul Cristian Aguirre
Tango/04 Computing Group
Wayne Johnson wrote:
> Observability is that part of the object code that permits you to use
> debugging tools. It is also that part of the program that tell you
> that you had a decimal data error in line 47000. If you remove
> observability, the object code is smaller because all of these 'tags'
> are no longer in the object. You will also have a tough time
> determining where a program fails (assuming, of course, that there is
> a failure).
>
>
> If the programs are behaving as they should, then remove
> observability!!! This creates a smaller program which requires less
> memory and it doesn't have to keep track of the program line numbers
> which could permit it to run a little faster. But what if it craps
> out on me?? Then I would compile to get the observability back and
> run the program again to get more information on the problem.
>
>
> I know that I'll get arguements about this but I still believe that
> one should remove observability once the programs are running well.
> Most programs run day in and day out with no problems. It is these
> that I remove observability from.
>
> Also, try to optimize the program. Optimizing analyzes the object and
>
> sometimes it can help.
>
> Wayne Johnson
>
> dadam...@aol.com (DAdams7363) wrote:
>
Bill Tech
When upgrading from 2.x to 3.0.5 or higher, you can bring the compiled code
to the higher version ONLY if it is observable. Otherwise, you must
re-compile your source in the new version. Even when you bring the old
observable code to the new release, it will recompile automatically when you
access the program for the first time. Observability basically means that
the object code has enough additional information to compile without needing
the source code. I believe that programs have to be recompiled to be used
in the 64 bit environment. You don't need to worry about this when
upgrading from 3.0.5.
Bill Tech
DAdams7363 wrote in message
<19980301160...@ladder02.news.aol.com>...
Richard Daniels
> You need observability when moving programs to V4R6 or above from any
> release below that. V4R6 is the first RISC release.
Of course, you mean V3R6 is the first RISC release.
danh...@millcomm.com
In <6di8tr$rnt$1...@bell.pconline.com>, "Bill Tech" <bt...@dataworksmpls.com> writes:
>When upgrading from 2.x to 3.0.5 or higher, you can bring the compiled code
>to the higher version ONLY if it is observable. Otherwise, you must
>re-compile your source in the new version. Even when you bring the old
>observable code to the new release, it will recompile automatically when you
>access the program for the first time. Observability basically means that
>the object code has enough additional information to compile without needing
>the source code. I believe that programs have to be recompiled to be used
>in the 64 bit environment. You don't need to worry about this when
>upgrading from 3.0.5.
You need observability when moving programs to V4R6 or above from any
release below that. V4R6 is the first RISC release.
Dan Hicks
Joep Beckeringh
Bill,
I think you've got it wrong there. Recompilation is only needed when you
move programs from CISC to RISC (or the other way round, which is possible
as well). Any release up to V3R2 is CISC; V3R6 and higher is RISC. V3R0M5
was basically V2R3 adapted for the then new hardware (the first black
machines); as far as I know there was no recompilation needed.
Joep Beckeringh
Bill Tech heeft geschreven in bericht <6di8tr$rnt$1...@bell.pconline.com>...
Bradley V. Stone
On Wed, 4 Mar 1998 22:30:47 +0100, "Joep Beckeringh" <jo...@tip.nl>
wrote:
>Bill,
>
>I think you've got it wrong there. Recompilation is only needed when you
>move programs from CISC to RISC (or the other way round, which is possible
>as well). Any release up to V3R2 is CISC; V3R6 and higher is RISC. V3R0M5
>was basically V2R3 adapted for the then new hardware (the first black
>machines); as far as I know there was no recompilation needed.
>
>Joep Beckeringh
>
You don't need to recompile if observability is intact when moving
from CISC to RISC. But if it isn't, you do need to recompile. No two
ways around it.
Bradley V. Stone
bvs...@usa.net
http://prairie.lakes.com/~bvstone/
1992 Yamaha FJ1200
1969 Suzuki T250
"People train don't run out of Wicheta... Lesn' your a hog, or a cattle. People train runs out of Stubville."
danh...@millcomm.com
In <2460AFB460AA1918.146A45A6...@library-proxy.airnews.net>, Richard Daniels <rlda...@wynth.com> writes:
>
>danh...@millcomm.com wrote:
>> You need observability when moving programs to V4R6 or above from any
>> release below that. V4R6 is the first RISC release.
>
Right. I finally broke myself of the habit of typing V3R2 when I meant
V4R2 and now I'm screwing up the other way. V3R6 was the first RISC
release (not counting the S/36-only release, whatever it was called).
JGMercer
Observability (as I understand it) is an RPG (could be COBOL too) program
characteristic which allows programmers to set and observe breakpoints for
debug purposes. If you display a programs characteristics you'll see
observability *Yes/*No as one of the fields. However, once a program is
"perfect" (is it ever), it can be recompiled without observability to save disk
space.
If you move to a RISC box (V3R6 or V3R7 or V4Rx) your programs require
observability. Our s/w our vendor provided a CL to recompile and restore
observability for RISC move-- it was easy.
Bob Gilsdorf
Compile and restore observability is easy only if you have the source in
the same place as when the object was first created. If you've moved it
or otherwise lost the source, you're screwed! If you've got programs
that need to be compiled over a specific environment, CL won't do it.
--
R. Gilsdorf
AS/400 System Engineer
Sophisticated Systems Inc.
R...@centuryinter.net
Unknown
Observability is composed of two parts, debug information and an
intermediate representation of the program code (between source and
processor executable instructions) the program template.
A program object would look something like this:
Program
Processor executable instructions
Debug information
Program template
When you run a program, only the executable portion is used. The
program does not take more memory to run because of the other
information, If the program bombs and there is debug information, the
error message will have more information.
The programe template can be used to regenerate the executable portion
and this is what allows to move a program object from a CISC AS/400 to
a RISC one (or RISC to CISC) without having to recompile from source
even though the processor instructions are completely different. Of
course, the system does translate ("recompile") from the template to
processor instructions, but it is done transparently. (Meaning it's
done under the covers, not that it does not take time or resources.)
Obviously, keeping observable information in the program object does
make them (substantially) bigger so you can remove it.
For OPM programs you cannot choose the type of observable information
you remove with the CHGPGM command, it's all or nothing. For ILE
programs you can select either one or both; which means you can still
copy programs that do not have debug information but have the program
template between CISC and RISC machines.
Thierry Bernard
Informatech
Ad van Dongen
Thierry Bernard wrote:
>
> Obviously, keeping observable information in the program object does
> make them (substantially) bigger so you can remove it.
> For OPM programs you cannot choose the type of observable information
> you remove with the CHGPGM command, it's all or nothing. For ILE
> programs you can select either one or both; which means you can still
> copy programs that do not have debug information but have the program
> template between CISC and RISC machines.
>
> Thierry Bernard
> Informatech
For OPM programs you can remove the debug information using CPROBJ, you
can remove the program template using CHGPGM, so your statement is not
correct.
ad
Ad van Dongen
ad