Test a tandem server using Fup Copy
Roshintosh
I've got a server which I want to test..........
I know I could write a test harness, but I haven't time
Someone said it's possible to test the server using a fup copy to the
server process.
Is it true ?
How can I do this ?
Any other way to test a server class from a tacl prompt ? IPMGUN
is not possible because can't install it.
Sorry for the basic question !
dimandja
Youi will need to worry about formatting binary fields correctly.
But, if you have created a file that can comfortably hold all your
data, then FUP Copying a record from the file to your process should
work.
Keith Dick
As dimandja said, yes, you can send test requests by using FUP COPY from a file containing a test message to the server process name. You could do it with a command like:
FUP COPY testfile,$svr
I can't immediately think of a way to modify this to capture the server's reply so that you could compare it against an expected reply, so I'm not sure this approach is very suitable for something like regression testing. It is suitable for sending a test message if you want to do some debugging of the server code.
Writing a "test harness" that merely reads test messages from an input file, does WRITEREAD to the server process, and compares the reply from the server to the next expected reply from another input file seems to me like it would be a very quick program to write in either COBOL or C, and not much harder in TAL, so I'm not sure you are right when you save you don't have enough time to write such a program. As long as you resist the temptation to make it more complicated than it needs to be, it ought to take only an hour or two to write and test a simple test driver in whichever language you are most comfortable using.
As dimandja said, if the server's requests contain binary fields, you'd have to go to a little effort to prepare the file of test messages so that the binary fields were set up correctly. You'd have to do that no matter how you sent the test messages to the server. Of course, if the server's request messages contain only character fields, this isn't a problem and you could prepare the test messages with a text editor. You might have to do some additional work if the last field contains trailing blanks and the server expects the message to contain the trailing blanks, since Edit files trim off trailing blanks. There are some simple ways to deal with that -- ask if you need suggestions about that.
You asked whether you could use TACL to send the test messages. Possibly. The TACL function you'd need to use would be "#requester read". That calls writeread for the process, sending what you put into the prompt variable and putting the reply into the read variable.
The TACL Reference Manual says that the prompt variable cannot be a struct variable, but for a server whose request message contains binary fields, you would need the prompt to be a structure. So perhaps TACL can only be used with servers whose request messages are only text. However, the TACL Programming Manual contains an example (example 5-11) that claims to be able to send structured messages containing binary fields using #requester read. Without access to a system, I cannot do a test to see whether the reference manual is correct or the programming manual is correct. I have a feeling that the programming manual probably is right, but I don't know why there would be an incorrect restriction listed in the reference manual.
If you are adept at TACL programming, you might be able to get a test driver going in TACL quicker than you could in COBOL or C or TAL, but if you are more familiar with COBOL or C or TAL, and not so familiar with TACL programming, it probably would be quicker using COBOL or C or TAL rather than TACL.
Keith Dick
A typo correction and an additional point:
The typo: In the paragraph about writing a test harness,
"I'm not sure you are right when you save ..."
should be
"I'm not sure you are right when you say ..."
The additional point is that if you want to use TACL only to send test messages to a server, and don't care about getting the server's reply, then using "#requester write" should do the job, and there is no warning about using TACL STRUCT. There is a warning about data being truncated without an error being reported, and I have to say I don't know what condition that is warning about, but I have a feeling it isn't relevant for this use.
Doug Miller
>As dimandja said, yes, you can send test requests by using FUP COPY from a file
> containing a test message to the server process name. You could do it with a
> command like:
>
> FUP COPY testfile,$svr
>
>I can't immediately think of a way to modify this to capture the server's reply
Oh, that's easy: pass the server an ASSIGN message pointing its OUTfile to a
terminal, a file, another process -- pretty much anywhere except $RECEIVE.
[...]
>
>You asked whether you could use TACL to send the test messages. Possibly. The
> TACL function you'd need to use would be "#requester read". That calls
> writeread for the process, sending what you put into the prompt variable and
> putting the reply into the read variable.
>
>The TACL Reference Manual says that the prompt variable cannot be a struct
> variable, but for a server whose request message contains binary fields, you
> would need the prompt to be a structure.
No, you don't. A scalar copy of a structure would do just fine.
> So perhaps TACL can only be used
> with servers whose request messages are only text.
It's certainly easier, but that's not required.
> However, the TACL
> Programming Manual contains an example (example 5-11) that claims to be able
> to send structured messages containing binary fields using #requester read.
> Without access to a system, I cannot do a test to see whether the reference
> manual is correct or the programming manual is correct. I have a feeling that
> the programming manual probably is right, but I don't know why there would be
> an incorrect restriction listed in the reference manual.
They're both correct; there is no conflict.
In the TPM, Example 5-11 which you cited:
#APPENDV p [to_cmon] == p is the prompt variable for #REQUESTER READ
In the TRM, in the "Considerations" for #APPENDV:
If from-variable-level is a variable level of type STRUCT, the #APPENDV
function appends a line containing the binary data of the STRUCT to
to-variable-level, which can be of another type. This function is primarily
used to supply structured data to variables associated with servers and
requesters.
Keith Dick
> In article <kLqdneF53azoy2LQ...@giganews.com>, kd...@acm.org wrote:
>
>
>>As dimandja said, yes, you can send test requests by using FUP COPY from a file
>>containing a test message to the server process name. You could do it with a
>>command like:
>>
>> FUP COPY testfile,$svr
>>
>>I can't immediately think of a way to modify this to capture the server's reply
>
>
> Oh, that's easy: pass the server an ASSIGN message pointing its OUTfile to a
> terminal, a file, another process -- pretty much anywhere except $RECEIVE.
That would work for a COBOL server, where "OUTfile" means the FD that usually is assigned to $RECEIVE and to which the replies are written. But for a server in any other language that actually calls REPLY, that wouldn't work. But for COBOL servers, yes.
Ah, now I remember how that works. Thanks for pointing out what I had forgotten.
Dave
It may be easier in the long run to use a simple client program where
you can set up the message to be whatever you need. something like
this:
#pragma nolist
#pragma wide
#include <stdio.h>
#include <ctype.h>
#include <fcntl.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <time.h>
#include <tal.h>
#include <cextdecs>
#pragma list
short main (int argc,char *argv[])
{
char pmonname[] = "$PDEBS";
char servername[] = "COBSRVR";
char buf[50]= "Hello World";
short count_read;
int error;
BEGINTRANSACTION();
error = SERVERCLASS_SEND_ (pmonname
,(short)strlen(pmonname)
,servername
,(short)strlen(servername)
,buf
,5
,(short)strlen(buf)
,&count_read
);
ENDTRANSACTION();
exit (0);
}
MicroTech
> I've got a server which I want to test..........
> How can I do this ?
> Any other way to test a server class from a tacl prompt ?
You can also use the MicroTech freebie MIP (Multi-purpose Interactive
Program). Go to
https://sites.google.com/site/microtechnonstop/microtech-sodtware-freebies/microtech-software
and download MIP (and the MIP manual). You can use MIP to set u[p the
structure the server expects (SETSYMBOL (SS) commands), then OPEN the
server, then WRITEREAD whatever you set up using SS. The reply will be
displayed as a "raw dump" (address, hex data, ASCII data). Doesn't get
much simpler, but only good for basic one-shot testing.
Cheers,
Henry Norman
MicroTech Consulting
sites.google.com/site/microtechnonstop
Pete
If you can still use interactive inspect, you could prepare an inspect
obey file that sets the fields of the input structure with m[odify] to
the values you want to test, E.G.:
m mystruct.binary_field = 13;
m mystruct.ascii_field[0:2] = "ABC";
and so on...
Then set a breakpoint in your server someplace after the read
completion on $RECEIVE, execute the fup copy somefile,$SRV and when
when it hits the breakpoint, execute the obey file. You need to be
have a pointer with the appropriate structure set to the input buffer
for this to work.
P Kelly
All things considered, I will write a quick cobol program test
harness.
I started writing one earlier today
I want to use Params to populate the request to the
serverclass.......
Now, I'm sorry to pollute the forum with such a simple question, but
I have no choice !
I have an Obey file containing something like the following
param day^of^week Tuesday
run object
I obey the obey file by typing obey file
It runs the program
I use the GETPARAMTEXT function to read the parameter in the cobol
program
For some reason, it always returns -1 (can't find the param
day^of^week)
I never really ran a program before from a tacl prompt........is
GETPARAMTEXT supposed to be able to pick up a Tacl Param when run
from a tacl prompt ?
Is there something I need to do ? I did RTFM a bit......
thanks
dimandja
Keith Dick
You probably did not use a SAVE directive to save at least the PARAM message. Look at the description of the SAVE compiler directive and if you have more questions or that isn't the problem, tell us more about the problem.
It might be a better choice to use SMU_Param_GetText_ rather than GETPARAMTEXT just because SMU_Param_GetText_ works with both COBOL85 and NMCOBOL/eCOBOL, so that there would be one less thing to change if you ever have to change the program to use the native mode compiler. You have to look in the CRE Programmer's Guide for the description of the SMU_xxxxx procedures. There isn't anything better about using SMU_Param_GetText_ except that you would not have to change the code if you ever switch to native mode.
P Kelly
> Can you post the code you supplied for GETPARAMTEXT?
ENTER "GETPARAMTEXT" OF COBOLLIB
USING WS-PORTION
, WS-TEXT
GIVING WS-RESULT
it works in lots of batch programs we run, but will not pick up params
when run at the tacl prompt
I'll try the save directive compiler thing..
P Kelly
It reads the param correctly........using SMU_Param_GetText_
thanks
Doug Miller
[...]
>I use the GETPARAMTEXT function to read the parameter in the cobol
>program
>
>For some reason, it always returns -1 (can't find the param
>day^of^week)
>
>
>I never really ran a program before from a tacl prompt........is
>GETPARAMTEXT supposed to be able to pick up a Tacl Param when run
>from a tacl prompt ?
Yes, absolutely. That's why it exists: to pick up param values provided by the
program that launched it (whether that program is TACL, or something else,
doesn't matter).
>Is there something I need to do ? I did RTFM a bit......
The Cobol manual does not clearly document the fact that if you want to
retrieve PARAM values using GETPARAMTEXT, your program must include the
compiler directive ?SAVE PARAM (or ?SAVE ALL).
Keith Dick
It probably would work with GETPARAMTEXT, too, if the proper SAVE directive was used, but using SMU_Param_GetText_ is the better choice.
wbreidbach
>
> - Zitierten Text anzeigen -
I would not use the PARAM but read the information from a file,
preferred an Edit-file. That would allow to send more than one message
and to build up something like a reproducable test-scenario.