BPCS Naming Conventions

As explained in some CLP/400 examples of CLP/400 programs, software for BPCS needs to be named in such a way that it is going to work within BPCS Security, which has some variations by version.

This article structured to support people familiar with different BPCS versions adding what we need to know in parallel. Perhaps if this gets too large, break some sub-sections into different articles, carefully cross-linked because these subjects are so intertwined.

BPCS Conventions

For reasons of BPCS being a licensed and copyrighted ERP this is just a synopsis of key FAQ so as to avoid having to repeat ourselves within CLP/400 examples of programs.

BPCS V4.0.5.CD Conventions

BPCS comes with applications in which the first 3 letters of the programs are an abbreviation of the application area, such as

• INV = Inventory;
• ORD = Customer Orders;
• PUR = Purchase Orders;
• SYS = System Stuff.
  • See SYSCMDUSNO in CLP/400 examples for a program to Display selected recent critical DSPLOG events that IT wants to know about

BPCS V4.0.5.CD More

Also see

• BPCS *LIBL Gotchas
  • soft coded

BPCS Security

For reasons of Security by Obscurity, this is just a synopsis of key FAQ.

BPCS V4.0.5.CD Security

What people can access and run is controlled by several elements:

• their 400 user profile;
  • Managed by 400 Security Officer
  • Do they have command line access?;
• HOW do they access the 400 ... via Green Screen or Client Access?;
  • Is their Client Access setup so that they have the equivalent of command line access?;
• their BPCS user security;
  • Managed by BPCS Security Officer
  • See below for more info
• are they on the list for some menu we added?
  • Managed by any BPCS user whose BPCS user security authorizes them to maintain menus
• variations in library list by individual person
• modifications in violation of BPCS standards

BPCS V4.0.5.CD User Security

BPCS User Security controls

• Which BPCS Environments may this person access?;
• Is this person an ordinary user or a BPCS Security Officer?
• What can the user access outside of the normal menu structure?
• What applications and sub-application areas is this user authorized to run?
• What Financial Companies is this user allowed to get into?
• What Warehouses can this user get into?
• What Inventory Transactions may this user do?

Note that

• If a user is not authorized to access some menu, for that user it is as if that menu does not exist.
• Menus can have options that not all users are authorized to access. For those users, those options text appears but the menu option # is blanked out, and will not work for them

BPCS V4.0.5.CD Implied Security

There are some realities not spelled out by the BPCS documentation that companies using this ERP from SSA discover in general practice.

You need some values in the 400 user profile to permit a person to create a program and get it complied so that it will run in the BPCS library list, and have any co-worker run it Ok.

You need some values in the BPCS User Security (explained above) to grant you access to be updating menu options to add programs ... for most sites 99% of the programs added to menus are CLP programs, but other kinds are supported.

Al Mac showed some co-workers how to create Query definitions; embed them in CLP programs using CLP/400 examples such as INVENGQRY to show them how; compile the result; and put the CLP program onto BPCS Menus.

The co-workers that Al had been showing how to make new Query; embed in CLP; install on BPCS Menus - they were BPCS Security officers who apparently had not understood when Al said that ONLY a BPCS Security Officer can run software that is inside BPCS that is in violation of the BPCS Naming conventions.

However, some of what Al tried to explain fell out of our collective brains as was discovered when these co-workers tried to show OTHER co-workers how to run their new creations.

Fortunately they had understood when Al Mac said not to use name of something that already exists, and how to check that. They had created new software with any old name that suited their fancy, and because they were BPCS Security officers, they could run ANY software that got added to BPCS.

However since their added software was outside the BPCS Naming Convention Rules, it could not be run by anyone who was bound by BPCS Security which is ruled by BPCS Naming Conventions.

BPCS 405 CD Danger Will Robinson

BPCS versions prior to current ones have security that was fine when those versions were current, but the needs of security have marched forwards, and the older versions, if not modified from a security perspective, have some serious concerns.

