IBM Mainframe Forum

I checked the IEC* msg book (iea2m740)

The 04C indicates a problem in the length of a buffer which has to be equal or greater than the BLKSIZE in DCB.

Does it means i have to release some kind of ressource after each close/before each open or do I have
to control the length of DBCBUFL ?

To steve-myers I'm eager to hear your explanation about CLOSE so I try to find out what is the real problem.

I also cheched this link
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d551/2.2.9?ACTION=MATCHES&REQUEST=CLOSE&TYPE=FUZZY&SHELF=DGT2BK81&DT=20090122165044&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

I've added a FREESPOOL after each CLOSE it seems to prevent the S013-04C

Very good. You figured out that CLOSE does not free a below the line buffer pool, and you have changed your program to free the buffer pool manually by using the FREEPOOL macro after you CLOSE your DCB. I promised to tell why MVS works that way.

Back in the dark ages of OS/360 storage was rare and very expensive. A concept the architects of OS/360 came up with to conserve storage in OS/360 was to share a buffer pool between several DCBs, either concurrently or serially, which is sort of what is unintentionally happening here. There were several reason for this idea.

• Storage use.
• Storage fragmentation. GETMAIN in OS/360 (and z/OS, too) uses a first fit strategy, which is not always the best way to allocate storage. This is a particular problem when storage is scarce and programs are repeatedly using GETMAIN and FREEMAIN. FREEMAIN always connects a block of newly freed storage to a contiguous block of previously freed storage, but this has a performance penalty. See the next bullet.
• Performance. GETMAIN/FREEMAIN in OS/360 (and z/OS, too) was very slow, so the less time spent running this service the better off your program is.

I never really figured out how to make buffer pool sharing work, so I never tried to use this idea, but it's been there since I started writing programs for OS/360 in 1968.

Now, fairly obviously, if a buffer pool is being shared by several DCBs that are using the buffer pool concurrently, or you really want to share the buffer pool serially, you can't automatically free it in CLOSE.

A gotcha about FREEPOOL that was not closed until the 1990s was it would fail, pretty spectacularly, if there was no buffer pool when you tried to do a FREEPOOL. To this day I still test if there is a buffer pool to free before I do a FREEPOOL macro.

There is one other way to make your program work, at least for a time, without freeing the buffer pool after you CLOSE the DCB. Let's see if you can figure it out yourself.

There are other problems in the program, which I suspected, but I only just read the program in detail.

What happens if the dataset is not on DASD? You can only do an OBTAIN for disk datasets.

Your test for DSORG=PS will fail for DSORG=PSU, but you do want to be able to read these datasets.

All the files i need to check are meant to be on DASD with DSORG=PS, but "meant to be" doesn't imply it will always be the case.
So I need to enhance my programm.

I have to find a way to test wether or not the file is on DASD and take care of PSU.

I also have an ohter issue, is there a way in HLASM to perform a data set list ? I'm checking our SAMPLIB and take a look at DGT1C105
but If you have a hint.

This is sample DD selection code. I check the UCB just after the RDJFCB. I could check for a JES2 dataset and consider it a sequential dataset, but I don't. TIOEFSRT is in the TIOT DD entry. UCBOB, UCBTBYT3 and UCB3DACC are in the IEFUCBOB macro. Since I have a UCB address, the alternate method to check device type, DEVTYPE, isn't necessary here. This code is AMODE 24, it will work AMODE ANY with one minor change. I don't think the SR 0,0 just before the OBTAIN macro is necessary any more, but back in OS/360 I had an OBTAIN fail if it wasn't there, so I still put it in. Notice that I'm checking for DSORG=PO and a member name specified in the JFCB; this is effectively a sequential dataset.
One possibly useful enhancement is that you can count the records in a DSORG=DA dataset using a sequential DCB, but I'm unsure if that's real useful for you.

DS1DSORG is a two byte field; both bytes should be checked, not just the first byte.

HLASM is a programming language; it could not do a dataset list. The correct method to ask your dataset list question is something like, "Can I obtain a list of datasets in Assembler?" This is still not a complete question, since you do not specify the source of the dataset list. I presume you mean,"Can I obtain a list of dataset names from the catalog?" Yes, you can use the IGGCSI00 program, but that's another topic. Another method would be to examine the output from IDCAMS. I have used both methods in the past.

Argh ! I found out a new issue with my program.

On a given file which contains 21,441,853 rows, my program display 4,664,637 which is 21,441,853 - 16,777,216 ...

My program runs in AMODE 24, i have to read more about 31-bit adressability.

sensuixel wrote:Argh ! I found out a new issue with my program.

On a given file which contains 21,441,853 rows, my program display 4,664,637 which is 21,441,853 - 16,777,216 ...

My program runs in AMODE 24, i have to read more about 31-bit adressability.

I'm guessing (because I was too lazy to look) your code is something like -
Changing to AMODE 31 will fix the problem, but another way is -
This method is AMODE agnostic. Another method is to replace the LA 3,1(,3) with AHI 3,1.

Actually, I should not be too critical. The fundamental problem was diagnosed correctly, and that's often the hardest part of problem resolution. The proposed solution, though correct, might involve more work than was really required.

When I first read the post, I started off on the wrong response, but before I clicked the Submit button, I realized I hadn't engaged my brain, so I didn't make a complete fool of myself, and I started over.

thank you really much for your contribution, it really helps me to comprehend and it often brings me more question, that's the good way