Is there a tool for converting data areas in the internal format to the new readable format?

, , ,
1

Hello,

we are evaluating NaturalONE at the moment and really like the new readable data area format. However, as we cannot convince all our developers to switch to NaturalONE (yet), we need to find a way to make Natural Studio and NaturalONE work together on the same code base. We would like to use the new data area format in SVN and need to find a way to convert data areas that are modified with Natural Studio into the new format before committing to SVN, so that deployment can happen via Ant scripts from NaturalONE, that need the new format. NaturalONE does this conversion automatically when it imports sources from the server into the local working copy, but Natural Studio simply saves the old format.

Long story short: Is it possible to convert the “old” internal data area format to the “new” one with a command line tool, e.g. ftouch?

Best regards,
Stefan

2

Hi Stefan,

Natural’s GP-File of LDAs, PDAs and GDAs are kind of readable

Look at this:


prompt> hexdump -Cv /natdir/fsuer/MYLIB/GP/NATERR1L.NGL
00000000  ff ff 4c 01 00 00 00 ea  ff ff ff ff ff ff ff ff  |..L.............|
00000010  ff ff ff ff ff ff 00 08  00 02 06 03 09 00 01 00  |................|
00000020  4e 41 54 45 52 52 31 4c  cc 48 4e 47 4d 49 f0 00  |NATERR1L.HNGMI..|
00000030  00 00 00 00 00 00 00 00  00 00 00 48 00 00 00 01  |...........H....|
00000040  00 00 00 a2 00 00 00 01  30 30 31 30 20 44 45 46  |........0010 DEF|
00000050  49 4e 45 20 44 41 54 41  20 4c 4f 43 41 4c 20 00  |INE DATA LOCAL .|
00000060  30 31 31 30 20 20 31 20  23 4e 41 54 45 52 52 31  |0110  1 #NATERR1|
00000070  4c 20 00 30 31 32 30 20  20 32 20 56 45 52 53 55  |L .0120  2 VERSU|
00000080  43 48 45 20 28 4e 33 29  20 00 30 31 33 30 20 49  |CHE (N3) .0130 I|
00000090  4e 49 54 20 3c 31 30 3e  20 00 30 31 34 30 20 20  |NIT <10> .0140  |
000000a0  32 20 43 56 2d 54 45 43  48 20 28 43 29 20 00 30  |2 CV-TECH (C) .0|
000000b0  31 35 30 20 49 4e 49 54  20 3c 28 41 44 3d 4e 29  |150 INIT <(AD=N)|
000000c0  3e 20 00 30 31 36 30 20  20 32 20 56 49 53 49 42  |> .0160  2 VISIB|
000000d0  4c 45 20 28 4c 29 20 00  30 31 37 30 20 45 4e 44  |LE (L) .0170 END|
000000e0  2d 44 45 46 49 4e 45 20  00 1e                    |-DEFINE ..|
000000ea

So try out the following:

  • find out the Path of the regrarding GP-File.
  • cut the first 72byte and the last byte
  • replace 0x00 with Newline

example:

prompt> perl -e'undef $/; $lda=substr(<STDIN>,72); chop $lda; $lda=~y/\x00/\n/; print $lda;' < /natdir/fsuer/MYLIB/GP/NATERR1L.NGL
0010 DEFINE DATA LOCAL
0110  1 #NATERR1L
0120  2 VERSUCHE (N3)
0130 INIT <10>
0140  2 CV-TECH (C)
0150 INIT <(AD=N)>
0160  2 VISIBLE (L)
0170 END-DEFINE
3

Hi Matthias,

what I need is a tool that creates the exact same format that NaturalONE uses. NaturalONE converts the data areas into the format that is used in DEFINE DATA, e.g.

01 P-PARAM (A8)

I need to be able to create this format from a script, so that I can run it after copying sources via Natural Studio. Both platforms have to use the same format in SVN. Otherwise any automatic deployment is impossible.

Best regards,
Stefan

4

Well, I don’t know what platform you are using. If your Sources and GPs are stored on the file system you can use the logic of the perl-script I posted above…

Since I don’t have NaturalOne you have to try out if it uses the same logic as the script.

5

Maybe there’s an easier solution. Have you tried out USR4201N with option “define data format”?

6

Hi,

Yes, I think the best way is to use API USR4201N. Perhaps you can run it directly from Natural Studio !

If you choose to use an external tool, be carefull about evolution on internal format of Software AG data areas!

Best regards

7

Hi Bernard and Matthias,

I tried URS4201N and it seems promising. However, I just found out that Natural Studio has an option that turns on the conversion of the Data Areas when transfering the sources to SVN. Although that does not solve my problem directly I think I can work something out :slight_smile:

Best regards,
Stefan

8

I am confused a bit. Why wouldn’t the developer tools (Natural Studio and Natural ONE) work the same way? Don’t they both access the same source (e.g., mainframe Natural) through the Natural Development Server (NDV)? I am just trying to understand why the need to pass source data for programming objects outside the architecture.

Regds,

Brian

9

Hi Brian,

what I tried to do was to get the sources on the server directly under version control. We run Natural on Linux and the FUSER folder is a directory on the file system, which could be connected to SVN directly. If that was possible, there would be no need for developers to “copy” sources into their working copy on their client. However, Natural saves data areas in FUSER in the internal format, but I wanted the “DEFINE DATA” format in SVN, so that if we decided to switch to NaturalONE later, we could use SVN without the need to change the sources.

But I do not think that versioning the FUSER directly is worth the effort of scripting the transformation. I think I will stick with local working copies on the developers’ clients and use Natural Studio’s “Local Versioning” plugin.

Best regards,
Stefan