Re: BPCS error message F1

[DAsmussen@xxxxxxx]

--
[ Picked text/plain from multipart/alternative ]
Al,

In a message dated 1/27/02 2:25:24 PM US Eastern Standard Time,
MacWheel99@aol.com writes:


> Thanks for your illumination.
>
> A lot of the modifications that I have done, have been of the form of
> plagarizing techniques I have seen BPCS doing in one place ... generally I
> like to keep the volume of techniques in any one program down to what is
> already there unless complex needs demand more complex solutions.
>
> I have done some modifications using techniques that I have not yet
> encountered in what SSA has written.
>
> This means that in some programs where SSA was using ERRMSG
> against SSA's error message numbers, I created my own subroutine & sub
> program doing the same thing against our added error messages, then copied
> that to other programs needing similar service.
>
> Can you point me at a better source for my future plagarism?
> In other words, I am modifying the RPG code that comes from AS/Set
> and would prefer to be using techniques that are less susceptible to future
> trouble.
>
> Al's initial challenge was with JIT600, which we have modified, but the
> error
> messages in question were native BPCS messages:
> <<snip>>

I'm glad you asked.  Number one, you should not be modifiying
AS/Set-generated programs outside of AS/Set.  The latter will come back to
haunt you if you load a BMR.  Number two, AS/Set "newbies" can generate this
type of error if they utilize "screen level verification" of variables,
instead of program variables.  I forgot to mention the latter in my earlier
post.

The "time honored" tradition is that, if all else fails, look at INV100.
INV100 follows SSA standards even when other programs do not.  In order to
follow messaging standards, you _MUST_ utilize a CL program.  For AS/Set
programs, that CL program is CLMSG, although we usually modify it to fit the
client's needs and ensure that SSA does not modify ADK in a manner that would
adversely affect program performance.  Do _NOT_ modify those AS/Set programs
outside of ADK, and when using ADK, do _NOT_ use screen-level verification...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"The future has a way of arriving unnannounced." -- George F. Will