Issue with YOBPGMDS data structure

[Anon Anon]

Hi All,

Does anybody know if there is any runtime behavioural difference between RPG400 and RPGLE when generated from Plex? We are facing one strange issue which I think is to do with how program is invoked on iterative calls.
In all of our RPG programs we have used below API to read Program data structure for error handling. This is based on CA provided data structure YOBPGMDS.

It looks something like below :

C MOVELYYPPGM &(1:)
C MOVELYYPSTS &(2:)
C MOVELYYPPLB &(3:)
C MOVELYYPEFL &(4:)
C MOVELYYFSTS &(5:)
C MOVELYYPERL &(6:)
C MOVELYYPJOB &(7:)
C MOVELYYPUSR &(8:)
C MOVELYYPJNO &(9:)

D YZPGDS ESDS EXTNAME(YOBPGMDS) //Data structure definition

The problem is with MOVEL statement for YYFSTS. When a program containing this API is called twice it throws a decimal data error on said statement on second call.

This used to work alright in previous versions (RPG400 via Plex5.1). And now we are converting it to RPGLE via Plex7.
As per our observations the problem lies on how the RPGLE program is called second time within a same call stack (it was RETURNed and not TERMINATEd on first call).

Whenever a RPG400 program is called following statement is always executed as it is embedded within *INZSR. This initialize the YYFSTS field to zeros and hence no error occurs on any MOVE statements.

0018.79 C *INZSR    BEGSR                        
0018.81 C Z-ADD*ZEROS YYFSTS

While in RPGLE this does not seem to be the case , it would not invoke *INZSR and hence no initialization takes place.

As I mentioned , on first call this field contents will be 00000.0 and on subsequent invocations it will be ' .' (i.e blanks with a dot in it) which throws decimal data error.

Also to clarify there was no real error in the function which would cause this field to be set with any value other than zeros/blank.

Another interesting fact that we have noticed is the definition of this field. IBM documentation suggests that Program Status Data structure stores 'Status information on the last file used ' from location 209 and 243 which is a character field of length 35.

The data structure defined in our programs ( based on external DS PLEX700/YOBPGMDS provided by CA) splits this field into two fields called YYFSTS and YYPERL. Out of which YYFSTS is zoned decimal and YYPERL is character.

As this is pretty old piece of code I was not expecting any difference in behaviour when upgraded to ILE.

Any hints highly apprciated.

Regards,
Amit

[Dean_Eshleman]

Hi Amit,

Looking over our code here, it looks very similar to yours. We don't have an API like yours though, so we haven't run into this problem. We generate RPGLE and we return from our programs all the time. We are at Plex 6.1.

The quickest way to solve your problem is to create another API that initializes the YYFSTS field to zeroes. Then, add a call to the API at the beginning of your program so that it gets executed every time. This call could be added to your pattern so that it is inherited, just like your error API is probably inherited. Then, I would report the problem to CA because it definitely sounds like a bug. Hope that helps.

Dean Eshleman,
Everence Financial

[Anon Anon]

Thanks for your prompt response Dean.

I agree to the fact that quickest solution would be to add an another initialization routine which would always run. But before that I want to make sure there is no other configuration sort of things which I might be missing.
Also this API is coded in pattern and hence almost there in all the programs. Having already built thousands of programs I want to be careful as this warrants another full rebuild.

You said you also use similar code. Are you using field YYFSTS as well? If yes do you initialize it every time program is called?
As mentioned in original post the problem lies in fact that *INZSR is automatically called at invocation in RPG400 but it does not in RPGLE.

Regards,
Amit

[Dean_Eshleman]

Hi Amit,

We don't have any code that references YYFSTS in the generated RPGLE code, so we have never run into this problem. We do have some error handling code related to the PSSR subroutine. We have modified the YOBPSSR program so that it logs the errors to a file. The program status data structure is passed to YOBPSSR and the fields such as YYFSTS are written to a file. We haven't encountered a problem with that field containing a non-numeric value. I'm curious what would be changing YYFSTS to something other than numeric after it has been initialized to 0. It seems like some other code is setting the PSDS to blanks and that is causing the problem. The fact that you are returning from the program rather than terminating shouldn't make a difference.

Regarding the *INZSR subroutine in RPGLE programs.  It is my understanding that it will be called the first time the RPGLE program is invoked.  So, I don't think it is an RPGLE versus RPG400 issue.

Dean Eshleman,
Everence Financial

[Anon Anon]

Hi Dean,

Yes in theory the *INZSR should not be called on subsequent invocations if program is returned. Though what I fail to understand is why this was not happening before in RPG400 Plex 5.1 world but in Plex 7!

And if Plex 7 is correct I dont think any other option than fixing this in patterns and rebuilding everything again.

Regards,
Amit

[Anon Anon]

Just to close this thread , we have now decided to not make use of this particular field and commented it out altogether from the API.

[George Jeffcock]

Hi Dean,

We have modified the YOBPSSR program so that it logs the errors to a file.

