hope someone can help me. I cannot see the DSPLY 'some text' output from my RPGLE program in the command window. I am using IBM Websphere development studio client for iseries to create a simple RPGLE program. I can compile the program with no errors, but cannot see the display text to see if it works when running it CALL MYLIB/TESTRPG.
Here's my program code:
/free
dsply 'Hello World';
return;
Please help. Feels like i am "learning in the dark".
Thanks in advance
If you are running your program on the emulated terminal (the green screen), then there are some places where your program's output does not really show (it lights up during the execution time of your program, but that's normally to brief to even notice it).
You can look at what has been displayed in your interactive job's joblog with dspjoblog (it's a little weird to use at first).
execute the command dspjoblog
press F10 to display all messages
pres PageUp to scroll to previous messages
You should be seeing something like:
3 > call MYLIB/TESTRPG
DSPLY Hello World!
There are places where you don't have to do that. The tool PDM is one such place (at least on the machine I'm using). You can start that program by simple entering
strpdm
You will have a command line at the bottom, from which you can call your program. While inside PDM, every dsply command should interrupt the flow of your program, light up and wait for you to hit Ctrl or Enter or whatever your key for execution is.
Another place where you can see your messages immediately is QCMD. You can start it by typing
call qcmd
You may have to hit F10 there, that toggles display of your dsply messages. Here you will see the messages without having to press return.
If you are in fact running your program directly from within IBM Websphere Development Studio, I am afraid I can't help you, since I never do that. If you have access to a terminal, you might be able to try one of the ways I described.
This is just a note I made on this in 2006 (16 years?!) about calling CL within RPG.
Maybe change the DLYJOB below to SNDMSG, SNDBRKMSG, etc
(https://www.ibm.com/docs/en/i/7.4?topic=messages-commands-used-send-system-user)
/IF Defined(*CRTBNDRPG)
H DFTACTGRP(*NO)
/ENDIF
H BNDDIR('QC2LE')
D GoCmd PR 10I 0 Extproc('system')
D CmdStr * value
D options(*string)
D NullString C -1
D Success C 0
D Returncode S 10I 0
D User S 10 Inz(*User) Varying
/free
Returncode = Gocmd('DLYJOB DLY(300)'); // change to a SNDBRKMSG maybe?
Select;
When Returncode = Success; // Command was successful
When Returncode = NullString; // Command string was null
Other;
Endsl;
*INLR=*ON;
/end-free
Good luck
Related
I am working on a Tcl project where a certain procedure will run continuously. user can abort that procedure anytime using some Key-Combination. So basically, I need to trap the signal within Tcl code. So far, everything is done except one problem.
I am using Ctrl+Z i.e. SIGSUSP signal (SIGTSTP in case of Tcl) which technically does the job.
signal trap sigtstp onAbort
But, pressing Ctrl+Z immediately returns the Shell prompt, rest of the output from the program comes after that and when output comes to an end, no shell prompt returned (as it is already returned before). I need to press Enter again to get the prompt.
Following is the case I am refering to. You can see the prompt (polaris#ubuntu:~$) is returned in between output of the main program.
Also as output of pressing Ctrl+Z, it returned [40]+ Stopped, which is bit annoying. Can I avoid this ?
Can I avoid this whole problem using some other key-combination i.e. signal ? Or can I avoid this with Ctrl+Z also by tweking something ?
NOTE: I have tried using Ctrl+C. I got the exactly expected behavior with that. Unfortunately I can't use Ctrl+C as it is used for some other functionality.
Cz causes the shell to send the current foreground process a SIGSTOP(19). This signal cannot be caught or ignored and so your program will receive it and run the default handler. This is not killing the process as your question suggests you're trying to do. This only suspends it and you can bring it back into the foreground using fg on most modern shells.
Looks like you're out of luck. However, you might be able to rebind the keychord at the level of the shell. This is outside your program though and your end users don't have control over it. (Cf. https://superuser.com/questions/378018/how-can-i-do-ctrl-z-and-bg-in-one-keypress-to-make-process-continue-in-backgroun)
Also, if your program relies on user inputs for various actions (since you suggest that C-c does something else), perhaps you should make it a full fledged CUI application using curses or something?
In IDLE, there's no clear screen, and after reading the forums the best method is plainly to print a ton of "\n"s. However, after playing with IDLE, I made a discovery. When my game was waiting for an input after printing out instructions using print statements, instead of inputting any useful character, I entered 'control-z,' and IDLE began to remove the text that was display by the print statements, one by one.
My main question is, how do I manually in the code itself enter 'control-z', so I can utilize this functionality?
If you're confused by my story, here's some example code and try it yourself by hitting control-z.
print("Some Text")
print("More Text")
input("The Input (Hit Control - Z Here):")
^Z is a bit of a mess. The ascii control char ^D is usually interpreted as EOT, end of transmission, which on Unix and many other systems means end of file, close the application. Ascii ^Z is meant to be interpreted as SUB, substitute, whatever that means. Editors ofter use it as UNDO (meaning undo a ^X cut). Microsoft (and a few other old systems) at least sometimes interprets ^Z as end of file, with the same effect as ^D on *nix.
The Windows console closes a text app after ^Z . ^D is passes on to the app. IDLE, as a cross-platform app, closes on ^D. IDLE used to close on ^Z on Windows, but now, for me, it only erases the prompt. (I don't know if this alternative is intended.) I do not see the progressive deletion you report. What OS and what Python version are you running?
To answer your main question: you can't. input is usually used in assignment statements: string = input('prompt'). The way to imitate input statements is to directly assign 'user input': s = 'simulated user input'. However, this does not work for characters that get intercepted by the programs managing the input window and never sent to the python program.
IDLE's Shell generally imitates Python's interactive console. The latter (at least on Windows) makes everything, except the current input, read-only. Shell follows suite. Imitation is especially strict as regards executing user code. It is intended that user code tested in IDLE should run in Python without IDLE. It would be wrong for IDLE to clear the interactive shell in response to user code when Python cannot.
For editor and output windows, ^A (select all) followed by Backspace (delete), Delete, or ^X (cut) do clear the window.
Shell does, however, has more editing commands than many (most? all?) consoles and a menu system. These additions are allowed since they are interactive only and not accessible from user code. There have been various proposals and patches to enable clearing part or all of the shell window. https://bugs.python.org/issue6143 has some of the discussions and proposals.
I'm using Microsoft Visual C++ 6.0 and trying to debug someone else's program. I tried to use printf statements but for some reason, these statements are not shown on the screen as the program runs. I am able to use fprintf to print these statements to file, but this is useless when the program crashes in the middle of execution, as the file would be empty then.
How can I force some output to screen?
To force output to the screen, please see the first section below. The second and third options below are also good for debugging program crashes like these.
Using printf with fflush (refinement of Vishal Kumar's answer)
Vishal Kumar's answer worked for me, but I had to do a little research to find out how to use fflush. I had a problem where my program was crashing "in the middle" of a printf statement which did not make sense. Here is my refinement of his answer. In cases where a debugger is difficult to use (e.g. multithreading), you can use fflush after every printf (or fprintf) statement. For example, "pepper your code" with:
... // code
printf("Part 1 executed successfully");
fflush(stdout); // flushes the stdout buffer
... // further code
printf("Part 2 executed successfully");
fflush(stdout);
... // repeat as necessary
Run, observe the output, and put more print statements between the last statement that prints, and the first statement that doesn't print, until you isolate the problem.
Debugger
If you are able to use a debugger, it is a more efficient choice than peppering your code with output statements as described above, but there are cases where you have to resort to that.
Valgrind
If you are using Linux (which I gather you are not because it is in MS Visual C++), valgrind is another option to see where your code is crashing (and for detecting memory leaks). If your code is compiled for debug, if your program is called "myProgram", you can just call from the terminal window as follows:
valgrind myProgram
How do I scroll up and see previous displayed lines in the output?
I'm using QB64, and had to run a program 1000 times, but I cannot see the starting lines. Actually, I can't see the first 800 lines or so.
Is there a way to expand the window or scroll up to see everything? Because I do not have a scroll bar, and if I use any key to scroll up, it exits the console window.
Thanks in advance.
The new version of QB64 supports a console window, which should be able to do what you want. I'm not too used to console though, but if all else fails you could always save the text in a string array and examine that. There are some examples of creating lists in the community at qb64.net or you could make your own list with scrollbars, etc.
Input a line in the loop for data output:
if x > 24 then
if 24 MOD x then sleep
endif
MOD is the command for modulus where the modulus will return the remainder of 24 and x. in this case if it is zero then it will pause the console output until the user presses any key.
If you don't want to mess with custom buffers, just use the console:
$CONSOLE:ONLY
_DEST _CONSOLE
With that in the begining of your program, QB64 will create only a console window, which by default can be scrolled back so the past lines can be seen.
I have an linux app that uses cups for printing, but I've noticed that if I print and then quit my app right away my printout never appears. So I assume that my app has to wait for it to actually come out of the printer before quitting, so does anyone know how to tell when it's finished printing??
I'm using libcups to print a postscript file that my app generates. So I use the command to print the file and it then returns back to my app. So my app thinks that the document is off to the printer queue when I guess it has not made it there yet. So rather than have all my users have to look on the screen for the printer icon in the system tray I would rather have a solution in code, so if they try and quit before it has really been sent off I can alert them to the fact. Also the file I generate is a temporary file so it would be nice to know when it is finished with so I can delete it.
As soon as your CUPS web interface (localhost:631) or some other thing to look at what CUPS sees shows you that CUPS received the job, you can quit the application.
How about using a print spool service like lpr & lpq?
You certainly do not need to wait till the paper is out of the printer. However, you need to wait until your temporary file is fully received by cupsd in its spooling aerea (usually /var/spool/cups/).
If you printed on the commandline (using one of the CUPS lp or lpr commands) you'd know the job is underway if the shell prompt returns (the command will even report the CUPS job ID for the job sent), and if the exit code ($?) is 0.
You do not indicate which part of libcups and which function call you are using to achieve what you want. If I'd have to do this, I'd use the IPP function cupsSendRequest and then cupsGetResponse to know the result.
Your app likely hadn't finished printing yet when you quit it. If you're using evince to print a PDF or other document, this is a known bug--there is no visual confirmation that the printing operation is underway. If the print job has been submitted, a printer icon will appear in your system tray until the actual printing has finished. You can click on the printer icon in the system tray and see what jobs are currently running and pending.