I've read in previous threads in the past about the potential issue of $ across CCSIDs. Of course, that was after having implemented the convention at my current shop.

I get yelled at enough for my wordy procedure names. I can't say I'd be a fan of such a lengthy prefix as 'srvpgm', although as suggested by John, exx (or exp) wouldn't be a bad alternative. But like I said, I really don't see our prefix of $ being an issue. Maybe it's short-sighted of me, but we're a small company, and our code resides on one box. Both programs and source reside in-house, so I don't really see an issue with using $ as a prefix.

Not that I don't appreciate our exported procedure naming being brought up, but my intent on giving a picture of our wiki was simply to show what can be done with wiki for reusable code documentation (whether what we have is something people like or not - and if not, hopefully it sparks thoughts on what 'right' is for people who aren't a fan of the presentation). Also, our wiki server is JSPWiki.

-Kurt


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, January 06, 2012 3:24 PM
To: Midrange Systems Technical Discussion
Subject: RE: In-house Reusable Code: Publishing and Documenting

Perhaps he should have given a reason. One, is that the dollar sign ($) is not an invariant character. With a different CCSID it will display as a different character. (Perhaps the British Pound?) I think the old sorcerer's redbook gave a suggestion to begin pointers with a lower case p like MyString pMyString So, he is just suggesting you evaluate an alternative to your procedure naming. You could go cobol wordy and name it something like srvpgmMyProcedure.


Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 01/06/2012 04:06 PM
Subject: RE: In-house Reusable Code: Publishing and Documenting
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Nathan, you're welcome to not like our naming conventions. :)

Our exported procedures begin with a $. That's just something "I grew up
with." That said, I like it. When in a program (not a service program),
a procedure call starting with $ is clearly an external procedure. This
has helped some people I've worked with that are new to the idea of
service programs.

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Friday, January 06, 2012 1:37 PM
To: Midrange Systems Technical Discussion
Subject: Re: In-house Reusable Code: Publishing and Documenting

From: Kurt Anderson
Here is a screenshot of one of our pages:


I hope my question is not too off topic, but I looked at the screen shot
and saw procedure names starting with the dollar sign $. Personally, that
drives me crazy. What is the story behind shops that begin procedure names
with $ and #. I see that often enough that I gather there is some
significant meaning or history behind it, but I've been left out of the
loop.

What am I missing?

-Nathan

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.