× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



| -----Original Message-----
| From: rpg400-l-bounces@xxxxxxxxxxxx
| [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Hans Boldt
| Sent: Friday, October 24, 2003 9:20 AM
| To: rpg400-l@xxxxxxxxxxxx
| Subject: Re: Benefits of Sub-procedures
|
|
| jt wrote:
| > ...  Similarly I would
| > ask, why would anyone want to code this:
| >
| > parms.transNo = %editc((%dec(transNo:%size(transNo):0) + 1):'X');
| >
| > in order to increment a transaction number...???  I ask this
| seriously:  Why
| > do you need "rocket science" to add 1 to an alpha transaction number??
| > Iirc, seems like only one person on this list even came up with an
| > /alternative/, a simple data structure.  I guess because if it ain't
| > "modern", it ain't cool...
|
| That's really the wrong question. A more appropriate one is this:
| Why would anyone want to implement a transaction /number/ as an
| alpha string?

You ask the "correct" question, Hans.  However, the better question still
is:  how much would it cost to develop a database that more closely mirrors
the functions of the business.  And:  Do you have control over the
transaction number data element (ie, does this come from an external source,
through EDI or such, and CAN that be changed to be numeric).

These are the questions a 400 software engineer and/or DBA and/or
"grunt-for-hire" and/or *one-man-shop* faces, daily.


| Many other languages with strong type checking require
| similar machinations. For example, in Python, you might code
| something contrived like:
|
| n='%.*d'%(len(n),int(n)+1)
|
| (That is, convert the number string to an int, add one. Then format
| it as a numeric padded to the length of the original string.)
|
| If you want looser interpretations of numeric and character types,
| you could go to Perl or Rexx, which allow mixed character and
| numeric operations. But then you'd still have the issue of keeping
| leading zeros.
|
| A more appropriate solution for this problem (in any language) would
| involve a procedure (remember procedures?)

Yes, I remember procedures, Hans...;-D

| which returns the next
| available transaction number as a string. Then, the users of the
| procedure are spared the gory details of the actual implementation.

What advantage does a procedure offer in this case...?

Well, that depends...

I try to design systems where the links between business, UI, program code,
and database are kept to a minimum (and I believe most good 400 architects
do also.)  So I like a database that is updated in as minimal number of
programs/modules as possible...  Ideally, there would be between 1 and 3
places the transaction number would be incremented and updated, in the first
place.

This is not always practical, but (from my limited understanding) the MVC
(YATLA (yet another TLA previously defined on this list..;-)):  There are
some efficiencies to having the database update isolated in a single module.
I believe Joe Pluta would concur, among others, and (last I saw) architects
of JDE used similar.


| Likewise, a Python programmer would (or should) never code that
| crufty statement above. A more typical coding practice would be to
| code a "transaction number" class. Getting a new transaction number
| would then just require a statement like "transnum=tn.next()". The
| details of how the transaction number are implemented belong in the
| class, and not in the calling code.
|
| For example, in Python you might code something like:
|
| class Counter:
|      def __init__(self, start=0, size=5):
|          self.count = start
|          self.size = size
|      def next(self):
|          self.count += 1
|          return '%.*d'%(self.size,self.count)
|
| c = Counter(start=234,size=7)
| print c.next()
| print c.next()
| print c.next()
| print c.next()
|
| (Sorry for posting Python code in an RPG list. But it's easier to
| whip up a Python example to illustrate my point. Don't sweat the
| details - just think of it as "executable pseudo-code".)

I wish you could tutor me in Python some more!

However, all this still looks like rocket science, to me Hans, because I
compare all this to the following non-pseudo code:

Move  TrnNbrParm  TrnNbrNum   10 0
Add   1           TrnNbrNum
Move  TrnNbrParm  TrnNbrWrk   10

(Btw, I would avoid designing a need for the two different alpha TrnNbr
fields, in the first place, and would avoid like the plague giving them the
same field name, because that ends in /more confusion/.. but then, mebbe
that's just me.)

|
| >
| > Businesses are not primarily about coddling people who care a
| /whole/ lot
| > more about looking cool than they do producing a solution, (one
| that works
| > like the Energizer Bunny (tm, I sure...;-)), and producing it on a
| > reasonable timeline (ie, cost).  At least, in my experience.
| >
|
| Exactly. And that's why programmers in practically all other
| programming languages use procedures extensively.

And why I have always like procedures, though I don't actually use them much
in the shop I work in!!!

However, anything can be overused, as well as underused...  Some prefer a
broad, flat HIPO design and others prefer an incredible complex and deep
HIPO design.  (Guess which I prefer.)

Something old RPG and COBOL programmers learnt, long before PERL was even a
gleam in someone's eye:  TIMTOWTDI (probably got that wrong, more than one
way to skin a cat).  In /this/ respect, the PERL Community offers no
new-found wisdom.


| This gets back to my theory that a large number of programmers
| really don't want programming to be easier, and I suspect that's
| true especially among RPG programmers.

Come again??

| Are more modern (that is,
| 1970's or later) programming techniques like procedures considered
| too "cool", and thus suspect?

As I said above, not in the least.

| Is RPG programming supposed to be
| hard?

System design architecture, systems analysis, and coding programs IS hard
work.. and that's why these people get paid good money (comparated to most
occupations), and doesn't matter the architecture philosophy, methodology or
language, in the least.

I don't believe you've had the experience, Hans, of having the business say
(for example):  We just sent out a flyer which implements a new feature for
the customer, a couple weeks ago.  We need the systems to start tracking
such-and-such, as soon as you can get to it!

Some corporate cultures would never do that, and (in my limited experience)
the banking, manufacturing and retail industries have different tendencies
to "fly by the seat of the pants", in general...  But I'd be surprised if
/any/ of the technical leaders on this list has /never/ ran into this
situation.


| Are RPG programmers who make programming look hard considered
| more capable than programmers who make it look easy?

I hope this can be taken in partial-tongue-in-cheek that I intend it:
Apparently, (if one considers n='%.*d'%(len(n),int(n)+1) as looking
hard...;-)

IOW:  NO, but I'm sure we've all ran into programmers, and SAs, and DBAs,
and architects, as well as managers and marketers, who WANNA believe that
what they do involves some black art, and if they can make others believe
that what they do is REAL HARD, then they can get better money for doing it!

Yes, I've seen quite a few programmers and contractors of that mind-set, but
I don't believe in that, m'self.  These, in my experience, tend to change
jobs and engagements quickly, because over the long-run those who don't know
what they are doing are found out.  (Again, doesn't /always/ work out that
way, and that's just my limited experience in contract coding, and for
brevity (ooops...;-) I'll spare all y'all some-a the specifics I'm thinking
of in writing above.)




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.