tal simple program reference

[SWAYAMPRAKASH RATHORE]

hello friends;
on which website ,i will get the simple program of tal.

[Doug Miller]

On 9/8/2011 10:36 AM, SWAYAMPRAKASH RATHORE wrote:
> hello friends;
> on which website ,i will get the simple program of tal.

RTFM. Specifically the Guardian Programmer's Guide.

[dimandja]

On Sep 8, 10:36 am, SWAYAMPRAKASH RATHORE <spr17....@gmail.com> wrote:
> hello friends;
> on which website ,i will get the simple program of tal.

If you can't find a manual, try:
http://www.helloworldexample.net/tal-hello-world-example.html

[wbreidbach]

Unfortunately this sample still uses the "old" procedure calls open
and close.
I recommend the Guardian Programmer's Guide or the TAL manuals.

[Warren M]

On Sep 8, 10:36 am, SWAYAMPRAKASH RATHORE <spr17....@gmail.com> wrote:

> hello friends;
> on which website ,i will get the simple program of tal.

It's not clear from your post if you're looking for a sample program
written in TAL (others have given you a link to this).

Or if you're looking for the TAL compiler itself. The TAL compiler is
present on all HP NonStop (Tandem) systems.
There is also a PC based version of the pTAL (and epTAL) compiler.
However, this must be licensed from HP.
In addition, there is a free PC based TAL syntax checker available
here:
http://h71028.www7.hp.com/nonstopcomputing/cache/79531-0-0-0-121.html

[dimandja]

On Sep 8, 5:07 pm, wbreidbach <wolfgang.breidb...@bv-

Considering the implied TAL skills of the OP, I seriously doubt
procedure freshness is of any concern at the moment. I do so hope the
OP hits the books...

The good thing is that the example will still work as of this day.

[MicroTech]

Hello Swaya,

The referenced example is a tad simplistic. To get you started, take a look at the following (from "-- TAL code" through "-- END TAL code"). Please note the initial comment about PTAL object linking!

Cheers,

Henry Norman
MicroTech Consulting
sites.google.com/site/microtechnonstop

PS. I like the statement made on the referenced web site (TAL example): “If you use an ATM, you <sic!> transaction will probably be processed by a TAL interface program or something else.” How true this is ;).

Cut'n'paste from here:

-- TAL code
--
-- CISC object: runs as produced by compiler (no linking needed)
-- RISC object: Link using > nld <ptalobject> -o <ptalobject>
--
?NOLIST, SOURCE $SYSTEM.SYSTEM.EXTDECS0 (
? DEBUG
? DNUMOUT
? FILE_CLOSE_
? FILE_OPEN_
? INITIALIZER
? OLDFILENAME_TO_FILENAME_
? PROCESS_STOP_
? WRITEX
? )
?LIST
-- Simple LITERAL and DEFINE examples:
LITERAL
ASCII_A = 65;
DEFINE
ASCII_Z ( _arg ) = _arg #;

-- Global (external) data declaration:
INT
legacy[ 0:11 ]; -- Legacy file name format (from TACL startup message)

-- "Callback" proc to make INITIALIZER() extract RUN command OUT file name:
PROC getOutName( arg1, arg2, arg3, arg4, arg5 ) VARIABLE;
INT -- See Guardian Procedure Calls manual for full argument usage)
.arg1,
.arg2,
.arg3, -- Address of TACL startup message (RUN command parameters)
arg4,
arg5;
BEGIN
IF ( -1 <> arg3 ) THEN
DEBUG();
legacy':='arg3[ 21 ] FOR 12; -- OUT file name (old format) at offset 21)
END; -- getOutName()

PROC
?IF pTAL
S0000V00_RISC -- Name recognized by VPROC
?ENDIF pTAL
?IFNOT pTAL
S0000V00_CISC
?ENDIF pTAL
MAIN;

BEGIN
INT(16)
error, -- Error return
length := 0, -- Converted OUT file name length
outFile := -1; -- Opened OUT file handle
STRING
outName[ 0:35 ], -- Converted OUT file name
.EXT next, -- To hold "next buffer position" address
.EXT buffer[ 0:79 ]; -- WRITEX() buffer

-- Extract and convert legacy hometerm name ("callback" proc argument):
INITIALIZER( ,, getOutName );
IF ( error := OLDFILENAME_TO_FILENAME_( legacy, outName:36, length ) ) THEN
DEBUG();

