(GSKit) Storage allocation request failed

[erprob]

I'm suddenly getting the following error messages on code that has been running for years on version 1.38

initializing GSK environment
(GSKit) Storage allocation request failed.
ssl_error(4): (GSKit) Storage allocation request failed.
SetError() #24: gsk_env_init: (GSKit) Storage allocation request failed.

We checked all the normal stuff, like firewall blocking outbound call or the server is up etc. everything seems normal. I cannot find why all of a sudden all the calls are failing.

I found this post, upgraded to 1.48 and implemented the fix. But the calls are still failing.

c callp SetError(HTTP_SSSNFD: 'SSL Handshake: ' +
c ssl_error(rc))
c callp gsk_secure_soc_close(wwsslh)
c return *OFF
c endif

https://www.scottklement.com/forums/viewtopic.php?t=246

Once the calls start failing on the batch process, it cannot recover. and keeps getting

Any help would be appreciated. I cannot seem to find anything to point me in the right direction.
Thanks

[Scott Klement]

I can't recall running into this problem in all of the years I've been doing this.

But the error says that it's unable to allocate storage. Someone needs to take a look at the different programs that run in the job and determine how they are using storage, and why the usage is getting so high that they can't allocate more.

My guess would be a "memory leak". In other words, some program is doing something that requests memory, but never returns that memory back to the system. Over time it reaches a point where you hit the maximum memory usage allowed for a job in your subsystem, and at that point things will return errors that they can't allocate storage... in this case it happens to be GSKit -- but anything else that asks for storage would have the same problem... so the problem isn't with GSKit itself (or HTTPAPI for that matter) but the fact that you've used all your storage.

Need someone to analyze all of the things going on in the job and determinw where the storage is being allocated and why it's not being freed up.

[erprob]

Scott,

Thanks for the quick reply. I was kind of thinking the same thing. After doing more digging. It turns out the system has not had an IPL in over a year and 1/2. That seems like a really long time to me, even for an iSeries.

Again, this program has been running perfectly with no changes for over 2+ years at version 1.38. Another new process could easily be taking memory now and not giving it back. The temp space seems high also, when I compare it to a different system.

Once I get the system admin to IPL performed. I will update the forum.

Thanks

[Scott Klement]

Thanks for the quick reply. I was kind of thinking the same thing. After doing more digging. It turns out the system has not had an IPL in over a year and 1/2. That seems like a really long time to me, even for an iSeries.

The iSeries line of computers was discontinued 17 years ago. Current versions of HTTPAPI don't work on iSeries.

I don't think an IPL will "fix" the problem. But, it might "work around" it temporarily by freeing up more temporary storage so that it takes longer before the problem manifests again.

Again, this program has been running perfectly with no changes for over 2+ years at version 1.38. Another new process could easily be taking memory now and not giving it back. The temp space seems high also, when I compare it to a different system.

As far as I know "temp space" (temporary storage) and "memory" are the same thing due to the single-level storage paradigm of the operating system.

It sure sounds to me like you are hitting a per-job limit (imposed by the subsystem), not hitting a system-wide limit. I say that because once you run out of memory, subsequent calls also fail due to lack of memory. Yet, meanwhile, the other jobs on the system still work. So other "processes" (jobs) are not the likely culprit, here.

[erprob]

Scott,

you are correct in your analysis. After the IPL, the process ran normally for a while again. But as you push through more transactions. it is failing apart. I do have code in there for http_persist_close(pComm); and https_cleanup();

Something must have changed on the system that it is now not allowing the HTTPAPI program to obtain the temp space it needs.

We are still looking. We changed wrksyssts max active on pool 2 and added a delay in the job. But that did not fix it. I normally never worry about memory on the power systems. Not sure what else to look at.

Let me know if you have anything to look at.

[Scott Klement]

We are still looking. We changed wrksyssts max active on pool 2 and added a delay in the job. But that did not fix it. I normally never worry about memory on the power systems. Not sure what else to look at.

As I said before, I suspect you have a memory leak in a program that runs in that job. Since I don't have any idea what programs run in the job or how they work, there's very little I can do to help. You need someone to do some troubleshooting and determine what, exactly, is using the memory in that job, and trace back to determine why it's not freeing things up properly.

https_cleanup() isn't going to help, since it only allocates memory once per activation group, and cleans it up automatically when the activation group ends.

Calling http_persist_open without calling http_persist_close would certainly cause this sort of problem... but you said that's not happening.

But... that still leaves every other piece of code running in every other program in the job as possible suspects.