MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Determine whether ALTLIB allocated

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> TSO and ISPF
View previous topic :: View next topic  
Author Message
misi01
Advanced


Joined: 02 Dec 2002
Posts: 616
Topics: 171
Location: Stockholm, Sweden

PostPosted: Fri Apr 24, 2015 7:18 am    Post subject: Determine whether ALTLIB allocated Reply with quote

We have the following problem. Each general script we have here consists of TWO scripts (in reality). The first script is a simple skeleton that exists in library 1. This contains code along the lines of
Code:
rexx_lib = 'xxxxxx.TSO.yyyy.EXEC'   
rc = call_script('CMPLGEN', parms) 


and where call_script does the following (amongst a few other things)

Code:

parse arg script_name, temp               
                                         
source_lib = "'"rexx_lib"("script_name")'"
etc etc
address TSO "exec "source_lib" '"exec_arg"'"


In xxxxxx.TSO.yyyy.EXEC, CMPLGEN might contain something like at the start

Code:
    wsXLib="'xxxx.TSO.yyyy.EXEC',",                     
           "'zzzz.ISPF.PR2.REXX'"                         
    address TSO     "ALTLIB ACTIVATE APPLICATION(EXEC) ", 
                                   "DATASET("wsXLib")"     


and at the end of the script

Code:
Address TSO     "ALTLIB DEACTIVATE APPLICATION(EXEC)"


Now to my problem. Let's assume we have 2 scripts, each one based on the standard above (skeleton and "real" code).

Normally, if you run script A, it will do the ALTLIB activate/deactivate with no problem.
In the same way, B can perform the same steps.

The problem arises (I think) because A will also call B. At the same time, B can be run as a stand-alone script.

Theoretically, this means that A activates the ALTLIB at the start, it then calls B which also activates the same ALTLIB (and deactivates it when leaving). To my way of thinking, that would pull the rug out from under A's feet (especially if A then calls C that needs to do the same stuff with the same ALTLIBs).

My question. Is there a way for B to KNOW it's being called via A or being called as a primary command.
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12357
Topics: 75
Location: San Jose

PostPosted: Fri Apr 24, 2015 9:14 pm    Post subject: Reply with quote

misi01,

How about issuing ALTLIB display and finding out the ddnames from IKJADM3.

Code:

ADDRESS TSO "ALTLIB DISPLAY QUIET"                                     
ADDRESS ISPEXEC "VGET (IKJADM IKJADM1 IKJADM2 IKJADM3 IKJADM4) SHARED"
CHKLIB = ' '                                                           
PARSE VAR IKJADM3  "=SYS" CHKLIB                                       
IF DATATYPE(CHKLIB) = NUM THEN                                         
   SAY 'ALTLIB IS ACTIVE'                                             
 ELSE                                                                 
   SAY 'ALTLIB IS DEACTIVED'           
                               
ADDRESS TSO "ALTLIB RESET"                                             
ADDRESS TSO "ALTLIB DISPLAY QUIET"                                     
ADDRESS ISPEXEC "VGET (IKJADM IKJADM1 IKJADM2 IKJADM3 IKJADM4) SHARED"
CHKLIB = ' '                                                           
PARSE VAR IKJADM3  "=SYS" CHKLIB                                       
IF DATATYPE(CHKLIB) = NUM THEN                                         
   SAY 'ALTLIB IS STILL ACTIVE'                                       
 ELSE                                                                 
   SAY 'ALTLIB IS DEACTIVED'           

_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
misi01
Advanced


Joined: 02 Dec 2002
Posts: 616
Topics: 171
Location: Stockholm, Sweden

PostPosted: Sat Apr 25, 2015 1:23 am    Post subject: Reply with quote

I played around with that testing it, but I somehow assumed it would/might give me the NAMES of the allocated altlib libraries which it didn't.

According to the online help, I got the impression that the display command COULD return up to 99 variables but I couldn't seem to get more back than those you showed.

THEORETICALLY, the display option could tell you you have altlib libraries allocated, but these AREN'T the 2 i mentioned in my first append.

Hmmmm, am I going to have to with some buggy option whereby I vput/vget a variable indicating altlib allocation?
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12357
Topics: 75
Location: San Jose

PostPosted: Sat Apr 25, 2015 11:33 am    Post subject: Reply with quote

misi01 wrote:
THEORETICALLY, the display option could tell you you have altlib libraries allocated, but these AREN'T the 2 i mentioned in my first append.


misi01,

Did you notice the title of the topic which you wrote by yourself? "Determine whether ALTLIB allocated" and the answer was showing you a way to do it.

Secondly if you want know " if B being called via A or being called as a primary command." you could have looked up the "PARSE SOURCE" command which will give you what you are looking for. Anyway here is the sample.