-- Open hometerm:
IF ( error := FILE_OPEN_( outName:length, outFile ) ) THEN
DEBUG();

-- Initialize WRITEX() buffer:
buffer ':='
?IF pTAL
"RISC"
?ENDIF pTAL
?IFNOT pTAL
"CISC"
?ENDIF pTAL
& ": " -> @next;

-- Build text string (ASCII #65 (A) to #90 (Z)):
USE i; -- Assigns register for i (fast!)
FOR i := ASCII_A TO ASCII_Z ( 90 ) DO
BEGIN
next := i;
@next := @next[ 1 ];
END;
DROP i; -- Release register

-- Write result to hometerm:
WRITEX( outFile, buffer, 0 ); -- 0 byte count = blank line
WRITEX( outFile, buffer, $INT( @next-@buffer ) );
WRITEX( outFile, buffer, 0 );

-- Close opened files (not necessary, but good habit):
FILE_CLOSE_( outFile );

-- "STOP RUN" (not needed, but pTAL defaults to ABEND):
PROCESS_STOP_();
END; -- S0000V00_*ISC()
-- END TAL code

[Keith Dick]

SWAYAMPRAKASH RATHORE wrote:
> hello friends;
> on which website ,i will get the simple program of tal.

All of the NonStop documentation can be found by going to:

http://www.hp.com/go/nonstop-docs

On that page, scroll down to the heading "NonStop Technical Library", then click the link for the release series you are using: "H-Series", "J-Series", or "G-Series". Most documents are the same for all releases, but some do depend on the release letter.

On the pages those links take you to, there are links to all of the manuals, in alphabetical order by title. The manuals that probably are most of interest to you right now are "TAL Programmer's Guide" and "Guardian Programmer's Guide". The first is a complete description of the TAL language. The second explains how to use many of the programming interfaces to the Guardian OS, which includes lots of sample code, and quite a few full programs.

That should get you started, along with the samples Dimandja and Henry gave you. My opinion is that the example Henry gave is rather difficult for a beginner to understand, so if you find that one confusing, do not blame yourself. You should be able to understand it eventually, after you learn a fair amount about TAL programming.

[PRY]

Hello Keith,

I am trying to convert TAL socket program in to pTAL. After compilation and linking with library LNETINDN, getting following errors when debugging pTAL exe:

$DATA03 PTAL 4> rund myexe
PID: \XYZX.1,381 \XYZX.$DATA03.PTAL.MYEXE (ELF)
External References Not Resolved to Any User/System Library:
Prg: \XYZX.$DATA03.PTAL.MYEXE -> __stdio_fp (PROC)
Prg: \XYZX.$DATA03.PTAL.MYEXE -> abort (PROC)
Prg: \XYZX.$DATA03.PTAL.MYEXE -> calloc (PROC)
Prg: \XYZX.$DATA03.PTAL.MYEXE -> errno (DATA)
*ERROR* PROCESS_CREATE_ Error: 63

-----------------------------------------------------------
NLD command :> NLD $SYSTEM.ZTCPIP.LNETINDN ptalobj -o myexe

Please suggest me how can fix above error.

[Robert Hutchings]

Can you give us more info on your source code? It looks like you have external procs that are not satisfied at run-time.

[PRY]

On Friday, July 18, 2014 6:31:21 PM UTC-5, Robert Hutchings wrote:
> Can you give us more info on your source code? It looks like you have external procs that are not satisfied at run-time.

Hi Robert, Thanks

In program mainly following procedure calls are used :

initializer, socket_nw, gethostbyname, connect_nw, recv_nw, send_nw2 and get_errno.

Can i use INITIALIZER system procedure with CRE independent socket library, and "MAIN" routine of the program is in pTAL.

[Keith Dick]

The HP documentation on this seems to be terribly deficient, and I don't know all the tricks you need to know, either.

Your problem, of course, is that your program is using some library functions that you did not include in the link. If you still have access to the TAL version of the program, use BIND to see where those procedures are in the TAL version of the program. That might be a big clue as to where to get them for the pTAL version. Is your TAL/pTAL code calling the ones listed as undefined?

The undefined names look like C runtime library things, but the sockets library to be used with TAL is supposed to contain the parts of the C library that it needs, so I don't know why those C library names would be undefined unless they were being called from your TAL/pTAL code. Probably there is something happening here that isn't exactly clear, as Buffalo Springfield once said.

The TALDOCUM file in the ZTCPIP subvolums seems to say that you need to link with ZCRESRL and ZCRTLSRL for native applications, but that is in a section talking about the version of the sockets library that is to be used with the CRE. You are using the version that does not use the CRE, so I imagine ZCRESRL should not be included. Whether ZCRTLSRL can be used, I don't know -- it might depend on the CRE, and so cannot be used without ZCRESRL. You could try to link with ZCRTLSRL, since I don't see any other advice about what to link with when using the LNETINDN, but I don't believe that is likely to work.

As far as using INITIALIZER from pTAL, it can be used, though there are some things that need to be changed. The TNS/R Native Application Migration Guide talks about the ones related to Sequential I/O and the RUCB. If you aren't using INITIALIZER to initialize SIO FCBs, then just ordinary TAL to pTAL conversion should be all that is needed.

However, depending on how things work out with those undefined names, it might be less work to change your program to have a C main function that does nothing but call your pTAL main procedure. Then you could use the version of the sockets library that works with CRE, and I'll bet those undefined symbols no longer would be undefined (assuming you link with the SRLs mentioned above and any others that normal C programs need). How easy that is to do depends on what you are using INITIALIZER for. If you are just using it to read and discard the startup messages, you could just delete the call to INITIALIZER and everything should work. If you are using INITIALER to get the arguments on the command line from the startup message, you would have to make some changes to your program -- perhaps get those arguments in the C code before calling your main procedure, rebuild the command line argument string from them, and pass it to the main procedure. Then instead of getting the co
mmand line string in the startupproc of INITIALIZER, you'd get it from your main procedure argument. If you are using INITIALIZER to get the ASSIGN and PARAM messages, a little more work would be needed, but for PARAMs it is not very much.

If you decide to convert to a C main function and are not sure how to fix whatever dependency on INITIALIZER you have, describe how you depend on INITIALIZER and we can offer advice about it.

[Robert Hutchings]

I would have to download the pTAL manual and research this. It might be useful for you to try to figure this out. Sometimes other people are not available to help, and developing "troubleshooting" skills is very desirable. I don't blame you for posting on this forum, however. I'm just saying that being self-sufficient has it's own rewards :)

[Robert Hutchings]

Go here:

http://bit.ly/1zTWitH

Find the section that explains sourcing In CRE External Declarations for
pTAL Modules.

[PRY]

Hello Keith, Thanks a lot for all the given information.

I have converted pTAL main to a C main function and now all undefined error been resolved.
And, INITIALIZER am using to get param like IP, PORT, pathway server name and log file name.

[PRY]

On Saturday, July 19, 2014 3:04:37 PM UTC-5, Robert Hutchings wrote:
> I would have to download the pTAL manual and research this. It might be useful for you to try to figure this out. Sometimes other people are not available to help, and developing "troubleshooting" skills is very desirable. I don't blame you for posting on this forum, however. I'm just saying that being self-sufficient has it's own rewards :)

Hello Robert, Thanks
I am trying to figure it out, only i had some confusion on certain points that's why posted it on forum. Thanks once again for wonderful advice of being self sufficient..... :)

[Keith Dick]

The undefined names he reported are not from the CRE. The CRE names begin with CRE_, RTL_, or CLU_, and, anyway, he was trying to run without the CRE altogether, since a pTAL main program cannot use the CRE. So I believe that portion of the manual will not help solve this problem.

[Keith Dick]

One fairly simple approach would be for you to use the C library's getenv() function to get the value of those few PARAMs before calling your pTAL main procedure and pass their values as arguments to your pTAL main procedure. You would also have to change any place in your TAL code that currently gets the value of those PARAMs from the PARAM message that your INITIALIZER paramsproc received. The best way to go about that depends a lot on exactly how the TAL code went about dealing with the PARAMs. If the TAL retrieved the values of the PARAMs immediately upon receiving the PARAM message and saved them in global variables, you could replace that code with code that sets those global variables from the new arguments to your pTAL main procedure, and all the rest of your program should continue to work without change.

If the paramsproc in your TAL code saved the PARAM message in a global variable, and scaned it each time a request was made for the value of a PARAM, maybe the simplest approach for that case would be to have your C code use the external variable environ (which is declared char **environ; -- it is an array of string pointers) to construct what the PARAM message was (before the C startup routine parsed it into the environ form), pass that reconstructed PARAM message as an argument to your pTAL main procedure, have your pTAL main procedure store the reconstructed PARAM message wherever your paramsproc would have stored it, and then the rest of the pTAL code should work as it did before.

If you use the environ external variable, you can tell when you have reached the end of it by testing whether the pointer is NULL.

[Robert Hutchings]

I'm trying to help Keith. Maybe I was wrong. I thought the INITIALIZER routine was part of the CRE, but I guess not. My bad.

[Keith Dick]

Robert Hutchings wrote:
> I'm trying to help Keith. Maybe I was wrong. I thought the INITIALIZER routine was part of the CRE, but I guess not. My bad.

I know you are trying to help, but when I spot a suggestion that almost certainly is based on a misunderstanding and would most likely just distract the guy from the actual problem, I think I ought to speak up. I tried not to criticize you, and not just say it is a wrong suggestion, but point out why it was a wrong suggestion, so the guy knows why it probably isn't useful to go down that path.

[Robert Hutchings]

Okay, no problem. It's good practice to research these issues...

[PRY]

I removed the call for INITIALIZER from pTAL source, and as i mentioned below used C library's get_param_msg() function in pTAL source code to get the values of all the required params and it is working now.

int proc get_param_msg = "get_param_msg" ( msg^p, len )
LANGUAGE C;
int .msg^p;
int .len;
EXTERNAL;

Thanks for all your help.

[Keith Dick]

I did not know about that C library function to get the whole PARAM message. Using that is much better than what I suggested. I'm glad you found it.

[prakash...@gmail.com]

I am getting errors when changing the tal program to ptal. Is there any document stating the error numbers and corresponding solution. I am eagerly searching the document from long back. I am not able to get it. Could you please help me to sort out.

[Keith Dick]

prakash...@gmail.com wrote:
> I am getting errors when changing the tal program to ptal. Is there any document stating the error numbers and corresponding solution. I am eagerly searching the document from long back. I am not able to get it. Could you please help me to sort out.

I do not remember ever seeing a manual that included the error messages produced by the pTAL compiler. There might be a manual that contains the pTAL error messages, but my guess is that there is none.

I have only rarely used pTAL, but my memory of it is that the messages usually were enough to understand the problem just from the text of the message, or at least gave enough of a clue about what aspect of the statement was causing trouble so that I could look up the descriptions in the pTAL reference manual or the pTAL conversion guide, and from that figure out what was the problem.

Do you know how to find the manuals online? If you have not already downloaded a copy of the "pTAL Reference manual", "pTAL Conversion Guide", and maybe "pTAL Guidelines for TAL Programmers", I recommend that you download them to your PC so you can access them quickly when you need to look up something. In case you do not know how to get to the online library:

1. Go to http://www.hpe.com/info/nonstop-docs
2. On the page that appears, click on "HPE Integrity NonStop L-Series"
3. On the page that appears, type pTAL into the search box and push the Enter key
That will list documents that match
4. To view a document, click on its title, which will display information about
that document to the right
5. To download the document, right-click on the icon that is a downwards-pointing arrow.
That will display the document in the web browser. When the document is displayed,
you should see an icon near the top of the window that looks like a floppy disk.
Click on that icon to download the document.

If you cannot figure out what is causing a problem by yourself, post more details -- at least the error message and a few lines of code around the point of the error, and if you have changed those lines show the original TAL, too -- and someone here will try to help. If you have tried several things already when trying to fix the problem, describe or show what you have tried.

If the TAL program is old and you have not compiled it with TAL for some considerable time, make sure it compiles without error with the TAL compiler before trying to convert it to pTAL.

[wbreidbach]

From my experience converting a TAL program to a PTAL or XPTAL program is no real problem. I think there is something like a conversion guide availeble.
I had very few things to change, mostly things with pointers, expecially computing an actual string length using 2 pointers, that is different in PTAL. And ther is another thing: TAL is somewhat more tolerant concerning addressing errors.
If you want the same source for TAL and PTAL theere is a toggle available:
?if ptal
put PTAL code here
?endif ptal
?ifnot ptal
put TAL code here
?endif ptal
Doing this you can use both compilers.
And do not forget:
The ?SEARCH is not supported by PTAL!

And feel free to post your errors, I am sure somebody will be able to help.