DFU functionality in RPG-II?

[Michael Kennedy]

G, it's kinda quiet around here! ;-) And this post is unlikely to
generate any traffic!

I need an RPG-II (S/36) implementation of the basic functionality of
DFU, with source code so that it can be tweaked. I've Googled a lot, but
found nothing.

Any suggestions very welcome.

Obviously, it would need to be adjusted for each file-spec, indexing,
record layouts, fields, validation, etc, but the basic logic and overall
functionality would need no changes.

Meanwhile, I've started a brief spec, and some elementary code, to
provide the functionality, so if anyone wants it when it's cooked,
you're welcome.

- Mike

[JHL]

how about a program that will create an rpg 2 file update program,
inquiry program or report program based on f & i specs?

caveat is that it will only accept 1 key field in the file, but of
course after the rpg 2 is generated, it could be modified.
also creates the ocl.

say $100 us dollars? email me offline michael, and we can discuss
more. joe leblanc michigan software jhl at michsoft com

p.s. and you thought there would be no reply. :)

[Michael Kennedy]

Sounds GREAT, Joe.

(Apologies for the delay).

There are a few "issues" to cover, which we'll deal with offline, and
then, presumably, post the final outcome here.

- Mike

[goo...@miamicomputer.com]

In my book there are two types of DFU programs. Those that update
master files (indexed) and those that allow you to key transactions.
Probably one fo the first programs I wrote on the s/36 when we moved
to it was a program that was for keying transactions where you could
add new records, update and/or delete records, be able to duplicate
fields, etc. And go find a record(s) based upon a field. Nothing fancy
but that same core frame has been used in countless programs. The
typical trick with these were to use an indexed file with a key of 1
byte in an unused positions. Of course dupkeys were allowed.

And the reason for not using dfu was because of blank records, no
validation etc.

> >>    - Mike- Hide quoted text -
>
> - Show quoted text -

[Michael Kennedy]

goo...@miamicomputer.com wrote:
> In my book there are two types of DFU programs. Those that update
> master files (indexed) and those that allow you to key transactions.
> Probably one fo the first programs I wrote on the s/36 when we moved
> to it was a program that was for keying transactions where you could
> add new records, update and/or delete records, be able to duplicate
> fields, etc. And go find a record(s) based upon a field. Nothing fancy
> but that same core frame has been used in countless programs.

Excellent!

In my situation, the client is very familiar with DFU, mostly for file
enquiries, and I want to emulate that facility, while, hopefully, adding
some features like in Query/36, scrolled lists of records, etc.

> The
> typical trick with these were to use an indexed file with a key of 1
> byte in an unused positions. Of course dupkeys were allowed.

Nice!!

> And the reason for not using dfu was because of blank records, no
> validation etc.

Understood. Yet, DFU is nifty, easy to implement, etc...

- Mike

[Allyn Uptain]

Since we never have discussions in this group anymore, I may as well add some unnecessary comments of my own. ;-)

I never liked DFU because of the lack of edits. But

>In my situation, the client is very familiar with DFU, mostly for file
>enquiries

In that situation, it's a useful tool.

But I don't think it would be that hard to make a scrolling, inquiry only pgm skeleton (model), that an intelligent person could change around as needed for different files. It doesn't seem hard to programmers anyway, since that's what most of do every time we write a "new" file inquiry pgm. Take the last one you made and change it around for this new file.

Merry Christmas, Happy New Year

and somebody ask a question every now and then! ;-)

later -

[Michael Kennedy]

Allyn,

Thanks for dropping by. Things are very quiet around here!!

(And, so far, I've still not used some files you sent me a long time
ago!! Thank you).

Allyn Uptain wrote:
> But I don't think it would be that hard to make a scrolling, inquiry only pgm skeleton (model), that an intelligent person could change around as needed for different files. It doesn't seem hard to programmers anyway, since that's what most of do every time we write a "new" file inquiry pgm. Take the last one you made and change it around for this new file.

Agreed. Still "a bit" of work, though. I did draw up a detailed
(generic) spec, and did some coding, but abandoned that when Joe
mentioned that he already had a similar animal.

I just got Joe's (Thank you, Joe), but I must first convert from AS400
tape to S/36, and then onto PC, and then....

I might then try to knit the functionality into Joe's code, where
required, useful, etc.

> Merry Christmas, Happy New Year
>
> and somebody ask a question every now and then! ;-)

Merry Christmas to you, and to all our (3!!) lurkers!!

- Mike