Having multiple variables point at various places in a single big buffer is quite easy to do with any simple value types, as evidenced by my previous example code with char buffers. But that is NOT true for strings. You just happen to stumble upon the place where .NET is more like a functional language: strings are immutable and you cannot modify them in place. As soon as you touch them, you get a new object. You also have to care religiously about padding with spaces because .NET will not do that automagically for you.
What you could maybe do is make your own CobolString class which will be mutable and when you need a real .NET string, you can call ToString(). Something similar has been done with the SecureString class who handles encrypted strings in a more secure way. That would probably work, that is, until you find the next problem. But I am still pretty convinced you have not looked at COBOL.NET seriously. I mean, language interop is supposed to be one of .NET strength, so why not exploit that instead of trying to fit a square in a circle? And Fujitsu is hard at work on this. They even have batch conversion tools and specialized libraries. Think about if porting Python code to C# would be practicable and easy... I doubt so. http://www.netcobol.com Frans: zSeries mainframes are FAR FAR *FAR* from being dinosaurs. http://www.ibm.com/systems/z/ Sébastien > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Jon Rothlander > Sent: Wednesday, November 15, 2006 8:17 PM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > >>The solution proposed is simply silly when you look at the 3Gl's > today. > > So how would you solve it? It's easy to say that the solution is silly > if > you cannot offer a non-silly solution. > > >> people shouldn't focus on how to implement a bad solution because > >>it's apparently hard to implement > > So what exactly is hard to implement in regards to a class with > properties, > which handles this easily? Sounds pretty simple to me and I've been > doing > that for the past year or so. I have not found anyone that struggle > with > that solution. > > My goal in posting this question was to see if .Net had some way to > support > multiple variables pointing to the same set of memory. That's sounds > like a > reasonable thing to me. If it did support that, it would save me the > time > of having to construct these data structure classes. > > So what solution do you suggest? > > In .Net if we want to write code out to an ASCII formatted flat file to > be > loaded into another system, how would you accomplish this if the flat > file's > character data is positional? Like my first example which listed > something > like... > > "First Name Middle Name Last Name " > > Someone in a previous post asked why anyone would want to do this. > Well, > that is the data I am given. I don't think I can convenience all of > the > applications that interface with application that I am porting to .Net, > to > go in and rewrite all of their systems to support my need that the data > not > be in this format. I have to handle what I am given. The client's > question > would be to ask why .Net cannot handle this common and very simple data > format. > > In .Net without any structure to handle this, such as the > class/property > examples in previous emails, you cannot do something like... > > String FirstName = "First Name" > String MiddleName = "Middle Name" > String LastName = "Last Name" > String FullName = "" > > FullName = FirstName + MiddleName + LastName > > That will not work. You'd end up with... > > "First Name Middle Name Last Name" > > That's not valid for the ASCII formatted-positional file format. So > you'd > have to go in and add a buffer function to adjust the number of > trailing > spaces. At that point, what's the point! Why not just use the > class/property solution, which you say is silly. Doesn't sound nearly > as > silly as going through all of this extra work to get the ASCII > formatted > file that you need. > > Then going the other way, you'd have to read in the data using > positional > string manipulation such as MID(). That's allot of extra code to add > to > support something as simple as reading positional character data. > > Oh. Maybe you mean that .Net applications shouldn't interop with > legacy > systems that are not Xml compatible or systems that are using non-SQL > database such as DB2... which would include most hotel systems, most > insurance companies, banks, and most systems written pre-2000. Or > should we > force all of these systems to upgrade to web services, xml, or sql > server so > we .Net developers do not have to work around issues like this. > > By the way, most of these systems are running modern (not dinosaur) > systems. > IBM is running commercials right now trying to sell these systems... > with a > new and more modern name. Most of these systems are running Windows as > well. So the clients that I am working with want to port the legacy > systems > into the Windows partition and work with .Net going forward. However, > right > now the best solutions port to a Java partition and run them in > WebSphere. > IBM seems to have a pretty big service for this, so apparently they > don't > think it's silly to find a solution for this. > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