Depending on where you get your BPCS Tech Support, there are fixes for these concerns. You need to visit BPCS-L for more info on this subject.

For multiple reasons, it is customary that

• BPCS Security Officer be no higher in 400 Security than Programmer or Operator
• 400 Security Officer NOT be recognized by BPCS Security
  • Depending on 400 security rules, a higher security person may be needed to load software from tape to 400 libraries, and to have that coded correctly to work within BPCS you may want to have a special sign on with 400 security higher than is needed for normal BPCS operations within the family of BPCS users and use it only for stuff like that
  • Occasionally something goes haywire with BPCS security resulting in NO PERSON who is in the BPCS user family being able to sign onto the 400 (everyone locks up at the security error). In case this happens to you, you need a high security 400 sign-on to do the fixing, that is not in the BPCS user collection. You cannot repair this if 400 security officers all are also having the same crash.
    • Consultants Personnel not always comprehend all nuances, so some stuff should be checked after they have completed a contracted visitation
      • Make sure they did not put 400 security officer into BPCS security, but if they did, take it back out
      • Change passwords they were told about
      • If you have one of those BPCS Security Audit packages (see BPCS_L for info on what's out there) then this is a good time to run it again

Other Security

Also see General Computer Security

This is not precisely what any one company might be doing, but what many of us wish we were doing. Other folks might add here, or in links to other articles, a list of general advisable good security practices.

• 400 GO SAVE 21 regularly on rotating media with some always off site, including associated with time of last fiscal month
  • Off site media is needed in case something bad happens at your physical site, like disaffected person going postal, tornado or other disaster strkes there
  • Standard 400 backups are not encrypted. Give some thought to what your exposure is if someone steals the off site media. Can anyone with access to another AS/400 process your data?
• If backup is left running unattended, have a system to sign off the 400 security officer needed to run it, before normal crew have access to main console
• backup tapes library to include a year ago
  • if some software or data is only used annually, like in end year, or physical inventory, and it gets deleted by accident, we not know that until next time we try to use it
• on-line "backup" library of software subjected to volatile modifications, just in case we need to get to a version prior to some changes
• utilize 400 security auditing to look for various suspicious activities
• data that gets onto the tapes could be checked occasionally to verify everything that is there that should be there is in fact there
• DSPLOG captures a message at end of a successful backup. See SYSCMDUSNO for a sample program to capture and check those messages.
• Correlation
  • 400 system knows when people trying to access our system
  • we know who previously was authorized to access our system
  • monitor and capture logs and do message notification
    • when new users added
    • when new devices added
    • when connection made by method other than one of our usual
• Passwords for Security and sensitive 400 stuff
  • changed more often than we require of ordinary users
  • changed at end of visit of any outside consultant who needed to use them
  • changed at end of employment of co-workers who may have known them
• IT passwords written down very carefully
  • Written down places known only to IT staff and their management
  • Copy of set to boss of IT staff so just in case we get killed or out of commission by surprise, the next person in our shous can be provided with the keys to the 400 kingdom, as opposed to no one able to crack security, if we were doing a real good job with it
    • Perhaps copy of this in an envelope provided to company attorney for access in case of change of corporate ownership, or if subpoena by law enforcement authorities
  • Use a coding system for written down passwords such that if anyone gets at where we have them written down, the passwords are not immediately obvious. The Password Write Down Systems must be able to be clearly communicated to co-workers, hopefully them never written down, but remind people not to put the conversion coding system the same place as that which is to be converted.
    • Let's not be too obtuse. IBM recently visited where Al Mac works and needed into System Tools not touched in years. It took several tries to get the right password out of Al's written down but disguised security info.
• be paranoid when developing reports that look for whatever could possibly be going wrong
• periodically re-read security documentation to seee if we've overlooked anything
• there is add-on stuff to enhance BPCS security and its management, also for general 400 security

[_pw9_]

nvnv