iPgmr.com Frequently Asked Questions

If you do not find an answer to your question here, please call iPgmr.com at 320-200-2920. Your questions are very important to us. It is only through your questions and comments that we gain the insight we need to know how our systems are being used and where improvements are needed.

General Questions
  Who is iPgmr.com and what is the no-cost license all about?
  Is a license agreement required for each copy of the software installed?
  What is the difference between a *SAVF download and a distribution system?
  What can I do if my system won't restore either the *SAVF or the distribution CD?
  With the whole world moving to "the cloud", why the iSeries?
  Why RPG III and green screens, isn't that old technology?
  Is it necessary to use the command interface to access iPgmr.com systems?

Tax Calculator Questions
  How are tax rate changes handled?
  How often are updates made to the tax calculator?
  What are UNSPSC codes and what purpose do they serve?
  How do I incorporate the tax calculator into my system?
  Can the tax calculator use zip codes to identify counties?
  Does the system create print-and-sign-ready forms for remittances?
  Does the system support the Streamlined Salestax User Agreement?

Accounting System Questions
  How scalable is the accounting system?
  Can I pick and choose the parts of the accounting system I want to use?
  The system has been restored, now what? (Sub-system setup documents)
  Is there a way to transfer data from my existing systems to IAS?
  What are private information files and how do they work?
  What types of audit controls does the accounting system employ?
  How often is the system updated and how are updates distributed?
  What standards are supported by the EDI system?
  The system supports 850 purchase orders. Why not 860 PO changes?
  Besides EDI, what other interfaces does IAS support?
  Does IAS do ERP? MRP? HRM? CRM? SCM?

mEDIator Questions
  What is the mEDIator?
  How does the mEDIator work?
  What versions and standards are supported by the mEDIator?
  What documents does the mEDIator support?
  What translators does the mEDIator support?

DRG Grouper and Patient Indexing Questions
  What is a DRG Grouper?
  How does the DRG Grouper work?
  Can the grouper be updated?
  What is the Patient Indexing System?
  Why doesn't the grouper recognize CPT codes?
  Why am I being asked to be contacted by iPgmr.com?

iPgmr_base RAD/ALM Library Questions
  What is the iPgmr_base RAD/ALM Library?
  How does iPgmr_base speed up application development?
  What are some of the key features of iPgmr_base?
    1. Operating Environment
    2. Commands
    3. API's
    4. User Interface
  What application library management tools are in iPgmr_base?
    1. Single Development Library
    2. Separate Distribution Libraries
    3. Release/Modification Level Control
    4. Build Date/Time Tagging
    5. Report Log Reporting
    6. Source Code Change Management

Utilities Questions
  Should utilities be restored to QGPL or should they be restored to their own library?
  Does SPLCHK work with other data dictionaries?

Collaboration Program Questions
  What is the collaboration program?
  The software is free, why the need to control distribution?
  Who is eligible for the collaboration program?
  How does maintenance work for redistributed software?

General Questions Top

Who is iPgmr.com and what is the no-cost license all about?

iPgmr.com,LLC was formed in 2009 to market the sales tax calculator which had recently been developed. The tax calculator was created in anticipation of efforts by individual states to require the collection of sales taxes on out of state sales. In 2010 it was decided to create the Integrated Accounting System (IAS) as a platform for the tax calculator as well as to create a base system for most any business enterprise. Development of IAS began in Q1 of 2011 and became available for general distribution in Q1 of 2014.

It was decided to change the licensing of iPgmr.com products to a no-cost license in 2012. The change was made effective as of January 1, 2013. The no-cost license was intended to serve three primary purposes. First, to encourage the adoption of our software by as broad a user base as possible. Second, to provide a legal framework for the development of collaborative works between iPgmr.com and our users and with other software developers. And third, to assure the intellectual rights of iPgmr.com are adequately protected in an open source environment.

The license agreement also puts forth the written agreement covering our fees for maintenance and support. Please note that we never charge to answer your questions or to provide defect support for our products. Service fees only apply when it has been determined and communicated that futher support will be billable.

NOTICE 11/18/2020: As of January 1, 2021, iPgmr.com will cease billing for or accepting payment for the renewal of annual maintenance agreements. All existing maintenance agreements will be honored through their current expiration date. Maintenance on all iPgmr.com program products will continue and updates will be made available to all licensed users, current or new, without cost through *SAVF downloads for as long as it is possible or reasonable to do so.

Is a license agreement required for each copy of the software installed?

As a licensed user, you can install any number of copies of the software on any number of systems in your enterprise. The only restriction is that you cannot redistribute copies of the software, in whole or in part, to an unlicensed party. A separate license agreement is required for each program product (i.e. salestax, accounting, mEDIator, etc.).

Maintenance agreements follow license agreements. If you want to have iPgmr.com maintain the systems for you, one maintenance agreement must be executed for each licensed program product. Only one maintenance agreement is required for each program product regardless of how many copies of the program product there are in the enterprise.

What is the difference between a *SAVF download and a distribution system?

A *SAVF (iSeries save file) download is a fully operational image of the current iPgmr.com program product. The save file restores as a single library that contains all programs and data files. With the exception of the RAD/ALM library and the programmer utilities, save files do not include RPG or DDS source code.

A distribution system is a production version of the software distributed as an ISO image on CD that can be restored directly on your system. Distribution systems are broken down into four separate libraries, one each for source code, program objects, user data, and user modifications. This breakdown allows updates to be implemented by restoring the source and object libraries while leaving user data and modifications unaffected.

Each distribution library is identified by release and modification level. In addition, each library includes a build data and time. Together these values uniquely identify the current operational environment, which can be helpful when dealing with support issues.

What can I do if my system won't restore either the *SAVF or the distribution CD?

The iPgmr.com development system is running i5OS V5R3. All program have full observability so they and other system objects should be able to be restored on releases V5R3 and above. Special restore media can be prepared for releases V5R1 and V5R2 upon request. If you are unable to restore either an iPgmr.com CD or *SAVF, please contact iPgmr.com to find out if another alternative is available.

With the whole world moving to "the cloud", why the iSeries?

No doubt about it, the cloud is the future of computing and the mainframe is dead, or so we have been told. Well we were told the same thing during the PC revolution when the power to compute came to the desktop. And we were told the same thing again during the client-server revolution when it became possible to link the desktop computers together. And now we are being told that the cloud, which will remove the burdens of systems management and provide world-wide accessability to applications and data, will for sure put an end to the mainframe.

Yet, as with the earlier cases, rather than dying and going away, the mainframe adapted and benefited from the advancements in technology. Will the mainframe do the same with the cloud too? Only time will tell. But consider this: Isn't the mainframe, with its ability to run multiple operating systems, to virtualize its hardware resources, and to process high volumes of transactions, in its own way a private cloud? And isn't the cloud, with its pools of memory and CPU's, and its massive amounts of storage, in reality bringing mainframe-like capabilty to its subscribers?

So, how does the iSeries fit into this picture? Well, when it comes to adapting to new technology, no mainframe is more capable than the iSeries. With its origin in the IBM Future Systems project of the 1970's, the iSeries has proven itself capable of supporting any viable technology to come along. And it has grown in both speed and capacity to where it has virtually no limit today. Moreover, it has done all this without any disruption to any existing applications.

