× 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.




Hi Hans,

My two cents on this:

The DCL keyword: This would make my RPG look like CL. That alone would kill it for me.
Comma vs Colon: Only a proctologist would really care.
Calc Spec V: Already free so we just lose the /free and /end-free and make it compulsory.

At this point in time I really don't think I would want my $100 spent on freeing RPG. It is functionality I want, not lipstick.

I would spend my money on:

1) Overloading sub-procedures ($75)
This is an obvious need and is well overdue.

2) Namespaces for Service Programs and Modules ($20)
I would like to have a NAMESPACE keyword (H-spec) for a SRVPGM or MODULE and then qualify a procedure with that namespace. This would allow me to reference two service programs that export a similarly named subprocedure and not have conflicts.

For example, two SRVPGMS export a getName procedure. This conflict is solved with the following two lines:
NAMESPACE(MYSRVPGM1 : 'Contact')
NAMESPACE(MYSRVPGM2 : 'Customer')

I could then have:

contactName = Contact::GetName(parm);
customerName = Customer::GetName(parm);


We REALLY need this. We use so many SRVPGMS and it just gets harder and harder to keep procedure names unique across our SRVPGMs. We simply shouldn't have to.

3) Ability to put a Binding Directory into another Binding Directory ($5)
We have lots of Service Programs, and we generate quite complex inter-dependencies. For our prototype copybooks we can copy our prototypes into other copybooks to form new (more complex) copybooks. Unfortunately, we can't do the same with our Binding Directories. This is a real pain.

Example:
A Person 'object' is implemented in three SRVPGMS. Each has its own copybook and Binding Direcory. To include the Person objects in a program we use a /include of the PERSON copybook (which includes a /include of the three SRVPGM copybooks). We also reference the PERSON Binding Directory. This doesn't reference the theee original Binding Directories (because it can't) so it has to list the three SRVPGM objects again. If we split one of the original SRVPGMS into two we would have issues. The copybook is easy because we reference the two new copybooks in the original and all copybooks built on it would get the new values. However, ALL of the Binding Directories that list the original SRVPGM have to be found and amended. This could be solved by simply amending the original Binding Directory to include a refenrece to the two new Binding Directories and letting all references filter through. Just want to keep it consistent.

Hope that all makes sense, and Happy New Year!

Cheers

Larry Ducie



_________________________________________________________________
View photos of singles in your area! Browse profiles for FREE
http://clk.atdmt.com/NMN/go/150855801/direct/01/

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.