Joined: 02 Dec 2002 Posts: 616 Topics: 171 Location: Stockholm, Sweden
Posted: Fri Apr 24, 2015 7:18 am Post subject: Determine whether ALTLIB allocated
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
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
Joined: 26 Nov 2002 Posts: 12358 Topics: 75 Location: San Jose
Posted: Fri Apr 24, 2015 9:14 pm Post subject:
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
Joined: 02 Dec 2002 Posts: 616 Topics: 171 Location: Stockholm, Sweden
Posted: Sat Apr 25, 2015 1:23 am Post subject:
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
Joined: 26 Nov 2002 Posts: 12358 Topics: 75 Location: San Jose
Posted: Sat Apr 25, 2015 11:33 am Post subject:
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.
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
Joined: 02 Dec 2002 Posts: 616 Topics: 171 Location: Stockholm, Sweden
Posted: Mon May 18, 2015 7:02 am Post subject:
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
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