Hello, I have a doubt in C / C ++ can travel between variables through the use of pointers. Example:
  - I have the variables A, B and C, and my pointer * p is in the variable A when added will have addressed the variable B.
Would be able to do the same in Cobol, N have variable numbers and navigate between them only through pointers?

Since a POINTER can contain *anything*, sure, you could do that.

Without knowing exactly what you want, I'd not recommend doing it. It will probably make your programs horribly unclear when there's a much easier "COBOL" way to do what you want (whatever it is).

Agreed with Bill. It can be done easily; but without knowing why, it can't be recommended.

For example, you might have ten 4-byte integers stored contiguously in memory. A pointer could have the address of the first byte of the memory initially. By incrementing the pointer by 4, the pointer would then point to the second of the ten integers. Increment the pointer by 8 more, and the pointer would jump to the 4th integer.

But why?

It would probably be better to declare the integers as an array and use the array index to access the different elements. The programming could be more understandable later because the purpose of an array is usually understood quickly while jumping around with a pointer can obscure what happens.

There are many other ways that a pointer might be used to point to different variables, and in most cases the variables should probably be accessed by standard means. If you describe the business problem that you want to solve, we might be able to recommend a better method.

If you are trying to do what I think you're trying to do, I don't think it will work.  I think you're trying to

SET PTR TO ADDRESS OF PIC1

in some kind of loop

    add a constant to PTR

and eventually have PTR be set to ADDRESS OF PIC12

 

In general, I don't think you should count on storage layout in this fashion.  In this case, I don't think that all of your numeric edited fields are identical length so I don't think that there is a single constant that can be used.

Allan,

Are you really saying that we shouldn't rely on the "storage layout" of an 01-level? Or any group data-item in COBOL?

I know you are not :-)

As in Assembler, you could do this. There are various numbers of ways to do this. The last, possible, way that would be considered by a COBOL programmer would be with a POINTER.

Even if that route were chosen, the lack of "pointer arithmetic" would be an issue, leading to the REDEFINES fudge, where the coder also must be aware of "native binary" to avoid trashing an otherwise fine address, and anyone who is aware of all that will also be aware that relying lock-step on how the "current" compiler defines a POINTER internally is a really, really, bad idea, and even more so on the cusp (of undetermined magnitude) of a change-of-addressing for COBOL.

Lots of ways to do what is wanted, and without knowing what is actually wanted (rather than "I want to use a POINTER, whatever the consequences"), difficult to do other than say "drop this bad idea".

 

(You can rely on 01 storage layout.)  Java offers reflection (or introspection);  COBOL does not.  If you try to go down the path of introspection by manipulating your own pointers, you risk introducing errors.  You also make it impossible to every change the 01 data item (except maybe to add items at the end.)
 

It is still not clear what you want to do. If you want to put data into those fields, it would be deeply obscure to do other than give those fields meaningful names and reference them by name.

If your need is to take some input in that format, and just treat it as "character" data to do something else with, the look to use UNSTRING.

Some other ways than UNSTRING would be to parse the line using: variable-length fields; reference-modification; REDEFINES as a table and use byte-by-byte.

Unless you have vast amounts of data, I'd see no reason not to look up UNSTRING.

You could use a POINTER to do the parsing. COBOL has only had POINTERs since the 1985 Standard, so with long-standing options which are available, understood and robust I doubt many COBOL programmers would for one second consider using a POINTER.

There are no COBOL verbs with "increment" or "decrement" a POINTER in any way. This means you'd need to use REDEFINES and define a "native binary" (COMP-5) field and do addition/subtraction/other calculation with that. Which would make your code reliant on knowing how the compiler defines a POINTER, which is down to the implementor, and open to change at the implementor's whim. For instance, if Enterprise COBOL goes 64-bit at some point in the future (and V5+ has set everything in place for that to happen along the way) then your code would no longer work.

If you can describe exactly what you want to do with the data described by that structure, we can make suggestions about how to do it which will not rely on how the compiler defines things internally.