Daniel Staal wrote: > That's a signed number, with 9 digits before the decimal point and 4 > after.
Thanks. That is useful background. Unfortunately it does not explain the what was shown in the OP, since there were only twelve digits in the sample COBOL strings, not the thirteen that would be indicated by a likely interpretation of the format specifier in the OP, or by your explanation of the format specs. > > ... > Close: their the filesystem signed value indicators unpacked numeric > records for COBOL files. Or at least this format of COBOL files. > > ... > Which is exactly what he is trying to do. In fact, it sounds like he > already has a way to do it. He's just asking if there is a *better* > way. > > > Practice thinking in full concepts, expressed in full words. You > > will get more long-term mileage out of this step than any code > > solution could possibly provide. > > > > Joseph > > He did. He's asking for semi-high level advice here: what is the > *best* way to do a particular conversion. Anyone who can answer the > question probably has done the conversion themselves, Not true. Those are strings. Strings, with a clear explanation of their formatting rules, are emminently amenable to simple logic without recourse to any particular esoteric body of knowledge. > and would > understand the few things he left unexplained. Anyone who couldn't > understand what he left unexplained would have no answer; they've > never done it. I am sorry to hear about this gap in your capacities. Please, though, do not project it on others. You are vastly overrating the value of particular jargons, while failing to understand the capacity of the human mind to translate basic logical constructs between expression patterns. > He explained enough to be clear, but not enough to be > redundant. (Though I would like to know what system he is getting > the file from, it could be pertinent.) The OP is fortunate here. Jeff Westman seems to be familiar with the subject matter, and he provides some advice that sounds pretty useful. > > > A search of CPAN for COBOL doesn't turn up anything particularly > promising, but that is occasionally the case. Modules are sometimes > hard to find, and may not be under the obvious-at-the-time keywords. > > This is a common question class on this list. I see it often: some > question that the details of make little or no sense to me, but does > to people who know what the poster is talking about. The general > population of the list may or may not be able to answer, but the > poster is looking for those few who *can* answer. They provide > enough for someone who knows the problem space can answer, but don't > bother to define everything because it would bore people, and not get > any better answers. Wrong again. For one thing, by the time the OP has taken the effort to articulate the problem in a manner that does not rely on esoteric knowledge, the solution, particularly in the case of format conversions, will probably reveal itself in the process of articulation. If not, it will provide background to open the question to a broad array of brilliant minds, many of them unhampered by the compulsions towards turf protection.. > There are a few of us here who will admit to knowing COBOL. We can > answer the question as asked. For those who don't, Oliver can > probably do as good a job of coding a conversion routine as they can. > > Daniel T. Staal So where is your answer? I see a maybe reference to one module that presumably handles many tasks in this particular conversion interface. What if this module doesn't answer the need? Should the OP) just shrug his shoulders then, and walk away with the certainty that if it hasn't been done, it can't? I would suggest that an exercise in accessible communication open up many promising avenues for him. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
