|
View previous topic :: View next topic
|
| Author |
Message |
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Hi Experts,
I got following error due to i didn't refresh LLA after copying the new module . I know the reason is because of the pointer save in storage is the old so it cant find the new module. But my questions is that how about if nothing changed in term of location and size for new modules . It stay in same location where the old module resides. Even I don’t do the LLA refresh , it should load the new module since LLA only save the time to fetch the module but actually the load module is still in physical DSAD not in virtual memory and It still need actual physical I/O to get the load module, right ?
| Code: |
S ABENDAID
$HASP100 ABENDAID ON STCINRDR
IEF695I START ABENDAID WITH JOBNAME ABENDAID IS ASSIGNED TO USER
ABENDAID
$HASP373 ABENDAID STARTED
ACF9CCCD USERID ABENDAID IS ASSIGNED TO THIS JOB - ABENDAID
IEF403I ABENDAID - STARTED - TIME=07.26.42
IEW4009I FETCH FAILED FOR MODULE CWINSTAL FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE CWINSTAL FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE CWINSTAL, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*
CSV028I ABEND106-0F JOBNAME=ABENDAID STEPNAME=ABENDAID |
|
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| It does NOT stay in the same location. When you update a PDS member, the space currently in use is left unused and the member moved to the end of the data set. This is why compresses are needed. Since LLA uses the directory location of the member, updating the member means a refresh is needed. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
Mr. Sample is correct. When you “copy” a module, even if it replaces an existing module, it is always added to the end of the data set. For example, I ran this JCL.
| Code: |
//A EXEC PGM=IEFBR14
//LM DD DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
// DSN=&SYSUID..COPYLM.LOAD
//B EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//I DD DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//O DD DISP=(,CATLG),UNIT=SYSDA,SPACE=(CYL,(1,1,1)),
// DSN=*.A.LM
//SYSIN DD *
C I=I,O=O
S M=(TSOLPDIR,LISTPDS)
//C EXEC PGM=IKJEFT01,
// PARM='LISTPDS COPYLM.LOAD DUMP'
//STEPLIB DD DISP=(SHR,PASS),DSN=*.A.LM
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//D EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//I DD DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//O DD DISP=OLD,
// DSN=*.A.LM
//SYSIN DD *
C I=((I,R)),O=O
S M=(TSOLPDIR,LISTPDS)
//E EXEC PGM=IKJEFT01,
// PARM='LISTPDS COPYLM.LOAD DUMP'
//STEPLIB DD DISP=(SHR,PASS),DSN=*.A.LM
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//F EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//I DD DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//O DD DISP=OLD,
// DSN=*.A.LM
//SYSIN DD *
C I=((I,R)),O=O
S M=(TSOLPDIR,LISTPDS)
//G EXEC PGM=IKJEFT01,
// PARM='LISTPDS COPYLM.LOAD DUMP'
//STEPLIB DD DISP=(SHR,PASS),DSN=*.A.LM
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//H EXEC PGM=PDSGAS
//STEPLIB DD DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=OLD,DSN=*.A.LM |
LISTPDS is a TSO command processor and is an alias of TSOLPDIR. Its output when DUMP is specified mimics the output from the IEHLIST LISTPDS command. The output for the first TSO in batch step is -
| Code: |
-MEMBER- --TTRC-- --USER DATA (TTRC AND USER DATA ARE HEX)
LISTPDS 000003B1 0000080000 000000C2E3 0012D812D8 000000881A 01000000E3
E2D6D3D7C4 C9D90100
TSOLPDIR 0000032C 0000080000 000000C2E3 0012D812D8 0000008812 01010000
1 ALLOCATED DIRECTORY BLOCKS, 1 USED DIRECTORY BLOCKS |
The first 6 hexadecimal digits after the member name are the location of the first data record for the member – 000003. The output for the second TSO in batch step is -
| Code: |
-MEMBER- --TTRC-- --USER DATA (TTRC AND USER DATA ARE HEX)
LISTPDS 00000BB1 0000100000 000000C2E3 0012D812D8 000000881A 01000000E3
E2D6D3D7C4 C9D90100
TSOLPDIR 00000B2C 0000100000 000000C2E3 0012D812D8 0000008812 01010000
1 ALLOCATED DIRECTORY BLOCKS, 1 USED DIRECTORY BLOCKS |
And the third -
| Code: |
-MEMBER- --TTRC-- --USER DATA (TTRC AND USER DATA ARE HEX)
LISTPDS 000013B1 0000180000 000000C2E3 0012D812D8 000000881A 01000000E3
E2D6D3D7C4 C9D90100
TSOLPDIR 0000132C 0000180000 000000C2E3 0012D812D8 0000008812 01010000
1 ALLOCATED DIRECTORY BLOCKS, 1 USED DIRECTORY BLOCKS |
The last step runs a program that locates the space occupied by deleted members; its output is
| Code: |
DIRECTRY 000001 000001 000002 0125000001 0125000002
*****GAS 000003 00000A 0125000003 012500000A
*****GAS 00000B 000012 012500000B 0125000012
TSOLPDIR 000013 000013 00001A 0125000013 012500001A |
The program regards the PDS directory as a member. Much of this output is for debuggging, not really necessary since the last update was in 2007
TSOLPDIR 000013 000013 00001A 0125000013 012500001A
The first set of hexadecimal digits after the member name is the first block address; the second set is the address of the EOF “record” at the end of the member. Since “gas” “members” do not have a directory entry, the first set of hexadecimal digits are not printed. |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Hi Mr samply and steve , really appreicate your answer. Back to my example , What i did is :
1. Copied over the new load modules into LLA /LNKLST for Abend-Aid
3. Not refresh LLA
2. Issued the command /S Abendaid to start the product
Then i got the fetch I/O error . According to your answer , when updated the same module , the loaction for new load module should be at end of PDS so it should still can exceute the old module since the pointer is not changed. I don't undersand , whey i get this error ? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Jack: I do not think you bothered to actually read my long post. You do not "copy over" a load module. That is not possible. You added the new modules at the end of the library, deleted the old names in the directory, and added the same names to the directory, as was done in my example. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| You got the error because the LINKLIST contains directory pointers to the modules. When you updated a module, you moved the member to the end of the PDS, which changes the directory pointer. Since you did not do the LLA refresh, the LINKLIST continued to point to the where the module USED to be. Hence the fetch failed as there no longer is any data at the location on the disk -- the member got moved. |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Thank you . Normally when i do the maint for my products , i just copy the updated load module from my SMPE libs to my production lib (LNKLST) then just staging there and wait for IPL to do the refresh. Before IPL i have no issue for these production . How to explan this ?
Like we disscussed before , i should also get fetch error because the module has been moved to end of PDS.
Thanks |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Found the following from IBM red book ABC system progrming . How LLA still can find old module since pointer has changed.
"Whenever you update a load module in a library that LLA manages, make sure you follow the update by issuing the appropriate form of the F LLA command. Otherwise, LLA continues to use an older version of a load
module." |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| jackzhang75 wrote: |
| Found the following from IBM red book ABC system progrming . How LLA still can find old module since pointer has changed. |
Remember that the data (in this case the load module) does not disappear, only the directory entry does. |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
| So now i just confused why sometime it get fectch error sometimes it still can load old module. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Fetch is done when no previous version has been read. So in your original post the module needed to loaded from disk; if it does not have to be loaded from disk no fetch is done and the LLA discrepancy won't appear. But since you may not know if a previous fetch has been done on the load module, you should always do F LLA,REFRESH after updating the link list. |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Thank you Robert. now it make more sense. So weather or not you get I/O error is depends on when the Fetch is done , right ?
So for example , i have a job to excute the program CWPAMAIN .
As soon as i submit this job , it will go to fectch the load module
CWPAMAIN or it used previous done , how to determine this ?
//ASM EXEC PGM=CWPAMAIN, <--- CHECK
// REGION=4096K, |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| it will go to fectch the load module CWPAMAIN or it used previous done , how to determine this ? |
One of the points we're trying to get across to you is that YOU DON'T KNOW AND YOU CANNOT FIND OUT (at least, not in any easy way -- it may or may not be available by going through control blocks but that would require a LOT of research). Just accept that you do an F LLA,REFRESH after an update to the LINKLIST and go on. |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
| Thank you Robert. How about if lnklst is PDSE not PDS? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
- Unless the program referenced in // EXEC PGM=xxx is in the LPA, it will not be available. But it takes an IPL to refresh LPA. Many products load modules into CSA to provide a pseudo LPA when they start. I do not know if ABENDAID is one of them. If CWPAMAIN is the ABENDAID initializer, it's unlikely to be in the pseudo LPA.
- LLA refresh updates the directory, but it the library added an extent to store the module, the new extent will not be available until the system is IPLed. This WILL result in an I/O error.
I cannot answer your query about a PDSE from my own knowledge. I speculate that since PDSE reuses space, strange things can happen. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| The issue is with how the directory is updated and the LINKLIST not pointing to the current member after an update, so using PDSE instead of PDS in the LINKLIST doesn't really change anything -- a PDSE still uses directory entries, and does not put replaced members back where they came from -- find the Using Data Sets manual and look up PDSE gas for more information. A PDSE in the LINKLIST is helpful as it only takes one extent out of the 255 available to the LINKLIST, but you can still get fetch errors and S106 abends with a PDSE. |
|
| Back to top |
|
|
jackzhang75
Active User
Joined: 09 Jun 2014
Posts: 125
Location: US
|
|
|
|
Thank you Robert. very nice answer.
Stave, can you tell me more about pseudo LPA , it was very intereting . Product will load the modle into CSA and keep in there until IPL ? |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| jackzhang75 wrote: |
| ... Steve, can you tell me more about pseudo LPA , it was very intereting . Product will load the modle into CSA and keep in there until IPL ? |
I don't know all that much. Yes, the module storage persists - usually - until the next IPL. Module information is kept in the same control structures that are used for MLPA. The module search is slower because the control structure is less conclusive for a fast lookup.
I said the module storage persists to the next IPL because it may be used by a program even if the lookup information has changed, so it's dangerous to delete the storage. |
|
| Back to top |
|
|
|
|
