i got a problem with simple cobol call - returning test program.
I am using micro focus cobol.
here are my 2 codes.
***************** CALLING PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. callreturning.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 VA PIC S9(8) USAGE DISPLAY.
01 VB PIC S9(8) USAGE DISPLAY.
01 VC PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION.
MOVE 1 TO VA.
MOVE 2 TO VB.
move 3 to VC.
CALL "add_two" USING VA VB returning VC.
* DISPLAY VA VB VC.
EXIT PROGRAM.
END PROGRAM callreturning.
*********CALLED PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. add_two.
ENVIRONMENT DIVISION.
DATA DIVISION.
LINKAGE SECTION.
01 PARM_A PIC S9(8) USAGE DISPLAY.
01 PARM_B PIC S9(8) USAGE DISPLAY.
01 PARM_C PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION USING PARM_A PARM_B returning PARM_C.
move 3 to PARM_C.
* ADD PARM_A TO PARM_B GIVING PARM_C.
goback.
END PROGRAM add_two.
CALLING program simply calls the second program with using returing value.
But when i compile both program and run, error happens.
error code: 114, pc=0, call=1, seg=0
114 Attempt to access item beyond bounds of memory (Signal 11)
Did i make a wrong code? or other problem? please help me :)
I am testing 'RETURNING' phrase
Your program compiles and works just fine if you get rid of the returning statement.
Background
01 levels defined in the linkage section are more like pointers in a C program. For normal parameters they are set by the calling program. But returning parameters will be unassigned.
The error is probably caused by trying to use an unallocated pointer.
Solution
Do not use returning as it is for working with languages like java.
Allocate storage to the return-value before using it.
See:
Microfocus Manual, Look at the returning example
IBM Manual Look at the Returning Phrase Section
Finally, returning is for working with java. Anything "type" defined on returning should be java compatible (i.e. binary-long and not 9(4)). I strongly suggest not using Returning in Cobol unless you are calling other languages.
Old Question, so i try a short Answer:
First, there is nothing wrong with using returning in MF-COBOL.
So, this is native COBOL (NetExpress as IDE, i assume). To correct ist just change the second Program:
Move PARM_C from the linkage to the working-storage section
The Procedure Division doesn't get the returning Phrase in its opening declaration. Move it instead to the goback phrase:
PROCEDURE DIVISION USING PARM_A PARM_B.
*>...
goback returning PARM_C.
Related
I'm trying to get reflection information for a compute shader compiled by my program by calling D3DCompile() or D3DCompile2().
Compilation is OK, confimed by code executing correctly.
Then I call D3DReflect to get a reflector against the compiled code.
Once I have the reflector, I call reflector->GetDesc(&ShaderDesc);
This works perfectly: ShaderDesc structure reports ConstantBuffers equal to 1 which is correct.
Then I call reflector->GetConstantBufferByIndex(0) which always returns the null pointer.
What is wrong ?
My environment: Windows 10 fully up-to-date, DirectX11 on NVidia Quadro K4200 with driver 24.21.14.1240 dated 21/07/2019, D3DCompiler_47.dll dated 19/03/2019.
Edit:
In the shader, the constant buffer is defined like this:
cbuffer TImageParams : register(b0)
{
int2 RawImageSize; // Actual image size in RawImage
// More items....
};
Kind regards
I have a very old piece of code to handle Excel files in Delphi 5, which I adapted to work with Delphi 2005, which I used professionally until 2010. Since then, there was no reasonable free version of Delphi. Therefore, it is only now that using Delphi 10.2.3 Tokyo I would like to adapt it once again.
A problem that I was not able to solve is related to the use of OleStream.Seek(...) in the function given below, where I get a fatal error with all expressions in OleCheck(...).
Also, I didn't find any hint on a similar problem searching for the function OleStream.Seek(...) on the Internet.
The code is the following
function Streamseek(offset : longint; origin: word):string;
var
Pos : longInt ; // Pos: largeint;
begin
if FBIFFVersion > biff4 then begin
case Origin of
soFromBeginning:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_SET,Pos)); // ENUM: set =0
soFromCurrent:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_CUR,Pos)); /// 1 cur
soFromEnd:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_END,Pos)); // 2 end
end;
Of course, it is just one function in a much bigger program, which is not relevant here.
My problem is: I searched for
OStream.Seek(Offset,STREAM_SEEK_SET,Pos) on the Internet, but I could only find OleStream.seek(offset : longint; origin: word):string; except for one webpage, but there the same types were used.
Working with IStream in Delphi
So, I wonder what parameter types need to be used.
In the German version of Delphi 10.2.3, I get the error:
[dcc32 Fehler] line(878): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen
In English:
The types of the real and the formal var parameters must be the same.
It is clear that largeint is not a modern parameter type, and I only see the possibility that, instead of Integer, LongInt, Int64 or else is needed since the number of parameters should be OK.
LongInt instead of Integer for offset does not work, Longint instead of LargeInt does not work for pos.
Has anyone an idea what might be the reason for the error? What are the required types of this function in Delphi 10.2.3?
I am a beginner to programming. I am trying to run a simulation of a combustion chamber using reactingFoam.
I have modified the counterflow2D tutorial.
For those who maybe don't know OpenFOAM, it is a programme built in C++ but it does not require C++ programming, just well-defining the variables in the files needed.
In one of my first tries I have made a very simple model but since I wanted to check it very well I set it to 60 seconds with a 1e-6 timestep.
My computer is not very powerful so it took me for a day aprox. (by this I mean I'd like to find a solution rather than repeating the simulation).
I executed the solver reactingFOAM using 4 processors in parallel using
mpirun -np 4 reactingFOAM -parallel > log
The log does not show any evidence of error.
The problem is that when I use reconstructPar it works perfectly but then I try to watch the results with paraFoam and this error is shown:
From function bool Foam::IOobject::readHeader(Foam::Istream&)
in file db/IOobject/IOobjectReadHeader.C at line 88
Reading "mypath/constant/reactions" at line 1
First token could not be read or is not the keyword 'FoamFile'
I have read that maybe some files are empty when they are not supposed to be so, but I have not found that problem.
My 'reactions' file have not been modified from the tutorial and has always worked.
edit:
Sorry for the vague question. I have modified it a bit.
A typical OpenFOAM dictionary file always contains a Foam::Istream named FoamFile. An example from a typical system/controlDict file can be seen below:
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object controlDict;
}
During the construction of the dictionary header, if this Istream is absent, OpenFOAM ceases its operation by raising an error message that you have experienced:
First token could not be read or is not the keyword 'FoamFile'
The benefit of the header is possibly to contribute OpenFOAM's abstraction mechanisms, which would be difficult otherwise.
As mentioned in the comments, adding the header entity almost always solves this problem.
I'm getting this on the console in a QML app:
QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
The app is not crashing so I can't use the debugger to get a backtrace for the exception. How do I see where the error originates from?
If you know the function the warning occurs in (in this case, QFont::setPointSizeF()), you can put a breakpoint there. Following the stack trace will lead you to the code that calls that function.
If the warning doesn't include the name of the function and you have the source code available, use git grep with part of the warning to get an idea of where it comes from. This approach can be a bit of trial and error, as the code may span more than one line, etc, and so you might have to try different parts of the string.
If the warning doesn't include the name of the function, you don't have the source code available and/or you don't like the previous approach, use the QT_MESSAGE_PATTERN environment variable:
QT_MESSAGE_PATTERN="%{function}: %{message}"
For the full list of variables at your disposal, see the qSetMessagePattern() docs:
%{appname} - QCoreApplication::applicationName()
%{category} - Logging category
%{file} - Path to source file
%{function} - Function
%{line} - Line in source file
%{message} - The actual message
%{pid} - QCoreApplication::applicationPid()
%{threadid} - The system-wide ID of current thread (if it can be obtained)
%{qthreadptr} - A pointer to the current QThread (result of QThread::currentThread())
%{type} - "debug", "warning", "critical" or "fatal"
%{time process} - time of the message, in seconds since the process started (the token "process" is literal)
%{time boot} - the time of the message, in seconds since the system boot if that can be determined (the token "boot" is literal). If the time since boot could not be obtained, the output is indeterminate (see QElapsedTimer::msecsSinceReference()).
%{time [format]} - system time when the message occurred, formatted by passing the format to QDateTime::toString(). If the format is not specified, the format of Qt::ISODate is used.
%{backtrace [depth=N] [separator="..."]} - A backtrace with the number of frames specified by the optional depth parameter (defaults to 5), and separated by the optional separator parameter (defaults to "|"). This expansion is available only on some platforms (currently only platfoms using glibc). Names are only known for exported functions. If you want to see the name of every function in your application, use QMAKE_LFLAGS += -rdynamic. When reading backtraces, take into account that frames might be missing due to inlining or tail call optimization.
On an unrelated note, the %{time [format]} placeholder is quite useful to quickly "profile" code by qDebug()ing before and after it.
I think you can use qInstallMessageHandler (Qt5) or qInstallMsgHandler (Qt4) to specify a callback which will intercept all qDebug() / qInfo() / etc. messages (example code is in the link). Then you can just add a breakpoint in this callback function and get a nice callstack.
Aside from the obvious, searching your code for calls to setPointSize[F], you can try the following depending on your environment (which you didn't disclose):
If you have the debugging symbols of the Qt libs installed and are using a decent debugger, you can set a conditional breakpoint on the first line in QFont::setPointSizeF() with the condition set to pointSize <= 0. Even if conditional breakpoints don't work you should still be able to set one and step through every call until you've found the culprit.
On Linux there's the tool ltrace which displays all calls of a binary into shared libs, and I suppose there's something similar in the M$ VS toolbox. You can grep the output for calls to setPointSize directly, but of course this won't work for calls within the lib itself (which I guess could be the case when it handles the QML internally).
Good day. The programs function is to take an equipment number (or none), display that number with a description (or all) in alv, and then run IE03 should the user double click on
Program worked fine in client 110, but in 150 a runtime error happens. This morning I tried to make a new program with a shorter name (only lead I had), activated it (window popped up asking me to activate the previous version as well). That didn't work and now the original doesn't work in either.
The program "SAPLSKBH" is terminating because program line is too long, being 78 chars wide which is too much for the internal table "\FUNCTION=K_KKB_FIELDCAT_MERGE\DATA=L_ABAP_SOURCE[]"
It sounds like you are using REUSE_ALV_GRID_DISPLAY for output, is that correct?
Check you source code; somewhere you have a line that is more than 78 characters. The function K_KKB_FIELDCAT_MERGE takes the source code of your program to produce a structure that corresponds to the table/structure you give it. (In the old days, there was a limit of 78 characters width for a line of ABAP code, and this is an old function module).
You can alternatively build a field catalog yourself in code, rather than use this function.