|
View previous topic :: View next topic
|
| Author |
Message |
SV44765
New User
Joined: 02 Jul 2009
Posts: 3
Location: Pune
|
|
|
|
I have submitted one job in Mainframe (MVS/Z0S). But I want to know how much virtuval memory is used by job while executing.
Please let me know if anyway to find this.
Thanks & Regards,
SV44765 |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
If your site has a monitoring tool such as Mainview or Omegamon, use them to determine this. If your site does not have such tools, you may be able to tell from SDSF, IOF, (E)JES or whatever spool product you're running. If neither of these options is available, you may not be able to tell while the job is running how much memory it is using.
The more important question is, why do you want to know how much virtual memory the job is using? You cannot change the job once submitted so if you haven't given it enough memory you'll get a memory-related abend. |
|
| Back to top |
|
|
SV44765
New User
Joined: 02 Jul 2009
Posts: 3
Location: Pune
|
|
|
|
In my program Array size 3000, but I have increased this size to 10000 with "DEPENDING ON x" clause. I thought memory for array will dynamically allocated at run time based on x.
Please let me know if it is correct or not and which memory is good for job running quickly either dynamic or static.
Any way to find how much virtual memory used by the job aftert completing the job.
Thanks & Regards,
SV44765 |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Using the SMF type 30 records will allow you to find the resources (including memory) used by a job -- but only after the SMF data is written.
| Quote: |
| In my program Array size 3000, but I have increased this size to 10000 with "DEPENDING ON x" clause. I thought memory for array will dynamically allocated at run time based on x. |
Actually, no dynamic memory allocation occurs in COBOL (which I assume from the DEPENDING ON). Your COBOL proigram, when compiled, reserves the maximum amount of space for the array -- if the number of occurrences is less than the maximum, the extra space is still part of the load module even though you don't have any data in it. So the amount of memory used by your program will not vary depending on how many occurrences of the table you have. |
|
| Back to top |
|
|
SV44765
New User
Joined: 02 Jul 2009
Posts: 3
Location: Pune
|
|
|
|
Hi,
Thank you very much Robert...
That means memory allocated for totally which size is specified in the array.
I am not able to understand SMF type 30 records how can use this?
Thanks & Regards,
SV44765 |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Your best bet on using the SMF type 30 records would be to contact your site support group for assistance. IBM mainframes write System Management Facilities (SMF) records to record system activity -- for performance monitoring, capacity planning, and / or charge back purposes. There are more than 100 types of records and some of the records have as many as 20 subtypes. The complexity of SMF data is legendary -- many of the records use individual bits of a byte to denote flag values. SMF data is not typically used by applications programmers but interpreted by systems programmers; many sites do not let applications programmers even look at the SMF data. There are packages available to manage SMF data (MICS and MXG are two), which can help with analysis and reporting.
If you do a search on this forum, there have been a number of mentions of SMF data. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Quote: |
| I am not able to understand SMF type 30 records how can use this? |
SMF, is a standard feature of MVS that collects and records a variety of system and job-related information.
If you have read access to the dumped SMF data and can use SAS to get the statistics you need - with a lot of trial and a lot more error 
If you have MXG or MICS available - talk to the sysprogs / performance & capacity / storage management teams to see if they already produce the reports that might interest you, and see if they can give you the code to find out what you need. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
It seems your key-board understands your thoughts and types before you fingers instruct them by it's own..
Well, I've other question here to ask about the bold text in below quote,
| Quote: |
| Actually, no dynamic memory allocation occurs in COBOL (which I assume from the DEPENDING ON). Your COBOL program, when compiled, reserves the maximum amount of space for the array -- if the number of occurrences is less than the maximum, the extra space is still part of the load module even though you don't have any data in it. So the amount of memory used by your program will not vary depending on how many occurrences of the table you have |
DEPENDING ON clause is of no use from memory saving per se then? A weired question now, why do they provide this option is COBOL coding then? And if so, coding a static table or dynamic in some COBOL code will not make any difference, really? Please assist. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Memory usage will vary if an OCCURS DEPENDING ON is part of an FD 01 -- the buffer size used will depend upon the number of occurrences. For WORKING-STORAGE the size is fixed. This code:
| Code: |
WORKING-STORAGE SECTION.
01 WS-VARS.
10 WS-TABLE-SIZE PIC 9(05) VALUE 100.
10 WS-TABLE OCCURS 1 TO 100000
DEPENDING ON WS-TABLE-SIZE
INDEXED BY WS-TABLE-NDX.
15 FILLER PIC X(10).
/
PROCEDURE DIVISION.
S1000-MAIN SECTION.
DISPLAY 'WS-TABLE-SIZE ' WS-TABLE-SIZE . |
produces this compile output:
| Code: |
0Source Hierarchy and Base Hex-Displacement Asmblr Data Data Def
LineID Data Name Locator Blk Structure Definition Data Type Attributes
2 PROGRAM-ID MF0091------------------------------------------------------------------------------------------------------*
13 1 WS-VARS . . . . . . . . . . . . . . . . . . . BLW=00000 000 DS 0CL1000005 Grp-VarLen OG
14 2 WS-TABLE-SIZE . . . . . . . . . . . . . . . BLW=00000 000 0 000 000 DS 5C Disp-Num D
15 2 WS-TABLE. . . . . . . . . . . . . . . . . . BLW=00000 005 0 000 005 DS 0CL10 Group O
17 WS-TABLE-NDX. . . . . . . . . . . . . . . . IDX=00001 000 Index-Name
18 3 FILLER. . . . . . . . . . . . . . . . . . BLW=00000 005 0 000 005 DS 10C Display |
Notice that the pseudo-assembler generated for WS-VARS is 1,000,005 bytes -- 5 for WS-TABLE-SIZE, 1 million for the table even though only 100 occurrences (1000 bytes) have been defined by the WS-TABLE-SIZE variable.
Once I've got some SMF data to run through, I'll see how the actual memory usage is -- my job statistics don't provide enough detail. |
|
| Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
| Anuj Dhawan wrote: |
| A weired question now, why do they provide this option is COBOL coding then? |
Because the ODO clause allows you to limit the range of a SEARCH or SEARCH ALL at run time. Most of the tables I've dealt with are built at execute time and the final size of them is not known until the table has been built. |
|
| Back to top |
|
|
Bill Dennis
Active Member
Joined: 17 Aug 2007
Posts: 562
Location: Iowa, USA
|
|
|
|
| In the job output, look for the IEF374I msg for the step. The amounts after VIRT and EXT are the virtual storage allocated for the step. This includes your program and other called pgms, etc. |
|
| Back to top |
|
|
|
|
