scobol
Sach
Can anyone tell me how can I find out source from object of screen
cobol. The way we find source for any object using bind list command,
same way can we find source of screen cobol?
I know we use SCUP to manage screen cobol object but how to find it's
source.
Thanks in advance.
Keith Dick
My first thought was that the SCUP INFO command would display that information, but the manual seems to show that it isn't included in the INFO output.
It has been ages since I've debugged a SCOBOL program, so my memory of the interactions are very dim. I would be very surprised if SCOBOL stores the whole source program into the POBJSYM file, so it must have the source file name in there somewhere, but I would not suggest trying to dig it out of there yourself, except in dire emergency.
One trick that isn't very convenient, but would be suitable for occasional use might be to set up a minimal SCOBOL main screen and include a call to the SCOBOL program whose source file you want to know. Start that in a test Pathway system set up for debugging, put the terminal into INSPECT while it is sitting an an ACCEPT in the main screen, put a BREAK on the PROGRAM-ID of the program whose source file you want to know, then respond to the main screen and let the code execute the call to the PROGRAM-ID in question. It will go into INSPECT at the start of that program. If you use the SOURCE command at that point, it will either show the source or tell you it cannot open the source file and give you the name of the file. In the latter case, you have the filename. If it displays the source, I cannot remember whether it also shows the source file name. If so, you have the name. If not, I think an INFO LOCATION command, or a LIST SOURCE OPEN command will reveal the name.
Once you get the name of the file, you can abort the TERM, so you do not have to worry about setting up everything needed to run the SCOBOL program whose source file name you are trying to find -- just enough to get your test main SCOBOL program to be able to call it.
Of course, if you already have a test Pathway system set up for debugging the application that uses the SCOBOL program whose source file you are trying to find, you just have to alter its configuration to reference the POBJxxx files containing the version of the SCOBOL object whose source you are trying to find (or to reference a copy of those files), and debug the application, putting a BREAK on the PROGRAM-ID of the SCOBOL program in question and proceed as I described above.
I don't know why SCUP's INFO command doesn't show the object file name. I guess they just didn't think it was important at the time the code was developed.
Doug Miller
First off, if it wasn't compiled with ?SYMBOLS, you can't do it at all. The
information simply isn't there.
If it *was* compiled with ?SYMBOLS, you can get at the information, but it
isn't completely straightforward. It's in the symbol table...and assuming that
the formats haven't changed much since I last had to deal with this, here's
how you find it:
The POBJDIR record for a given Scobol program unit gives the offset of the
program unit's symbol table within the POBJSYM file, and its length; look in
words 20:21 for the offset, and 22:23 for the length. The first 13 words in
the symbol table are a header; words 10:11 of the header give the offset,
within the symbol table, of an array containing the source file names and
their modification timestamps at the time of compilation. This array includes
the Scobol source file and any COPYLIBs that were used in compilation.
For one-time use, do it with FUP: (caution -- done completely from memory, has
not been tested)
-- get the directory entry for this program unit
COPY POJBDIR,, FIRST KEY ("programunitname"),H,COUNT 1, SHARE
[locate the symbol table offset in the output -- if it's zeros, there's no
symbol table for this program unit]
-- dump the symbol table header
COPY POBJSYM,,FIRST KEY ([symbol table offset]), RECIN 26,H, COUNT 1, SHARE
[locate the source-file array offset in the output]
-- dump the source-file array
COPY POBJSYM,,FIRST KEY ([symbol table offset + source-file array
offset]),RECIN 47,H,COUNT 4, SHARE
Increase the count in the last COPY command as needed in order to dump the
entire array, if there are more than four entries in the array. There may be
multiple identical entries corresponding to multiple COPYs from the same
library.
If you need to do this repeatedly, it shouldn't be too hard to write a TACL
macro that will issue the appropriate FUP commands, and parse the output --
much easier than writing it in TAL or C.
Doug Miller
>My first thought was that the SCUP INFO command would display that information,
> but the manual seems to show that it isn't included in the INFO output.
>
>It has been ages since I've debugged a SCOBOL program, so my memory of the
> interactions are very dim. I would be very surprised if SCOBOL stores the
> whole source program into the POBJSYM file, so it must have the source file
> name in there somewhere, but I would not suggest trying to dig it out of there
> yourself, except in dire emergency.
Oh, it's not *that* hard to get at. :-)
>
[snip description of using INSPECT to find source file names]
This won't do any good for anything that's already been compiled, but is sure
to be useful for the future: run ALL your Scobol compiles using a TACL macro
as a front end which, for every successful compile, inserts a row in a SQL
table (or Enscribe file) containing the program unit name, compilation
timestamp, source file name, and source file modification timestamp. Among
other things, this will enable you to find out the source file name for *any*
Scobol object module that was compiled through that macro, regardless of
whether it was compiled with ?SYMBOLS or not.
Sach
Thanks a lot you both for your help. It's really nice to learn new
things from you.
Brandon Jenkins
files?
Or can someone post the layouts?
Keith Dick
I am nearly certain that you will not find a manual containing the file layout, since that is the sort of information that wasn't intended for customer use (to allow it to be changed, if necessary, for enhancements). It is possible that it was published somewhere and I just don't know about it. Possibly in a Support Note.
Doug Miller gave a little bit of information about the file format in another post in this thread, but you probably have seen that. Maybe he knows where to find some more information about the file layout. I have never tried looking into the contents of those files.
Doug Miller
Everything I know about the file layouts I determined myself by laboriously
analyzing dumps of the files.