Problem With OS upgrade : need to find the new QSYSINC library sources

470 pts.
Tags:
AS/400
i5
QSYSINC API UPGRADE
V4R5
Hi, in order to prepare the migration from our current I5 in V4R5 to the brand new I5 that will delivered with V5R2, i need to know the sources contains of the V5R2 QSYSINC/QRPGLESRC file but i'm not able to find this on the web. Can someone help me in this urgent issue ? Thanks a lot. Thierry.

Answer Wiki

Thanks. We'll let you know when a new response is added.

The QSYSINC library is installed when you install option 13 (System Openness Includes). This option should automatically install as part of the upgrade process since you have this option on your current V4R5 system. If for some reason it does not install automatically you can also install it with GO LICPGM, menu option 11.

Discuss This Question: 6  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    What could you do with them before the upgrade? If there are changes, you can't expect to use them or even test them until after the upgrade anyway. Further, you mostly shouldn't be "using" them at all. If you use them, it should only be for copying into the locations you'll actually use after modifying them appropriately. They shouldn't be directly referenced anywhere. Tom
    125,585 pointsBadges:
    report
  • bvining
    Tom, Can you explain your rational for not using the QSYSINC includes? Or why, if they are used, you recommend copying (and modifying) them first? I have used them for years and have never encountered a problem when (properly) using the IBM provided includes. Not using, or using modified versions, seems to introduce more (initial and ongoing) work for the developer.
    6,465 pointsBadges:
    report
  • TomLiotta
    Hi, Bruce. First, maybe you haven't had problems with them, but I've had to create a couple PMRs for corrections. (Not recently.) However, that's not a big deal. Fixes might be generated for anything -- commands, APIs, you name it. That's not sufficient to avoid using things. My original stand goes back to the earlier QUSRTOOL source. Though not supported, these became the basis of many sites' production functions. Compiled objects were carried forward for years. In some cases, for long after the updated QUSRTOOL library had dropped them. For some objects as example, the Y2K boundary brought some very tricky times for sites that hadn't tracked where everything had come from and gone to. Had the sources been copied into development libraries and handled as development source members, much trouble could have been averted. QSYSINC is certainly different in terms of support. But it's also source that is not under direct control of (non-IBM) developers. It can change at any time. An added structure can bring name conflicts. When the QSYSINC source is used for study and learning, it's being used for its best purpose (IMO!) When it's incorporated into live production objects, it should be by way of controlled source that is maintained along with all other source. Copy it verbatim if desired; but keep it in your CMS with the rest. That's the most important element to me. Of much lesser importance, some of it isn't neatly usable without some change. Some variable areas need attention for example. And the names... well, IBM field names can be just a little obscure to say the least. Also, the data types have slight inconsistencies in styles at points. For example, in EIM in QRPGLESRC, we see these two data items in two separate structures:
    D EIMHT                   1      4B 0
    and
    D EIMMPBC                 1      4U 0
    The 'B' data type has got to be one of the top sources of confusion for new programmers who try APIs. I get a tiny twinge when I see them used in QSYSINC. Definitely legitimate, and they're very unlikely to lead me astray. But I tend to think of developers who come after me. I very much prefer making a copy, documenting where it originated and then going through it line by line to set names, data types and everything else to make it more useful. That includes reworking the IBM comment lines as well as adding numerous additional items that may be needed. For example, the QDFFSCRA data structure in member QDFRTVFD needs to be BASED() to be really useful. It's not, so data would need to be copied into it to process it. And to copy, you'd need to create your own BASED() definition anyway. Most recurring list item structures are similar. They aren't easily usable as they're delivered. They don't need much change, but they're still changed. It doesn't seem to be a good practice to rely on changes made directly to QSYSINC, so copies should be made. Okay, it's true that none of this is absolutely required. I'd be more than happy to learn better ways. Tom
    125,585 pointsBadges:
    report
  • bvining
    Tom, You bring up some very good points. QUSRTOOL, as you pointed out, was not supported by IBM and was dropped in favor of QSYSINC so that an IBM supported set of API include files could be provided. Being IBM supported did bring along a few "rules", which then influenced how the QSYSINC include file members were provided. It's my understanding that the QSYSINC includes are considered to be a formal programming interface where IBM, when possible, provides upward compatability from release to release. As IBM upgrades QSYSINC when the operating system upgrades, one area of concern would be with user updates to the QSYSINC includes. So that no one could inadvertently modify the source, and then lose the modification on an upgrade, QSYSINC files were set as read-only. Non-IBM developers, if they want to modify items such as variable names, are required to copy the source to another source file. From there they can make their changes and use these copies as their development includes. Change can happen at any time and IBM attempts to minimize the disruption. The RPG field names are, as you point out, a "little obscure" but do have some attributes worth pointing out: 1. They start with the letter Q followed by the operating system component identifier which is providing the API (such as bn, dc, us, etc). It's generally accepted (actually stated in some obscure IBM manual that I don't have handy) that names starting with Q are considered to be in the IBM i namespace and should be avoided by users when coming up with their own names. So new structures, and fields, starting with a Q should not cause name conflicts if application developers "follow the rules". 2. The data structure and field names are unique across all APIs. In an application program you can include any combination of QSYSINC RPG API includes and you won't find any name conflicts. This unique naming constraint is why so many names end with a numeric sequence (that is maintained by the component identifier). Something along these lines was needed, in the deep past, specifically due to the lack of qualified name support by RPG and support for only 10-character names. Other QSYSINC language include files, such as for COBOL, didn't appear to need the use of "obscure" names. Though that view, over time, has introduced some problems with compatibility. COBOL for instance has, since QSYSINC first became available, added new reserved words such as LIBRARY, LIBRARY, no surprise, was a name used in just a few QSYSINC includes and caused mention in the Memo to Users as an incompatible change (and changes to the application program source if they ever needed to recompile -- though I imagine a few users may have used LIBRARY independent of QSYSINC too). Like you, I find many of the QSYSINC includes to be most useful when based. To base QDFFSCRA I would:
     /copy qsysinc/qrpglesrc,qdfrtvfd                       
                                                            
    dScrnSizePtr      s               *                     
    dScrnSize         ds                  likeds(QDFFSCRA)  
    d                                     based(ScrnSizePtr)
    
    Using this approach I have based access and the use of IBM's provided definition. And as you know, defining the pointer ScrnSizePtr is optional though I always do so explicitly. I've been burned once too often by having RPG implicitly define pointers (and then being rudely reminded that RPG will implicitly define them in my procedures and not globally). I'm with you on the 'B' vs 'I' and, as you point out, 'I' is being used more often. 'I' though wasn't valid when QSYSINC came out (along with 'U', qualified names, names greater than 10 characters in length, etc) and compatibility needs to be maintained (though 'B' vs "i" is a stretch in that I can't imagine too many -- if any -- applications really being dependent on 'B' characteristics). Changing all of the definitions to 'I' probably should have been done long ago. From a change control point of view I can certainly see where you're coming from. I really hadn't really considered QSYSINC from that point of view and now see where copies of QSYSINC would be of value. Thanks for your insight. Bruce
    6,465 pointsBadges:
    report
  • TomLiotta
    Bruce, No real disagreements; just a couple comments... So new structures, and fields, starting with a Q should not cause name conflicts if application developers “follow the rules”. Strongly agreed. Still -- at my previous job, we had a QA group. Someone had created a QAPROD library for their apps. Shortly after I started, I was asked to look into the main system backup procedure to find out why that group's library hadn't been saved for such a long time. I mean, hey... it was saving *ALLUSR libraries, wasn't it? It's not like QAPROD was created by IBM, eh? If only rules could be enforced as years go by...
    dScrnSize         ds                  likeds(QDFFSCRA)
    
    I like LIKEDS() there. It's not too painful as a workaround. I'd sure like it more if there was a variation of /COPY that indicated "for reference only, not for inclusion as source". Just to keep clutter reduced. Some of the members are pretty extensive. But that's a nit, mostly. This last one is probably a 'low blow', so please don't think of it personally nor even seriously, but still FWIW: Being IBM supported... The EDTDOC command is also kind of 'supported'. Of course, the CPP and what goes with it...? That's just a light-hearted jab at IBM and isn't a truly serious element, but it's the kind of thing that keeps me focused on trying to support myself. Finally, thank you for your insights too. It's always educational for me when I see you get dragged into a dialog. Tom
    125,585 pointsBadges:
    report
  • bvining
    Tom, First off I disavow any tie in to office! Text on the 38 was more than sufficient for my needs. But since you brought up EDTDOC, that's a good example of where an operating system should not have implemented a command that was clearly application related. But the EDTDOC command is still supported and functional (kinda). While the default OV application associated with EDTDOC is no longer available, the EDTDOC can continue to be used with other office-related applications. The Change Office Program (QOGCHGOE) API and Document Handling Exit point do provide some level of support. And yes I know you were just having fun with the EDTDOC example. But Rochester did try to provide support for the OS command even though the original application was withdrawn. And Rochester certainly tried to avoid similar situations (application oriented interfaces being provided in the OS) as time went on.
    6,465 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following