And that is "Why the iSeries". The cloud will undoubtedly be the best solution for many users and for many applications. But as with all technologies, it will never be the best in all cases. Nor will the cloud be the last revolution in computing. And right now, no one knows the real costs of cloud computing. Fee structures for applications, storage, users, and access will evolve as the market matures. Then there is the never ending question about security. The cloud will be a prime target for individual, corporate, and state sponsored attacks. Where then do you really want your data to be? Out there, wherever that might be, or on your own inhouse iSeries, a system already proven to be the most secure system in the world.

Why RPG III and green screens, isn't that old technology?

Yes, they are old technology, but both are far from dead. By developing in RPG III, iPgmr.com applications can be re-compiled to run on older AS/400's, thousands of which are still in active service. Also, all the code used to develop iPgmr.com systems is line-for-line convertible to RPGLE using the IBM supplied CVTRPGSRC command. There is a utility with each program product that converts source code and replaces the OPM programs with ILE modules.

Similarly, the use of "green screens" may seem old and out-dated. However in a transaction based world, the world in which business is ultimately conducted, green screens continue to prove themselves more productive than graphical interfaces. Moreover, staying within the native i5OS environment ensures these systems are and will remain secure. Still, where web access is needed, the iSeries supports technologies that can integrate these RPG applications with web-based services.

At iPgmr.com we use telnet services to access our iSeries server. Mocha TN5250 is the telnet client we use for workstation access and TN3812 provides our local printer support. With secure telnet services, any iPgmr.com application can be run safely anywhere on any device that has internet access. CGIDEV2 web services have been used to extend iPgmr.com applications to the internet. The tax calculator on this website is an example. Also, an order entry demo has been created to show how it is possible to adapt an IAS function to a web service. Click Here to run the demo.

Is it necessary to use the command interface to access iPgmr.com systems?

All iPgmr.com program products come with a command interface to access the system. The command invokes the signon program for the system. Users can bypass the manual signon by providing their user ID and password as command parameters. A sample program is provided with each system that shows how users can log onto the current iPgmr.com system directly from an iSeries signon. More information is provided with each system's installation instructions.

Tax Calculator Questions Top

How are tax rate changes handled?

As would be expected, rate changes are a constant issue with sales tax. Managing these changes was a primary concern when developing the tax calculator. Each state was carefully researched to find out how and when the state would provide official notification of changes to their sales tax policies. When a rate change is published, the new rate is added to the rate table and the existing rate, if any, is flagged for obsolescence. All rates, past, present and future are available to the tax calculator for the computing of sales taxes.

While iPgmr.com makes every effort to assure the accuracy of all tax calculations made, we know that errors will occur. You, our users, are our best auditor. We welcome all questions regarding tax calculator results and will make any adjustments that are needed to make sure our calculator is the best, most accurate available.

How often are updates made to the tax calculator?

Regular updates are distributed quarterly, in March, June, September, and December. If an interim change or update is warranted, it will be sent out with an appropriate notice. Updates are automatically sent out to all users with a current maintenance agreement.

What are UNSPSC codes and what purpose do they serve?

UNSPSC codes are "an open, global, multi-sector standard for efficient, accurate classification of products and services". The coding system was developed by the United Nations Development Programme (UNDP). They were initially used as a common coding system for international manifesting and customs declarations. The coding system is based on a simple eight digit numbering scheme. The first four digits identify the product or service family, and the last four identify a class within the family. More information about the system is available at www.UNSPSC.org.

UNSPSC codes are used by the tax calculator to identify taxable and non-taxable goods and services. For example a number of states exempt clothing from sales tax. Code 53100000 is the parent code for clothing. Making code 53100000 exempt from taxes will exempt all codes 53100000 thru 53109999. Some states which exempt clothing do so with the exception of athletic wear. Exempting all clothing classes except 53102900 (athletic wear) allows the tax calculator to accomodate the distinction.

The tax calculator has a cross-reference file which allows users to match-up company goods and service codes with corresponding UNSPSC codes. Using the cross-reference file, the tax calculator can identify taxable and non-taxable goods and services based on company codes. Also UNSPSC code 99999999 is recognized by the tax calculator as "other taxable". It may be used at anytime in place of a valid code.

How do I incorporate the tax calculator into my system?

The sales tax calculator can be called from any program in your system by issuing a call request to program $$SLSTAX. $$SLSTAX accepts from one to three parameters. The first parameter is required and includes the request and returns the computed tax totals. The second parameter is optional and returns the detailed results from the tax calculator. The third parameter is also optional and provides the save directives for the request.

A typical implementation of the tax calculator would be twofold. First, the tax calculator would be called by an order entry program to compute sales taxes as they apply to an order so the customer can be informed of the tax liability to be incurred with the order. Second, the tax calculator would be called again, this time by an invoicing program to both compute and to save for reimbursement the sales tax for the invoice as it applies to the fulfilled order and the actual tax liability incurred.

More detailed information about $$SLSTAX and the API parameters can be found in QTXTSRC source file members $$SLSTAX and SETUP. Use SEU to display the members and search for "API" or print the members using the system supplied PRTTXT command. QTXTSRC also has several pseudo-code examples (RPGIII, RPGIIIDTL, RPGIIISAV, RPGIV, RPGLE) that show how to code the API in an RPG program.

IAS program $$IASSTX is a working example of integrating the tax calculator into a production environment. $$IASSTX acts as an intermediary, making sure the requestor's library list is set up for the tax calculator and then processing the sales tax request. IAS program AR200 (Order Maintenance) does a simple call to $$IASSTX and program AR300 (Billed Order Maintenance) calls $$IASSTX with a save request.

Can the tax calculator use zip codes to identify counties?

The question arises because the tax calculator often needs to know both the city and the county in order to compute the appropriate tax amount. Many cities span multiple counties and so the idea of using zip code to identify county seems logical. The tax calculator can and will do so where possible. However that is the exception rather than the rule. In the vast majority of multi-county cities there is little or no correlation between zip code and county. So, what can be done?

Since most customer name and address files do not have a place to record county, it may be necessary to create a separate customer county information file. The file would require just two fields, customer ID and county. Adding an entry for those customers for which county is required would allow that information to be retrieved and included in the call to the tax calculator API.

Whether in a customer file or in an ancillary file, having county included in the customer profile can be very helpful when auditing tax collections and remittances. It is recommended that county assignments be verified with customers so that there is no question as regards the county of record.

Does the system create print-and-sign-ready forms for remittances?

That would be really nice, but no, it does not. Remittance reports were designed to serve as a source document for the completion of most any remittance form. Contact iPgmr.com if you need help with your particular reporting requirements. Where specialty reports are needed, they will be developed and added to the tax calculator system for all users to access.

Many states are now requiring electronic entry of sales tax remittances. Most are doing so as a web service which fits the iPgmr.com report model well. However, it is expected that at some point computer-to-computer electronic filing will become the primary means of remittance processing. Before that can happen, though, data formatting and transmission standards still need to be developed. If and when that happens, the iPgmr.com Tax Calculator will be ready to take advantage of the opportunity.

Does the system support the Streamlined Salestax User Agreement?

The Streamlined Sales Tax User Agreement (SSUTA) is a state sponsored system for computing and remitting sales taxes currently supported by 22 of the 45 states with a sales tax. To date, there has not been any request from our customer base to support the SSUTA system. Regardless, we have done some preliminary work to implement SSUTA processing.

