Re: SQLRPG error MONMSG possible ?

["Peter Dow" <pcdow@xxxxxxxxx>]

Hi István,

My apologies for the length of these e-mails, I'm probably not being very
concise, however, I'm am trying to make sure I'm being clear.

I agree that the AS/400 job logs are great, except when some one fails to
log CL commands, or sets the logging level to omit stuff. However, filling
it up with "normal" exceptions as caused by a WRITE statement that gets a
duplicate key error, makes it harder to see the useful stuff.

When speaking of using the WRITE stmt with an error indicator or with an "E"
extender, I did not mean to imply that the program should ignore it. What I
meant to point out is that after issuing the WRITE stmt, OS/400 checks for a
duplicate key condition, and if one is found, it generates an exception,
logs it to the job log, sets on the error indication (either the indicator
or the %error flag) then returns to the program. At this point, programs I
have seen that use this method usually add 1 to a sequence# (a key field)
and loop back to try the WRITE stmt again. I don't think I've ever seen a
program that ignores the error indicator or flag. The OS/400 process of
generating an exception and logging it to the job log is in my experience
(relatively) time consuming, especially compared to a SETLL.

I understood the "cheated" file method having both used it and seen it used.
Usually a SETGT followed by a READP or REDPE, then adding 1 to a sequence#
for the new key. This can also be done by determining the new key before
loading the record, and therefore only using one file; however, that
increases the amount of time between determining the key and actually
WRITEing the record, giving another program more time to get the same key.

Dilbert is a cartoon character created by former Pacific Bell (telephone
co.) employee Scott Adams. Check out www.dilbert.com and let us know what
you think!

Regards,
Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax


From: István Rudas <Istvan@Rudas.net>
> (somehow I feel uncomfortable of this big text because this all is
> well-known like how to broil water?? playing piano with boxer's gloves!?)
>
> I like your comment on job log lenghth, but same time I like the job log
of
> the AS/400 compared to earlier machines (the S/36 mainly), where I can
see,
> that IBM has done a good effort to give us more details/assistance: its
> better to search in hundred pages than to have one singele cryptic message
> like often in the S/36 historyfile (thanks God my last S/36 customer
> converted to AS/400 last year!). Yes, the AS/400 job log is babbling a lot
> and sometimes unnecessarily for me but I am confident, that in future
there
> will be more intelligence (artificial?) in the job log mechanismes, maybe
> some thesaurus/fulltext search, homonyms, acronyms, direct access to
> related technical manuals and the whole rest of modern search engines (all
> ideas welcome). --- Do you remember "Guru Meditation #4711000" on
> Commodore? ;-)
>
> In your cases  that "WRITE with error indicator" is the bad one for me, if
> there is after it no error handling when the error indicator comes *ON;
> catch an error and throw it away?  Am I wrong?  --- In the original
> question, the partner asked "SQLRPG: MONMSG possible?" and I answered yes,
> there is an IBM-defined SQL Datastructure with fields passing back error
> codes. Today, I would add yes, catch it and then do something with it. I
> think, that's the proper way.
>
> The "cheated" file: I mean a CRTDUPOBJ with no data for having it during
> compiling, KRENAME the record formatname and I-spec OrigField to NewField
> Name (=OPM!), then OVRDBF. This is for cases, where the programmer has
done
> first the filling/handling of the fields and looks later (assume that by
> other reason you cannot look first), how the new key has to be composed
and
> where to add or insert the new record (case if not just the next
> sequence#). In doing SETLL and then some READs to find out the right
> position, he gets existing records, which change the contents he has
> collected/evaluated before. There it is: when the fields are renamed, the
> READs do not destroy the originals.
>
> One of the disadvantages is writing a lot of lines, another when the
> Databasefile has changed, not to forget a new CRTDUPOBJ ("visual level
> check"??!)
>
> The multi occurrence Data Structure I did not use until today, by thinking
> about it I have the problem how to make it
selfdifining=parallel=consistent
> with an external descirbed Databasefile? Is there a way to bind File and
> External DS together (I dont know until today, sorry), and more, is there
a
> way to bind two DS together with "level check"?
> Until now, for me the usage of internal DS generally is a love-and-hate;
> files have a level check mechanism, DS has not. To let it up to the
> programmer (even if I am the programmer, ;-) is not my thing, if I can I
> avoid (visual level check, time consuming scanning through Source-Code).
>
> Having used prefixes only in Database-DDS-fields (since nn years of
> course!), in my imagination I expect that the (new) PREFIX in RPG-IV could
> be the better thing, it is valid for the whole file = all fields receive
> the prefix. If yes, it would shorten the above CRTDUPOBJ-strategy and help
> making it more sure/robust.
>
> One earlier comment of Rob Berendt I could not understand because I dont
> know what/who a Dilbert is? Maybe some joke?

> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---