This is a statement referring to problem caused by page fault:(from Silberschatz 7th ed P-310 last para)
'We cant simply restart instructions when instruction modifies several different location
Ex:when a instruction moves 256 bytes from source to dest and either src or dest straddles on page boundary , then,after a partial move, if a page fault occurs, 'we can't simply restart the instructions'
My question is::
Why not?
Simply restart the instruction again do the same copy after page is in.
Is there any problem in it?
[edit]Can anyone explain
What exactly happens in case source and destination locations are overlapping?
[/edit]
P.S=> sorry for the late edit.
Because the counter register (e.g. ECX) has been changed since the start of the operation.
Related
I am working on a pexpect script that is running populating an output file name and then a prompt for the file's parameters.
The program that the script runs asks for Device: then Parameters: always on the same line.... so if the file path-name that is entered for Device is long, sometimes the Parameters prompt wraps to the next line.
My code looks like..
child.expect_exact('Device:')
child.sendline('/umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
child.expect_exact('Parameters:')
This times out.. and here is what is in child.before
' /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT Param\r\neters: "RWSN" => '
so the expect fails... (a child.expect('Parameters:') also fails)
How can I ignore the \r\n if it is there, because depending on the length of the path/filename I am using it may not be there at all, or be in a different position.
Thanks!
Actually... I found a way to calculate how much is left on the given line, and dynamically set my expect to how much of the Parameter prompt should be visible... seems to be working
#look for end of line and fix how much of 'Parameters:' we look for in pexpect
dlen = 80-len('Device: /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
pstr='Parameters:'
if dlen > len(pstr):
dlen=len(pstr)
else:
dlen=dlen-3 #remove the /r/n
child.expect(pstr[0:dlen])
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?
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)
I have a program create by Delphi language. This run on windows XP SP3.
After Open and stop program multi time (~600 to 700 times) (Only open and stop, does not do any thing). My program will be error:
Cannot input to text box of system.
Cannot click on some button.
When bug has occurred, the error will exist until the computer is restarted. (Restart program cannot resolve this bug)
I was check some information of system, and bellow is result:
Total GDI handles is less than GDI handles in normal: (Use GDIView to detect that)
case normal: 3513 GDI handles
when error occur: 3410
Class Name of control is bad: (Use spy++ detect)
Normal: Class name of text box is Tedit.
When error occur: "Toolbar_Customize" or "" or any value (This value is awlay change) ==> I think because that, i cannot input value to textbox.
Some time, i cannot start another program of windows when this bug occur.
Please help me.
P/s: any unclear please comment
This reminds me of the following issue (Resource leak caused by RM_GetObjectInstance message):
http://qc.embarcadero.com/wc/qcmain.aspx?d=90511
There is a workaround in the last comment.
I have a BEAST of a program written in VB6. It uses ActiveReports to generate letters.
The reports are processed in a loop; with verbage-building loops and (a whole lotta) nested 'if' and 'case' statements. Fugly!
The reports are sent to the printer like such:
Function PrintIt(ltrobj as Object)
Set ltrobj = MyARdocument '(.Dsr file)
ltrobj.txtfield1 = strVerbage 'This string was populated somewhere else
ltrobj.Printer.DisplayProgressDialog = False
ltrobj.PrintReport False
End Function
Now here's the weird part: The pages physically come out of the printer rotated 90 degrees each iteration of the loop. What's even weirder -- this only happens for my VB6 application -- other Word documents, reports, batch jobs, whatever come out normal.
So the first page comes out like normal, the header first (pointing North). The second page comes out sideways (header pointing West). The third comes out of the printer like the first, the fourth comes out like the second, and on and on...
The printer: A Ricoh Aficio MP5000
I cannot find a setting on the printer, or a property in ActiveReports that controls this.
Any ideas, help, or a general direction would be greatly appreciated!
Thanks,
Jason
There is no "rotation" setting in ActiveReports. The closest things that might impact this would be the page size and orientation, but at worst I would expect them to flip back and forth not actually rotate the page. I would try to do a few things:
Trace the printer & page settings related to orientation and page size as report prints.
Try printing to another printer to see if it happens on all printers or just this one.
Preview the reports on screen and see if they're rotated in the preview or not (or export them to PDF with report.Export(...) ad see if they're rotated there).
To trace page settings you should do it in a couple places. One on the printer, and another on each page (or Canvas) in the report. There is also the ActiveReport.PrintWidth (the width of the report, not the pages) that may also be relevant. So just before printing each report try tracing out the following values:
report.PrintWidth
' the default settings for the report
report.PageSettings.TopMargin
report.PageSettings.RightMargin
report.PageSettings.BottomMargin
report.PageSettings.LeftMargin
' actual printer's current settings:
report.Printer.PaperSize
report.Printer.PaperHeight
report.Printer.PaperWidth
report.Printer.Orientation
' settings for a specific page:
for each page in report.Pages:
report.Pages(...).Width
report.Pages(...).Height
report.Pages(...).Orientation
BTW: ActiveReports COM Help is here.
If the preview/PDF test seems okay then I'd focus on the printer itself. Same for the print to another printer obviously. Otherwise, focus on ActiveReports settings.
Hope this helps
Scott Willeke
GrapeCity
Delphi 2007 on windows 7 just does nothing on the saveDialog.Execute call. I have seen another person mention this a few weeks back but it was with Borland c++.
See the thread "TOpenDialog.Execute not working " on embarcadero newsgroups.
Problem there was resolved by deleting the executable name from
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options"
I got the same problem (savedialog not working) in windows XP.
After lots of unsuccessful attempts according to the voluminous exchanges in the embarcadero group you mention (https://forums.embarcadero.com/thread.jspa?messageID=196950&tstart=0#196950).
I found what the reason was : the initial file dir and filename of the Savedialog12 were bad, contradicting each other, the filename containing the fullpath of the last file I had opened (I had thought it was smart to prepare the saving of the file I had opened last; unfortunately what I had put in the initialdir was equal to what I had put in the filename !)
The problem was already solved by clearing both fields of the save dialog.
Further, my initial goal to prepare the saving was reached by putting valid values in the involved fields :
SaveDialog1.FileName:=ExtractFileName(Opendialog1.Filename);
SaveDialog1.InitialFileDir:=ExtractFilePath(Opendialog1.Filename);