The effort to prepare for SSUTA has given us some significant reservations about the system as it is currently implemented. What could have been a very effective solution to a very big problem seems to have failed miserably. Early information regarding SSUTA suggested that it would simplify tax calculations by providing rate tables based on zip+4 location coding, and then simplify remittances by having each member state act as a clearing house for remittances as is done in the trucking industry with the International Fuel Tax Agreement (IFTA).

Use of zip+4 coding has significant advantages over standard 5 digit zip codes. Whereas a single 5 digit zip code can often serve multiple communities, each city will have unique zip+4 codes. Zip+4 can also differentiate county qualifiers where a city spans more than one county. Zip+4 can even accurately identify special tax districts such as transit service areas, commercial zones, capital improvement districts, police jurisdictions, fire and rescue service areas, etc. because zip+4 is a street and block level identifier.

On remittances, having each SSUTA member state act as a clearing house, tax remittances would be submitted to the home state as a single payment with zip+4 distribution information for all remitted taxes. States would then take their portion and make distributions to their cities, counties, and special tax districts. Any out-of-state taxes received would be forwaded to the appropriate state with the corresponding distribution information. With each state doing the same, every tax authority would eventually receive all collected taxes due to them even if it might be a month or two in coming.

Sadly though, the system as it currently exists does none of this. Rather than focussing on zip+4, SSUTA allows states to submit a hodgepodge of 5 digit zip codes, zip+4 codes, and addresses for locations. Then there is no direct correlation between boundary data and rates. Rates are identified by Federal Information Processing Standards (FIPS) place codes, but FIPS codes are optional entries in the boundary database. What sense does that make?

Then, when it comes to remittances, it seems it is the submitter's responsibility to separate and send separate remittances to each state in which a collection has been made. Not only does that add to the administrative responsiblities of the submitter, but it also means that the submitter would need to be registered with each state in which a tax was collected. Not exactly what any business would want to do or should have to do.

A comparison of rates revealed some issues that could be problematic. The single most obvious problem was the application of food and drug rates by the states. SSUTA supports a single rate for both product categories, but some member states have different rates for each and some exempt one but not the other. There was even a number of states that exempt both food and drugs from sales tax, but then provided a rate to SSUTA. It was thought that states were to align their tax code with the SSUTA model before being accepted as a member state, but obviously that is not the case. Such problems would be a nightmare in an audit!

Most concerning to us, though, has been the condition of data submitted by the states. Duplicate records, incomplete data, even corrupted data has been found in the files downloaded from SSUTA. Apparently the states have no responsibility to ensure the validity of their submitted data nor does SSUTA do any review of the data before it is made available for download.

Given the number of issues we have encountered with SSUTA, the potential time committment for ongoing support for SSUTA, and the lack of interest in SSUTA by our customers, iPgmr.com has decided to not support SSUTA at this time.

Accounting System Questions Top

How scalable is the accounting system?

The Integrated Accounting System (IAS) was designed for small to medium sized business enterprises. It supports anywhere from 1 to 990 business units, referred to as companies in IAS. Each unit is operationally separate within IAS, but units can be combined and consolidated through the financial report writer of the general ledger. Each business unit has a functional limit of about $100,000,000.00 in annual revenue, a payroll of about 10,000 active employees, and a customer base of about 100,000 accounts.

Although IAS can manage a relatively large, multi-level enterprise, it can just as well be used to support the smallest of businesses. However, some functions might seem overly complicated in such an environment. That is because the system was designed to provide for the separation of responsibility required in a corporate environment. None-the-less, with IAS you will have a solid and stable platform that will serve your needs for many years to come.

NOTE: Functional limits are based on data base field sizes of monetary fields and record identification numbers together with data retention requirements of seven to ten years. They are in no way representative of the physical capacity of the iSeries hardware which, for all practical purposes, is unlimited.

Can I pick and choose the parts of the accounting system I want to use?

The answer is both yes and no. IAS is restored as a single program product and there is no way to restore only one part of the system. However, each of the sub-systems which make up IAS (i.e. AP, AR, GL, etc.) is in effect a stand-alone system and can be used as such.

That said, there is one additional consideration, and that is the general ledger (GL) system. Even though each sub-system can and will operate independently of the others, they ALL depend on the general ledger to verify accounts, to determine the accounting period for transactions, etc. Therefore it is not only necessary to implement the GL system, but it is also necessary that the GL system be the first one implemented.

There is a document, QTXTSRC/SETUP which describes the steps required to set up each sub-system. The set-up steps are presented in the order recommended to avoid other sub-system interaction problems. Regardless, once the GL system is operational the other sub-systems can be implemented in any order desired.

The system has been restored, now what?

As noted in the restore instructions, once the system is installed and you are able to invoke the ACCOUNTING command, you are encouraged to contact iPgmr.com for a system walk-thru. The walk-thru is intended to give you an introduction to the system, its operation, features, and instructions for taking the next step.

Source file QTXTSRC has a number of documents that can be reviewed for information regarding the implementation and operation of the system.

  • OVERVIEW (IAS Overview)
  • SETUP (New Company Setup Instructions)
  • GL (General Ledger System)
  • AP (Accounts Payable System)
  • AR (Accounts Receivable System)
  • FA (Fixed Assets System)
  • IC (Inventory Control System)
  • PR (Payroll System)
  • EA (EFT/ACH Processing)
  • EDI (Electronic Data Interchange)
  • CLOSING (Period-End Processing)

These source file members can be viewed on-line using SEU or printed using the supplied PRTTXT command.

Is there a way to transfer data from my existing systems to IAS?

There is no provision in IAS for the transferring of data directly from an existing system into IAS. There is, however, a framework in place for using existing data to expedite the entry of customers, vendors, products, etc.

The framework provides a roadmap for the transferring of file data and for managing the transfer process. Data transfer programs parallel their file maintenance counterparts, making use of imported data to initialize field data to both expedite data entry and minimize key entry errors.

Import programs are not functional programs as provided, but must be coded for each specific implementation. iPgmr.com will provide assistance with these programs and the importation of user data upon request. All import assistance provided by iPgmr.com is billable at the current hourly support rate.

The import framework does not address the transference of operational data such as orders, invoices, vouchers, payroll, etc. Operational data should be allowed to be built through use. It would be expected that each system would be used initially in parallel with the existing system in order to verify operation and accuracy. Then, after a reasonable period of time, make the transition to IAS, which by then would have a functional base of data built.

One exception as regards the transfer of operational data to IAS is the general ledger. There is a command, ENTBEGBAL, which invokes a utility that provides for the direct entry of account balances for past periods and past years. These balances can be referenced by the financial statement writer to allow an uninterrupted flow of financial reports with period-on-period and year-on-year comparisons.

The document, QTXTSRC/IASIMPORT provides additional information about the import process.

What are private information files and how do they work?

Private information files are used to isolate personal information such as social security numbers and bank account numbers from generally accessible data about employees, customers and the company itself. i5OS system level security may then be applied to these files which assures that this sensitve data is accessible only to those who have been granted the proper authority.

All iPgmr.com data files are initially created AUT(*CHANGE), the default for i5OS as it is shipped. This grants all users the ability to read, write, update, and delete data from the files. To secure a private information file, public authority must be revoked and replaced by individual user authorities.

