22
Sun, Dec
3 New Articles

Telephone Call Accounting with Your AS/400

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

With tight budgets and cost cutting, many of us are looking to get more mileage out of our current systems with little or no additional cost or effort. One opportunity is tighter controls over long-distance phone calls. The AS/400 can help by capturing and reporting call data.

The traditional name of applications that monitor long-distance calls is Telephone Call Accounting. This application is generally implemented by utilizing a private branch exchange (PBX), commonly called a telephone switch. This system sends a record through an asynchronous serial port upon the completion of each telephone call. This record consists of at least the following information:

o Call type o Call start date o Call start time o Call end time or call duration o Call extension o Dialed number o Outgoing trunk or class of service

Telephone switches provide the information in various ways. Some calculate the call duration for you, and others leave you with an end time, which lets you do the duration calculation. Some switches provide additional information, such as:

o Access code o Accounting code o Internal called extension o Authorization code o Additional call classification codes

Cost-saving Opportunities

The serial interface on a telephone switch is usually called a Station Message Detail Recording or Reporting (SMDR) port. This feature has been available for years and was designed to be hooked to a serial printer. The printer provides a hard copy of each call made. By using the AS/400 instead of a serial printer, we can capture the call data and process it accordingly. Although this article focuses on a ROLM PBX, most contemporary PBXs have similar functionality.

Capturing the amount of time spent on the phone, as well as the cost of individual calls, is very useful. With a record of each call made, it's easy to analyze the amount of time spent on the phone. Calculating the cost of these telephone calls, however, is not so easy.

Typical phone charges are mileage-based; charges are determined by the distance between parties. To calculate this distance, you must obtain the Vertical and Horizontal Coordinate (V&H) tables from Bell Labs. These tables provide latitude and longitude for all area code and exchange combinations. Calculating the distance is done by a simple triangulation algorithm. Precalculated distance tables can also be obtained from third-party vendors.

Some call plans provided by long-distance carriers offer a flat rate per minute of telephone time, regardless of where in the U.S. the call takes place. If your long-distance plan has a flat rate, it's easy to capture time spent on the telephone along with the cost of the calls.

Many useful reports become apparent once you see the data available from a telephone switch. These reports can result in significant cost-saving opportunities. Some reports that could be useful include telephone calls of a long duration, commonly called numbers, calls made during nonbusiness hours, and 900 and 976 calls.

In many cases, significant reductions are possible by giving managers a list of telephone calls made by their personnel. Call accounting results in the elimination, or minimization, of telephone abuse and unauthorized personal calls.

You can capture these call records and implement a rudimentary telephone call accounting system with a simple asynchronous program on the AS/400. In the remainder of this article, I'll discuss the configuration of a typical environment and show a sample program that captures and stores call accounting data for processing.

