|
John Carr CDP wrote: > Hans > > I am sooooo happy for the two(or is it three) people in the world that have > a dire need for variable length/graphic fields in their programs. > (Maybe the same two that desperatly needed RPG/370) > As compared to the hundred's of thousands of programmers who have a need > (like yesterday) for not HARD CODING IN EACH PROGRAM WE WRITE initial > values for subfields when the data base ALREADY KNOWS what I want. > (Who the heck took it out, Wait till CUDS at COMMON!!) > > As you know, When we write a maintenance program against a file(maybe > from a package) that has 50 - 500 fields each with their own default > value, It would be nice to have an externally defined data structure > which we could just say RESET and have the DFT values be initialized > correctly for the next record add. Without hard coding those values > in each program. Of course you have heard this many times. sorry. Hi John! I'm rather bummed out about the EDS DFT function myself, so you don't have to sell me on the requirement. If it's any consolation, this should be a big priority for the next release. (Who knows, maybe we can squeeze it back into this release, but that's not very likely.) Regarding varying length char fields, this has been in DDS for a long time. Maybe few use it since the languages never supported it well? Now, with this new release, there will be no DDS data types that are not supported by RPG. Before ILE RPG, string manipulation was a major pain in the (um, er) language. The situation improved tremendously with expressions in ILE RPG. In fact, intermediate string results in expressions were kept in character varying form right from the start! But until now, we had no way of maintaining a varying length char value from one expression to another. The varying length types should make string manipulation even easier. > > The other things are great, and needed, Don't we aready have INDDS by > using INDARA in the DDS? INDDS was a relatively simple addition to the "Named Indicators" function. It offers several advantages: 1) It allows you to name conditioning and response indicators in your program, so you don't have to refer to indicators by their 2 digit code name; 2) You can have an INDDS for each file, thus minimizing "indicator cram". Our goal since the initial design of ILE RPG was to minimize the need to refer to those old-style, cryptically named 2 digit indicators. With the INDDS, as well as the new indicator BIF's (%EOF, %ERROR, etc), there are only a few places left where the old-style indicators are needed. (LOOKUP, SHTDN, and the TESTx opcodes.) Cheers! Hans Hans Boldt, ILE RPG Development, IBM Toronto Lab, hboldt@vnet.ibm.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the Midrange System Mailing List! To submit a new message, * * send your mail to "MIDRANGE-L@midrange.com". To unsubscribe from * * this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe MIDRANGE-L' in the body of your message. Questions * * should be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
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.