iPgmr.com application programs which access private information files try to open the file when the program is initialized. If the file is not accessible to the user, the program continues, but any use of the private information file and the data it contains is bypassed.

What types of audit controls does the accounting system employ?

Just what audit controls are or what they include may differ depending on who is asking. There are a number of audit controls inherent to IAS. These include:

  • Segregation of Responsibility
  • Internal and External Audit Controls
  • Data Retention
  • Monitoring Ongoing Activity
More specific auditing information can be found in the IAS system overview and in individual system overview documents found in file QTXTSRC.

How often is the system updated and how are updates distributed?

New releases occur when there are changes to the data base or when there is a major change to the system itself. As explained under "What is the difference between the *SAVF download and a distribution system?" the distribution system includes four libraries, a source library, an object library, a data library, and a user modification libarary. Updates to the system are done by replacing the source and object libraries. This will update the entire active program set and leave all user information intact. Updating to a new release or modification level is more involved, but tools are provided which help with the migration of data and the management of the transition without any significant disruption to the ongoing operations.

Release 1.0 was made available for general distribution on 03/10/2014.
Release 1.1 was made available for general distribution on 10/08/2014.
Release 1.2 was made available for general distribution on 08/23/2015.
Release 1.3 was made available for general distribution on 04/04/2016.

Licensed users with a current maintenance agreement can download full-source updates at anytime. iPgmr.com updates the download whenever a fix has been issued or a new feature has been added. A report log documents the changes made so users can determine the impact on their systems.

What standards are supported by the EDI system?

The IAS EDI interface was developed to support version 4010 of the ANSI X12 standards. Version 4010 was selected because it is still in wide use today and there was ample information sources available for the documents implemented. Regardless, the system is adapatable enough to support other standards and/or versions as the need arises.

In this initial implementation of EDI, IAS has also limited the transaction sets that are supported. For many users of IAS, the supported transaction sets will suffice. None-the-less, the system can be expanded to include many other transaction sets as well as to process both inbound or outbound versions of the transaction sets initially implemented.

It should be noted that IAS provides the interfaces for EDI processing only. To fully implement EDI, a translator and a communication sub-system is also needed. Solution providers such as Gentran and EXTOL can help you with these aspects of the EDI process.

The system supports 850 purchase orders. Why not 860 PO changes?

Processing changes in an electronic world presents a host of issues. What changes are allowed and from whom? How are change notifications disseminated? Who is responsible to follow through on changes received? Can and will the submitting trading partner accept an 855 change rejection? These and other questions need to be addressed before implementing any automated change process. iPgmr.com will be looking to its user base for input regarding the features to be included in a change processing interface.

Besides EDI, what other interfaces does IAS support?

There are a number of interfaces built into IAS. For example, all IAS sub-systems are interfaced to the General Ledger. Inventory Control has an optional interface to Accounts Receivable. When activated, this interface will create requisitions for inventory as orders are entered and update orders as requisitions are fulfilled. Fixed Assets also has a built in interface to Accounts Payable. That interface tracks and documents costs associated with capital projects through A/P purchase orders. And of course, there is the interface to the iPgmr.com Sales Tax Calculator making IAS one of the few systems available, on any platform, ready for the challenges of the Marketplace Fairness Act*.

The question, however, is really directed to interfaces with non-IAS systems. In other words, the question is, "Will IAS interface to my (fill in the blank) system?". The answer to that question is a qualified yes. Yes, because IAS was designed to be interfaced to**. And qualified because each interface will be unique and will need to be specifically developed for each implementation. iPgmr.com has considerable experience with the development of interfaces and of course with IAS. We will provide technical assistance when requested, but actual development assistance is billable at the current hourly rates.

* The Marketplace Fairness Act is a bill under consideration in the U.S. Congress that would lift the current restrictions on interstate sales tax collections. That could make retailers responsible for collecting and remitting sales taxes to every city, county, and state to which a sale is made.

** Each IAS system has various entry points to which interfaces can be integrated. For example, Accounts Receivable can be interfaced at the order level as may be the case for an internet store-front application, or it can be interfaced at the invoice level as may be the case for an industry-specific billing system.

Does IAS do ERP?

ERP (Enterprise Resource Planning) has been a subject of board room meetings and executive breifings for well over twenty years. It has also been the promise of countless sales calls placed by hopeful hardware and software salesmen. But as many have found, talking ERP is one thing, doing ERP is quite another.

By definition ERP is, "an integrated suite of applications that share a common data and process model covering finance, HR, distribution, manufacturing, service and the suppyly chain" (www.gartner.com/it-glossary). By that definition, IAS is an ERP system. But ERP today has gone far beyond that original definition to include any number of highly specialized, industry specific applications.

What is important is that IAS is an enterprise level system and that it does provide all the basic concepts of ERP in a fully integrated suite of systems. IAS was designed to be a foundation system, one that most any specialized ERP application could be interfaced to. For example, one aspect of ERP is the management of product distribuion. Though IAS does not have a logistics system (a component of SCM), it does maintain product shipping information and customer shipping preferences. When combinded with customer orders (also an IAS function) and production schedules (a component of MRP), a picture of the distribution requirements begins to emerge. In turn, that data can be used by an in-house logistics system or be sent, likely via EDI (with IAS support), to a logistics provider. The same is true for other aspects of ERP such as materials management, job costing, workflow management, quality control, etc.

iPgmr.com is always ready to help with the development of specialized applications and interfaces to other systems. Though such assistance is billable, considering that there is no cost for the back-end systems (i.e. AP, AR, IC, FA, GL, etc.), the cost of implementing a custom ERP solution with IAS should be well within the reach of most any size company. Moreover, with IAS as the foundation, time and resources can be more focused on the specific aspects of ERP that are of greatest value to the enterprise.

Does IAS do MRP?

MRP (Manufacturing Resource Planning), like ERP, is a very broad-based concept encoumpasing all the resources of a manufacturing company. By definition, IAS is not an MRP system, but it does provide many of the base components. Sales, inventory, financials, etc. are supported, although true cost accounting is not. iPgmr.com can provide technical support for the interfacing of MRP components with IAS.

Does IAS do HRM?

HRM (Human Resource Management) is a product of the human relations movement of the early 20th century, when researchers began documenting ways of creating business value through the strategic management of the workforce (Wikipedia). This has manifested itself in a variety of systems for recruitment, training, performance, caree development, benefits, health and safety. Although IAS is by no meaans a comprehensive HRM system, it does have a number of HR application built into the payroll system.

1) FTE Allocations - Staffing metrics are often measured in FTE's (Full Time Equivalents). An FTE can be one full time employee or two or more part time employees which together add up to the equivalent of one full time employee. IAS FTE allocations can be used in determining staffing levels, setting work schedules, budgeting employee costs, conducting contract negotiations, completing compliance reports, etc.

2) Job Evaluations - Documenting of job descriptions and listing of job requirements are a must when looking to hire new employees. For current employees, having clearly identified performance evaluation criteria in conjunction with those requirements provides a solid foundataion for career development initiatives. IAS will help with the development of these and other job related HRM programs.

3) Benefit Accounting - Benefits are used as incentives for the recruitment and retention of employees. IAS provides a means of cataloging the benefits that are available, who in the organization is eligible, the level of participation among eligible employees, and estimating the cost of providing these benefits. Estimated costs can be automatically posted to the General Ledger.

