I'm parsing an XML using XMLLite. I notice that when its a relatively large file, the reader's pointers fails to locate the next element(tag) of the file. When i reduced the contents of the file, it could successfully parse.
The reader continually shows node type "XmlNodeType_None" and fails to complete parsing, getting stuck in an infinite while loop.
Is it to do something with its file size? Or anything in initializing the IStream? My file has around 9000 bytes of data only.
Thanks
Do not use the SUCCEEDED macro to check if you should continue processing the value returned by IXmlReader::Read. Instead, check that the return value of IXmlReader::Read is equal to S_OK for the condition of your loop.
Related
I am dynamically creating a PS file (based on timestamp from input file) on the Cobol program and using it as output file to write transaction details, but if the input file s received twice, job is failing with duplicate dataset. So I thought of rewrite the file if the file is already allocated. To do this i have tried all these options I-O/Extend/Output to open the output file but it is failing with Filestatus 98
Any idea how can to do this?
DISPLAY '5000-B-->'
PERFORM 5000-ALLOCATE-ACK-FILE [ Allocate File Dynamically]
DISPLAY '5000-A-->'
DISPLAY 'I-O--B-->'
OPEN OUTPUT OUT-ACK-FILE
DISPLAY 'WS-OUTACK-STATUS-->' WS-OUTACK-STATUS
DISPLAY 'I-O--A-->'
Error:
ALLOCATE OK 00
5000-A-->
I-O--B-->
IGZ0255W Dynamic allocation failed for ddname OUTACK while processing file OUT-A
return code from the dynamic allocation was X'4', error code X'FFFFFFFF
information code X'0'.
WS-OUTACK-STATUS-->98
I-O--A-->
You don't show details of how the allocation is done, or how you check for existence of the data set.
Anyway, on z/OS the DISP parameter of the allocation of a PS data set determines whether the data written replaces the current content (if any), or whether it is appended to the current content (if any).
DISP=NEW and DISP=OLD replace
DISP=MOD appends.
The OPEN parameters don't vary.
I start using a TFileStream and TStreamWriter to write simple text logfiles (instead of old Writeln(T,....)). And I have multiple applicatiosn writing to the same logfile.
Each appplication has its own TFileStream of course and they each open the file like this
FFileStream:=TFileStream.Create(LogName, fmOpenReadWrite+fmShareDenyNone)
FExporter:=TStreamWriter.Create(FFilestream, TEncoding.UTF8);
FExporter.NewLine:=#$0A;
FExporter.AutoFlush:=TRUE;
and write to the file with
FExporter.BaseStream.Seek(0, soFromEnd);
FExporter.Write('['+DateToStr(Now, FDateTimeFormat)+'] ['+TimeToStr(Now, FDateTimeFormat)+'] [#'+Lead0(GetCurrentThreadId, 5)+']: '+EntryText);
FExporter.WriteLine;
the result is somewhat "unsatisfactory" as the lines are displaced, empty lines in between and does not seem to work.
HOW would I do that correctly?
Writing multiples lines at the same time in multiples process may result in unexpected continue, because parallels execution.
You should assure that you are writing a block continually so WriteLine shoud be send inside the write using lineBreak at the end.
So the way you can write should be:
FExporter.BaseStream.Seek(0, soFromEnd);
FExporter.Write('['+DateToStr(Now, FDateTimeFormat)+'] ['+TimeToStr(Now, FDateTimeFormat)+'] [#'+Lead0(GetCurrentThreadId, 5)+']: '+EntryText + System.slineBreak);
//FExporter.WriteLine;
Update1:
As the link Oliver posted, sometime it can not work if the message size to be written is bigger than the OS file sector and, at that very moment, other process also try to write a message. Thus in this case the result content might be mixed.
So doing what I first purpose you would increase the probability to have the desired result, but may not be the solution in 100% of the cases.
To be 100% sure of writing continuous log in a single file, using multiples process, you should create a log process to receive a message from the others and to be the only responsible for writing synchronized log throughout threads.
I am trying to read the contents of an ostrstream using the str (). While trying to do so, i always come across access violations and my application crashes. Is there a way to read from strstream without causing stream errors?
I am working on a legacy project built on Borland C++. I am presently using Borland C++ v5.02 for building my project. Since the code is vast and scattered over a large number of files, I am unable to paste the code here. However, I will try to highlight my use case.
ps is the stream which is being used throughout the project to print receipts. I need to get the receipt data from this strstream without breaking the code.
string str = ps.pStr->str ();
ps.Pstr->rdbuf ()->freeze (0);
ps << EndJob;
The last line causes access violation
You missed set null in the end of the buffer.
Before any call to str() that uses the result as a C string, the buffer must be null-terminated, typically with std::ends.
Hi I am using LabView 2012, Delphi XE7 and GPIB (I think 488.2), Win7 SP1 and Agilent 53131A.
I used the given NI examples.
NI Labview example - Found in LabVIEW's help - GPIB.vi.
I tried writing and reading to query frequencies from 2 channels and they are successful.
They are are sent and read in succession.
*IDN?
:FUNC 'FREQ 1'
:READ:FREQ?
If they are successful, that meant GPIB for Agilent and NI MAX and driver are successfully installed and configured.
I am also able to use KeySight Connection Expert's to write and read, Again it is also successful.
However, When I used the given NI example in Delphi. Orginally it was saved as Delphi 3 or 4.
I used the Scope Simple example for universal counter. I used it mostly for writing and reading in the simple way. All it needs initialization, read/write and cleanup
I changed the following codes as shown below, in SimpleForm.pas
The detected device is at GPIB0::3::INSTR so, at line 32,
PRIMARY_ADDR_OF_COUNTER = 3;
String to write and read so, at line 132,
CommandBox.Text := '*IDN?';
then it was compiled with no error and run.
String to write was successfully
But upon reading, it was not successfully.
The string output is supposed to be ' HEWLETT-PACKARD,53131A,0,4806'.
The error at the end of the program is as follows below:-
Unable to read from device
ibsta = SC000 <ERR TMO>
iberr = 6 <EABO>
ibcntl = 0
From these readings, I figured out as :-
EABO means abort
I am not familiar with working of GPIB. Kindly advise.
You are correct that EABO is the identifier for an abort. In addition, we can see from ibsta = SC000 <ERR TMO> that the cause of the abort was a GPIB timeout error. I am not familiar with Keysight Connection Expert or your instrument, but since the error was from GPIB timeout, the most likely causes are:
The query was improperly formatted and the instrument thought it was just a write statement with no response needed. (That's probably why the write function had no error, but the read function timed out.)
The query was improperly formatted and the instrument returned an error.
Instrument needs to have 'Talker' capability enabled to send data. (Most instruments do this automatically with queries.)
For more information on generic GPIB commands, see this reference from the folks at National Instruments.
My COBOL program reads a VSAM file that may or may not be empty. When the file is empty i get a status code 35 while opening in INPUT/I-O mode. I do not want to handle it in program but in a JCL. Is there any way by which VSAM file can be checked if it is empty or not...if it is not possible through a JCL then can we handle it in program without having to check status code 35?
Add OPTIONAL to the SELECT clause in the FILE-CONTROL paragraph.
SELECT OPTIONAL fdname
ASSIGN TO ddname
...
When you get a starus "35" exit the program with a
MOVE 8 TO RETURN-CODE.
GOBACK.
[example here][1]
http://ibmmainframes.com/about60344.html
You can then test for a non-zero return code in your JCL with a COND=8 on the next step which will only execute when your program detected an empty file.
I seem to recall that you could use IDCAMS to repo the file into a dummy dataset and you would get an RC=4 if it was empty.
That is from memory a few years ago, but then you could put that check in your job stream before running your program and control execution of the next step using the IDCAMS return code.