I am sending a file from UNIX to MAINFRAME server via connect direct. I am able to upload the file successfully.At the destination host, when the file is received it is not readable and not in the same format as I sent from the UNIX server.
Below is the transmission job
Direct> Enter a ';' at the end of a command to submit it. Type 'quit;' to exit CLI.
submit maxdelay=unlimited TINIRS process snode=b1ap005
TRANSMIT copy from (file=myFile.txt
pnode
sysopts=":datatype=text"
)
ckpt=1k
to (file=myFile.txt(+1)
snode
DCB=(DSORG=PS,RECFM=VB,LRECL=1500)
disp=(new)
)
pend ;
Please let me know the DCB values needs to be updated. The file I am sending has 3 records of variable length and the maximum length of record is 1500.
Actually, that looks almost right. But if your maximum record length is 1500 characters (exclusive of the NL at the end of the line), your LRECL should be at least 1504. But don't skimp on the maximum - there's no cost or penalty to larger values (up to 32767). And NealB's correct - if this is a text file, you may need to specify a character-set translation - but I don't know how to do that in CONNECT:Direct.
C:D automatically converts ascii to EBCDIC when DATATYPE=TEXT is used. To be positive, you may want to use ":datatype=text:xlate=yes:".
Related
I'm using phpagi $agi->get_data to read digit from user.
In some telephones, user didn't hit any key, but audio playback immediately stops and get result of "D" !!
I searched a lot about it, and looks like $agi-get_dat receives DTMF data that contains 0-9*#ABCD.
1st question is, why my users get "D" without hitting any key!
2nd question is, how can i ignore these characters to prevent interrupting my ivr.
phpagi getdata do this call
https://wiki.asterisk.org/wiki/display/AST/AGICommand_stream+file
so you can extend it by adding allowed digits param. PhpAGI lib is opensource and have source code.
Actualy you can just use stream_file call
stream_file (line 677)
Play the given audio file, allowing playback to be interrupted by a
DTMF digit. This command is similar to the GET DATA command but this
command returns after the first DTMF digit has been pressed while GET
DATA can accumulated any number of digits before returning.
return: see evaluate for return information. ['result'] is -1 on hangup or error, 0 if playback completes with no digit received,
otherwise a decimal value of the DTMF tone. Use chr() to convert to
ASCII.
link: http://www.voip-info.org/wiki-stream+file
example: Ping an IP address
array, stream_file (string $filename, [string $escape_digits = ''],
integer $offset)
string $filename: without extension, often in /var/lib/asterisk/sounds
string $escape_digits
integer $offset
you can check the logs by the following command :
asterisk -vvvvv
and you can check the value of the input for example in php code :
$val = $agi->get_data
exec("echo $val >> /tmp/output")
and then check this file : /tmp/output
I made a call flow using php AGI in asterisk. For getting DTMF from caller, I have user fastpass_get_data() function of AGI. In this function caller can press any key. As and when caller press any key, playing prompt will be stoped.
Now I want that when caller press "1" at that time only that playing prompt will stop. So while prompt file is playing and user press any digit except "1", it will not affect playing file. But if user press "1" playing prompt file file should be stopped and call flow continue onwards.
Thanks !!!
Use streamfile command
stream file Usage: STREAM FILE <filename> <escape digits> [sample offset]
Send the given file, allowing playback to be interrupted by the given digits, if any.
Use double quotes for the digits if you wish none to be permitted.
If sample offset is provided then the audio will seek to sample offset before play starts.
Remember, the file extension must not be included in the filename.
Returns: failure: 200 result=-1 endpos=<sample offset> failure on open: 200 result=0 endpos=0 success: 200 result=0 endpos=<offset> digit pressed: 200 result=<digit> endpos=<offset>
http://www.voip-info.org/wiki/view/stream+file
When I call sqlite3_open_v2() on a zero byte file with flag SQLITE_OPEN_READWRITE, the function returns zero. Then the "PRAGMA quick_check;" statement returns a row containing string "ok". So zero-byte file is considered a valid database? Seems a little counter-intuitive?
Well I don't think it's "valid". If it's zero bytes, it's nothing, other than a reference. Yes you can open it. But that's not working if the file has >= 1 byte.
So as long as the file is 0 bytes, you can open it; once you start making changes, it will become an SQLite file.
If you open a non-SQLite file and try to make changes, it will give you an error message:
Error: file is encrypted or is not a database
The (only) way to create a new, empty database is to attempt to open a non-existing file.
A zero-sized file is considered the same; it's just an empty database.
There are some settings (such as the page size) that must be set inside an opened database connection, but that would affect the structure of the database file.
Therefore, SQLite delays actually writing the database structure until it is actually needed.
I am trying to create a file format for myself, so i was forming the header for my file. To write a known length string into a ByteArray, which method should i use, writeUTF() or writeUTFBytes().
From the Flex 3 language ref, it tells me that writeUTF() prepends the length of the string and throws a RangeError whereas writeUTFBytes() does not.
Any suggessions would be appreciated.
The only difference between the two is that writeUTFBytes() doesn't prepend the message with the length of the string (The RangeError is because 65535 is the highest number you can store in 16 bits)
Where you'd use one over the other depends on what you're doing. For example, I use writeUTFBytes() when copying a XML object over to be compressed. In this case, I don't care about the length of the string, and it'd introduce something extra to the code.
writeUTF() can be useful if you're writing a streaming/network server, where as you prefix the message length to the message, you know how many bytes to stream on the other end before the end of the message. e.g., I have 200 bytes worth of message. I read the length (16-bit integer), which tells me the message is 100 bytes. I read in 100 bytes and I know it's a complete message. Everything after is another message. If the message length said the message was 300 bytes, then I'd know I'd have to wait a bit before I have the full message.
I think i have found the solution myself. It came to me when i was coding to read back the data. The corresponding functions to read from a bytearray readUTF() and readUTFBytes(length:uint) requires the length to be passed to it.
So if you know the length of the string that you are gonna write, you can use writeUTFBytes() and use readUTFBytes() with that size. Else you can use readUTF(), letting as3 write the size of the data which can be read back without any need to know the length of the string while using readUTF().
Hope this might be useful to some one as well.
I have a device that sends data to a server.
Data
[ Client ] == > [ Server ]
After the validation on the server I want to return a message:
OK
[ Client ] < == [ Server ]
Is there a standard "OK" message to return? And an "ERROR" message? How does it looks like? (e.g. ":0011", ":110F")
You've got to design an application-level protocol. TCP is a byte stream, so even the definition of "Data" in your client->server piece needs some protocol so that the receiver can know what bytes make up the data (when to stop reading).
A couple of common types of protocols are...
Length-delimited chunks. Every message starts with a 16 or 32-bit length prefix. Then that many bytes follow. The length needs to be in a defined byte order (see htons, ntohs, etc). Everyone who uses this protocol knows to read the length prefix then read that many bytes. Having defined that "chunk" on the network, you might put a header on the contents of the chunk. Maybe a message type (ACK, NAK, Data, etc) followed by some contents.
ASCII newline delimited. Each message is a line of ASCII (or UTF8, etc) text. It ends at a newline. Newline endings for the lines play the same role as the length prefix for the chunks above. You then define what's in each line (like space or comma-delimited ASCII/UTF8/whatever fields). Somewhere in that you'd define what data looks like, ACK, etc.
I'm sure you could come up with other ideas, but that's the basic job: defining your application-level protocol on top of TCP's byte stream.