4) Earned Hours - Earned hours, i.e. vacation, holidays, sick leave, parental leave, etc., can be difficult to compute and track. The IAS payroll system will compute earned hours based on hours worked, and monitor hours available by employee. Accrued hours represents a liability to the enterprise and IAS can automatically post computed amounts to the General Ledger.

These applications are all able to benefit from the data accumulated by the payroll process and therefore well suited to be included in IAS. Other HRM applications, such as recruitment and application processing, ADA compliance, diversity initiatives, etc., are better suited to the desktop where specialized applications are often available. Basic HRM reporting is provided in IAS. Specialized reports can be developed in-house or as a billable service of iPgmr.com.

Does IAS do CRM?

CRM (Customer Relationship Management) uses technology to organize and automate sales, marketing, customer support and technical support to enhance the company's interaction with current and future customers. CRM in IAS begins with a good customer database and good sales records. The sales analysis report writer mines that data for trends and patterns that can be used for targeted marketing. EDI streamlines ordering and invoicing for large volume customers. And CGI can open up your systems to the world wide web. iPgmr.com can help you exploit the IAS features that best suit your CRM initiatives.

Does IAS do SCM?

SCM (Supply Chain Management) accounts for the flow of goods and materials from raw materials, to work in progress, to finished goods to final consumption. SCM is typically tailored to specific industries. Although IAS does include an integrated inventory control system, it is by no means an SCM system. iPgmr.com can help you with the interfacing of specialized SCM systems with IAS.

mEDIator Questions Top

What is the mEDIator?

The mEDIator is an EDI middleware program product that bridges the gap between your application programs and a an EDI translator. It provides a common interface for both inbound and outbound messaging and tools for automating and documenting EDI processes in an enterprise.

The mEDIator was born from work done in the development of the Integrated Accounting System (IAS). There, a common interface was developed for adding EDI capabilities to the various systems. The mEDIator uses the same logic, but does so in such a way that it operates independent of any specific system or database.

NOTE: The mEDIator is a constant work in progress. iPgmr.com is continually adding support for new standards, transaction sets and data elements, as well as translators, value-added networks (VANS) and communication systems. If we do not yet support your configuration, we will work with you to add the necessary enhancements. We do so without charge so that we may in turn make those enhancements available to all our users.

How does the mEDIator work?

At the heart of the mEDIator is a transaction file which is used to record the receeipt of an inbound message or to provide a trigger for the creation of an outbound message. The transaction file maintains processing and tracking information that can be used to match-up EDI message data with user operational data. Transactions can be identified by trading partner, transaction set, usage (sent or received), as well as user entity identifiers (i.e. customer number, vendor number, etc.) and operational identifiers (i.e. PO number, invoice number, etc.).

The mEDIator employs a technique that uses character strings as keys to access user files. This allows the mEDIator to validate a customer ID or to retrieve data from a customer file without having to specifically define the file to the mEDIator.

The mEDIator also makes extensive use of data structures to pass message specific information to and from the EDI process in the form of parameters. These parameters can be thus be defined specific to the user environment without the need for custom coding in either the user system or the translator.

What standards and versions are supported by the mEDIator?

The mEDIator is not tied to any specific standard or version. Support files have been initialized with segment and element definitions applicable to the ANSI 4010 standard. Maintenance programs allow the addition of any undefined segments and elements as well as the addition of new transaction sets. These definitions may be updated in the future as data is available to do so.

It should be noted that the supplied definition files are used primarily for validation purposes. Unsupported standards and/or versions can be processed by turning off validation in the mEDIator control file.

What documents does the mEDIator support?

The mediator must function independent of document definitions as there will be different document definitions for differnet trading partners even within the same transaction set. What the mEDIator does provide is a set of tools which help to document the relationships between document definitions and the user database.

iPgmr.com has provided sample document definitions for users of the Integrated Accounting System (IAS). Links to download these documents are proveded below.

Sample EDI Documents (.doc MS Word files)

  1. EDI Trading Partner Profile
  2. EDI 810 Invoice Send
  3. EDI 850 Purchase Order Receive
  4. EDI 855 PO Acknowledgement Send
  5. EDI 856 PO Shipment Notification Send
NOTE: These documents contain references specific to IAS. Such references would not be included in a document definition provided to a prospective trading partner. The "notes" feature of the mEDIator is where such user specific information would be documented.

What translators does the mEDIator support?

Translators are separate entities from the mEDIator. A translator may be a program product such as Gentran, or Extol, a value-added network such as Kleinschmidt, Advantis or Sterling Commerce, or a translator may even be a user built system. All can be used with the mEDIator.

To be able to exploit the power of the mEDIator, though, it is necessary to be able to work with the translator and in some cases with the communication system to extract transaction tracking information. That information is used to update mEDIator transaction records with interchange, group and set control numbers. It is also used to update the receipt of functional acknowledgements.

Tracking information is used by the mEDIator to support communication data access. That makes the mEDIator uniquely able to provide a direct connection from your system data to EDI transmission data, which in turn can be used to add functionality to user applications.

NOTE: If your particular configuration is not yet supported by the mEDIator, we will work with you to add the needed interfaces. This is done without charge to you as such enhancements are then shared with all users of the mEDIator.

DRG Grouper and Patient Indexing Questions Top

What is a DRG Grouper?