Code:

PARSE SOURCE . CALLTYPE .                                     
SELECT                                                       
  WHEN CALLTYPE = "COMMAND"    THEN SAY 'CALLED AS COMMAND'   
  WHEN CALLTYPE = "FUNCTION"   THEN SAY 'CALLED AS FUNCTION' 
  WHEN CALLTYPE = "SUBROUTINE" THEN SAY 'CALLED AS SUBROUTINE'
  OTHERWISE SAY "NONE ABOVE ARE TRUE"                         
 END                                                         


misi01 wrote:
According to the online help, I got the impression that the display command COULD return up to 99 variables but I couldn't seem to get more back than those you showed.


TSO Manual wrote:
QUIET
indicates that you want messages saved and not displayed at the terminal. Messages can be saved in the ISPF shared pool when QUIET is used and ISPF is active. Variable IKJADM1 contains the first message, variable IKJADM2 contains the second message, and so on.


If you understood the output of ALTLIB DISPLAY Command then you would have noticed that it is showing you the DDname of the search order. And you are concatenating all your ALTLIB datasets to a single DD wsXLib.

So if you really want to test 99 variables you need to to have activate an ALTLIB with atleast 95 datasets.

Some thing like this

Code:

ADDRESS TSO "ALTLIB ACT APPLICATION(EXEC)",                           
            "DATASET("'MISI.ALTLIB1'")"                               
ADDRESS TSO "ALTLIB ACT APPLICATION(EXEC)",                           
            "DATASET("'MISI.ALTLIB2'")"                               
ADDRESS TSO "ALTLIB ACT APPLICATION(EXEC)",                           
            "DATASET("'MISI.ALTLIB3'")"                               
ADDRESS TSO "ALTLIB ACT APPLICATION(EXEC)",                           
            "DATASET("'MISI.ALTLIB4'")"                               
ADDRESS TSO "ALTLIB ACT APPLICATION(EXEC)",                           
            "DATASET("'MISI.ALTLIB5'")"             
                 
ADDRESS TSO "ALTLIB DISPLAY QUIET"                                   
ADDRESS ISPEXEC "VGET (IKJADM IKJADM1 IKJADM2 IKJADM3 IKJADM4",       
                      "IKJAD5 IKJADM6 IKJADM7 IKJADM8 IKJADM9) SHARED"
SAY 'IKJADM  = ' IKJADM                                               
SAY 'IKJADM1 = ' IKJADM1                                             
SAY 'IKJADM2 = ' IKJADM2                                             
SAY 'IKJADM3 = ' IKJADM3                                             
SAY 'IKJADM4 = ' IKJADM4                                             
SAY 'IKJADM5 = ' IKJADM5                                             
SAY 'IKJADM6 = ' IKJADM6                                             
SAY 'IKJADM7 = ' IKJADM7                                             
SAY 'IKJADM8 = ' IKJADM8                                             
SAY 'IKJADM9 = ' IKJADM9                                             


misi01 wrote:
Hmmmm, am I going to have to with some buggy option whereby I vput/vget a variable indicating altlib allocation?


I am not sure as to why you think it is a buggy option. At the beginning of your exec have ALTLIB RESET and then activate the ALTLIB and after the ALTLIB DISPLAY you know that you have the ALTLIB active.

Your condescending attitude isn't going to win any volunteers that are trying to help. Wish I could Stop responding to your queries.
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
misi01
Advanced


Joined: 02 Dec 2002
Posts: 616
Topics: 171
Location: Stockholm, Sweden

PostPosted: Mon May 18, 2015 7:02 am    Post subject: Reply with quote

Kolusu. Just read (as in the past tense) the last line of your append.
[GROVEL]
My apologies if my appends come across as condescending. That is NOT my intention.

Also, be aware of the fact that I DO appreciate the fact that you answer a number of my (and others') queries.
[/GROVEL]

Quote:
Secondly if you want know " if B being called via A or being called as a primary command." you could have looked up the "PARSE SOURCE" command which will give you what you are looking for. Anyway here is the sample.

Maybe I expressed myself badly. You have 2 options. Let's say that the actual script I'm talking about is called TRACECPY. This can be called in one of 2 ways:-
1) Via the SKELETON TRACECPY in library 1. All this does is run the code I mentioned originally:_
rexx_lib = 'xxxxxx.TSO.yyyy.EXEC'
rc = call_script('TRACECPY', parms)

2) Via a skeleton TRACEMOD (same principle as TRACECPY), but in this case TRACECPY is then called from TRACEMOD.

So basically, the real TRACECPY is going to be called from a depth of 2 (via skel TRACECPY) or 3 (via skel TRACEMOD, real TRACEMOD and then REAL TRACECPY)
_________________
Michael
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> TSO and ISPF All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group