Migration from BS2000 to Linux

, , ,
1

Hi There,

do you have some hints what i have to think about if i want to migrate my Natural 3.1.2 Programms from BS2000 to Natural on Linux.

I think things like Hexvalue inits and so on (EBCDIC vs. ASCII is only at Hexinits a Problem i think). Over there i would think about Userexits and Binaryusage of Controllvariables. Does someone have some hints over there i have to think about?

Greetings
Sascha

/Edit: I saw there that also some Inputs might have problems.

Some Points i got from this Thread:

Controll Variables

  • INPUT (SB=#VAR) isn’t available outside the Mainframe

System Variables

  • tpsys – On Mainframe there are UTM or something like that which often to be used to differ between Batch and Dialog Mode. (Use *device instead)

Charset

  • ASCII Sorts: a-z, A-Z, 0-9
  • EBCDIC Sorts: 0-9, A-Z, a-z
  • Char " is H’7F’ on EBCDIC and H’22’ on ASCII

Endian - depends Variables Format I, F
The decimal Number 100 would be saved in different Order at the following Systems (as Integer - length 4 Byte). Also have a look at this for Endians.

  • Little Endian (x86 Processors) – 64 00 00 00
  • Middle Endian (Some old Style 16bit Systems) – 00 64 00 00
  • Big Endian (RISC, Mainfraimes, most other non x86) – 00 00 00 64

Define Window
On Mainfraime the Size of Columns that would be displayes is a little bit lower than on Open Systems. If you define a Window with Size 7 * 20. Display show the following:

  • with Frame on Mainframe 15 Columns
  • without Frame on Mainframe 19 Columns
  • with Frame on Open Systems 18 Columns
  • without Frame on Open Systems 20 Columns

On Mainframe the Background would be overlayed from the Window 21 Columns and on Open System 20 Columns

Call of Jobs/Programs outside of Natural

  • on Mainframe you could use call ‘NATRJE’
  • on Open Systems you could use call ‘SHCMD’
2

I don’t know whether it’s possible or not to execute OS-commands on mainframe. On Open Systems it looks like this:

CALL "SHCMD" "CMD.EXE /C DIR"

Maybe it is usefull to search for “mainframe” or “linux” in the Natural help. I got 142 hits on “mainframe”. One Example:

As far as I know the output-managment (printing etc.) on mainframe is completely different to linux.

3

At Host you could use NATRJE to Execute Jobs in Background.

Thanks for the Tip with the Nat 6.x Help. I use my SPoD Help so i could see the most Problems.

Greetings Sascha

4

The sort order is also very different between the two platforms because of the base code set.

EBCDIC goes

a-z A-Z 0-9

Unix (whether it’s ISO-8859, Unicode, UTF, etc.) is

0-9 A-Z a-z

und special characters ($, @, _, usw.) sort in different locations.

MfG,
Ray

5

Good hint! But does this really effect the SORT-command in Natual? I thought this is ADABAS-stuff…

6

This affects “everything”, it is a platform / character set issue.

Wherever you SORT, be it Adabas, a workfile, other databases, the order will be different compared to the mainframe.

7

Ja, was schrieb Wolfgang W. waves :smiley:

True, it doesn’t affect the NAT program syntax itself, but the results may be surprising if you aren’t expecting it.

This is something that is sometimes overlooked when planning conversions. Back in my support days, I spoke with customers who didn’t understand why they weren’t getting the expected results.

8

Cheers, Ray :wink:

Exactly, wherever you deal with data, the sort order is different due to the beforementioned character set issues.

And there’s more to it, when calling 3gl subroutines, watch out for word sizes, byte orders etc. when dealing with “integer” or “binary” data.

9

On Linux, you got the possibility to change the sort behaviour of sort, ls and other OS-commands. For more information see

man locale
man 5 locale

But I guess Adabas doesn’t care about these settings…

10

afaik Natural and Adabas can use a collating sequence thus changing sort orders of bytes. With the upcoming UTF or Double Byte Character Set support, this will be necessary anyway.

11

How about Workfiles with Integers and Packed Numbers? AFAIK Mainframes use Big Endian Numbers, PC’s with Linux and Windows use Little Endian. I will try it if i have installed Nat for Unix. But i’m not sure if this would be a Problem.

I saw also that DEFINE WINDOW would be a Problem because on Mainframe they have less characters to display than on Open-System Plattform.

Over there i would have a look at some Systemvariables like *tpsys and so on.

Greetings
Sascha

12

There’s no problem in connection to workfiles. If I set a 4-byte-integer to 100 and write it into a UNIX-Workfile, the content is H’00000064’
So “big or little endian” is only internal stuff in that case.

But this ENDIAN-thing is a problem for Generated Programs (if you want to use them on Mainframe and Open Systems at the same time). But there is a Natural-Parameter ENDIAN to solve this.

13

I tried it on a x86 Linux System where it would be a Problem i got H’6400000A’ with ENDIAN Default.

14

Did you use the Linux-Utility “hexdump”? Look out! This utility switches the bytes during display. You have to use hexdump with the parameter “-C”. Example

prompt> echo 1x | hexdump
0000000 7831 000a
0000003
prompt> echo 1x | hexdump -C
00000000  31 78 0a                                          |1x.|
00000003
15

I used hexer an Hex-Editor.

16

Sorry, I don’t know hexer, but it’s possible that this program switches the bytes during display as well.

I guess you wrote a 2-Byte-Integer into your workfile. So the third byte should be the Linefeed ‘0A’. But your third byte is ‘00’. My speculation is, that “hexer” switches the bytes like the linux-Hexdump…

To clarify the endian-question, just try out the following code and see, if you get different results on the different machines …

define data local
01 #i4 (i4)
01 #b1 (B1)
end-define
*
#i4 := 100
*
define work file 1 '/tmp/endian-test.txt'
write work file 1 #i4
close work file 1
*
define work file 1 '/tmp/endian-test.txt' type 'unformatted'
*
read work file 1 #b1
write 'workfile:' #b1
end-work
*
close work file 1
*
end

And please remember that endianess is a question of the Processor and not a question of the Operating System…

17

Did i ever said something other? As i said Posts before i use Linux on a Intel x86 Machine which uses Little Endians and our BS2000 Machine uses BigEndian (Siemens S115). (Some RISC-Systems with HPUX here will also use Big Endian)

Btw. Hexdump without Parameter would like to switch the bytes like in an 16bit middle endian environment. hexer and hexdump -C didn’t try to emulate this old Style.

So the Display of an I4 Variable (Value 100 Decimal) without setting the Natural ENDIAN Parameter should be the Following.

Little Endian (x86 Processors)


64 00 00 00

Middle Endian (Old Style some 16Bit Processors)


00 64 00 00

Big Endian (Most other Processors - Mainfraimes, RISC,…)


00 00 00 64

There could be an 0D 0A oder 0A on PC’s depends on Operating System. Mainframes (BS2000) does have an 4 Byte Attribute in Front of each Line (SAM Files) which describes how long the line is.

Greetings Sascha.

18

OK! OK! You mentioned it. In the initial question you said

But later you talked about Linux@x86. And I was babbling about my UNIX (Solaris@SPARC). And that system is big endian.

I gave that hint because your

looks to me like a 2-Byte-Integer plus a Newline, and both “switched” via hexdump.

OK, then I was wrong… :oops:

And finally - to get back to your initial question:
Yes, you will get a problem, if you have to migrate program which are using workfiles containing integers. But I guess, meanwhile you found that out by yourself. :wink:
Anyway, this discusstion was very interesting for me.

19

It was also interesting for me because i got from this discussion the ENDIAN Natural Parameter which will solve the default Problem. But i’m not sure if i better write Programs which converts the Workfiles or just use the ENDIAN Parameter.
I think Natural is still slow enough and i didn’t know if the ENDIAN slowes it down a little more :lol:

20

After my initial comment above, I’ve been watching this thread, and it’s been interesting.

I knew about endian-ness, but for some reason I’d never thought of it in relation to writing a work file. And that is something that probably gets overlooked often, too.

And having been away from ADA/NAT (and SAG in general) for 3 years :cry: I didn’t know about the ENDIAN parameter either. (I hope someday to get back in the area.)

And I also find anything about BS2000 interesting. Since it doesn’t exist on this side of the pond (F-S’ loss, IMHO), I know it only from my occasional forays into its world back in my days in development. Someday I’d like to work with it more. :slight_smile:

Viel spa