HP3000-L Archives

January 2003, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Roy Brown <[log in to unmask]>
Reply To:
Roy Brown <[log in to unmask]>
Date:
Mon, 27 Jan 2003 18:22:30 -0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
Denys Beauchemin wrote:
> I don't know RPG at all.
>
> But from what I am reading from your excellent post is that RPG will
> totally hide the requirements of doing DBFINDs and DBGETs on specific
> paths by virtue of using the CHAIN construct.  It would that as Vamsi
> is trying to get a specific record form a master data set PCMASTER,
> somehow the CHAIN command is misinterpreting the request and instead
> of using a key value to do a DBGET 7, it is using said key value to
> do a DBFIND 1, followed by DBGETs on the master.  Is there no way to
> expect a DBGET 7 on a master with RPG?  If there were, I would hope
> that RPG would not confuse master and detail and would adjust itself
> "under the hood (bonnet, isn't it?)' correctly.

Bonnet, indeed. The other end from the boot...

While there is no doubt that doing a DBFind on a Master *will* cause this
error, the implication of the above, unfiltered, would be that the RPG CHAIN
construct has *never* worked on Master datasets. Somehow, I doubt this......
(and I might even have read the damn things in this benighted language myself,
though as it will have been nigh on 20 years ago, please forgive me if I'm a
little vague).

Given the general quality of HP's languages, I'd say that we have to look for
RPG being fed wrong parameters, rather than the language itself being at
fault.

For instance, has Vamsi set up all his File Description Specification and
Continuation lines correctly for this dataset in this database?

Certainly, you don't tell RPG much more than this; that you are talking about
a dataset in an Image database, and then RPG goes off and looks at the
database, works up the access path it needs, and proceeds along it.

It's a shame RPG hides things to the extent of not saying *what* intrinsic
couldn't get access; obviously a TurboImage one, but which one?

My TurboImage manual (C.65.00 PDF manual set) may be ageing a little. But
while it lists -21 under DBError, with several different literals according to
the exact circumstances, of which the one Vamsi reported and Patrick
reproduced is listed, none of the individual intrinsics which can return -21
say much more than 'Bad Dataset Reference'. So it might be another of them
that Vamsi has hit. DBError just says that it knows which message to show
according to additional information in the error return, but it doesn't say
what.

Hmm... just reading some more in the RPG Manual, and I think I might have
found it: Input/Output Mode field (col 67) of the File Description
Continuation Line for the Image Dataset - 4,5,6,7,8,C,R - the DBGET modes we
know and love, plus a couple of RPG 'specials' for 5 and 6 with duplicate
handling.

So it's not *quite* as 'magic' as I remember.  I bet Vamsi has put 5, or C
(because it's a CHAIN read, the RPG thing) instead of the 7 he should put as
this needs an Image 'calculated' (keyed) DBGET.

Bottom line? You do need to know how Image works to use this stuff then.....

Bottom bottom line? RPG has an implied 'processing cycle'. If you can get on
this cycle, it's brilliant. It just carries you along. So to read a file
sequentially, and even to collate it with another file in the same sequence,
and write an output file, print or disc, you don't have to specify very much
more than the input files and the output files, and maybe some calculations
you want done on each input record to get the output values. The whole of the
file handling is implied for you.

It's not even too bad if, at Calculation stage, you want to nip off and do a
few lookups.

But, but, but.....  you can't do everything you might want to do in a program
that way. No worries; RPG gives you the Exception 'E' statement, via which you
can do pretty much anything you want. Theoretically.....

COBOL is like a millpond. It just sits there. If you want anything done, you
have to say what. But that means it's no harder to go one way, particularly
than another.

OTOH, RPG is like a millwheel. Go with it, and you get taken from A to B
almost effortlessly. Go against it (with those 'E' statements) and not only
have you got to get the job done, you have to fight to halt, and maybe even
reverse, that giant millwheel. By hand.

This is nature's way of telling you when to write in RPG, an when not to.

Of course, all this applies to RPG II, (and therefore RPG/iX). The RPG III you
get on an AS/400, or whatever it's now called may be a very different beast.
At least, I hope so.....

--
Roy Brown

Posting with the OEnemy, tamed by OE-QuoteFix 1.18.3
http://jump.to/oe-quotefix

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2