|
If I recall correctly, pointers in OS/400 have special tag bits in memory which are only set if they're manipulated using the MI or W-Code operations designed for working with pointers. If the CL program defines it as a character variable, those bits would not be set correctly, and the system would refuse to treat it as a pointer. You could, of course, write the program and then use STRSST to edit the compiled machine code so that it treated these bits correctly, but that would require a very low-level knowledge of the system, plus you'd have to do it EVERY time you recompiled the program. Really, you're MUCH MUCH better off using a language that's capable of working with pointers. And since this is the RPG list, I'll recommend RPG :) On Tue, 19 Nov 2002, Ken Sims wrote: > Hi Hans and Michel - > > > > The 3 types of variables someone can define with DCL (*DEC, *CHAR, > > > *LGL) don't suit my needs. Is there another way to declare variables ? > > > >I wouldn't count on it. If CL doesn't know a string of bytes can > >contain a pointer, then the fact that it is a pointer value would be > >lost. > > If CL character variables are aligned on a 16-byte boundary, then if you > just receive the value from one procedure and pass it to another without > manipulating it, you should be okay. > > The question then is, are CL character variables aligned on a 16-byte >boundary? > > Since you talk about calling procedures rather than programs, I assume that > this is a program created from an ILE CL module. That being the case, I > think the translator should put a 16-byte character variable on a 16-byte > boundary for you. > > Ken > Opinions expressed are my own and do not necessarily represent the views of > my employer or anyone in their right mind. >
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.