Diagnosis Related Groups (DRG's) are a means of ranking acute care inpatient hospital episodes of care by resource intensity. Grouping patients in this manner allows hospitals to evaluate and manage costs by DRG or groups of DRG's. Hospitals can also benchmark by groups for quality of care and resource measurement. Computer programs called groupers assign hospital cases to DRG's.

Although hospitals assign DRG's to cases for internal use, DRG's are used by third-party payors to manage reimbursement costs. The iPgmr.com DRG Grouper is designed to assign DRG's consistent with the reimbursement groups for Medicare patients as defined by the Department of Health and Human Services (HHS), Centers for Medicare and Medicaid Services (CMS).

How does the DRG Grouper work?

The DRG Grouper uses the codes assigned by a medical records coder to analyze the specifics of a patient care episode for assignment to a DRG. The CMS grouper uses the following steps to identify the DRG for a patient care episode.

  1. Lookup the DRG for the principal diagnosis.
    Every diagnosis code that can be assigned as a principal diagnosis has been assigned to a DRG by CMS. Therefore, assignment of the principal diagnosis code is critical to the DRG assignment process. According to CMS, "The principal diagnosis is the condition established after study to be chiefly responsible for the admission." Therefore, the principal diagnosis must be a condition that existed at the time of admission and must be supported by the available clinical documentation.

  2. Lookup the MDC of the principal diagnosis DRG.
    Each DRG is assigned to one of 25 Major Diagnostic Categories (MDC's). Each MDC corresponds to a single organ system or etiology. MDC is used to identify relationships between diagnosis codes and procedure codes as done in the next step in the DRG assignment process.

  3. Check for surgical procedures applicable to the principal diagnosis.
    Anytime a surgical procedure is included in a patient care episode, care resources will be significantly impacted. However, CMS will only take into consideration those procedures that are consistent with the principal diagnosis. To be considered applicable to the DRG assignment, the procedure must be assigned to the same MDC as the DRG of the principal diagnosis. (Procedures can apply to multiple MDC's.) When a surgical procedure related to the principal diagnosis is found, the DRG will be reassigned to the more resource intensive surgical DRG.

  4. Check surgical hierarchy of all related procedures.
    In cases where multiple procedures related to the principal diagnosis are performed, surgical hierarchy, as assigned by CMS, is used to identify the most resource intensive procedure. The procedure with the highest surgical hierarchy is then used for the DRG assignment. (Hierarchy ranges from 01, high, to 99, low.)

  5. Check for complicating factors that affect the level of care required.
    Just as surgical procedures impact the resource requirements for a patient care episode, so do certain secondary diagnoses which are identified by the grouper as complications or comorbidities (CC). Within the list of accepted CC's are those that are identified as major complications and comorbidities (MCC). MCC's are recognized for their additional resource requirements. Special rules are applied when the principal diagnosis is itself a CC/MCC. Most DRG's have three resource related levels; without CC/MCC, with CC, and with MCC. The DRG with the highest applicable care level will be assigned.
Code files and index cross reference files used by the grouper have been created from CMS code files downloaded from the CMS web-site, http://www.cms.gov/Medicare/Coding/ICD10/ICD-10-MS-DRG-Conversion-Project.html.

Can the grouper be updated?

The answer to that is a qualified yes. Qualified because the ability to update will depend on the Centers for Medicare and Medicaid Services (CMS). If CMS continues to put the data for future updates into the public domain, then yes, the grouper will be accordingly updated. In fact the grouper was designed to support current, past, and future versions concurrently. Updates will be availble to all licensed users with a current maintenance contract.

What is the Patient Indexing System?

The primary purpose for the Patient Indexing (PIX) System is to provide a working platform for the DRG Grouper. It was designed to collect the information needed to assign a DRG to a patient care episode and record the results. In addition to processing DRG assignments, the PIX system has tools for case mix indexing and reimbursement analytics. The grouper itself is accessed via an API and does not require the use of the PIX system.

The PIX system contains all the information required for the grouping process, which means that it can be used as a stand-alone system. No private information is maintained by the PIX system, which means that in and of itself, it does not present a security risk nor does it violate any HIPPA data privacy regulations. Interface values are provided which can be used to link PIX to existing medical records or patient management systems if desired.

Why doesn't the grouper recognize CPT codes?

CPT codes, or the Current Procedural Terminology code set, is similar to the ICD code set but is used to identify services rendered rather than diagnostic and clinical data as do ICD codes. Although CPT codes are often used to communicate information between physicians, accredidation organizations, and insurers, CMS groupers are solely based on the ICD code set and do not recognize CPT codes.

Though CPT and ICD procedure codes serve much the same purpose, there is no direct correlation between the two code sets. Some services identified by CPT do not exist in the ICD code set and some procedures in the ICD code set do not appear in the CPT code set. These and other inherant differences between the classification systems make any effort to interchange the two extremely difficult.

Moreover, because CPT codes are a copyrighted product of the American Medical Association (AMA), any use of these codes without specific permission of the AMA would not be allowed. To provide a free product, we do not subscribe to copyrighted materials in our program products.

Why am I being asked to be contacted by iPgmr.com?

Our DRG grouper has been processing user requests since July, 2015. We receive anywhere from a handful to several hundred submissions every day. Each request has been accompanied by an invitation to reach out to us and let us know if the service is useful and a request for assisting with verification of the grouper's results.

Not receiving any responses to our invitation, it was decided in 2016 to begin logging user requests so we could at least see what requests were being processed and what kind of errors users may be experiencing. Reviewing those logs allowed us to identify some erroneous DRG assignments and to build a better analyzer for exploring the what if questions. We also identified a common issue, that being the use of Current Procedural Terminology (CPT) codes. (See "Why doesn't the grouper recognize CPT codes?" also in this section.)

For those familiar with HTTP logs, requests are identified by IP address, date and time. Although IP address can identify the origin of the request, it can only do so if the request originated from a fixed IP address. Many requestors use cable, mobile, or other shared IP resources, which provide no useable identification. Even where the IP address identifies a particular organization (i.e. university, insurance company, hospital or clinic, etc.) it does not identify who within the organization is making the request so we have no specific contact information.

Still wanting to be able to learn how the grouper is being used and whether the results are accurate, it became necessary to make a direct appeal to our users. So if you are being asked if you are willing to be contacted, we are doing so because we believe your input will be useful to others. We are not looking to solicite your business as we already provide all our systems free of charge. Our intention is only to help us provide a more useful and accurate service to you and any others that may use our serivce. So we encourage you to say YES to our request, even if you don't think your thoughts and observations would be useful.

iPgmr_base RAD/ALM Library Questions Top

What is the iPgmr_base RAD/ALM Library?

RAD is an acronym for Rapid Application Development, and ALM an acronym for Application Life-Cycel Management. RAD is a set of tools and programs that help to expidite the development of a new application program product. ALM provides the infrastructure to manage and document the evolution of the program product throughtout its useful life. The iPgmr.com RAD/ALM library contains a functioning base system, a replication utility to create an application development library, and tools to document changes and manage production releases.

How does iPgmr_base speed up application development?

Every computer system, regardless of its complexity, is made up of three basic programs; a data entry program, an inquiry program, and a report program. For example, take a simple name and address application. After defining the database, a data entry program is needed to add, update and delete names and addresses. Another program is needed to display the data records, providing the ability to search the database by name, location, zip code, etc. A report program then completes the application adding the ability to create a hard-copy directory or contact list.

There are programs in iPgmr_base that can be used as templates for new program development. For example, program RPT100 is the report log maintenance program. Copying the source for RPT100 and its display file, S#RPT100, will provide the starting point for any other file maintenance program. Likewise, program RPT101 and display file S#RPT101 for an inquiry program, and programs RPT200 and RPT201, display file S#RPT200, CL program CLRPT201 and print files RPT201P1 and RPT201P2 to request, submit and print a report log report.

Of course there is more to it than just copy and paste. Each program will be unique in its own regard depending on its purpose, the user requirements, and how it will be processed. Regardless, the basic logic is there. Moreover, the supporting programs and API's of iPgmr_base are also there to add functionality to your programs without having to create and test a lot of new program code.

Using the development model along with the operational model of iPgmr_base and some helpful guidance from iPgmr.com, a simple, production ready application can be up and ready for use, complete with users, menus, help text, field prompting, output print control and purging and archiving in just a matter of hours. And although development time will increase along with the complexity of an application, the overall development time will still be significantly reduced as you become more familiar with and more comfortable in using the tools and techniques of iPgmr_base.

What are some of the key features of iPgmr_base?

1. Operating Environment

The operating environment of iPgmr_base should be reasonably familiar to anyone who has been a user on any iSeries system. Users access applications from a menu of actions which have been organized by function and possibly customized for the individual user. The menu is accessed through a signon request which identifies the user and establishes the environment for their interaction with the sytem.

The user signon is accessed via an iSeries command. The command has parameters that allow a variety of execution options. By default, the signon display is presented and the user must enter their application user ID and password. After validating user credentials, user type is identified (user, supervisor, or administrator), the user environment is set (default job description, output queue, country, base currency, and date format), and the menu is displayed.

Note: Application user ID and password may or may not be the same as the user's iSeries system user ID and password. iPgmr.com can help you with how to best utilize the options as they pertain to your systems and users.

Note: The command used to access iPgmr_base applications is the same as the application itself. For example, to access iPgmr_base, enter the command IPGMR_BASE and press enter. However, since the command object resides in library IPGMR_BASE, which would not likely be in your active library list, the command request will fail because the command will not be found. On the iSeries, it is possible to qualify a command request by prefixing the command name with a library name and slash (/). So entering IPGMR_BASE/IPGMR_BASE on a command line will find the command regardless of the current library list. The command processing program identifies the library from which the program was called and adjusts the user's library list, if needed, to include the library or libraries needed to process application programs.

2. Commands

Like iSeries system commands, iPgmr_base command names use a consonent-heavy naming convention with the exception that each begins with the letter "i" to identify them as iPgmr_base commands. iPgmr_base commands include:

  • iCMPSRC (Compare Source)
    Performs a line by line comparison of two source members. Identifies lines added, changed and/or deleted. Useful for analyzing code changes between releases and comparing user modified programs with the current base code.

  • iCPYDTA (Copy File Data for Release/Mod Level Update)
    Copies all physical data files from one library to another. Used to initialize data files when preparing for a release or modification level update.

  • iCRTDEVLIB (Create Development Library)
    Using library iPgmr_base as a source, the command processing program creates a new library and replicates the iPgmr_base objects, along with all corresponding source code and data. The new library becomes the platform for a new application library.

  • iCRTDISLIB (Create Distribution Libraries)
    Although a development library can be used as a production system, the iPgmr_base model distributes the objects into four separate libraries; one for source code, one for programs, one for data, and one for user modifications. This model makes updates a relatively simple operation of replacing program objects and if provided, the supporting source code without disrupting the target data. Libraries are identified by release and modification level and tagged with build date and time to keep track of production code levels.

  • iCRTPGM (Create Program Object for V5R1, V5R2 Systems)
    Although the IBM SAVLIB command will create a save compatible with a previous release, it does not always save program objects. iCRTPGM compiles the program objects on the target system from the restored source code.

  • iCVTRPG (Convert RPG to RPGLE)
    Converts RPG III systems to RPGLE. Uses IBM CVTRPGSRC command to convert source code and CRTBNDRPG to compile the converted source.

  • iDOCSRC (Document Source)
    This command helps the on-line readability of source members through colorization. Its primary focus is on RPG program source, but does highlight comments in CL and DDS too. iDOCSRC also performs conditional resets of audit dates.

  • iDSPBLD (Display Build Date/Time Information)
    Distribution libraries created by command iCRTDISLIB are tagged with the date and time of creation. The first step in resolving any programmatic issue should be to identify the build date and time of the active distribution libraries. Directing a user to execute this command will do exactly that. iDSPBLD displays all corresponding libraries, their current build date and time, and highlights the library set from which the command request originated.

  • iDSPDBF (Display Database File)
    This command will display any physical or logical data file in a field formatted display. Fields can be selected, omitted, or displayed in any order. Refernce fields can be held on the display when windowing left or right. And files can be repositioned by key fields or by relative record number.

  • iPRTTXT (Print Source Text Member)
    Prints a formatted list of the contents of a text source file member. iPRTTXT recognizes formatting directives in column one:
       # = Heading line, followed by number (1-9) for line number and heading text
       % = Force overflow (i.e. new page)

  • iRGZF (Reorganize Files)
    Reorganizes physical data files by number of or percent of deleted records or through a selection list of files. Used to reorgainze data files after purging and archiving outdated data.

  • iSCANSRC (Scan Source)
    Scans the contents of source file members for a value or character string and displays a selection list of all candidate members. Use to find out every program where a particular file or field is referenced or to find out in what program where this or that is done.

  • (Spell Check Text)
    Performs spell check on the contents of a text source member using the IBM QTWCHKSP API. Displays selection list of suggested spellings when misspelled word is found.

  • iSPLDCT (Spell Check Dictionary)
    Edit, reorganize and recreate spell check dictionaries. Allows use of SEU to manage dictionary source and CRTSPLDCT to recreate the dictionary.

  • iSQL (iPgmr.com SQL Processor) Enter and execute SQL statements using the IBM QMQRY processor. Processed statements are archived for auditing and retrieval.
iPgmr_base commands are limited in their scope and provided specifically to support iPgmr_base processes and support services. More full featured versions of these commands and other utility commands are available for download from the iPgmr.com Utilities Download page. And since iPgmr_base is distributed with all source, you can modify any command or command process to suit your specific needs.

3. API's

API is an acronym for Application Programming Interface and makes it possible to execute programs with parameters. Parameters provide for the sharing of information between programs. Request parameters send information to the API and return parameters send processed results back to the calling program.

iPgmr_base provides a number of API's which have been created to support processes in other iPgmr.com applications. A full list of API's can be found by displaying the contents of library iPgmr_base. API's are programs which begin with $$. A complete description of the API function, operation and parameter useage is documented in the API program source. Consider a few examples:

  • $$CITY (Resolve City Name)
    Resolves city name to abbreviated format for validation. For example, regardless of how Elk Grove Village is submitted (i.e. Elk Grv Vlg, ELK GROVE VLG, elk grv village, etc.) it is resolved to ELK GRV VLG, which is a valid location name in the location database. The same is true for names such as Saint Paul, Mountain Home, Valley Junction, Chicago Heights, Fort Worth, Kansas City, etc.

    Measurement conversions for cubes, distance, volumes, and weights. Converts between measurements (i.e. quarts to gallons, cubic feet to cubic inches, pounds to ounces, etc.) and between English and metric (i.e. miles to kilometers, inches to centimeters, quarts to liters, etc.)

  • $$DATE (System Date Utility)
    Performs date validation, date format interchanges, computes date spans, etc.

  • $$TIME (System Time Utility)
    Performs time validation, time format interchanges, computes time spans, etc. Works with any date format including julian dates. Identifies day of the week for any date and will identify holidays (U.S.) corresponding to dates.

  • $$EDIT
    Used by programs to edit an input variable. It checks input for a question mark (?) used to indicate a prompt request. It also checks for numeric values and if found, will right adjust and blank fill so the resutlt can be moved into a numeric field for processing. Character values are returned as entered.

    Convert numbers to strings, strings to numbers, etc. Program source details each API function. Designed primarily for receiving HTML form function numbers and formatting numbers for HTML displays.

  • $$EXCHG (Get Exchange Rate)
    Retrieves exchange rate between two currencies for a given date. (Requires maintaining exchange rate tables for exchange currencies.)

  • $$HELP (Help Text Display)
    Displays contents of text source member for on-line help requests. Supports text scanning functions, which can be included on the program call to pre-position the display to a particular record format, field name, etc. Recognizes the same page formatting characters used by command iPRTTXT.

  • $$MILE (Compute Miles and Direction Between Two Points)
    Uses great circle route calculation to determine distance between any two defined locations. (Requires longitude and latitude coordinates identified in location database.)

  • $$NAME (Validate Name Data Type)
    Validate name value format according to IBM established protocol, i.e. starts with A-Z, @, #, or $ and remaining characters are A-Z, @, #, $, _ or 0-9, and string contains no imbedded blanks.

  • $$SPLNBR (Spell Number)
    Converts number to words for check printing. For example, $1,251.25 converts to ONE THOUSAND TWO HUNDRED FIFTY ONE DOLLARS AND 25 CENTS.

  • $$UPC (Validate UPC Code) Performs format validation for UPC code, i.e. number of characters, all characters numeric with valid check digit. Validates EDIfact, 3 of 9, ...
There are also a number of CL program API's. These API's begin with a single $. Most of these API's provide i5OS command functions, which cannot be directly executed from a high level language program. For example, $SNDMSG will execute a send message command which is only valid from a CL program call.

NOTE: Because iPgmr_base includes all source code, you can modify any API to suit your specific needs.

4. User Interface

Programs developed using the tools and techniques of iPgmr_base will result in systems which have a recognizable and consistent interface for users. Users who are comfortable with the display layouts, function key operation, error handling, field prompting, etc. are much quicker to learn how to use new applications when they appear in a format for which they are already familiar.

All displays present the system date in the upper left corner and the processing program name in the upper right corner. Under date is the name of the current user and under program name, the current default country. Top-center displays the application program description. At the bottom of the display is a list of available function keys and the action they invoke. Anytime an input field is preceeded by a highlighted question mark (?), the input field is promptable. Entering ? and pressing enter, or positioning the cursor in the input area and pressing F4 will invoke prompting. Although not displayed, F1 is always available to invoke user help text.

Menus are all two column menus with two digit menu options; options 01-20 in the left column, and options 21-40 in the right column. Option 90 is always Signoff. Options 80-89 are used for session control and special functions. F13 on menus is assigned to a user calendar. When available, pressing F13 displays a list of notifications that have been programmed for the current user for the current date.

Maintenance programs typically offer three options; Add, Change, and Delete. Below the option field is a place to identify the object of the maintenance, i.e. customer number, employee number, etc. A highlighted (white) question mark indicates a promptable field. Entering a question mark or positioning the cursor in the field and pressing F4 will invoke a search and select inquiry program.

Inquiry programs display a list of data records from the application database. Inquiry programs double as selection programs for promptable fields. Since inquiry programs can only display a few records at a time, additional reacords are displayed each time the Roll-Up/Page-Up key is pressed and the previously displayed records each time the Roll-Down/Page-Down is pressed. The display order can be changed and the display reset to any deisred staring point. A record selection option displays the selected record detail or optionally returns the key value to the program requsting the prompt.

Print programs are supported by a print control sub-system. Print control allows for pre-defined values to set form type, output queue, form length, form width, font size, and print quality. Print control is defined by print file and optionionally by user. Each user has an assigned output queue that will be used where no print control output queue has been identified. API program $$REPLOG can be called from report writer programs to archive report requests for future reference. And API program $$REPORT is used to present run-time output overrides.

What application library management tools are in iPgmr_base?

1. Single Development Library

Initializing a new application with the iCRTDEVLIB command creates the workspace for the development of a new application. For example, you are tasked with the development of an inventory control system. iCRTDEVLIB is used to create a library named INVENTORY. INVENTORY will have its own operating environment including users, menus, a job description for batch jobs, and an output queue for printed reports. There are source files for coding the database files. application programs, and help text for the system. And there is a command, INVENTORY, to invoke the system for testing.

2. Separate Distribution Libraries

When an application is ready for production use, command iCRTDISLIB is used to duplicate the contents of the development library into four separate libraries; one for source code, one for program objects, one for data, and one for user modifications. Separating of system objects in this way makes it possible to update production systems without any disruption to the existing data or user modifications. It also provides the option of distributing application software with or without source code.

3. Release/Modification Level Control

Distribution libraries are named for the release and modification level they represent. Using the example of the inventory system, production system libraries INVSRC10, INVOBJ10, INVDTA10, and INVUSR10 correspond to release 1 modification level 0. Release and modification level numbers are set as parameters of command iCRTDISLIB. Parameter defaults are changed to match the current release identifiers.

4. Build Date/Time Tagging

Each time iCRTDISLIB is run a data area is updated with the date and time of the request. That information can be helpful when responding to user problem requests. Bringing users up to the current program (i.e. object) build will resolve any known issues. Command iDSPINVINFO, in the case of the inventory system example, will display the build date and time of all inventory system libraries on the requesting sytsem.

5. Report Log Reporting

Every iPgmr_base has a report log for documenting problems, requests, and enhancements. Each entry is assigned a tracking number that can be referenced in source code. Marking programs with the tracking number will make it possible to identify where changes have been made and why. The log, when actively maintained, can serve to inform users of system changes included in the most recent build.

6. Source Code Change Management Source utilities, i.e. SEU, WDS, etc. mark each line of source code added or changed with the date of change. That can be very helpful when looking for program fixes or modifications. However, knowing where to look can be the bigger problem. iPgmr_base has a command, iSCANSRC, that can identify source members having a particular audit date, a report log tracking number, or any other search arguement.

Utilities Questions Top

Should utilities be restored to QGPL or should they be restored to their own library?

Yes, it is best to restore utilities to the general purpose library, QGPL. Most users and most batch job descriptions will include QGPL in their active library list which would make the utility available for use by most every user and most every batch job. If restored to its own libarary, then any request to the utility would fail unless the restored library was in the active library list.

While restoring a command to a private library is more secure, it will also make use of the command more complicated. If unauthorized access is a concern, then i5OS security should be used to secure the utility. Simply remove public authority to the command object and then grant use authority to only those users or groups which should have access.

Does SPLCHK work with other spelling aid dictionaries?

The answer is yes. The USRDCT (User Dictionary) parameter of SPLCHK allows the inclusion of a second spelling aid dictionary with the SPLCHK request. As distributed, the default for USRDCT is *NONE.

The dictionary supplied with SPLCHK is a US English dictionary. It includes most every word and name that is commonly used in the English language. It is automatically included in every SPLCHK request. The supplied SPLCHKDCT command can be used to add words, names, abbreviations, acronyms, etc. to the dictionary or to create a special spelling aid dictionary to be referenced by the USRDCT parameter.

Special spelling aid dictionaries may also be acquired commercially. For example, IBM has spelling aid dictionaries specifically designed for medical, legal, and scientific applications. They also have dictionaries available for most every commonly used language in the world.

Collaboration Program Questions Top

What is the collaboration program?

Whereas the iPgmr.com no-cost license prohibits the redistribution of software, the collaboration program removes that restriction for those participating in the program. The program was created for software developers and value-added remarketers who wanted to include iPgmr.com program products with their offerings.

The software is free, why the need to control distribution?

Just as the license agreement establishes a legal framework for the use of the software, the collaboration program agreement provides a legal framework for the redistribution of the iPgmr.com software.

The collaboration agreement has two basic provisions:

  1. To ensure that the software continues to be distributed free of charge.
  2. To ensure that each recipient of the software are themselves licensed.

Who is eligible for the collaboration program?

The collaboration program is open to any individual, company, or organization that wishes to redistribute an iPgmr.com program product, in whole or in part, to others outside their own organization. The collaboration agreement is an addendum to to the iPgmr.com no-cost license agreement, so all participants must be a licensee of the product being redistributed.

How does maintenance work for redistributed software?

Each licensee of iPgmr.com software must be current with maintenance to recieve or be eligible to download full-source production systems. Distributors would also need to be current with maintenance to recieve or be eligible to download full-source production systems. Distributors may not provide updates for their customers who are not current with an iPgmr.com maintenance agreement. Distributors may charge for maintaining enhancements and modifications that they have made for their customers, but not for maintaining iPgmr.com program products.