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?
/Edit: I saw there that also some Inputs might have problems.
Some Points i got from this Thread:
INPUT (SB=#VAR) isn’t available outside the Mainframe
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)
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.
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.
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.
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)
#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
close work file 1
And please remember that endianess is a question of the Processor and not a question of the Operating System…
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.
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.
Anyway, this discusstion was very interesting for me.
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:
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 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.