2

I am attempting to send a file from IFS to an outq on our AS/400 system. Whenever I do, I get exactly what I send, as well as a line of "@" symbols of varying lengths appended to the end.

Here's the command I'm using:

qsh cmd('cat -c /path/test.txt | Rfile -wbQ -c "ovrprtf file(qprint) 
outq(*LIBL/ABCD) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)" 
qprint')

The contents of test.txt is just Hello World!

The output I get when I send the command is

Hello World!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

I have not found any posts online about a similar problem, and have tried changing values and looking for additional switches to get it to work. Nothing I'm doing seems to fix the issue.

Is there a command or switch that I am missing, or is something I have in there already causing this?

EDIT:

I found this documentation which is the first time I've seen this issue mentioned, but it's not very helpful:

“Messages for a Take Action command might consist of a long string of "at" symbols (@) in a pop-up message. (The Reflex automation Take Action command, which is configured in situations, does not have this problem.) A resolution for this problem is under construction. This problem might be resolved by the time of the product release. If you see this problem, contact IBM Software Support.”

The only differences are: 1) this is not a pop-up message, it's printed. 2) I don't believe we use Tivoli Monitoring, although I could be wrong.

Assuming we do use Tivoli Monitoring, what would the solution be? There's no additional documentation past that, and I am not a system administrator, so I can't really make the call to IBM Software Support myself. And assuming we DON'T use it, what else could cause this issue?

TheLittlePeace
  • 181
  • 13

1 Answers1

2

I get different results, yet similar. I created a test.txt with Windows Explorer, put in Hello, world!, saved it and tried the script. I got gibberish for the 'Hello, world!' and then the line of @ symbols.

My system is 7.3 TR5, CCSID 37 (US English) and my IFS file is CCSID 1252 (Windows English). Results did not change if I used a stream file of CCSID 819 (US ASCII).

I didn't have any luck modifying Rfile switches.

I found that removing devtype(*userascii) produced printed output in plain English without the @ symbols. Do you really need *USERASCII? I would think that would be more for a pre-formatted 'print-ready' file like Postscript or the like.

EDIT: some more things to try I don't understand why *USERASCII is adding those @ symbols; it looks like a translation issue.

I tried this and still got the extra @@@... You might have to play with the TOCCSID() parameter. Although a failure, it did give me an idea: what if those @ symbols are EBCDIC spaces being sent as-is to the *USERASCII print stream? All we'd need is a way to send only the number of bytes in the stream file, without any padding.

CRTPF FILE(QTEMP/PRTSTMF) RCDLEN(132)

CPY OBJ('/path/test.txt') TOOBJ('/qsys.lib/qtemp.lib/prtstmf.file/prtstmf.mbr') replace(*yes)

ovrprtf file(qprint) outq(*LIBL/prt3812) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)

cpyf prtstmf qprint

The data in QTEMP/PRTSTMF is in ASCII; DSPPFM shows that much. It also shows a bunch of spaces: after all, it is a fixed length file. My next step was to write an RPG program to read the stream file and print it, but Scott Klement already did that: http://www.scottklement.com/PrtStmf.zip

This works on my system:

ovrprtf file(qsysprt) outq(*LIBL/abcd) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)

prtstmf stmf('/path/test.txt') outq(abcd)
Buck Calabro
  • 7,558
  • 22
  • 25
  • Removing DEVTYPE(*USERASCII) caused the file to be stuck in the outq... every time I try to release it, it goes back to being held. I tried the other device types: AFPDS gives me random characters, IPDS doesn't let me release, SCS gave me different random characters, LINE would not release, and neither would AFPDSLINE. – TheLittlePeace Mar 05 '19 at 17:14
  • Check for messages in QSYSOPR message queue (DSPMSG QSYSOPR), and also check the job log for the writer (WRKWTR nnnnn, F17, option 10). Look at the detailed messages, F10. This will give you a clue as to why the output will not print. What are the CCSIDs of the system and stream file? – Buck Calabro Mar 05 '19 at 17:46
  • Hmm, it looks like it's now just defaulting to *SCS when I omit DEVTYPE completely. When I look at the job log for the writer, it's giving me no new errors, but at some points in the past it says "SCS data stream is not valid. Error occurred while transforming data". Doesn't this make sense, since I'm trying to send the text file directly? Stream file CCSID is 1252 and system is 65535. – TheLittlePeace Mar 05 '19 at 18:24
  • The system at 65535 is probably why your results differ to mine. 65535 means (binary, do not translate) even tough it tries to translate to US English. Mostly. I edited the answer for a few more suggestions. The writer's job log will give an error when the spooled file is released. If it can't handle the file, it issues that message and holds the spooled file - making it 'stuck' as it were. – Buck Calabro Mar 05 '19 at 19:21
  • The Scott Klement solution worked! No @ signs. Thank you very much! – TheLittlePeace Mar 05 '19 at 20:22