What errors do actually capture..Program Errors (divide by Zero etc) but File Errors don't use the F SPEC setting of INFSR(*PSSR) as INSERT,UPDATE generate using INDICATORS which take precendence over PSSR. Is this your findings and or how have you logged FILE errors using PSSR . Really is ancient our generated rpg code.....

Kind Regards

[Dean_Eshleman]

Hi George,
>
What errors do actually capture..Program Errors (divide by Zero etc) but File Errors don't use the F SPEC setting of INFSR(*PSSR) as INSERT,UPDATE generate using INDICATORS which take precendence over PSSR. Is this your findings and or how have you logged FILE errors using PSSR . Really is ancient our generated rpg code.....


The only file errors we capture via the PSSR changes we made are level checks and file authority problems. Other file errors that are caught by the indicators are handled by our own logic. Normally, if an Insert or Update function fails, the Returning status will be set to some sort of error.  The calling function is responsible for checking this.  In our patterns, we check the Returning status and if it isn't Successful, we send a message. Normally, this message is written to a data queue. Then, somewhere up the call stack it will read any messages on the data queue and either display them or print them on a report. Does that help?

Dean Eshleman,
Everence Financial

[George Jeffcock]

Don't laugh but messing around with dataueues for the very first time and thought perfect for PSSR routine. The open statement helps us as this does not use the indicators which is a real bonus but simply disappointed I could not get the insert update staments to work with out code changes. But very happy to still get messages now to help desk etc when a program and some file errors occurs with out gen and build, bloody marvellous, thank you for confirming my assumptions, and qudos to synon for obypssr

[George Jeffcock]

Thank you for posting this Amit.

I too have just come up against this today after trying to extend this functionality to ReturnStatus and not just CallStatus checking..i.e. now repeat calls

I have YYPMDS as input which contains YYFSTS and on the second call I get Decimal Data Error.

This posting saved me time so thanks for the orginal post.

 

 

 

 

[Kiyoshi]

hi,

Just FYI

As a paret of Plex r7.1 we added new data structure for RPGLE name as YOBPGMDS4. It is due to the problem to get connecting user via these API from RPGIV functions. See botomn..

Yes, the datastructure for RPGIII and RPGIV is different.

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014733323#77777777-0000-0000-0000-000014733323

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzasc%2Fsc092507488.htm See item (9)

In ILE RPG, positions 254-263 of the program status data structure (PSDS) contain the user name of the originating job. In OPM RPG, these positions reflect the current user profile. The current user profile in ILE RPG can be found in positions 358-367.

 

and here is the spec

https://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c092508381.htm

 

Just share the info..

Regards,

Kiyoshi

 

---

AS400/GetJobUser

OBAS400/Get System i User ID

Fix details are as bellow.

A fix was implemented for retrieving correct user ID through the following source code object when using RPGIV functions with new style dispatcher YOBSYTCPDP. It used to return the user who started Dispatcher instead of connecting the Client User ID.

 

[George Jeffcock]

Can you post the new YOBPGMDS4 datastructure please

Why? Because all our RPGIII or RPGIV call (VIA SOURCE) an external function (DumpPSDS) which has YOBPGMDS as its input.

But when we move to Plex7.1 the RPGIV source will use a different external defined DS.

DumpPSDS is to be called from NATIVE rpg functions also, so they will not be best please when we move to Plex7.1 that DumpPSDS will change!

I think I will create:

DumpPSDS(Plex61) - With YOBPGMDS as its input and to be called by RPGIII Plex functions and RPGIV Plex6.1 generated functions

DumpPSDS(Plex71) - With YOBPGMDS4 as its input and to be called by Native RPG programs now and Plex7.1 generated RPGIV functions in the future

 

But I need to provide the native programmers the YOBPGMDS4 now 

[George Jeffcock]

Here is YOBPGMDS, how will YOBPGMDS4 be different

 

YYPPGM	*PROGRAM	CHARACTER	10
YYPSTS	*STATUS	NUMERIC	5
YYPSTP	Previous *STATUS	NUMERIC	5
YYPSSQ	Source stmt seq. no.	CHARACTER	8
YYPRTN	*ROUTINE	CHARACTER	8
YYPPRM	*PARMS	NUMERIC	3
YYPMID	Exception msgid	CHARACTER	7
YYPMIN	MI/ODT number	CHARACTER	4
YYPMSW	Work area for messages	CHARACTER	30
YYPPLB	Program library	CHARACTER	10
YYPMSD	Retrieved exception data	CHARACTER	80
YYPEXI	Called program exception	CHARACTER	4
YYPX01	Unused	CHARACTER	26
YYPEFL	Name of file in error	CHARACTER	8
YYFSTS	Status code of last file	NUMERIC	5
YYPERL	Status info of last file	CHARACTER	30
YYPJOB	Job name	CHARACTER	10
YYPUSR	User name	CHARACTER	10
YYPJNO	Job number	NUMERIC	6
YYPEDT	Job entry date (YMD)	NUMERIC	6
YYPSDT	Job exec date (YMD)	NUMERIC	6
YYPETM	Job exec time (HHMMSS)	NUMERIC	6
YYPCPD	Date program compiled	CHARACTER	6
YYPCPT	Time program compiled	CHARACTER	6
YYPCPL	Compiler level	CHARACTER	4
YYPSFL	Source file name	CHARACTER	10
YYPSLB	Source library name	CHARACTER	10
YYPSMB	Source member name	CHARACTER	10
YYPX04	Filler	CHARACTER	96

 

 

