Re: QYASPOL (waiting for iASP availability on IPL)

Le 29/08/2022 à 22:55, Kelly Beard a écrit :

I don't do CL much, but occasionally I can fake my way through it. We have
in our startup program a brain-dead DLYJOB(900) to allow time for an iASP
to come up, then we start our business processes once we think it's ready.
900 seconds is 15 minutes, a really long time. We recently turned on
another CPU and upgraded our storage to the latest NVM or whatever IBM is
calling it - basically we have no more spinning disks. I thought I'd get
clever and write 'something' that sits in a loop waiting for the targeted
iASP to become ready, then I could unload the requisite RUNJVA commands
that start business stuff up. Then I wouldn't have to be up at 2AM on
Sunday morning to do this manually. Our iASP is called 'DATADEV'. I've
had a dilly of a time finding a good CL representation of the error code
parameter, but there are other parameters to fix right now too. Presently
the first SNDPGMMSG prints 'YASP0100', which it should. The second one
prints nothing at the moment, the third, random garbage, probaby because
the CHGVAR is just some

This is something I have in-progress. If anyone has something better than
this, hit me up. I'd appreciate it.

QYASPOL API does not sound to be easy to use as far as I understand it.

I guess that you want to know the IASP setup (name, device ....), so that you can get when it is VARIED ON and initiate starting the IASP residing applications. Did you investigate using ASP_INFO view (https://www.ibm.com/docs/en/i/7.5?topic=services-asp-info-view) in place of the API?

There is also an exit point that you might try to use. QIBM_QDC_VRYEXIT with PSON0200 format (The exit point programs are called after the object vary on has started.) (https://www.ibm.com/docs/en/i/7.5?topic=ssw_ibm_i_75/apis/XDCVRX400.htm). Using this one might be efficient as it is closely tighted to the vary on action and you do not have to take care of IASP in your startup program. Note that this exit point supports PROF0100 format (The exit point programs are called prior to the object being varied off. This format can issue a return code value with the ability to reject the vary processing.) which might be efficient to properly close your application before varying off.

PGM
DCL VAR(&RCVVAR) TYPE(*CHAR) LEN(64)
DCL VAR(&RCVLEN) TYPE(*CHAR) LEN(4)

DCL VAR(&LISTINFO) TYPE(*CHAR) LEN(80)
DCL VAR(&NUMRECSRET) TYPE(*CHAR) LEN(80)

I believe this one should be *CHAR 4.

Required Parameter Group:

1     Receiver variable               Output     Char(*)
2     Length of receiver variable     Input      Binary(4)
3     List information                Output     Char(80)
4     Number of records to return     Input      Binary(4)
5     Number of filters               Input      Binary(4)
6     Filter information              Input      Char(*)
7     Format name                     Input      Char(8)
8     Error Code                      I/O        Char(*)

DCL VAR(&NUMFILTERS) TYPE(*CHAR) LEN(80)

I believe this one should be *CHAR 4 as well.

DCL VAR(&FILTERINFO) TYPE(*CHAR) LEN(80)
DCL VAR(&ERRCOD) TYPE(*CHAR) LEN(4)

DCL VAR(&FMTNAM) TYPE(*CHAR) LEN(8) VALUE('YASP0100')
SNDPGMMSG MSG(&FMTNAM)

CHGVAR VAR(%SST(&RCVVAR 64 1)) VALUE('X')
CHGVAR VAR(%BIN(&RCVLEN)) VALUE(128)

CALL PGM(QSYS/QYASPOL) PARM(&RCVVAR &RCVLEN &LISTINFO &NUMRECSRET
&NUMFILTERS &FILTERINFO &FMTNAM &ERRCOD)
SNDPGMMSG MSG('Error code stuff ' *CAT &ERRCOD)
SNDPGMMSG MSG(&RCVLEN)

ENDPGM