Compiler or Interpreter?
Moderators: chulett, rschirm, roy
-
- Charter Member
- Posts: 130
- Joined: Mon Sep 06, 2004 3:05 am
- Location: Dubai,UAE
Compiler or Interpreter?
Hi,
This is an Interview Question
Is DataStage a Compiler or an Interpreter? Explain why?
Kindly guide us
Thank You
This is an Interview Question
Is DataStage a Compiler or an Interpreter? Explain why?
Kindly guide us
Thank You
Warm Regards,
Amruta Bandekar
<b>If A equals success, then the formula is: A = X + Y + Z, X is work. Y is play. Z is keep your mouth shut. </b>
--Albert Einstein
Amruta Bandekar
<b>If A equals success, then the formula is: A = X + Y + Z, X is work. Y is play. Z is keep your mouth shut. </b>
--Albert Einstein
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
Although the last thing I want to do is simply post an answer to an interview quesiton, I think that this is silly enough to warrant an answer and that some of the members here might be interested in an answer.
The underlying Server engine is a UniVerse based system. The programming language used in that Engine is UV/Basic. This language is compiled, but not to a virual machine that is at the OS or lower level, but to a binary pseudo-code. This pseudo-code is then run on the virtual machine that is UniVerse. This is debatably a compiled language, as he original Pick-based systems were actually not software packages running on a given UNIX or Windows system but were actually operatings systems in their own right.
In addition, when you 'Compile' a DataStage job it really creates 4GL code as a source-generator and then lets DS compile this. Again, another debatable issue whether DS programs are merely generated code, compiled objects or interpreted instructions. All in all the question is absolutely worthless - from any DS developing point of view apart from the ultra-deep-level this distinction makes no difference.
DataStage Px is another matter entirely, as this generates shell scripts, C++ programs and it's own control language.
The underlying Server engine is a UniVerse based system. The programming language used in that Engine is UV/Basic. This language is compiled, but not to a virual machine that is at the OS or lower level, but to a binary pseudo-code. This pseudo-code is then run on the virtual machine that is UniVerse. This is debatably a compiled language, as he original Pick-based systems were actually not software packages running on a given UNIX or Windows system but were actually operatings systems in their own right.
In addition, when you 'Compile' a DataStage job it really creates 4GL code as a source-generator and then lets DS compile this. Again, another debatable issue whether DS programs are merely generated code, compiled objects or interpreted instructions. All in all the question is absolutely worthless - from any DS developing point of view apart from the ultra-deep-level this distinction makes no difference.
DataStage Px is another matter entirely, as this generates shell scripts, C++ programs and it's own control language.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Charter Member
- Posts: 130
- Joined: Mon Sep 06, 2004 3:05 am
- Location: Dubai,UAE
Hi,
This question was asked to me by a collegue who attended an interview,
According to me the Interviewer is checking more of the interviewee's presence of mind rather then anything else, as the question has very little to do with the skills in developing jobs through DataStage
Anyways I would have answered it looking at the difference between the Compiler and the Interpreter
A Compiler converts High level instructions into machine language
and
Interpreter is a program that executes instructions written in a high-level language
Also an interpreter does not need to go through a compilation stage where the machine instructions are generated.
Clearly in DataStage we need to compile all our jobs before they can be run.
So DataStage is a COMPILER.
I am not sure whether I would survive the interview but definately show that I am aware about COMPILERS and INTERPRETERS
This question was asked to me by a collegue who attended an interview,
According to me the Interviewer is checking more of the interviewee's presence of mind rather then anything else, as the question has very little to do with the skills in developing jobs through DataStage
Anyways I would have answered it looking at the difference between the Compiler and the Interpreter
A Compiler converts High level instructions into machine language
and
Interpreter is a program that executes instructions written in a high-level language
Also an interpreter does not need to go through a compilation stage where the machine instructions are generated.
Clearly in DataStage we need to compile all our jobs before they can be run.
So DataStage is a COMPILER.
I am not sure whether I would survive the interview but definately show that I am aware about COMPILERS and INTERPRETERS
Warm Regards,
Amruta Bandekar
<b>If A equals success, then the formula is: A = X + Y + Z, X is work. Y is play. Z is keep your mouth shut. </b>
--Albert Einstein
Amruta Bandekar
<b>If A equals success, then the formula is: A = X + Y + Z, X is work. Y is play. Z is keep your mouth shut. </b>
--Albert Einstein
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The compiled code from a server job is not executable by the native machine; rather it is executed in a 'virtual machine' called the DataStage Run Machine. This assists in platform portability, and explains why you can't install an AIX DataStage on an HP-UX machine; the Run Machine is different.
It's definitely not an interpreted language.
In parallel jobs a mixture of C++ code is generated and compiled and osh scripts producted.
In mainframe jobs DataStage generates COBOL source code and job control language (JCL) for compiling and running the same, but actual compilation and execution takes place on the mainframe machine.
It's definitely not an interpreted language.
In parallel jobs a mixture of C++ code is generated and compiled and osh scripts producted.
In mainframe jobs DataStage generates COBOL source code and job control language (JCL) for compiling and running the same, but actual compilation and execution takes place on the mainframe machine.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Interesting. Not knowing the internals, in my mind I have always considered it to be 'interpreted' by the runtime installed on each specific server. Now I see that isn't exactly the case and this functions much like the RM/COBOL compiler and runtime I used many <cough> moons ago.ray.wurlod wrote:The compiled code from a server job is not executable by the native machine; rather it is executed in a 'virtual machine' called the DataStage Run Machine. This assists in platform portability, and explains why you can't install an AIX DataStage on an HP-UX machine; the Run Machine is different. It's definitely not an interpreted language.
Liant Software wrote:To develop an application, the programmer uses a combination of the standard RM/COBOL compiler and a platform-specific runtime that end-users employ. RM/COBOL compiles to an architecture-neutral, intermediate source code, which is executed by the runtime. If end-users wish to run the application on a different platform, all they have to do is add another runtime. This runtime reads the same code as the original, so no recompiling is necessary. Thus deployment is both easy and cost effective.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Im with you Craig. Ive been doin this since "The Year of the Great Flood" and I too have always thought DS to be Interpreted. Which goes to show two very important things:
1. This totally doesnt matter ... in the Grand Scheme of things
2. There is allways something else to learn.
1. This totally doesnt matter ... in the Grand Scheme of things
2. There is allways something else to learn.
Lance Short
"infinite diversity in infinite combinations"
***
"The absence of evidence is not evidence of absence."
"infinite diversity in infinite combinations"
***
"The absence of evidence is not evidence of absence."
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
At the risk of opening a (or another) can of worms, one can view the "assembly language" for this compiled code using the VLIST command. If you do you will make one fascinating discovery; there are quite a few multi-operand opcodes.
For example, the multicat opcode can concatenate together any number of strings in a single opcode. This is hugely efficient string handling.
For example, the multicat opcode can concatenate together any number of strings in a single opcode. This is hugely efficient string handling.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
There are some really interesting OPCODES out there It is actually possible to decompile the program and get almost everything back out except for variable names in common blocks. Plus a CASE won't go back because DS actually treats it as a IF-THEN-ELSE construct. I wrote a decompiler a while back - in BASIC
I still look at Uv/BASIC as an interpreted language, it just does the interpretation at a virtual-machine level between the human and the OS layers. The advantage of the DataStage method is that code is absolutely portable between implementations with the exception of having to do FNUXI when crossing the Wintel divide.
I still look at Uv/BASIC as an interpreted language, it just does the interpretation at a virtual-machine level between the human and the OS layers. The advantage of the DataStage method is that code is absolutely portable between implementations with the exception of having to do FNUXI when crossing the Wintel divide.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Actually, you don't need fnuxi for compiled BASIC code. The run machine checks the magic number to determine the byte order, and will adjust "on the fly". It's more efficient if you have corrected the byte order, of course, but it's not actually necessary.
<positive spin>
What this means is that compiled BASIC code is totally portable between platforms.
</positive spin>
<positive spin>
What this means is that compiled BASIC code is totally portable between platforms.
</positive spin>
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Ray - the code part is a new one to me, I recall having to FNUXI ported code (after the runtime engine tells you to; so at least the interpreter noticed that something was wrong with the magic number). I guess the enhancement isn't technically difficult, but as you stated it would slow down the process a bit.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>