IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Mainframe- how much virtuval memory used by Job


IBM Mainframe Forums -> All Other Mainframe Topics
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
SV44765

New User


Joined: 02 Jul 2009
Posts: 3
Location: Pune

PostPosted: Tue Jul 28, 2009 5:01 pm
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Tue Jul 28, 2009 5:07 pm
Reply with quote

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
View user's profile Send private message
SV44765

New User


Joined: 02 Jul 2009
Posts: 3
Location: Pune

PostPosted: Wed Jul 29, 2009 4:48 pm
Reply with 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.

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Wed Jul 29, 2009 5:09 pm
Reply with quote

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
View user's profile Send private message
SV44765

New User


Joined: 02 Jul 2009
Posts: 3
Location: Pune

PostPosted: Wed Jul 29, 2009 5:19 pm
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Wed Jul 29, 2009 5:27 pm
Reply with quote

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
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Wed Jul 29, 2009 5:44 pm
Reply with quote

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 icon_biggrin.gif

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
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Wed Jul 29, 2009 5:57 pm
Reply with quote

It seems your key-board understands your thoughts and types before you fingers instruct them by it's own.. icon_biggrin.gif

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Wed Jul 29, 2009 6:22 pm
Reply with quote

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
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1248
Location: Richfield, MN, USA

PostPosted: Thu Jul 30, 2009 6:28 am
Reply with quote

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
View user's profile Send private message
Bill Dennis

Active Member


Joined: 17 Aug 2007
Posts: 562
Location: Iowa, USA

PostPosted: Thu Jul 30, 2009 8:24 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> All Other Mainframe Topics

 


Similar Topics
Topic Forum Replies
No new posts Email attachment from mainframe is empty PC Guides & IT News 9
No new posts Mainframe Dataset Binary or ASCII Mainframe Interview Questions 4
No new posts Need help In Mainframe Automation AF/... CLIST & REXX 14
No new posts SPOOL to Mainframe dataset in batch mode JCL & VSAM 7
No new posts FTP VB File from Mainframe retaining ... JCL & VSAM 8
Search our Forums:

Back to Top