https://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c092508381.htm

 

1	10	Character	10	If the module was compiled with CRTRPGMOD, this is the name of the module that was created; if the program was created using CRTBNDRPG, this is the name of the program that was created. For a cycle-main module, this is the name of the main procedure.
11	15	Zoned decimal	5	Status code. For a description of these codes, see Program Status Codes.
16	20	Zoned decimal	5	Previous status code.
21	28	Character	8	RPG IV source listing line number or statement number. The source listing line number is replaced by the source listing statement number if OPTION(*SRCSTMT) is specified instead of OPTION(*NOSRCSTMT). The full statement number is included when it applies to the root source member. If the statement number is greater than 6 digits (that is, it includes a source ID other than zero), the first 2 positions of the 8-byte feedback area will have a "+ " indicating that the rest of statement number is stored in positions 354-355.
29	36	Character	8	Name of the RPG IV routine in which the exception or error occurred. This subfield is updated at the beginning of an RPG IV routine or after a program call only when the *STATUS subfield is updated with a nonzero value. The following names identify the routines:
37	39	Zoned decimal	3	Number of parameters passed to this program from a calling program. The value is the same as that returned by %PARMS. If no information is available, -1 is returned.
40	42	Character	3	Exception type (CPF for an operating system exception or MCH for a machine exception).
43	46	Character	4	Exception number. For a CPF exception, this field contains a CPF message number. For a machine exception, it contains a machine exception number.
47	50	Character	4	Reserved
51	80	Character	30	Work area for messages. This area is only meant for internal use by the ILE RPG compiler. The organization of information will not always be consistent. It can be displayed by the user.
81	90	Character	10	Name of library in which the program is located.
91	170	Character	80	Retrieved exception data. CPF messages are placed in this subfield when location *STATUS contains 09999.
171	174	Character	4	Identification of the exception that caused RNX9001 exception to be signaled.
175	184	Character	10	Name of file on which the last file operation occurred (updated only when an error occurs). This information always contains the full file name.
185	190	Character	6	Unused.
191	198	Character	8	Date (*DATE format) the job entered the system. In the case of batch jobs submitted for overnight processing, those that run after midnight will carry the next day's date. This value is derived from the job date, with the year expanded to the full four years. The date represented by this value is the same date represented by positions 270 - 275.
199	200	Zoned decimal	2	First 2 digits of a 4-digit year. The same as the first 2 digits of *YEAR. This field applies to the century part of the date in positions 270 to 275. For example, for the date 1999-06-27, UDATE would be 990627, and this century field would be 19. The value in this field in conjunction with the value in positions 270 - 275 has the combined information of the value in positions 191 -198.
201	208	Character	8	Name of file on which the last file operation occurred (updated only when an error occurs). This file name will be truncated if a long file name is used. See positions 175-184 for long file name information.
209	243	Character	35	Status information on the last file used. This information includes the status code, the RPG IV opcode, the RPG IV routine name, the source listing line number or statement number, and record name. It is updated only when an error occurs.
244	253	Character	10	Job name.
254	263	Character	10	User name from the user profile.
264	269	Zoned decimal	6	Job number.
270	275	Zoned decimal	6	Date (in UDATE format) the program started running in the system (UDATE is derived from this date). See User Date Special Words for a description of UDATE. This is commonly known as the 'job date'. The date represented by this value is the same date represented by positions 191 - 198.
276	281	Zoned decimal	6	Date of program running (the system date in UDATE format). If the year part of this value is between 40 and 99, the date is between 1940 and 1999. Otherwise the date is between 2000 and 2039. The 'century' value in positions 199 - 200 does not apply to this field.
282	287	Zoned decimal	6	Time (in the format hhmmss) of the program running.
288	293	Character	6	Date (in UDATE format) the program was compiled. If the year part of this value is between 40 and 99, the date is between 1940 and 1999. Otherwise the date is between 2000 and 2039. The 'century' value in positions 199 - 200 does not apply to this field.
294	299	Character	6	Time (in the format hhmmss) the program was compiled.
300	303	Character	4	Level of the compiler.
304	313	Character	10	Source file name.
314	323	Character	10	Source library name.
324	333	Character	10	Source file member name.
334	343	Character	10	Program containing procedure.
344	353	Character	10	Module containing procedure.
354	355	Binary	2	Source Id matching the statement number from positions 21-28.
356	357	Binary	2	Source Id matching the statement number from positions 228-235.
358	367	Character	10	Current user profile name.
368	371	Integer	10	External error code
372	379	Integer	20	XML elements set by operation
380	429	Character	50	Unused.