(Editor's Note: Due to the specialized hardware required for this application, we were unable to subject it to the testing procedures normally used for code printed in Midrange Computing. It is your responsibility to thoroughly test this, and all other code supplied by MC, before implementing it in your installation.)

Several system configuration objects need to be created before the program can be implemented. 1 shows a sample configuration composed of an asynchronous communication line configuration, controller configuration, device configuration, and specific Intersystem Communications Function (ICF) objects. These enable the AS/400 program to interact with the SMDR port. You'll need to create these objects in order to establish a communication channel between the two machines.

Several system configuration objects need to be created before the program can be implemented. Figure 1 shows a sample configuration composed of an asynchronous communication line configuration, controller configuration, device configuration, and specific Intersystem Communications Function (ICF) objects. These enable the AS/400 program to interact with the SMDR port. You'll need to create these objects in order to establish a communication channel between the two machines.

First, create the line description with the Create Line Description-Asynch (CRTLINASC) command. Several parameters on the line description are significant. In this example, the number of data bits is set to 8, the number of stop bits to 1, and parity to *NONE. These parameters are very important and, if not set correctly, will result in corrupt or unintelligible data. The parameters must correspond to the bit configuration of your telephone switch. Contact your telephone switch vendor for the appropriate specifications. The baud rate is also important. In this example, the baud rate is set to 9600 bits per second.

Also defined is the end-of-record table. Each record a telephone switch sends has a carriage return and line feed at the end. Most telephone switches that utilize SMDR adhere to this standard. The parameter EORTBL in the CRT LINASC command defines the carriage return and the line feed characters as signifying end-of-record.

With the end-of-record table defined, the communications subsystem will ensure that only one record goes to the receiving program at a time. Without the end- of-record defined, the communications subsystem could present a buffer of data that includes multiple records.

Next, create the asynchronous controller description. The only parameter that may need attention is the SWITCHED parameter. Since the AS/400 will be directly attached to the telephone switch, specify this parameter as (*NO). The asynchronous device description is created next. There are no special considerations for the device description attributes.

Once you've finished creating the line, controller, and device objects, create the ICF objects. Add an ICF Device Entry using the Create ICF File (CRTICFF) command. There are two important relationships between the CRTICFF and Add ICF Device Entry (ADDICFDEVE) commands in 1. First, the ACQPGMDEV parameter in the CRTICFF command must match the PGMDEV entry in the ADDICFDEVE command. If these two entries are not identical (in our example they are called ROLM), the ICF file will not be able to attach to the ICF device. Second, the FILE parameters must be matched between the two configuration objects. Finally, the CMNTYPE parameter in the ADDICFDEVE command must be set to (*ASYNC).

Once you've finished creating the line, controller, and device objects, create the ICF objects. Add an ICF Device Entry using the Create ICF File (CRTICFF) command. There are two important relationships between the CRTICFF and Add ICF Device Entry (ADDICFDEVE) commands in Figure 1. First, the ACQPGMDEV parameter in the CRTICFF command must match the PGMDEV entry in the ADDICFDEVE command. If these two entries are not identical (in our example they are called ROLM), the ICF file will not be able to attach to the ICF device. Second, the FILE parameters must be matched between the two configuration objects. Finally, the CMNTYPE parameter in the ADDICFDEVE command must be set to (*ASYNC).

The Sample Application

Once the creation of asynchronous and ICF objects is complete, a program can be written to receive data from the switch. Before we review the program, let's review the logic behind ICF communications.

The process of ICF communications described in this article is simple. First, issue an INVITE instruction to prepare the ICF communications subsystem for input. An INVITE in ICF is the equivalent of telling the SMDR port that a device is ready to receive data. Then issue a READ instruction to perform the read. Based on the way we've defined the line description, the ICF communications subsystem will present a single record with each READ instruction. All unblocking of data will be done by the ICF subsystem.

The logic of the program merely needs to invite input, read a record, and write it to a file. An ICF file is created (see 2) to issue the INVITE and the READ to the communications file. Writing the INVITE format puts the ICF subsystem in a state that will allow for a following READ. Reading the READ format receives a record of data. The example program does a simple test to check for a valid record type. If the record was read successfully, it's written to the detail file (see 3).

The logic of the program merely needs to invite input, read a record, and write it to a file. An ICF file is created (see Figure 2) to issue the INVITE and the READ to the communications file. Writing the INVITE format puts the ICF subsystem in a state that will allow for a following READ. Reading the READ format receives a record of data. The example program does a simple test to check for a valid record type. If the record was read successfully, it's written to the detail file (see Figure 3).

The RPG program (see 4) illustrates an example of passive communications. Passive communications either send or receive data, but have no mechanism to acknowledge a successful transmission. In this case, the communications program must be passive because the AS/400 is acting like the serial printer attached to the telephone switch's SMDR port.

The RPG program (see Figure 4) illustrates an example of passive communications. Passive communications either send or receive data, but have no mechanism to acknowledge a successful transmission. In this case, the communications program must be passive because the AS/400 is acting like the serial printer attached to the telephone switch's SMDR port.

Because of this passive communication, it's important to filter out corrupt data in the program. If the record is not valid, it's not written to the file but is printed on an audit report.

When an INVITE or READ is attempted to ICF file, an error indicator is returned if there is a communications error. If an error occurs, information about the operation can be captured in the information data structure and an error indicator is turned on. This error indicator is represented as *IN20 in the sample program. Information returned to the information data structure includes the record length, major and minor return code, status code, and the operation code. It's not uncommon, when setting up the initial connection between the AS/400 and an SMDR port, to experience some initial errors while you fine-tune the interface. This information can be useful in diagnosing those communications problems. A full description of these return status codes is supplied in the ICF Programming manual.

A Word of Caution

Be aware of some things when implementing this program. First of all, your SMDR connection between the PBX and the AS/400 may require you to purchase a simple asynchronous null modem cable. This cable crosses the transmit and receive signals of the RS232 interface, so the two machines can communicate. Second, some telephone systems have a buffer that stores call accounting records if the Data Terminal Ready (DTR) signal is not active. You can activate this signal by varying on the communications line. If no buffer is provided and calls are made, lost records will result. If there is a buffer, you must make sure that, after the line is brought up, the spooler is started in the telephone system.

Save Time and Money

Tracking your company's phone usage through the AS/400 is a quick way to cut costs and generate more productivity among your employees. Using the techniques presented in this article, your phone bill may no longer be the most dreadful mail of the month.

This is an example of how simple asynchronous communications can be on the AS/400. The resulting data can provide significant information to cut costs for your company. If you choose to put more time into the application, it can be expanded into a sophisticated system that will yield invaluable information. Fred Wiest has more than 16 years of software development expertise in IBM midrange and PC environments.

REFERENCES

V2: Asynchronous Communications Programmer's Guide (SC41-9592, CD-ROM QBKA1400).

V3: Asynchronous Communications Programming (SC41-3444, CD-ROM QBKANW00).

V2: ICF Programmer's Guide (SC41-9590, CD-ROM QBKA1D01).

V3: ICF Programming (SC41-3442, CD-ROM QBKANU00). RPG/400 Reference (SC09-1349, CD-ROM QBKA4E01).


Telephone Call Accounting with Your AS/400

Figure 1 Sample Configuration Objects for ASYNC Connection

 PGM VRYCFG CFGOBJ(ROLMLIN) CFGTYPE(*LIN) STATUS(*OFF) DLTDEVD DEVD(ROLMDEV) DLTCTLD CTLD(ROLMCTL) DLTLIND LIND(ROLMLIN) DLTF FILE(S5CDRW01) CRTLINASC LIND(ROLMLIN) RSRCNAME(LIN062) ONLINE(*YES) + INTERFACE(*RS232V24) CNN(*NONSWTPP) + BITSCHAR(8) PARITY(*NONE) STOPBITS(1) + DUPLEX(*HALF) ECHO(*NONE) LINESPEED(9600) + MAXBUFFER(4096) EORTBL((0D 3) (0A 3)) + DSRDRPTMR(6) TEXT('Rolm Call Accounting + Line') IDLTMR(1) CTSTMR(25) CRTCTLASC CTLD(ROLMCTL) LINKTYPE(*ASYNC) ONLINE(*YES) + SWITCHED(*NO) LINE(ROLMLIN) TEXT('Rolm + Call Accounting Controller') CRTDEVASC DEVD(ROLMDEV) RMTLOCNAME(ROLMLOC) + ONLINE(*YES) CTL(ROLMCTL) TEXT('Rolm Call + Accounting Device') CRTICFF FILE(AMALIB/S5CDRW01) SRCFILE(GPLIB/QDDSSRC) + ACQPGMDEV(ROLM) ADDICFDEVE FILE(S5CDRW01) PGMDEV(ROLM) + RMTLOCNAME(ROLMLOC) CMNTYPE(*ASYNC) VRYCFG CFGOBJ(ROLMLIN) CFGTYPE(*LIN) STATUS(*ON) ENDPGM: ENDPGM 
Telephone Call Accounting with Your AS/400

Figure 2 Sample ICF File

 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R INVITE INVITE * A R RECORD A DATA 113 
Telephone Call Accounting with Your AS/400

Figure 3 Sample DB2/400 Call Distribution Database

 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R CDRCAP TEXT('CALL DISTRIBUTION DETAIL + A FILE') * A CDTYPE 2A TEXT('RECORD TYPE + A 01=INCOMING CALL + A 02=OUTGOING CALL + A 03=TANDEM CALL + A 12=DUMB MODEM POOL CALL') A COLHDG('REC' 'TYPE') A CDDATE 8A TEXT('START DATE (MM/DD/YY)') A COLHDG('DATE') A CDTIME 5A TEXT('START TIME (HH:MM)') A COLHDG('TIME') A CDDURA 6A TEXT('DURATION') A COLHDG('DURATION') A CDFLAG 6A TEXT('CALL FLAGS + A -=NOT USED + A D=DIRECT INWARD SYSTEM (DISA) + A T=DIRECT TRUNK SELECT (DTS) + A C=ATTENDANT CONSOLE (ATC) + A A=ANSWER SUPERVISION + A 1=ROUTE OPTIMIZATION + A 2-9=ROUTE') A COLHDG('FLAGS') A CDCLNG 7A TEXT('CALLING EXTENTION') A COLHDG('CALLING' 'EXTENTION') A CDDIAL 16A TEXT('NUMBER DIALED') A COLHDG('NUMBER' 'DIALED') A CDACCS 4A TEXT('ACCESS CODE') A COLHDG('ACCESS' 'CODE') A CDCALD 7A TEXT('CALLED EXTENTION') A COLHDG('CALLED' 'EXTENTION') A CDACCT 12A TEXT('ACCOUNT CODE') A COLHDG('ACCOUNT' 'CODE') A CDAUTH 12A TEXT('FORCED AUTHORIZATION CODE') A COLHDG('FORCED' 'AUTHORITY') A CDCLAS 2A TEXT('CLASS OF SERVICE') A COLHDG('CLASS') *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 
Telephone Call Accounting with Your AS/400

Figure 4 Sample Call Accounting Data Capture and Report

 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FS5CDRW01CF E WORKSTN F KINFDS IOFB FF5CDRCAPO E DISK A FQSYSPRT O F 132 OF PRINTER * IIOFB DS I *STATUS STATUS I *OPCODE OPCODE I *RECORD FORMAT I B 372 3750RECLEN I 401 402 MAJCOD I 403 404 MINCOD * IREC DS I 1 1 RECTST I 1 2 RECTYP I 5 12 DATE I 15 19 TIME I 22 27 DURA I 30 35 FLAGS I 38 44 CALLNG I 47 62 DIALED I 65 68 ACCESS I 71 77 CALLED I 80 91 ACCONT I 94 105 AUTHOR I 108 109 CLASS I 110 117 CRLF ******************************************************************** * MAINLINE PROCESSING ******************************************************************** * * FIRST TIME THROUGH * C MOVE '1' *INOF C MOVE *ZERO BELL 1 BELL=X'07' C BITOF'01234567'BELL C BITON'567' BELL C MOVE *ZERO LF 1 LF=X'15' C BITOF'01234567'LF C BITON'357' LF * * LOOP UNTIL FINISHED * C *INLR DOUEQ'1' * * READ A RECORD FROM THE SWITCH * C WRITEINVITE 20 C READ RECORD 2021 C MOVELDATA REC C EXSR CHKERR * * PRINT THE RECORD * C *IN19 IFEQ '1' C EXSR PUTDET C ENDIF * * CHECK FOR SHUTDOWN * C SHTDN LR * * END OF LOOP * C ENDDO * * FINISH UP AND END * C MOVE '1' *INLR C RETRN * ******************************************************************** C CHKERR BEGSR ******************************************************************** * *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 C MOVE '1' *IN19 * * FILTER OUT FILLER DATA * C RECTST IFEQ BELL BELLS C RECTST OREQ LF LINE FEED C MOVE '0' *IN19 C ENDIF * * TEST RECORD FOR VALIDITY * C *IN19 IFEQ '1' * C RECTYP IFNE '01' C RECTYP ANDNE'02' C RECTYP ANDNE'03' C RECTYP ANDNE'12' C MOVE '1' *IN20 C ENDIF * C *IN20 IFEQ '1' C *IN21 OREQ '1' C *INOF IFEQ '1' C EXCPTHEADER C ENDIF C MOVE '0' *IN19 C EXCPTERROR C EXCPTAUDIT C ENDIF * C ENDIF * C MOVE '0' *IN20 C MOVE '0' *IN21 * C ENDSR * ******************************************************************** C PUTDET BEGSR ******************************************************************** * C MOVE RECTYP CDTYPE C MOVE DATE CDDATE C MOVE TIME CDTIME C MOVE DURA CDDURA C MOVE FLAGS CDFLAG C MOVE CALLNG CDCLNG C MOVE DIALED CDDIAL C MOVE ACCESS CDACCS C MOVE CALLED CDCALD C MOVE ACCONT CDACCT C MOVE AUTHOR CDAUTH C MOVE CLASS CDCLAS * C WRITECDRCAP * C ENDSR * ******************************************************************** * OQSYSPRT E 2 1 HEADER O 56 'CALL ACCOUNTING AUDIT' OQSYSPRT E 1 HEADER O 26 'DATE:' O UDATE + 1 ' / / ' OQSYSPRT E 11 HEADER O 26 'TIME:' O UTIME + 1 ' : : ' OQSYSPRT E 1 AUDIT O + 0 'DATA:' O DATA + 2 OQSYSPRT E 1 ERROR O + 10 'STATUS' O STATUS + 2 O + 2 'MAJOR CODE' O MAJCOD + 2 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 O + 2 'MINOR CODE' O MINCOD + 2 O + 2 'OPERATION' O OPCODE + 2 O + 2 'FORMAT' O FORMAT + 2 O + 2 'LENGTH' O RECLEN + 2 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: