Re: SQLRPG error MONMSG possible ?

Hi Peter,

(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?

Best Regards,
István

At 11:05 08.4.2000 -0700, PETER DOW wrote:
>Hi István,
>
>I'm not sure why you need a 2nd "cheated" file. SETLL does not read a record
>from the file, it simply sets (or doesn't set) the file pointer based on the
>access path. Even if it finds a match, none of the fields from any previous
>chain or read are touched. I haven't seen many programs that would have to
>worry about the file pointer since it's rare that you are sequentially
>reading a file and adding to it at the same time.
>
>It's true that job log length is not a problem disk-space wise in these days
>of cheap (relatively) disks, but wading through hundreds or thousands of
>pages to see what happened is time consuming. But even that isn't the real
>problem to me. The problem is the performance hit that occurs when a program
>has to handle an error. And actually, in an interactive program, that's not
>a big deal either. It's those batch jobs adding thousands or millions of
>records where you really notice the difference.
>
>Truth to tell, most of the programming I've been doing over the last n years
>has been of the maintenance variety, enhancing or fixing vendor software.
>The 3 methods I've seen mostly are 1) WRITE with error indicator, 2) SETLL
>with equal indicator, or 3) lock a data area that contains next unique
>sequence#. The programs I've written use SETLL only, and they've never had a
>problem.
>
>If you are concerned about saving the contents of a file, another method
>besides prefixing is to use a named externally-defined multi-occurrence (2
>occurrences) data structure. Just change the occurrence# before doing the
>CHAIN or READ. Or have two separate data structures. This works in RPG III
>or RPG IV.
>
>Regards,
>Peter Dow
>Dow Software Services, Inc.
>909 425-0194 voice
>909 425-0196 fax

+---
| 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
+---