How can I create process permanent file (like DCL does) from an application executable (I happen to be coding in Fortran, but I suspect that's not important to the answer).
I would like to create/open the file in one EXE, then be able to access it from DCL or another EXE in the same procedure.
I have a general understanding of RMS internals, so answers with FAB or RAB structures will probably be understood. As a guess, SUPERVISOR mode is involved.
Asked and answered. :-).
Note 870.1 How do you open process permanent files and channels 1 of 5
QUARK::LIONEL "Ad Astra" 5 lines 1-JAN-1989 00:15
< PPFs only through CLIs >
--------------------------------------------------------------------------------
For question 1, the ONLY way to create a PPF is through a CLI such
as DCL. The usual method is the DCL OPEN command. From languages,
you can only open existing PPFs.
Nothing has changed since.
PPF are very restrictive ( minimal buffers, no global buffers, ...) and should be created BEFORE with DCL before a program tries to use it.
What problem are you really trying to solve?
Hein
Related
Recently, I've been trying to write to a .PAK file while it is being used by another process in ring 0. This has been a problem for quite a while and i haven't had much success. I am able to use any programming language necessary to accomplish this, but C#/VB.net is preferred. I originally wanted to use a find and replace system when editing, but I will just choose and offset to write to and such instead.
No, I can't just terminate the process then edit; the process must be running. Yes, I obviously know the process with the file handle attached.
No, I can't just run as admin because the process is established in ring 0/the kernel.
I've tried multiple methods including setting the process speed temporarily to 0 to edit then revert, and changing the FileShare and other parameters, none with any success.
One approach which I have been told a lot and which I have no experience in is creating a "Kernel Driver". I'm not sure how to go about this and I cant find much info online so if you think that's is the best method please inform me on how to get started. Any help is appreciated!
Always create a temporary file (a copy of your original file). If you need to process a file within your codes, create a temp file, use the temp file and process that file. So if you need another process, there will be no problem.
I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.
I couldn't find a similar question here.
I have a PRO*C program named pro_c.pc. How can I call and execute this in a piece of PL/SQL code?! Could someone give me a simple example?!
You can link external libraries (Windows DLL or UNIX ".so" files) to Oracle and then make them callable via PLSQL. This has been around at least since Oracle 8i.
This though requires DBA privs on the server to set this up, and is probably not a recommended approach these days .... but useful for crunching huge data.
See here for more details.
Calling a actual program directly, as opposed to a library function from PLSQL would be done indirectly via DBMS_SCHEDULER as #Justin suggested as the easiest way, creating a program with the PROGRAM_TYPE as EXECUTABLE. See here for more info.
A couple of things to note when doing this, the program will run as the (assuming UNIX) "oracle" user - bringing with it some security considerations, e.g. if the program creates a file it will be created as owned by oracle, and so might not be accessible to an "application" user. The program will run on the Oracle database server.
I'm trying to write a social networking site in Malbolge with CGI. I need to store data in a database. How can I read and write files in Malbolge?
Is this the same Malbolge which is deliberately so difficult to write programs in that it took two years for the first program to be discovered (by a brute force search of the program space)? And which it then took cryptanalysis to find out how to write programs on purpose?
If so, the answer is that you can't --- it has no I/O capability other than stdin and stdout. Although I suppose you could connect it via a pty to a command line of some description.
I know there are other applications also, but considering yum/apt-get/aptitude/pacman are you core package managers for linux distributions.
Today I saw on my fedora 13 box:
(7/7): yum-3.2.28-4.fc13_3.2.28-5.fc13.noarch.drpm | 42 kB 00:00
And I started to wonder how does such a package update itself? What design is needed to ensure a program can update itself?
Perhaps this question is too general but I felt SO was more appropriate than programmers.SE for such a question being that it is more technical in nature. If there is a more appropriate place for this question feel free to let me know and I can close or a moderator can move.
Thanks.
I've no idea how those particular systems work, but...
Modern unix systems will generally tolerate overwriting a running executable without a hiccup, so in theory you could just do it.
You could do it in a chroot jail and then move or something similar to reduce the time during which the system is vulnerable. Add a journalling filesystem and this is a little safer still.
It occurs to me that the package-manager needs to hold the package access database in memory as well to insure against a race condition there. Again, the chroot jail and copy option is available as a lower risk alternative.
And I started to wonder how does such a package update itself? What
design is needed to ensure a program can update itself?
It's like a lot of things, you don't need to "design" specifically to solve this problem ... but you do need to be aware of certain "gotchas".
For instance Unix helps by reference counting inodes so "you" can delete a file you are still using, and it's fine. However this implies a few things you have to do, for instance if you have plugins then you need to load them all before you run start a transaction ... even if the plugin would only run at the end of the transaction (because you might have a different version at the end).
There are also some things that you need to do to make sure that anything you are updating works, like: Put new files down before removing old files. And don't truncate old files, just unlink. But those also help you :).
Using external problems, which you communicate with, can be tricky (because you can't exec a new copy of the old version after it's been updated). But this isn't often done, and when it is it's for things like downloading ... which can somewhat easily be made to happen before any updates.
There are also things which aren't a concern in the cmd line clients like yum/apt, for instance if you have a program which is going to run 2+ "updates" then you can have problems if the first update was to the package manager. downgrades make this even more fun :).
Also daemon like processes should basically never "load" the package manager, but as with other gotchas ... you tend to want to follow this anyway, for other reasons.