Re: Loading a program
Look at CobAnal www.cbttape.org FILE321 how I done this. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Miklos Szigetvari Sent: Wednesday, September 28, 2005 6:46 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Loading a program Hi Try to load a program via LOAD macro to find some text constants in the load module (i.e. the compile time text for every object) For my surprise the load length from reg1 is not the same as module length for program objects. (With DESERV I can find out the module lengh) I don't know if I can use this method (LOAD and search) to find out this text constants. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Loading a program
Hi Try to load a program via LOAD macro to find some text constants in the load module (i.e. the compile time text for every object) For my surprise the load length from reg1 is not the same as module length for program objects. (With DESERV I can find out the module lengh) I don't know if I can use this method (LOAD and search) to find out this text constants. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Loading a program
In a recent note, Miklos Szigetvari said: Date: Wed, 28 Sep 2005 18:46:17 +0200 Try to load a program via LOAD macro to find some text constants in the load module (i.e. the compile time text for every object) For my surprise the load length from reg1 is not the same as module length for program objects. (With DESERV I can find out the module lengh) I don't know if I can use this method (LOAD and search) to find out this text constants. Is this because the address returned by LOAD is the address of the entry point, which may not be the origin of the load module, nor even the CSECT with lowest address; particularly given the manner in which SMP/E maintenance scrambles CSECTs? I believe nowadays scatter loading is back. Different CSECTS in a single module may be loaded discontiguously, some above and some below the 16Mi line, depending on attributes. What does LOAD report for module length in this case? Needed: a facility to read a load module in the fashion of a sequential file. But this needs to work for LPA-resident load modules, and even programs defined by the IDENTIFY macro. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Loading a program
Upon return from the LOAD macro execution, The three low-order bytes of
register 1 contain a length value for the module. When the module is a
program object, bound with FETCHOPT=NOPACK option, the length value
returned is the number of doublewords equivalent to the
fullpage-multiple area obtained with GETMAIN to hold the program object.
If the program object is bound with FETCHOPT=PACK, the length value
returned is the number of doublewords equivalent to the virtual storage
size indicated in the directory entry.
During link-edit, The FETCHOPT option allows you to specify how a
program object should be paged-mapped (loaded) into virtual storage for
execution. The syntax of the FETCHOPT option is:
FETCHOPT=({PACK|NOPACK}{,PRIME|NOPRIME}). The parameters for FETCHOPT
are:
PACK|NOPACK
allows you to specify whether the program object is page-mapped into
virtual storage on a page or double word boundary. Specifying PACK
causes the program object to be page-mapped into page-aligned
virtual
storage and then moved to storage with double word alignment.
NOPACK
causes the program to be page-mapped into page-aligned virtual
storage
without a secondary move. The PACK option may be specified when
virtual storage is limited and performance is not an issue. It may
be
appropriate when many small programs are loaded.
PRIME|NOPRIME
allows you to specify if the program object should be completely
read
into virtual storage before execution. When PRIME is coded, all of
the program pages are read before program execution begins. When
NOPRIME is coded, program pages are not read until they are needed
during execution.
You cannot specify the combination (PACK,NOPRIME). The default is
(NOPACK,NOPRIME).
This option is only valid when processing program objects.
In PDSE load libraries, program objects are stored in pages that are 4K
long. Because the NOPACK option is in effect, the length that is
returned in register 1 is the length of all the 4K pages needed to hold
the table, not the actual length of the table.
Make sure that link-edit parameter FETCHOPT=(PACK,PRIME) is specified.
This will allow the LOAD macro to function properly.
Don Imbriale
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Miklos Szigetvari
Sent: Wednesday, September 28, 2005 12:46 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Loading a program
Hi
Try to load a program via LOAD macro to find some text constants in the
load module (i.e. the compile time text for every object)
For my surprise the load length from reg1 is not the same as module
length for program objects.
(With DESERV I can find out the module lengh)
I don't know if I can use this method (LOAD and search) to find out
this
text constants.
***
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Loading a program
I'm sure others know much more about this than I but I suspect that the length returned by DESERV is the total number of bytes that the program occupies on disk including entry point name tables and so forth, whereas the length returned by LOAD is only the bytes of memory actually occupied by the program as loaded into storage. I suspect the LOAD size could even be greater than the DESERV size because uninitialized, defined storage (a big DS) takes up no room on disk (at least in a traditional PDS load module) but of course occupies memory when loaded. Using LOAD to bring a non-executable table - or an executable program that is treated like data by the LOADing program - is an established MVS (etc.) technique. You should be able to accomplish what you are trying to do. I just saw some fast access to program object data API documented in the link editor (sorry, DFSMS program management) manual. I'm too pressed for time to look it up right now. Will it help? BTW, VSE uses or used a core image (quaint term) library for programs. What was on disk was exactly byte-for-byte what got loaded into memory. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Miklos Szigetvari Sent: Wednesday, September 28, 2005 9:46 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Loading a program Hi Try to load a program via LOAD macro to find some text constants in the load module (i.e. the compile time text for every object) For my surprise the load length from reg1 is not the same as module length for program objects. (With DESERV I can find out the module lengh) I don't know if I can use this method (LOAD and search) to find out this text constants. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
