Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.
Here's a prototype we have and I noticed that a field is defined as 9b 0. Should it be using 10i 0 instead?
//-- Prototype for the QSYRUSRI API D getUserInfo PR ExtPgm('QSYRUSRI') D RcvVar 500a D RcvVarLen 9b 0 D Format 8a const D UserPrf 10a const D Error 1a const D Receiver s 500a Inz(' ') D VarLength s 9b 0 Inz(500) D userPrf s 10a Inz Varying D userDesc s 50a Inz Varying
edit: In looking around, I see many with 9b 0, but also a couple with 10i 0, so I'm going to go with 10i 0. Any insight into why it's initialized to 500?
Viking,
9B0 is the legacy RPG III "binary" field, which were deprecated in RPG IV with the introduction of Integer variables.
There is an H spec keyword, EXTBININT(*YES) that I often include in my own code to make sure that externally described fields identified a "B" data types are translated to Integer in my programs.
The 2nd Parm of that API requires the length of the input parameter (the returned information) to be passed. Since the first parameter (the returned information) is declared as 500A it makes sense that they initialized the VARLENGTH field to 500 and will probably pass that as the 2nd parameter.
Normally you would specify %LEN(Receiver) for the 2nd parameter instead of an actual value, but some of this stuff was probably translated from RPGIII era to a Prototype and they "just got it to compile" as many lazy programmers like to say.
Here is my version of that prototype, as included in COZTOOLS:
D QSYRUSRI PR ExtPgm('QSYRUSRI') D szRecvBuffer 65535A OPTIONS(*VARSIZE) D nBuffLen 10I 0 Const D szAPIFmt 8A Const D szUsrProf 10A Const D apierror LikeDS(QUSEC_T) D OPTIONS(*VARSIZE:*NOPASS)
Thanks Bob.
So is it fair to say that anytime one comes across a 9b 0 field, it's safe to change it to 10i 0?
It is required. Except in DDS where they chose not to support Integers.