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
More 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.
TRY 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.
Forms 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.
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:
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.
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:
LATEST COMMENTS
MC Press Online